Network safety and depots

Topic: Network safety and depots (Read 3205 times) previous topic - next topic

Network safety and depots

March 04, 2010, 11:26:02 am

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!

Re: Network safety and depots

Reply #1 – March 04, 2010, 11:36:57 am

Quote from: jamespetts – on March 04, 2010, 11:26:02 am

A "call_convoy_tool", perhaps?

There is already something like that in the code:

Code: [Select]

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

Code: [Select]

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.

Re: Network safety and depots

Reply #2 – March 04, 2010, 12:50:50 pm

Quote from: Dwachs – on March 04, 2010, 11:36:57 am

There is already something like that in the code:
Code: [Select]
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
Code: [Select]
bool wkz_change_convoi_t::init( karte_t *welt, spieler_t *sp )

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.

Quote

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.

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?

Re: Network safety and depots

Reply #3 – March 04, 2010, 04:33:06 pm

No they certainly cannot interconnect. But with such a feature, they can at least print a decent error message.

Re: Network safety and depots

Reply #4 – March 04, 2010, 07:13:51 pm

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?

Re: Network safety and depots

Reply #5 – March 05, 2010, 01:10:34 pm

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.

Re: Network safety and depots

Reply #6 – March 05, 2010, 03:14:30 pm

Is the advantage of using particular letters that it avoids future clashes when merging in code from Simutrans-Standard?

Re: Network safety and depots

Reply #7 – March 05, 2010, 04:23:09 pm

yes, if you use fixed and documented letters, these letters can be avoided in trunk.