[Serana]

Hello,

I've had to many multiplayer games ruined because the server crashed because of a render or sound process crash.
So, for me, the server must be separated from the client.


I would like to design this modification with you.

Let's start with the requirements :
- The server, the dispatcher GUI and RunActivity must be in different processes (not threads).
- The server application should only show a log of all of the actions occurring on the server (connections, errors, etc.)
- In the RunActivity application, it should be possible to join a multiplayer server after the game is loaded.
- In order to have a good fluidity in the movements of trains, the position reports and the state of the train (that can affect graphics and sound) should be sent from the clients to the server every 50 ms (default value used in the IVAO multiplayer client for Flight Simulator).
- Signalling updates should be calculated and sent every 500 ms (usual cycle time for track side signalling systems).
- The dispatcher GUI must be more accurate than the current one (maybe we should use the TrackViewer view for this)

Don't hesitate to comment these requirements or propose new requirements.

Once these requirements are approved, I will start to design the architecture and the functions.

[James Ross]

In case you're not already aware, I'm pulling the simulator and viewer apart as soon as I can, which may make this work easier. It might also be worth asking JTang, who I believe has a standalone server already, whether that could serve as a basis or inspiration or not.

As for these proposals, they sound pretty good. Ideally, the dispatcher would actually just be another client to the server (running a 2D viewer instead of a 3D viewer). I'm not sure being able to join multiplayer after the game is loaded should be included here, though with the right code restructuring it may be easy to implement.

[Csantucci]

I always hesitate when I see that there are ideas to change features that - more or less - work and are used with satisfaction.
If there are crashes (yes, there are) the other approach is to remove bugs instead of rewriting everything.
Some preliminary comments:
- what is done should still be compatible with Jtang's Tsimserver, that is commonly used - at least in my country - to host the multiplayer sessions; I also think looking for Jtang's advice is important
- it should be still possible to act as dispatcher and at the same moment to be a player and to have a look - on the main OR window - at a specific point of the route or to follow a train (but I believe to understand this is possible in your idea); this should be possible without higher overheads than today's ones; also, the dispatcher window is commonly used also in single player
- I don't get the advantage in joining the MP session after OR is already running (that is when the main window already shows the world)
- reducing update time is quite desirable, especially when the trains of two or more players meet or even more run on parallel tracks; however for sure there are bandwidth limits here; in the first period when MP came out, update time was configurable via an OR option. I still think having this configurable is the best solution. This of course could be done also with today's architecture.

And anyhow: please no single feature less with this new architecture, if it is decided to proceed.

[Serana]

Csantucci, on 14 October 2015 - 11:11 AM, said:

I always hesitate when I see that there are ideas to change features that - more or less - work and are used with satisfaction.

Due to these crashes, it is not satisfactory at all in the community I come from.

Csantucci, on 14 October 2015 - 11:11 AM, said:

If there are crashes (yes, there are) the other approach is to remove bugs instead of rewriting everything.

There will always be crashes. Separating the server minimize the impact of a crash... that has nothing to do with the server.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- what is done should still be compatible with Jtang's Tsimserver, that is commonly used - at least in my country - to host the multiplayer sessions; I also think looking for Jtang's advice is important

I think the Tsimserver (and the OR server) is just broadcasting messages coming from each client. The new server will probably store the main states of the trains.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- it should be still possible to act as dispatcher and at the same moment to be a player and to have a look - on the main OR window - at a specific point of the route or to follow a train (but I believe to understand this is possible in your idea); this should be possible without higher overheads than today's ones; also, the dispatcher window is commonly used also in single player

I think we can probably have 3 modes : 3D only, dispatcher only, 3D + dispatcher

Csantucci, on 14 October 2015 - 11:11 AM, said:

- I don't get the advantage in joining the MP session after OR is already running (that is when the main window already shows the world)

It's simple : if the server crashes, you can reconnect without restarting the simulation.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- reducing update time is quite desirable, especially when the trains of two or more players meet or even more run on parallel tracks; however for sure there are bandwidth limits here; in the first period when MP came out, update time was configurable via an OR option. I still think having this configurable is the best solution. This of course could be done also with today's architecture.

The numbers I wrote were wrong.
On IVAO, the server/client communication is, by default, at a frequency of 0,2 Hz (5 s). For formation flights, the clients connect themselves to each other (P2P) and send messages at a higher frequency (by default, 10 Hz (100 ms)). That's a lot more acceptable.

[JTang]

It is currently impossible as James has said, until we have the viewer and simulator completely separated.

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

Even with crashes, using public servers will not be a big concern as the server will declare a new dispatcher. You just need to get reconnected and ask the declared dispatcher to assign you as an aider and gain full control back.

I could not see the need to have very high frequency of update, as trains move slowly.

[disc]

JTang, on 15 October 2015 - 03:52 AM, said:

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

The problem is, that try catch has some performance toll.

Lower update frequency looks nice, however it seems that the game needs an update locked to fps for those things that need frequent updates, and a slower update for others.

[Serana]

JTang, on 15 October 2015 - 03:52 AM, said:

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

Those crashes are provoked by a hang of the Render or Sound process. And a try/catch block can't do anything with this.
It has been repeatable on all of the players' computers.

[James Ross]

Serana, on 15 October 2015 - 05:06 AM, said:

Those crashes are provoked by a hang of the Render or Sound process. And a try/catch block can't do anything with this.
It has been repeatable on all of the players' computers.

If you have repeatable crashes or hangs, have they been reported anywhere? I agree with the separation (and with not adding try/catch) but just want to check we're also fixing the underlying issues that have been found.

[Serana]

Never found where these hangs came from. Each time there was a hang, the program wasn't executed in debug mode and the log didn't have any relevant information.

That's why it was never reported.

[James Ross]

Serana, on 15 October 2015 - 05:28 AM, said:

Never found where these hangs came from. Each time there was a hang, the program wasn't executed in debug mode and the log didn't have any relevant information.

That's why it was never reported.

If it's hanging, after 10 seconds or so it'll "crash" itself and the log should contain stack traces that are generally useful. Does it not do any of this?

[Serana]

I remember that there is indeed a "process was hung" exception in the log.

I have to do another multiplayer game in order to have the details.

[roeter]

Serana, on 12 October 2015 - 05:14 PM, said:

- Signalling updates should be calculated and sent every 500 ms (usual cycle time for track side signalling systems).

This number is fairly meaningless. "Usual cycle time" only applies to (a particular type of) solid state equipment. But many (if not most) OR/MSTS routes pre-date solid state signalling. Relais did, ofcourse, not have an update cycle time, and never mind mechanical (manual) signalling.
If it's reduction of data you are after, a small change can make the present system far more efficient.
Presently, all switch and signal data is distributed at a fixed interval. This can easily be changed to an on-change distribution. That will lead to an enormous reduction in transferred data. To safeguard system integrety, a low-frequent full update could be included (in portions so as to spread the load), but that can be send at a much lower frequence than every 0.5 second.

Quote

- The dispatcher GUI must be more accurate than the current one (maybe we should use the TrackViewer view for this)

That could be done, but would require a completely new interface to the TrackViewer to send the signal and switch commands.
The present very inaccurate display of the Dispatch Window is due to a basic programming error. The position calculation uses some very large numbers (the overall tile position) and some small numbers (the position within the tile). The sequence of the calculation is wrong and leads to significant loss of accuracy, which leads to the awfull display.
Quite some time ago I did an update of all those calculations which lead to a significant improvement of the display, but because other changes overlapped my work I never could commit those changes and have since lost that code.

More important though, neither the present Dispatch Viewer nor the Track Viewer can actually show the proper track state. Both are based on the track sections as defined in the .tdb, and not on the Track Circuits as used in the signalling. The present 'track occupied' state (the red line ahead of a train) is just a bit silly - it simply predicts the position over a certain time, using the switch states as they are set, but disregards the actual train route, signal state, sections claimed or reserved by other trains and even other stationary trains in the train's path. It also suddenly disappears if a train stops, as if a stopped train cannot have track cleared. It also does not show the occupied state behind the train. Perhaps it's usefull in multiplayer mode as that's a free for all anyway as everyone is running in explorer mode, but it is useless in single player mode when running an activity or timetable - there is no link between that red line and the actual sections cleared for that train.

To have a proper Dispatch viewer showing the 'real' track states it should be based on the Track Circuits as used within the signalling. That leads to two important complications. First, such a window can only be build and controlled from within the signalling, as the TrackCircuits are only defined during program initialization and do not exist in a database. The second restriction is that such a window can only be linked to the server as only the server has the correct states. Unless, ofcourse, this data will also be distributed, but that is not the case at the moment.

Another serious problem with the present Dispatch window is the way the signal control is handled, which is little short of absurd. Changing a signal to clear is simply done by setting the signal state. The required route is not checked through the normal signal logic and, even worse, when cleared the route is not protected through the signal logic either. This means you can clear a signal for a path through a junction, and then just clear another signal through that same junction on a conflicting path.
See the attached picture which has three signals cleared for conflicting moves over a junction. Even mechanical systems in the 19th century could do better than that.


So, in all, to get to a real proper Dispatch function, a lot of work will need to be done. Without that, there is no need to do much work at all, for the present function can never be considered as a proper dispatch function and is little more than a bit of a toy on the side.

Regards,
Rob Roeterdink

[BasilP]

James Ross, on 14 October 2015 - 10:42 AM, said:

In case you're not already aware, I'm pulling the simulator and viewer apart as soon as I can, which may make this work easier. It might also be worth asking JTang, who I believe has a standalone server already, whether that could serve as a basis or inspiration or not.

As for these proposals, they sound pretty good. Ideally, the dispatcher would actually just be another client to the server (running a 2D viewer instead of a 3D viewer). I'm not sure being able to join multiplayer after the game is loaded should be included here, though with the right code restructuring it may be easy to implement.

I wonder if this might create another opportunity for OR. Remember the old Train Dispatcher program? Could it be possible to have a viewer that could would be a dispatcher screen instead of the usual view of the train? This is basically done in the dispatch view of ctrl+9. Instead of a map of the tracks it would be a dispatcher's screen and the player would be able to control the signaling and the paths. A player could dispatch an activity or a timetable. Perhaps even an optional view of the ctrl+9 screen to display a dispatchers screen instead of the regular map view.

The old TD game was fun but I cannot get it to run on my current machine and it is no longer supported.

It probably sounds easier than it would actually be to develop.

Thanks
Basil

[ATW]

I say all signals on the start of any multi player be all signals set to STOP instead of system control at first or at least all absolute signals at junctions set to STOP.

[James Ross]

roeter, on 15 October 2015 - 09:47 AM, said:

The second restriction is that such a window can only be linked to the server as only the server has the correct states. Unless, ofcourse, this data will also be distributed, but that is not the case at the moment.

If we need to include that data in the network protocol, I'm sure we can, and depending on setup it may well be that different clients (3D viewer, dispatcher, tower, whatever) can "opt in" to what data it is sent to them. :)