OpenTTD Sharing Memory With Another Process

[SMurf]

Hello,

I have tried to give up this game a few times, but it is pretty much the digital equivalent of crack.

Anyway, I wonder how practical it would be to change the structure of OpenTTD so that rather than rendering the graphics itself, it passes information and updates about core structures (the map, players, etc.) to another process (via a pipe, domain socket or shared memory section, I suppose) so that the other process has carte blanche on what to do with the info (it could render it itself, or log stats in a database, or provide a game summary on a web page, the uses are endless...).

Presumably when it runs as a dedicated server it pretty much does this with a socket, doesn't it? I'm just not sure whether it spits out enough info to render the game as is, or if it's reliant on game logic being executed on the receiving end as well.

[planetmaker]

You may want to search this forum for the threads which discuss multi-threading of OpenTTD.

In short: the game state and progression are linked a lot. Drawing without knowledge of the complete game state is hardly possible.

[SMurf]

Hmmm, OK, I would like to abstract myself away from the main codebase (which is... quite complicated) and perform some graphical experiments on the output.

I'm just having a look at /src/network/core/tcp_game.h. In theory, if I could create a program that pretends to be an OpenTTD client (sends all the right packets, etc.) then I can get a copy of the current map and company stats, although actively "following" progress may be trickier.

Still, I have a way forward.

[Eddi]

you probably want to take a look at the "admin port". you can run a GameScript that listens on that port and can output stats and stuff through json objects.

it is not possible for you to immitate an openttd client without running the actual game.

[SMurf]

O rly?

{insert owl image here}

I did actually hack together a little something last night that basically joins a server as a spectator, downloads and decompresses the map and keeps the PACKET_CLIENT_ACK responses to PACKET_SERVER_FRAME coming. Other than that it dumps anything else that it receives to a file.

Alas, the admin interface doesn't provide access to the current map, which I really need for a graphical description of what's going on in the game.

[Eddi]

well, sure, but at the very least you need to decode the savegame, which means you need to either rely on that part of the game code, or you constantly need to adapt your code to newer server versions.

the Admin Port/GameScript combination would be more future proof. The Admin Port itself does not have the ability to query the map, but the GameScript does, so you can use the GameScript to translate your server queries