The idea is to provide
1) a way to set certain attributes such as the player's team to be used when joining the server, and
2) be able to pass user data which can be received by scripts.
These small additions would be extremely useful for gathers.
Example URLs:
soldat://host:port?password=123&team=alpha&data=userdatasoldat://host:port?password=123&team=alpha&myvalue=1&myothervalue=2Certain hardcoded, optional values such as 'team' will be interpreted by the game, others are simply forwarded to scripts:
Player.GetJoinParameter('team') -> 'alpha'
Player.GetJoinParameter('myothervalue') -> 2
Player.HaveJoinParameter('myvalue') -> TrueLegacy URLs can still be supported by checking whether the character after the port is a slash or a question mark.
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.
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;
This suggestion was created in collaboration between myself, Mr, and evh0.
