[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. :)

[Csantucci]

As of now such data aren't needed for the client players, because signal state is defined by the server and is transmitted to the clients. And signal states and switch states are enough for the clients to run trains.

[roeter]

Csantucci, on 15 October 2015 - 12:16 PM, said:

As of now such data aren't needed for the client players, because signal state is defined by the server and is transmitted to the clients. And signal states and switch states are enough for the clients to run trains.

True if you only want to run a train. But I was talking about the dispatch window. The point above was clearly that it should be possible to run the dispatcher window from a client. But if you want to use the dispatch window as a client, you will need the proper data to do so, and that data is presently only available on the server.

Regards,
Rob Roeterdink

[roeter]

Sometimes, a PC holds even more old rubbish than one had imagined, but even more rare, that rubbish suddenly has some use.
A bit of a search through some old directories brought to light an old zip-file which, surprisingly, contained the updated version of the dispatch window I mentioned above.
Here's two pictures of the same location : the first is the present dispatcher window, the second is my patched version.




But, as I said, when I completed the patch the code had been changed by others such that my patch was invalidated. The calculations had changed and even the methods which contained these calculations had been changed such that I could not even find anymore the lines of code which needed changing. But it shows it can be done. So perhaps someone can take the time and have a look at these position calculations and sort this out once and for all.

Regards,
Rob Roeterdink

[SteveSSW819]

Me, I kind of like the idea of players being able to join any time they want after the session has started. This can be a good tool for Simulated Railroads. I also would like to see some how the server running with out a graphics card. Something I can run on a Windows Server 2008, or 2012 remote desktop servers I have.