PACKET_CLIENT_GETMAP troubles: Revision of stable release

[Kiporshnikov]

Hi there! I'm currently working on a project in C++ which involves my program acting like a client in order to gain more control than the current scripts allow.

The idea is that the program will log in with rcon and perform actions from there.

Anywho, I've run into a problem with sending PACKET_CLIENT_GETMAP, I can't seem to figure out what I'm supposed to put as the unsigned integer that I send along with it.

I've looked through the source and found this piece of code, but without knowing the revision of the release build, I'm stumped.

Code: Select all

/**
 * The NewGRF revision of OTTD:
 * bits  meaning.
 * 28-31 major version
 * 24-27 minor version
 * 20-23 build
 *    19 1 if it is a release, 0 if it is not.
 *  0-18 revision number; 0 for releases and when the revision is unknown.
 *
 * The 19th bit is there so the development/betas/alpha, etc. leading to a
 * final release will always have a lower version number than the released
 * version, thus making comparisions on specific revisions easy.
 */

...

(1 << 28 | 2 << 24 | 0 << 20 | 0 << 19 | (22280 & ((1 << 19) - 1)) )

How do I make a 1.1.0 dedicated server accept me? I just want to be loved!

[Eddi]

for the NewGRF-Version, release builds get bit 19 set, and the revision is treated as 0, so for 1.1.0 it will be 0x11080000.

but i seriously doubt that your approach is the right way. if you need more access, the admin-port is what you need to use/extend.

[Kiporshnikov]

Can't believe I completely missed that.

[dihedral]

You might want to have a look at the admin network port - OpenTTD has a special network protocol for other apps to connect and get information pushed and run certain tasks (e.g. rcon, chat, etc)
it would be quite nice to see another library which connects to this network port (default port 3977) next to the existing java library

the admin network does not require you to download the map - you merely identify with your join packet sending a password along with the name and version of your bot. you can then further request the server to send updates e.g. for chat, client activity (join, part, error, nick changes) - the server will then send update packets as soon as something happens regarding your update requests and update frequencies

this is a nicer approach than pretending your bot is a client and also pops up in the client list in the game.

[Kiporshnikov]

You might want to have a look at the admin network port - OpenTTD has a special network protocol for other apps to connect and get information pushed and run certain tasks (e.g. rcon, chat, etc)
it would be quite nice to see another library which connects to this network port (default port 3977) next to the existing java library

the admin network does not require you to download the map - you merely identify with your join packet sending a password along with the name and version of your bot. you can then further request the server to send updates e.g. for chat, client activity (join, part, error, nick changes) - the server will then send update packets as soon as something happens regarding your update requests and update frequencies

this is a nicer approach than pretending your bot is a client and also pops up in the client list in the game.

Yeah, I switched to using that when Eddi pointed it out, although now I've switched lanes entirely, and am now compiling the program as part of OpenTTD instead, as it gives me much greater control over the server.

[planetmaker]

You might want to have a look at the admin network port - OpenTTD has a special network protocol for other apps to connect and get information pushed and run certain tasks (e.g. rcon, chat, etc)
it would be quite nice to see another library which connects to this network port (default port 3977) next to the existing java library

the admin network does not require you to download the map - you merely identify with your join packet sending a password along with the name and version of your bot. you can then further request the server to send updates e.g. for chat, client activity (join, part, error, nick changes) - the server will then send update packets as soon as something happens regarding your update requests and update frequencies

this is a nicer approach than pretending your bot is a client and also pops up in the client list in the game.

Yeah, I switched to using that when Eddi pointed it out, although now I've switched lanes entirely, and am now compiling the program as part of OpenTTD instead, as it gives me much greater control over the server.

A pity. And it seems you're re-inventing the wheel. As dihedral pointed out correctly, the admin port has been created exactly for this very purpose. Modifying the OpenTTD code now itself is most probably a dead end road while you could seriously contribute to the project on both sides of the admin interface:
a) providing a sound control programme which connects to the port, making use of the admin interface and its capabilities. Making really use of this should have priority. Did you actually check out its capabilities?
b) possibly extending further parts and actions to access via the admin port. This could also go in the direction of allowing some sort of scenario control or similar things like they're offered by goal servers like checking for services of certain towns, (more?) company stats, ...