[scottb613]

Hi Folks,

Just ran that demo uploaded - and - all I can say is WOW - amazing - nice work...

Regards,
Scott

[Csantucci]

Thanks Scott!

Hello Peter,
I run my WP test activities and they still run correctly. However I already had some indication in another forum that in some cases WPs do not seem to execute, but I wasn't able to collect enough info.
If you agree, we can try to have a remote debug. When it's time for an AI train to start, override method BuildWaitingPointList at line 3757 of AITrain.cs is executed. This method prepares the actions to be executed later. So this is the first point to see what happens. I ask you to set a breakpoint at line 3868 and to follow what happens there for trains 8 and 3. I don't know if these are WPs with associated signal or not. In both cases the if at that line should return true (because trains 8 and 3 aren't player trains), and so the lines immediately following should be executed. There, if there is no linked signal, only an AIActionWPRef should be created, while in the second case also an AIActSigDelegateRef should be created. The value of the delay for the AIActionWPRef is contained in waitingPoint[2].
So pls. report what happens in the execution of that method's part. If you're disturbed in line-by-line debuggingby the Watchdog process, you can comment lines from 128 to 143 of WatchdogProcess.cs.

[steamer_ctn]

Hi Carlo,

I will have a look at it.

In the meantime do you have a valid example of a wait point statement from a path file? Do you know the format of the statement. I would like to check that the statement in my pat files appear ok.

Thanks

[steamer_ctn]

Hi Carlo,

I think that I have solved the mystery.

It appears to be a problem related to the version of MSTS used to create the path files.

Normally I run MSTS BIN, but as I was having some MSTS problems I reverted to standard MSTS. It appears that MSTS didn't put values in the wait points, this was an enhancement that MSTS BIN allowed for.

I have re-installed MSTS BIN and reset the wait points, and they appear to be working now.

For reference

From log file:

WP, init action for train 8 at 53718 to 54018(HANDLE_ACTION)

WP, init action for train 3 at 53823 to 54300(HANDLE_ACTION)

So it appears that the delay time is now being recognised and processed.

From path files:

Train 3 (with MSTSBIN):

TrPathNode ( 7b110002 4 4294967295 27 )

where 7b11 - Hexadecimal for 31505

Train 8 (with MSTS BIN):

TrPathNode ( 03e80002 24 4294967295 22 )

Without BIN - no value set

TrPathNode ( 00000002 16 4294967295 43 )

So in summary, it appears that standard MSTS will set a WP, but no value, hence the train will stop momentarily, and then continue. (I seem to remember this described in past forums)

MSTS BIN is required to set values in the WP statements. It maybe possible to use a text editor to change the path file line.

I am sorry for throwing a red herring.

Thanks for your feedback and suggestions.

I wonder if the other forum users are experiencing the same issues. Perhaps a note could be included in the documentation to ensure that content developers are aware of this.

[Csantucci]

Peter,
in fact it is a known issue that in standard MSTS WPs hadn't their duration working. Only MSTSBin provided working WPs where the inserted duration was also written into the path file and then executed. I didn't think that could be the reason. I'm happy it's not an OR problem.

Pls. take also note of another point: The MSTS and MSTSBin path editors allow to move the WPs by dragging them with the mouse. Such dragged WPs are accepted by OR only if the Enhanced Compatibility option is set.

I had already packaged two test activities (.apk format) that run on the USA2 route with standard material. In Testwaitingsignal_behind_AI an AI train starts after 20 seconds, runs in front of a red signal, and waits there until 12:04 with an absolute WP, then restarts.
In Testchangereverse_short_AI_doubleWP an AI train starts after 20 seconds and runs forwards, then backwards, then again forwards with some standard waiting points in between. I have tested the activities only with the Enhanced Compatibility option set.
 testACTIVITIES.zip (5.16K)
Number of downloads: 317

Now I think you don't need any more these activities, however I leave them here.

No problem anyhow, all of us throw red herrings :)

[Eldorado.Railroad]

I have a scenario that gives a rather odd result.

First I know that I have Extended AI Shunting enabled because I can uncouple cars..etc.

The route that I am using is payware, MLT's Rogers Pass. The setup is as follows:

1) There are two AI trains that show up on separate tracks A and B.

2) The AI train on track A uncouples from the rest of the consist, and it will go to a wye to change direction, namely to reverse the engine.

3) The AI train on B uncouples from the rest of the consist, leaving the wagons behind. The engine ceases to exist shortly after uncoupling when it reaches the end of its path on track B.

4) The AI locomotive from track A which has gone through the wye now returns with the intent of connecting to the consist that was left behind on track B.

This is where we reach a deadlock. There are signal lights on the path to return to track B, they are RED and stay RED. It is as if, the program thinks that there not only is a consist on track B, but there is an AI locomotive attached which would like to move forward but cannot. Remember the AI locomotive that was on track B has long vanished.

Did I miss something here?

Thanks!

[Csantucci]

Even during shunting AI trains respect general signalling rules: so, if a section beyond a signal is occupied, such signal is red and can't be passed (if it is not permissive). However there are two alternate ways out:
1) you put a good ol'couple of reversal points between signal and consist to be coupled; OR checks free way only up to the first reversal point, and therefore does not set the signal to red
2) you clear the signal with the dispatcher window.

I attach here a packaged demo activity for the Marias Pass route, where the AI path has the couple of reversal points (it is erroneously called "TestdoubleWPsig", but instead it is a double reversal point).

 TestdoubleWPsig.zip (1.95K)
Number of downloads: 344

[Eldorado.Railroad]

From 03 February 2015 - 01:22 AM:

Even during shunting AI trains respect general signalling rules: so, if a section beyond a signal is occupied, such signal is red and can't be passed (if it is not permissive). However there are two alternate ways out:
1) you put a good ol'couple of reversal points between signal and consist to be coupled; OR checks free way only up to the first reversal point, and therefore does not set the signal to red
2) you clear the signal with the dispatcher window.

I attach here a packaged demo activity for the Marias Pass route, where the AI path has the couple of reversal points (it is erroneously called "TestdoubleWPsig", but instead it is a double reversal point).

TestdoubleWPsig.zip

Carlo,

I will revist what you have uploaded. If the cars on Track B from my original post, did not reside on a path, in fact they would be a loose consist, this deadlock would not arise. The question that I have is, why are cars that are left behind after being uncoupled not being "demoted" to just a loose consist on a path that really no longer "exists" because the locomotive that brought them there is long gone?

Thank you Sir,
Steve

[Csantucci]

Such cars are indeed "demoted" to a static consist. However it could have happened that some track reservation has not been cleared. Did the disappeared loco run against the path of the other locomotive, or in the same direction? Can you post a screenshot of the dispatcher window or of the MSTS AE windows where the path layout of the coupling loco can be seen?

[Eldorado.Railroad]

Csantucci, on 06 February 2015 - 11:07 PM, said:

Such cars are indeed "demoted" to a static consist. However it could have happened that some track reservation has not been cleared. Did the disappeared loco run against the path of the other locomotive, or in the same direction? Can you post a screenshot of the dispatcher window or of the MSTS AE windows where the path layout of the coupling loco can be seen?

Carlo,

Well I took a closer look. I also used the Dispatcher Window to clear the red signal....I think this is not as it should be when an AI engine meets a demoted consist. Fusion! The engine cannot couple with the consist left behind on Track B.


With regard to the original observation here are TrackA and TrackB as paths:



Track A path starts on the bottom and returns via a wye in the distance (out of view) on the left to Track B. Track B path ends on the left.

The trouble is the red signal in the wye on the return leg.

As indicated by the yellow path the engine enters the wye on the bottom and it proceeds to the right. It is on the return leg from the top left that is encounters the red signal as seen here:

This red signal never clears automatically, even if the track ahead is not occupied by an AI engine. I wish it did. I assume here that this is not a permissive signal (not an "expert" yet!).

Thanks for spending some time with this when you can.

Steve