0000367: Provide more elaborate soldat:// URLs

Notes
(0001813) DorkeyDear (reporter) 2013-08-02 16:57	If two unrelated scripts are on the same server, and both interpret a specific key=>value setup, issues could arise if the data was only intended for one script. Due to the this unlikely case, requiring multiple scripts on the same server that use the same key=>value pair (or similar) resulting in undesired results, it seems to me a very unlikely case but still notable. With this in mind, Note that this proposed feature's use will probably be rare and used only in a small number of scripts, and the risk of this issue is minimal. I don't believe any precautions or actions should be taken to prevent this issue, unless a very simple, easy, and clean solution is possible. One possible solution is to have a dedicated key value of `script` used to specify which script will receive the data. This may leave out the option of allowing multiple scripts to receive the data, unless multiple of the same key is possible or the key `script`'s value is delimited with many scripts listed. Also this leaves out the option of allowing all scripts except specified scripts to receive the data; this could resolved by a new key such as `noscript` specifying which script should not receive the data, with similar solution for listing multiple scripts.

(0001814) DorkeyDear (reporter) 2013-08-02 17:16	I can see use cases for using this information in the event OnRequestGame (Game.OnRequest in SC3). It would be possible to allow or deny a person from joining (or have some other effect) based on the data before the player joins the server. An example use case would be a password on a per-person basis. In a gather, to prevent unwanted people from joining (if spectators are not allowed) and to identify the IRC name with in-game name, a unique identifier could be sent to each player such as soldat://host:port?uniqeid=1aFg [^] . In the script, OnRequestGame would check if this uniqueid matches any from a list. If there is a match, the player would be allowed to join, and be automatically forced to the correct team; if there is not a match, the player would not join and could receive the `Wrong password` request error message. A proposed event change for SC3 to allow for this: function OnRequestHandler(Ip: string; Port: Word; State: Byte; Forwarded: Boolean; Password: string; Query: array of array[1..2] of string): Integer; Query would contain an array of key => value pairs, each represented by a static-length array of length 2. Another option is to pass in the unparsed query: function OnRequestHandler(Ip: string; Port: Word; State: Byte; Forwarded: Boolean; Password: string; Query: string): Integer; If custom types are allowed, a dictionary type could be made and passed: type KeyValuePair = record Key, Value: string; end; Dictionary = array of KeyValuePair; function OnRequestHandler(Ip: string; Port: Word; State: Byte; Forwarded: Boolean; Password: string; Query: Dictionary): Integer;

(0001815) Shoozza (administrator) 2013-08-02 17:31	Please do not post features on the bugtracker. Post features in the Game Improvements / Suggestions section on soldatforums: http://forums.soldat.pl/index.php?board=4.0 [^] Discussions about the features are better on the forums. Once it is clear that we want that feature and know how exactly it should look like (e.g. after collecting feedback from other people) the devs will add the feature to the bugtracker (or tell you to add it). Each feature request needs to include a link to its soldatforums suggestions thread. Features which don't include it will be closed/deleted or modified.

Issue History
Date Modified	Username	Field	Change
2013-08-02 16:31	Mr	New Issue
2013-08-02 16:57	DorkeyDear	Note Added: 0001813
2013-08-02 17:16	DorkeyDear	Note Added: 0001814
2013-08-02 17:31	Shoozza	Note Added: 0001815
2013-08-02 17:31	Shoozza	Status	new => closed
2013-08-02 17:31	Shoozza	Assigned To	=> Shoozza
2013-08-02 17:31	Shoozza	Resolution	open => won't fix

Relationships