[APK-LVDZ]

http://www.imghost.in/img/2015-06/24/mohjzyr5x8m5wk6ef85gykxbq.png

Hello! I will talk about our multiplayer session in OpenRails simulator, and then i will ask for many questions. I write to you from Latvia, but we are in russian forum http://trainsim.ru/f...isplay.php?f=56
Here we perform multiplayer session with a few members. You can try it with us, because we don't needed microphones. We have a Team Speak RC2 (download, author web), that contain a chat.
Now we translated our signal system lights. We invite you to our multiplayers!

Notes:
1. We use OpenRails 1370 RC3, because in last versions in multiplayer mode signal scripts not work properly.
2. You need to install the Microsoft Train Simulator (MSTS), XTrack 3.20 and NewRoads 4.0
3. You need to use any trains, which are only in installers on oficial portals.
4. You need to download our "budget train pack" for scenario. (trains, sounds, cabs, can use this consists)
5. You need to download routes: Savelovo, Malahitovka, Demitrov, Zilupe, SoobelRoute, Lesnogorsk.
6. For OpenRails lauching need Microsoft Net Framework (after Windows 7 not needed), need Microsoft XNA Framework
7. For playing you will need to get registration on our forum. Then you will need to write a request in this topics (can in English). Attention! You can not use any links and pictures in your post until you will have 5 messages (antispam system).
8. The all questions about multiplayers you can write to me.


==============
Questions to OpenRails developers, for multiplayer upgrading, if you will wants:

1. We wants to use the latest OpenRails versions, but we need to signal working only by sigscr.dat scripts, not watch to aspects names, because in MSTS this not used. We have a 1000 locos with our signal systems... Can anyone help to me?
2. We want to translate your Open Rails to russian and latvian language. How can we do this?
3. Why all the traffic lights in the multiplayer mode are red before junctions? How can I repare this? Can you create the fully MSTS-signals scripting support in multiplayer mode, because not good, if Open Rails not read scripts, and work as he wants?
4. 3. Is there a function or an array, which can be used to change or receive the traffic light reading for his ID? Can You make this? We want to write the dispatcher window specially to our routes.

http://www.imghost.in/thumbs/2016-01/24/wzma379jx7gs5mim312bj078o.png

[Serana]

Hello,

Translation is available only for versions above X2020.

Translating is a bit difficult for the first time if you don't have a manual. I don't think we wrote one.

[Csantucci]

There is a localization manual within the standard OR documentation pack. It is called "Localization Manual".
About signals, it's a more complicated story. Since what version OR you had no more correct signal indications?

[APK-LVDZ]

About translating - thanks!
About signal (for our need multiplayer mode only):
1. In line without any junctions signals work normally.
2. Before any junction signals are red (sigscr.dat is right). That not poor, but in this situation is needed function, which open signal by scripts (to one session end), no OpenRails interfere (only sigscr.dat working). Or need to working any signals by scripts by default, and can be closed manually. Can be manual box in options for enabling or disabling "only sigscr.dat instructions".
3. When i pick to signal, and then choose any function (STOP, APPROACH, PROCEED), this signal did not returned by default state (red, or by sigscr.dat scripts). Any dispatcher can forget the opened signal (in multiplaer can be >15 drivers). Very good can be automatically return to previous state after train has proceeded this signal (previous state - by scripts or closed).

About signal array or function - we needed to any function, which can change signal aspects to any head of signal by ID number from TDB file. Also otherwise - to get state of signal head with ID number from TDB file. That can be array, or function. This is necessary for dispatcher window code writing for special our routes, not universal, only technical preview.

[Jovet]

 APK-LVDZ, on 25 May 2016 - 01:39 PM, said:

About signal (for our need multiplayer mode only):
1. In line without any junctions signals work normally.
2. Before any junction signals are red (sigscr.dat is right). That not poor, but in this situation is needed function, which open signal by scripts (to one session end), no OpenRails interfere (only sigscr.dat working). Or need to working any signals by scripts by default, and can be closed manually. Can be manual box in options for enabling or disabling "only sigscr.dat instructions".
3. When i pick to signal, and then choose any function (STOP, APPROACH, PROCEED), this signal did not returned by default state (red, or by sigscr.dat scripts). Any dispatcher can forget the opened signal (in multiplaer can be >15 drivers). Very good can be automatically return to previous state after train has proceeded this signal (previous state - by scripts or closed).

About signal array or function - we needed to any function, which can change signal aspects to any head of signal by ID number from TDB file. Also otherwise - to get state of signal head with ID number from TDB file. That can be array, or function. This is necessary for dispatcher window code writing for special our routes, not universal, only technical preview.

So what you are saying is that Open Rails is not currently flexible enough with regards to enabling signals (to be better than Stop) around junctions in multi-player scenarios? You would like a mode where the human Dispatcher can explicitly Enable or Disable any junction signal? And a signal, so Enabled, automatically becomes Disabled when a train passes it?

[Csantucci]

Hi APK,
referring to your first point: at the moment sigscr.dat is executed at the server's site and then signal aspects are sent to the clients. It's so and I think it should remain so. The logic is made only at one place and the outcomes are sent around. If the logic were done in parallel at all clients, contradictory results could come out.
Re point 3 probably this can probably be done; however if it is not enough for you to use actual versions of OR, it makes no sense developing it.
Anyhow I'm sorry, but I don't understand why you can't work with signal aspects sent to the clients. That's the signal aspect the train must respect.

[APK-LVDZ]

 jovet, on 26 May 2016 - 03:59 AM, said:

So what you are saying is that Open Rails is not currently flexible enough with regards to enabling signals (to be better than Stop) around junctions in multi-player scenarios? You would like a mode where the human Dispatcher can explicitly Enable or Disable any junction signal? And a signal, so Enabled, automatically becomes Disabled when a train passes it?

STOP is a signal aspect. Some signals cannot show it by scripts. Problem - this STOP aspect applyed to all heads in one signal, but some times needed, for example, one head = STOP, other head = RESTRICTING, because from this changed next_sig_lr functions result. Other problem with all closed signals - dispatcher need to open the all signals before junctions manually, and this not control the junction states, may be mach errors. The next problem - dispatcher need to watch planned route. If signal is closed - then is error in patch create (train on track or wrong junction for example). If signal is opened, then the track is clear. The dispatcher need to watch this timely.
Will be good, as you said, if all signals will be work by scripts (now worked only without junctions). And may be to add in signal menu new commands "opened by default" or "closed by default" and existing. Closed - the current mode (by default that is now), and if we will choose in Open Rails options (need to add) the "Open signals before junctions by default", then the all signals will be worked by scripts and always will be opened until not watcher train in track, wrong junction or dispatcher command in signal "closed by default". That is my idea. Signal are worked in single player, because i ask for help. We can test all of this, because we have a few peoples, that you was watched in the screenshot.
We ask this to work in two multiplayer modes: cleared and with scenario.

 Csantucci, on 26 May 2016 - 10:25 AM, said:

Hi APK,
referring to your first point: at the moment sigscr.dat is executed at the server's site and then signal aspects are sent to the clients. It's so and I think it should remain so. The logic is made only at one place and the outcomes are sent around. If the logic were done in parallel at all clients, contradictory results could come out.
Re point 3 probably this can probably be done; however if it is not enough for you to use actual versions of OR, it makes no sense developing it.

Yes we know - the server generate signal aspects and send to clients. If client is dispatcher - then also send commands to server for aspects changing. This is correct! This is no problem.
About point 3: if signals in multiplayer mode will be closed automatically after train proceeding, this can help, but only in shunting operations. The signal sysem was wroted for working by default (MSTS), but the shunting operations are denied by default. If shunting operation is needed, then dispatcher open by APPROACH or PROCEED function the special signals, which can open any shunting signals. Then, train go by shunting signals and proceed the last opened signal (which was opened by dispatcher), and need to close this signal. I ask to help to create a new option "reset the APPROACH or PROCEED functions after train proceed". This will helps to multiplayers and will help to save your created signal working (It will be universal).
We ask this to work in two multiplayer modes: cleared and with scenario.

https://youtu.be/AFnKU2CQGJk

Quote

Anyhow I'm sorry, but I don't understand why you can't work with signal aspects sent to the clients. That's the signal aspect the train must respect.

Because need for right signal lights. And our signal system contain more than 8 aspects, or used combinations. Some signals are not coded to cab signal, and driver watch to signals in the route. For example - NORMAL = always RESTRICTING (not coded line), DISTANCE - CLEAR_1 (green). With menu this can not be release. From first need to signal working by scripts, and the we will writes a new dispatcher window, example:
http://www.imghost.in/thumbs/2016-05/27/rz705t9iri2bh1m83is6lahfj.png
But this if for some routes or distances. The full control is needed in Open Rails.

[Jovet]

 APK-LVDZ, on 26 May 2016 - 03:41 PM, said:

STOP is a signal aspect. Some signals cannot show it by scripts. Problem - this STOP aspect applyed to all heads in one signal, but some times needed, for example, one head = STOP, other head = RESTRICTING, because from this changed next_sig_lr functions result. Other problem with all closed signals - dispatcher need to open the all signals before junctions manually, and this not control the junction states, may be mach errors. The next problem - dispatcher need to watch planned route. If signal is closed - then is error in patch create (train on track or wrong junction for example). If signal is opened, then the track is clear. The dispatcher need to watch this timely.
Will be good, as you said, if all signals will be work by scripts (now worked only without junctions). And may be to add in signal menu new commands "opened by default" or "closed by default" and existing. Closed - the current mode (by default that is now), and if we will choose in Open Rails options (need to add) the "Open signals before junctions by default", then the all signals will be worked by scripts and always will be opened until not watcher train in track, wrong junction or dispatcher command in signal "closed by default". That is my idea. Signal are worked in single player, because i ask for help. We can test all of this, because we have a few peoples, that you was watched in the screenshot.
We ask this to work in two multiplayer modes: cleared and with scenario.

I must admit I'm being baffled by a language barrier here. I cannot really understand what you are requesting or asking for. I was trying to ask generalities with regards to your request, hoping that would be easier to get your point across. All I can gather is that you want all signals around junctions to be "enabled" by default unless a human dispatcher disables each one.

One issue I may see is if you have main signals and shunting signals as separate shapes, the shunting signal cannot overrule the main signal. They must be the same .s file and track signal marker, even if they are separate signals, so that the shunting signal (signal head) is capable of overriding the main signal (head).

[APK-LVDZ]

Sorry my English. Some words i translate with Google translate. I write about multiplayer mode only.

1. We need to the fully worked signal only by scripts (no closed signal by ORTS, only trains and junctions can close signal with "block_state" functions). Now the all signals are closed before junctions. Dispatcher cannot work with them, and cannot check trains routes.

2. Needs to return the default signal state by scripts for any manually opened signals, if train has proceeded this signal. For example - i open signal by "approach", train proceed - signal are returnet to "system controlled" (now the signal continue in "approach" state).

I wrote about universal solution, because you need to save your signal working (as it is), but this not worked in our routes. I offer to create the new option in ORTS start menu, that named "Open signals before junctions by default", "return signal in 'system controlled' after train proceeding" to save your and join our request. You will can use the now created system, and we will can use our system. This will be universal.

[Csantucci]

APK, can you make a graphic that describes your problem number 1 (maybe using screenshots of the dispatcher window)? Does the problem occur also in single player mode?