Xaphan said:
I'm not sure what I am doing wrong, is there a way to get the player ID using the unique ID from the database? would be be like (get_agent_id, ":agent_id", ":unique_id"), than (agent_get_player_id, ":player_id", ":agent_id"), ? because for some reason receiving the player_id and assigning it from the url response is not working.
No, because a particular player id and unique id are only linked for a play session while the client stays connected to the server: storing a player id in an external database makes no sense, because the numbers are reused for other players (unique ids) when disconnected, reconnected, or the server is restarted.
Xaphan said:
I will quote my reply from earlier in this thread about why distinguishing different url response types by integer count and string count is a non-standard and bad idea:
Vornne said:
I discourage the practice of distinguishing web server replies by the number of parameters, i.e. the (eq, ":integer_count", 2), (eq, ":string_count", 1) added in the first else_try block of script game_receive_url_response. It has somehow become popular with people writing simple guides for web servers with Warband, but it is a bad idea: no other message types can then use 2 integers and 1 string, having to add useless extra parameters to avoid conflicting, confusing anyone trying to merge different features that use a web server. You have a "status" value in reg0, which is very close to the right idea: it should be a unique "return code" to work in with the official name server and any other web server feature desired, so like the slots in module_constants, people only need to check one place for conflicts when merging code (that all the "return code" / "message type" numbers are unique). I didn't define the return code constants in the module system, because the languages of the module system and web server are different (Python, PHP) making it seemingly impractical to try use the same list; so the return codes are only named in the web server configuration, manually using the same numbers in script game_receive_url_response (you might have a better idea).
To reiterate: use a message type number at the start, like basically every other well designed network message format (strings are a bad choice because the computer only understands them as much longer numbers anyway, and in this case the M&B module system can't compare strings at all - no operations for it). Other examples you might be aware of are things like
HTTP 404 in a web browser (not found) or 503 (service unavailable), etc. This way many different people can transmit many different types of messages over the same system, by just maintaining a global list of numbers corresponding to message types. Similarly to how slots work in the module system: two different mod developers might write code that uses various agent slots, for example, and they happen to use numbers that conflict: all you would need to do to merge the code together is to change some slot numbers in module_constants so all are unique.
The PW name server system is designed in a similar way, though with two places for message ids rather than one, since compilation is done in two different languages (Python and PHP): in pwnameserver/private/config.php, the const members of pw_name_server_config, and in script game_receive_url_response, any (eq, ":return_code",
number) operations. To integrate different web servers written by different developers with the same Warband server, they all just need to follow the convention that the first integer (reg0) is a message type, and it will always be a number chosen to be unique compared to all the other message types used in other code. For example, since the name server code uses -3, -2, -1, 0, 1, 2, 3, 4, you might choose to use message numbers (type / return code / id / whatever you want to call it) from 30 to 40, or 100 to 200, or 4332 to 4387 - you can use whatever numbers tickle your fancy, as long as you make them unique for each kind of message. If you wanted to combine a punishments manager and a random welcome message generator, but the developers of each both decided to use message type / return code 47, you would just change one of them to 57, or something else. If the code was written using named constants like the name server, you would only have to change in one place - the number in the private/config.php file, for example, and all the other code using the named constant (like pw_name_server_config::name_invalid_error) would be automatically updated.
It would be possible to wrap entire groups of messages with unique numbers, as Ra'Jiska suggested, but that is more intrusive and harder to maintain: because you are adding a new number to the front of every format, rather than adjusting a message type number already existing for every message type, merging different web server features would require going through all the module system code and string formatting that composes or reads the message values for each type, incrementing the register numbers used, and making sure you understand all of the code to avoid introducing subtle errors.