[roeter]

eolesen, on 18 December 2013 - 09:25 AM, said:

Thanks, Rob, and yes, I did see that. Not knowing how long it will be for the next phase, it's going to be an ongoing problem for the short term if I update versions, and I won't get the benefit of fixes if I don't update.

Not the end of the world by any means, but still a "damned if I do, damned if I don't" type situation.

Yes, I realise that and I'm sorry for that, but it can't be helped.
Allready I got into trouble with others making changes to parts of the program which were affected by these changes, and there was some trouble sorting out these two sets of changes.
Waiting (much) longer before everything was done would have ended in a enourmess mess, with a great risk that I would have to recode half or more of the changes due to other changes on the same code. And that is all time wasted.
So I had to commit this first stage now in order to stay out of serious trouble.

Regards,
Rob Roeterdink

[edwardk]

Regarding resetting a switch after a signal has cleared it, we must be careful here. If we want OR to exercise real life procedures then we should not change this concept. Besides, Rob is doing such a good job in this area, why confuse him and make this project even more difficult for him. :thumbup3:

Run8 is strictly MP, does anybody know if this is being done?

Edward K.

[Csantucci]

Many theories have their validity, but the important thing is that the final result must be usable.
Due to problems already at startup of MP sessions, and due to the hard limitation that backward paths are not yet managed in the new MP OR versions, our group is still using Rel.1888 (the last one before Rob's reworking) for MP sessions, and I must say that such release together with the last memory management patches is quite reliable and usable.
In parallel I (and maybe another person) will have some personal debug with a server and a client OR instance, to provide to Rob inputs to get as fast as possible a playable and enjoyable MP version. Up to that moment (that is up to getting hands on experience in MP sessions with the new releases) I won't take positions on theories about what should be allowed and what should be forbidden.

As Rob said that my previous test report based on a Bernina test case was too complicated as a first case, I tried a simpler case, see picture below:

I first successfully prepared the station exit path for my client train, and then tried to clear the first signal in the path. The signal remained at stop both in the track monitor as in the dispatch viewer, as can be seen. It was instead possible to clear the second signal, but of course without the first signal cleared the train can't exit the station.

I tested same situation with release 1888, and here is the outcome:


The first signal on the path is in APPROACH_1 state already at game start. The second signal can be cleared, so the train can exit the station.
If Rob needs further info about this case I can provide it.

I foresee to provide further test cases.
I understand that Rob has a big work to do, but nevertheless I hope that this new MP management will become usable in not too long time, else we will have to stick to release 1888 for MP sessions, even if we can't enjoy improvements in other areas of OR.

[roeter]

Which route is that?
I have the route Bernina_Pass, but this location does not seem to be on that route.

Regards,
Rob Roeterdink

[APK-LVDZ]

Very hard route set :(
For multiplayer's junctions enough:
- Main route
- Side route
For signals enough:
- System Controlled - signals will be opened by scripts (always opened)
- Open once - can be, if route until next signal has junctions (for stations).
- Closed - for signal scripts her function block_occupied will be return "true".
Also need to set aspects for shunting operations :(

For path automatic set will be better if dispatcher click in first signal, choose the "Set Path", and then click in the last signal, until path is needed. But all signals in path will be opened by scripts.

We know, work has just begun, and we will wait as much time as needed.

[roeter]

APK-LVDZ, on 20 December 2013 - 03:26 PM, said:

For path automatic set will be better if dispatcher click in first signal, choose the "Set Path", and then click in the last signal, until path is needed. But all signals in path will be opened by scripts.

That's not possible - at least not without some additional definitions.
Signals have no 'knowledge' about the location of next signals, and the required route to that signal.
The method you describe is generally known as "NX" (eNtry eXit control : select entry and exit of required route), and requires, per combination of entry and exit signal, the route (sometimes routes, as there may be alternative paths between the signals) which has to be cleared.
So, an additional database would be required defining these paths.
In the past an attempt has been made to let the program search for such routes, but in complex areas with many switches this simply proved impossible.

As for your list of commands : those are available - just ignore the rest.
But those other commands do offer some very usefull functions, you just need to get to know how to use them. If used properly, they can save the dispatcher a lot of work.

Regards,
Rob Roeterdink

[Csantucci]

roeter, on 20 December 2013 - 02:36 PM, said:

Which route is that?
I have the route Bernina_Pass, but this location does not seem to be on that route.

Regards,
Rob Roeterdink

It's the route Genova-Livorno, that you can download here
http://www.trainsimh...oad.php?did=691
plus this route patch
http://www.trainsimh...=85&rowstart=30

The path that I used for the client is this one
 Massa_ZI_OR.zip (376bytes)
Number of downloads: 367

I will provide at least another test case on this route.

[Csantucci]

Second test case on same route.
I again run two instances of OR, and manage the client train using the server dispatcher window:

this is the situation for the client at startup:

The path stops before the first switch, and track reservation is provided straight away up to the end of the siding.
So I have to switch to side route the double switch above. When I do that, the double switch switches, however I get following pop-up window:

I select "continue", and I get following situation:

The new track reservation leading to the line track is shown, but the old track reservation is still shown in green.
Now I would like to open the first signal on the track reservation path, so that the train exits Wait Dispatcher mode. The first signal on the path is a signal at approach state. However when I try to clear it, it goes to... STOP state and remains there. No way to get it back to another state.
This is the final situation:

The signal that switched to the undesired stop state is the one above the two signals in approach state.

This is the used path:
 Migliarina_OR.zip (380bytes)
Number of downloads: 463

Both cases have been taken from real MP sessions.

[Csantucci]

Third test case with server and client, this time on the Bernina route at Miralago:
this is the initial client situation:

I try to clear (always with the clear once checkbox) the first signal on the path (the one before the trailing switch). It remains red. I try to clear the second signal after the trailing switch. It remains red too, even if both operations provide correct track reservation.
This is the final situation:


This is the path I used:
 OR_Miralago.zip (366bytes)
Number of downloads: 383

By the moment I think it's enough with test cases.

[Guille592]

APK-LVDZ, on 16 December 2013 - 02:01 PM, said:

Very big thanks! :jawdrop2:

I have one suggestion:
- for any aspect dispatcher can use individual color. This will resolve problems with "Orange" for STOP_AND_PROCEED (or others) for russian or any other country signals, and helps to peoples, which cannot watch the changing red and green signal in dispatcher window. Can be make properties of multilayer signal working with all others functions. For example, for using colors: Red, Green, Yellow, Orange, Blue, Gray, or all RGB colors.

We all thank You :rofl:
http://www.imghost.in/thumbs/2013-10/06/fgxm2y4lply2w5erflpmykeyh.jpg

Didn't saw your message but thinking the same here, I think it would be more usefull if we had colours. Cause I still didn't understood the new signalling system wich I think it's really awesome but the old one (Stop, approach, proceed) was very simple and very effective. It is well known that we have several signal systems all around the world, but adding colours to the dispatcher, to my personal oppinion, it would just nail it. If not possible, I would make the menu to look like the image below. This, would be for a manual mode just in case we couldn't control the automatic one. This manual menu, would follow the script we can actually find in the signals as is shown on the "sigcfg.dat" & "sigcfg.dat" files.

;)

Attached thumbnail(s)

•