A query for the developers working on network mode: I notice that there have been some major changes to the code for handling depots recently (indeed, I have spent a lot of time trying to make it work with Simutrans-Experimental, which is a large part of why the latest release is taking so long).
Simutrans-Experimental has had for quite some time an automated convoy replacement feature, written by Isidoro about a year ago. The recent changes to the code to accommodate networking have broken that feature, and I am working on fixing it (and adding one or two enhancements, including reducing the amount of memory that it uses). However, because I ultimately want Simutrans-Experimental to be network compatible, I need to make sure that the code that I use to fix it is also network compatible, and I should appreciate any guidance in that respect.
Specifically, the changes to the code in respect of depots recently seems to have involved taking the code for performing the actions away from the cl**** depot_frame_t (which would not be instantiated accross the network if one player opened a depot window, as this is just a GUI cl****) to depot_t, which would be an object present on every player's system in a network game. It seems to use werkz_t to communicate the message between the GUI window (depot_frame_t) and the actual depot (depot_t), using a pair of char fields, suggesting that this is the information that is transmitted accross the network. I have extended this architecture for the vehicle upgrading system in Simutrans-Experimental using the new code 'u', and it seems to work - at least in single player mode.
The convoy replacer is a different creature, though, as it is not ****ociated with any particular depot. The system has to save information to one or more convoys, which then automatically tell the depot to replace them whenever they next enter a depot (and optionally immediately send those convoys to a depot). Obviously, the identical technique as with depots cannot be used. There is a method "call_depot_tool" that has the effect of invoking the depot's functions from accross the network; what sort of equivalent might I need for the replacer? A "call_convoy_tool", perhaps?
Any tips/thoughts would be greatly appreciated!
There is already something like that in the code:
void convoi_t::call_convoi_tool( const char function, const char *extra ) const
This should be called from your replacement gui etc.
To perform the actions you have to modify
bool wkz_change_convoi_t::init( karte_t *welt, spieler_t *sp )
And a sidenote:
The different commands are distuingished by one char. May I suggest that you use 'X' in all such tools to identify the Experimental's features? The 'X' can be followed by any other characters to identify sub-features etc. Then there is a chance to implement reactions in trunk to handle commands from "experimental" clients. Also then the 'X' can be reserved and will not be used in later versions of trunk.
Thank you very much for your help - I shall look into doing it that way when I next get a chance to work on the code.
Interesting - are you suggesting a possibility of Simutrans-Experimental clients connecting to Simutrans-Standard servers, or vice versa? I had not hitherto considered that as a possibility, largely due to the substantial differences between the two: goods and p****engers would take different routes, different levels of revenues would be earned, etc., which would make the Experimental clients out of sync with Standard clients. Do you think that these issues are sufficiently surmountable such as to warrant developing a compatibility standard for networking?
No they certainly cannot interconnect. But with such a feature, they can at least print a decent error message.
Prissi,
ought this not be detected earlier, when the client begins to download the current (saved) game from the incompatible server? I recall that you made a suggestion at one point that some text be added to the Simutrans save game identifier - would this not be sufficient both for saved games and network games?
Actually, it would reject probably any game which pak does not met a certain checksum and exact game engine version. But the logic is not there yet. But maybe using capital letters you can avoid that future compatibility issue, if one extension happens to be on the SE letters.
Is the advantage of using particular letters that it avoids future clashes when merging in code from Simutrans-Standard?
yes, if you use fixed and documented letters, these letters can be avoided in trunk.