Elvas Tower: Multiplayer Open Rails - Elvas Tower

Jump to content

  • 5 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Multiplayer Open Rails Questions and sessions Rate Topic: -----

#11 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 30 May 2016 - 02:47 PM

Found some bugs (and not with signal). Signal scripts are right. Problem in ORTS only. I tested 3549 only multiplayer mode. My friend talk - in single mode all ok.

Brakes (no brakes):
https://www.youtube....eature=youtu.be

Junctions are blocked (need to unblock in multiplayer):
https://youtu.be/9CvMkhaUVIY

All red lights before junctions:
https://youtu.be/QnXf5FFt0Ig

=================
All situation with signal in ORTS 3549:
https://youtu.be/Nv9Nz5rgUeM

All situation with signal in ORTS 1370:
https://youtu.be/E-rdZewGFJ8
=================

If you use this dispatcher control, we ask for universal dispatcher window creating with two modes: your and our. In our the all junctions wil be not blocked, and the all signals will be worked only by scripts, no any closing from ORTS code. Thank you!

#12 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 31 May 2016 - 04:00 AM

Junctions blocked: in my opinion if the signal in front of the train is open, it is not so correct that you can move against the train the switch after the signal. You should first close the signal and then move the switch. Does the switch move if you do so?

#13 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 31 May 2016 - 12:25 PM

1) I have tested the above case with a test arrangement in the Marias Pass route: if you first set to red the signal in front of train _Dspp3 (your video "Junctions are blocked") you can then move the switches after such signal. And this is how it should be.

2) Look at this picture taken from your video about signals with release 1370:
Attached Image: Doublegreen.jpg
It is not realistic that both the opposite signals show green. Why do you prefer this?

3) Referring to the fact that in your video "All situation with signal in ORTS 3549" you don't get all green signals: this can be caused by the difference on how MSTS and OR interpret SignalNumClearAhead. Read paragraphs 10.14.1 and 10.14.2 of the manual and try what is suggested there.

4) Referring to your request that a forced signal should automatically return to system controlled when train has passed: I agree with that. I'll check to see if this easily implementable.

5) Referring to the fact that you don't like red signals in front of switches: well, the standard state of signals is red, and not green. It must be green only when a train is allowed to pass and a train is there.

#14 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 31 May 2016 - 02:45 PM

View PostCsantucci, on 31 May 2016 - 04:00 AM, said:

Junctions blocked: in my opinion if the signal in front of the train is open, it is not so correct that you can move against the train the switch after the signal. You should first close the signal and then move the switch. Does the switch move if you do so?


Yes, all right. In live. But if signal will works only by scripts, we will can not change anyone junction position. But junctions blocked only in one block, before this is opened signal. For this idea are necessary the dispatcher signal special control. Not aspects STOP or PROCEED, but "Closed" or "Opened" (by scripts), because many signal can not open with STOP or CLEAR_2 aspects by default. And I were showed the situations with one aspects and with many lights with them.
My idea for this - need to create a new signal options (not delete any old options "system controlled", STOP, APPROACH, PROCEED). "Closed" - a script function "block_state" will returns "block_jn_obstructed" anywhere, if path has junctions. "Opened" - this function will be "System controlled", and junction after this signal will be blocked and signal - opened by script. This is a ideal.


View PostCsantucci, on 31 May 2016 - 12:25 PM, said:

1) I have tested the above case with a test arrangement in the Marias Pass route: if you first set to red the signal in front of train _Dspp3 (your video "Junctions are blocked") you can then move the switches after such signal. And this is how it should be.


We cannot use the strong aspects from menu STOP, APPROACH or PROCEED. We have a many situations with aspect difference. We agree with junction blocking in situation, which I was writed above.


View PostCsantucci, on 31 May 2016 - 12:25 PM, said:

2) Look at this picture taken from your video about signals with release 1370:
Attachment Doublegreen.jpg
It is not realistic that both the opposite signals show green. Why do you prefer this?


We agree. But this we can modify by "opp_sig_lr" functions. I found the solution. In MSTS this work (not used the "enabled" function).
We can tolerate the opposite green signal, because in station other train driver watch the red light, if junction in not for his train. For multiplayer this is basis.

View PostCsantucci, on 31 May 2016 - 12:25 PM, said:

3) Referring to the fact that in your video "All situation with signal in ORTS 3549" you don't get all green signals: this can be caused by the difference on how MSTS and OR interpret SignalNumClearAhead. Read paragraphs 10.14.1 and 10.14.2 of the manual and try what is suggested there.


We cannot use the "STOP" aspect for normal head, and not use "enabled", and on all signal we use the "SignalNumClearAhead ( 10 )" line. I wrote our signal system for 3 simulators - ORTS, MSTS and RTrainSim. The all code need to compiled on all platforms without any changes (for route developers). We ask for ability to signal autoopen and junction unblock, or ability to open and close any signal by first paragraph in this post. The code of signal system is right, but we cannot use your opportunity.


View PostCsantucci, on 31 May 2016 - 12:25 PM, said:

4) Referring to your request that a forced signal should automatically return to system controlled when train has passed: I agree with that. I'll check to see if this easily implementable.


This can be by manual. Some situations need to stay after train proceeding, but many situations need to return in state "system controlled". Can you create the universal signal menu? The all options after pick to signal will be, for example:
0 System controlled
1 Opened by script
2 Closed
3 always STOP
4 always APPROACH
5 always PROCEED
6 STOP
7 APPROACH
8 PROCEED

By default junctions are unblocked. The all signals before junctions are closed ("block_state" returns "block_jn_obstructed" until signal will be opened). The functions 1, 4, 5, 7, 8 will block junctions until next signal with NORMAL head. The functions 2, 3, 6 will unblock junctions until next signal with NORMAL head. The function 1 will open signal by scripts. The functions with prefix "always" (they are: 3, 4, 5) will stay with his aspects after train proceeding until dispatcher change this. The functions 6, 7, 8 will stay until train proceeding, after them will be returned to "system controlled" (0). Can delete function 0, if will works 1, because they are the same.


View PostCsantucci, on 31 May 2016 - 12:25 PM, said:

5) Referring to the fact that you don't like red signals in front of switches: well, the standard state of signals is red, and not green. It must be green only when a train is allowed to pass and a train is there.


In this we watch other problem. The dispatcher see route in big station and cannot to understand the route status, if train is too long away. Need to watch for control - signal is opened or no. But if you will release the our idea from paragraph above, then we and you will get a universal system for all countries. We spend our multiplayers many years, and we can get to you the consultations about dispathcer working in live and in multiplayer sessions.

#15 User is offline   Jovet 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 2,240
  • Joined: 14-January 08
  • Gender:Male
  • Location:Omaha, Nebraska.
  • Simulator:MSTS/Open Rails
  • Country:

Posted 31 May 2016 - 04:37 PM

:scarerun:
Can you post some signal files? (sigcfg.dat, sigscr.dat)
:wallbash:
I would like to try and make some sense of this system. I'm really not getting it right now. It works in MSTS, correct?
:ko2:

#16 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 01 June 2016 - 05:57 AM

I had some analysis on the issue of point 4) of my post #13 (forced signal returning to system control after train has passed it).
I saw that this is implemented and works, but only when the train is in auto mode (auto signal or auto node). It is not implemented when the train is in manual or explorer mode. In my opinion there should be a coherent approach, and this is the approach where in all modes the signal automatically returns to system control after train has passed it; this because of two reasons:
1) else the signal remains open also when the train has passed, which is not a regular situation: another train would have free way into the section where the other train is
2) the (human) dispatcher in multiplayer mode has his life simplified.

So starting with x.3551 also in manual and explorer mode the forced signal returns to system control after train has passed it.

#17 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 01 June 2016 - 02:23 PM

View Postjovet, on 31 May 2016 - 04:37 PM, said:

:scarerun:
Can you post some signal files? (sigcfg.dat, sigscr.dat)
:wallbash:
I would like to try and make some sense of this system. I'm really not getting it right now. It works in MSTS, correct?
:ko2:


https://yadi.sk/d/BGSMSP1zrKL4H
Version: v7.1370.17

In this you will not find the block-system for opposite train blocking in one track line. But I can create this. System works in MSTS in single player:

http://www.imghost.in/img/2016-06/02/750mz45gk3kluh4zwpdi61irk.png

The signals N and P are entrance signals (worked only by dispatcher, or with function autoopen). The signals 1, 3, 4, 2 are passage signal (worked fully in automat). The entrance signal N try to find in next block any train. If this founded, then this signal show special aspect to next signal (exit or passage). If the next signal is passage, the this will not show any light and will send this aspect to next signal. If the next signal is exit signal - this will show a red light.

The entrance signal P will find the aspect "wrong direction" from opposite entrance or passage signal. After them this entrance signal P will show any signal by scripts, but will send to next signal the information about "track is free". The all passage signals will copy this "track is free" until will be found any train. The next passage signal will shows "in the line has a train (-s)". Signal will shows the standart values by scripts.

Next stage: The entrance signal N will be not found any trains, because they are in line, because this entrance signal will call to opposite signal for "track is free" status. If this will not found - the span are used by train, and will block opposite trains. This you can watch in this route http://trainsim.ru/d...d/show/id/1949/

Note: for span right blocking need to use a special marker near entrance signal, because the first signal will shows "no trains" until this train will not proceed the signal.

#18 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 01 June 2016 - 02:28 PM

View PostCsantucci, on 01 June 2016 - 05:57 AM, said:

I had some analysis on the issue of point 4) of my post #13 (forced signal returning to system control after train has passed it).
I saw that this is implemented and works, but only when the train is in auto mode (auto signal or auto node). It is not implemented when the train is in manual or explorer mode. In my opinion there should be a coherent approach, and this is the approach where in all modes the signal automatically returns to system control after train has passed it; this because of two reasons:
1) else the signal remains open also when the train has passed, which is not a regular situation: another train would have free way into the section where the other train is
2) the (human) dispatcher in multiplayer mode has his life simplified.

So starting with x.3551 also in manual and explorer mode the forced signal returns to system control after train has passed it.


Thank You! Now we ask to help with blocked junctions and signal working. The ideal will be "open by scripts" or "close by scripts". In first situation the script function "block_state" will be by track database, and the last situation - function "block_state" will returns "block_jn_obstructed" for signal closing. This will be universal for any country.

#19 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 05 June 2016 - 12:35 PM

What are your plans for our suggestion?
1. Make two signal working variants - first is now created and other with autoopen by default?
2. Make a new functions on the signals for autoopen and autoclose functions, which change the "block_state" any value to "block_jn_obstructed" for signal closing, and any other by scripts for opening signals?

#20 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 07 June 2016 - 09:31 AM

Hi I have a question to you is working on a multiplayer version of 3553?
We have the problem that the server establishes okay game, but the client does not connect and switch it to the single player mode.

  • 5 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users