Elvas Tower: Player train can't be placed correctly - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Player train can't be placed correctly Rate Topic: -----

#1 User is offline   Csantucci 

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

Posted 30 December 2019 - 08:54 AM

I'm referring to the single-track route Garfagnana (Lucca-Aulla), which can be downloadable from here http://www.trainsimh...ad.php?did=1167 plus this patch http://www.trainsimh...ad.php?did=1262 and to this activity http://www.trainsimh...ad.php?did=1187 , which requires only one trainset download, that is http://www.trainsimh...oad.php?did=341 .
The player train can't be properly placed at game start. More precisely, it is placed, but it is in a No-path authority state; this occurs because the train has no OccupiedTrack sections. This in turn occurs because the deadlock logic generates a deadlock section which ends exactly where the player train must be placed. The CanPlace method decides that the player train can't occupy its starting section because that section is deadlocked. The other train involved in the deadlock is an AI train which runs in the opposite direction and starts before the player train (it will end its run where the player train starts). I have checked the paths of the two trains, and there are stations where the paths of the two trains are placed on a different track, so that the meets would be successful.
So it seems to me that in this case the player train should be allowed to occupy its starting section.
A comment by Rob and a suggestion about what should be modified in the code would be welcome.

#2 User is offline   charland 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,516
  • Joined: 13-April 08
  • Gender:Male
  • Location:Brockville, ON, CA
  • Simulator:MSTS/OR
  • Country:

Posted 30 December 2019 - 12:57 PM

When I was creating the activities for the FJ&Gv2 I discovered that when making the activities in MSTS Route Editors, the engine you place is based on the center of the unit. When opening that activity in Open Rails, they appear to be casing the unit's location as the trailing truck, not the center of the unit. On a longer unit this could be enough to put your unit over the end of the track so it will not open in OR even if it runs fine in MSTS.

Paul :-)

#3 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 31 December 2019 - 03:18 AM

View PostCsantucci, on 30 December 2019 - 08:54 AM, said:

A comment by Rob and a suggestion about what should be modified in the code would be welcome.

Two word comment : oh dear :D :pardon:
It's now quite a few years since the deadlock processing was build, and there haven't been many reasons to get back to it. Also, I have not ran any activities for many a year now, and because of the different way trains are placed in timetables, this sort of problem is very unlikely to occur when running timetables. So this is pretty much unchartered water for me.
I had a quick look through the code, and noticed there are two possible reasons for this issue. First is a check through all possible paths through the area, to find if a free passage would still be available if the train was placed. The other is a straight forward check on deadlock trap.
One thing is clear. There will not be a straightforward easy solution to this, without risking placing trains in deadlock positions.
I will take a look at this, but it will take time and I can't promise that a save solution can be found.

Regards,
Rob Roeterdink

#4 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 02 January 2020 - 01:58 AM

Well, this really turned out to be a surprise. No problem at all. The activity started fine, my train was there with path and all, and crossed the other train at the appointed stop. So what's going on? No idea. The version I use is basically equivalent to the 'unstable version'. In fact, there have not been any changes to the deadlock processing for many a moon. Not easy to try and solve a problem if it does not occur.

Regards,
Rob Roeterdink

#5 User is offline   Csantucci 

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

Posted 02 January 2020 - 05:05 AM

Thank you for having tested. I suppose we have different settings.

#6 User is offline   Csantucci 

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

Posted 02 January 2020 - 05:21 AM

After some tests, I saw that the relevant setting is Forced Red at Station Stops; if it is unchecked, the problem arises. So now I have a way to overcome the problem by checking the option for this activity. Now I wonder why in this case such option influences deadlock processing, and I wonder if it's right that there is this influence in this case.

#7 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 02 January 2020 - 01:27 PM

View PostCsantucci, on 02 January 2020 - 05:21 AM, said:

After some tests, I saw that the relevant setting is Forced Red at Station Stops; if it is unchecked, the problem arises.

Tried that, but it still worked allright. What I did notice, though, is that the track ahead was reserved very far out for both trains - much further than one would expect for a signalled route, and also much further than that signals were shown as 'cleared' in the dispatch window. I could not see how far as the dispatch info ran of the screen.
So, perhaps in some circumstances, the track for the AI train is reserved right up to the end, or at least beyond the passing point, in which case there would be a deadlock conflict as the passing point would be out of reach for the player train.
Why the track is reserved so far ahead I do not know, but it must have something to do with the way the signals are set up. I did notice in the signal script that signal state and signal draw state are set separately and not through the definition of the signal states in the sigdat file. It could be that that throws off the system, with the state set to a value which is interpreted by the program as 'clear', and therefor the program continues to reserve the track, whereas the draw state is set to 'danger'. But that's just guessing, I did not check it out any further.

I do not think, however, there is anything in the program which links the state of forced red to the deadlock processing.

Regards,
Rob Roeterdink

#8 User is offline   Csantucci 

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

Posted 03 January 2020 - 01:31 AM

That became a bit strange, so I tried with other options, and the result is that probably you have tested with the Autopilot option unchecked.
If you check it and uncheck the Forced Red option, you should get the NOP situation.

I have analysed further the case. In fact the initialization of the player train is made by different methods depending from the autopilot option being checked or not (I had assembled the methods in case the autopilot option is checked, starting from your generic AI train code).
In particular the PostInit method for AI trains (the player train, when the autopilot option is set, performs to the AI train class) is an override of that for player trains, and the first difference that comes out is that there is a line
CheckDeadlock(ValidRoute[0], Number);

before
bool validPosition = InitialTrainPlacement(); 


Such line isn't there in the virtual PostInit method. If I set the autopilot option and bypass such deadlock check in case the train is the player train, the train can be correctly placed, both when the Forced Red option is set or not.
However, without such conditional bypass,
this line
                if (thisSection.CanPlaceTrain(this, offset, remLength))

within InitialTrainPlacement() gives opposite results if the Forced Red option is set or not.

So one could think to insert the above bypass. What do you think about that?
But then I did another test. Starting from the activity I generated a new one, where I inserted the original activity player train in the traffic, and generated a new player train with a very short path in the Lucca station.
I started the game with the Forced Red option set and not set. When the Forced Red option is set the former player train appears in track one, while when it is not set it does not appear. I don't know if this is a direct consequence of the different state of the option, or an indirect consequence due to the fact that the opposing train has run a bit less, because it has been slowed down by restricting signals before the stations. The fact remains that the AI train does not appear in such case.

#9 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 04 January 2020 - 08:34 AM

The problem is not in the program but in the signalling.
If forced red at station is not set, the signalling clears a way too long path ahead. There does not seem to be the usual restriction of clearing just 2 or 3 signals ahead. For the standard activity, if forced red is not set but Autopilot is, the path for the AI train is cleared almost up to the starting position of the player train, well beyond the passing point. So there is indeed a deadlock conflict and the player train can't start because it has no path available.
Setting forced red will prevent this as the program will not clear the signals beyond the next station.
What needs to be investigated is why the track reservation runs so far out. Probably something in the signal script.

Regards,
Rob Roeterdink

#10 User is offline   Csantucci 

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

Posted 05 January 2020 - 01:28 AM

I have done a counter-test. Within the virtual PostInit() I have placed the CheckDeadlock() call before the InitialPlacement() call (as is actually in the AITrain override PostInit()): as a result the player train can't be placed if the ForcedRed option is not checked.
So I have decided to move the call to CheckDeadLock() after the InitialPlacement() call in the AITrain override PostInit(), at least for the player train. I think it makes sense of having uniformity. I am confirmed in that by looking at the TTTrain override PostInit(), where the CheckDeadlock() call is after the InitialPlacement() call too ( and for all trains, which would tempt me to move the CheckDeadlock() call in the AITrain override PostInit() not only for the player train, but for all trains).

Page 1 of 1
  • 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