In T170180#2404740, @Geez wrote:

Hello p4k1tz.
Is there any relevant reason why do you need to know this information?

Hello Geez,

I am building a launcher that will be faster than the vanilla DayZ launcher and one that is not biased like other launchers. The real need here is to not put the burden of having an additional API on the gamservers who want to show up in this launcher (potential avenue of attack), and allow Nitrado or other managed servers to show up in the list (since the owner does not have access to install such an API).

I am willing to accept that this protocol changes and thus I may need to picot in the future, but having an initial understanding or explanation from BI in this case would be useful.

Hello again,

According to the devs:
https://developer.valvesoftware.com/wiki/Server_queries

It's just 1b header + long challenge, then some data if challenge is in incoming message - otherwise 1b header + int16 rules count and list of rules - which is as in steam documentation.

In T170180#2404850, @Geez wrote:

Hello again,

According to the devs:

https://developer.valvesoftware.com/wiki/Server_queries

It's just 1b header + long challenge, then some data if challenge is in incoming message - otherwise 1b header + int16 rules count and list of rules - which is as in steam documentation.

Hey Geez,

Thanks for the response, I will double check the information above and write my own a2s implementation to be sure the data is as expected. From there I will come back with any questions. One question now though if you have the time. What I am interested in is the rule value format, and with that being said, there is no specification from valve on what data is contained within that rule. I believe the data is up to the game developer, and has been truncated by BI to save space. My initial request was to get information on what each byte of the rule value was. Could you maybe run that by the developers to see if they could provide that?

Again, thanks so much for taking time out of your day.

Above is an example response that can be used as a reference. Between offsets 0x0000002E and 0x00000032 should be the steam ID of the mod. But Offset 0x0000002D describes the steam ID length being 4 byes. 2E through 31 are not the correct steam ID, and neither is 2E through 32. I can only assume one of these bytes is a modifier for the steam ID, is corrupt, etc.

Thank you for your consideration.

@Geez Any new information?

unfortunately no new information I can provide at the moment as the devs will have to dig deeper into this.

@Geez Battlemetrics have same problem to decode A2S_RULES correctly in some cases.

@Geez Any new information?

In T170180#2406074, @raxto wrote:

@Geez Battlemetrics have same problem to decode A2S_RULES correctly in some cases.

I believe the protocol used was recently updated which is why others are experiencing this as well. I have resorted to looking at this section at a bit level and found huge similarities with the first couple of bytes and only a single or couple 1's in up to the last 3 bytes. I am assuming that the length of the serial is used in conjunction with a comparison of the bits in each byte after. If certain bits are set, do some math and move on. Possibly a comparison of the absolute max int ID.

@Geez Has this question been passed to anyone for a potential answer?

Hello p4k1tz.
Due to the current priorities with the release and possible hotfix, we cannot address this immediately. I will let you know if there are any new developments.

In T170180#2408842, @Geez wrote:

Hello p4k1tz.
Due to the current priorities with the release and possible hotfix, we cannot address this immediately. I will let you know if there are any new developments.

@Geez how about now?

Hi @p4k1tz
You forgot to replace the escaped sequences with their original value. Regarding to