[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: 387

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: 423

[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

[Csantucci]

Steve,
the issue of the melting trains is not so nice. The problem is that to try to proceed a bit fast towards the solution of the problem, I should have the possibility to debug with the route (and the activity of course). I don't think the issue is easily repeatable on another route. A screenshot with the debug information HUD when the train is stopped at the red signal and another one just before the melting could be of interest, but probably not enough to solve the problem.

[roeter]

Quote

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!).

That is very likely - few routes allow 'call on' into yards etc. for AI trains, with such actions for player trains being left to use "ask permission" (TAB function).
Clearing the signal through the dispatcher window could well have the effect that it allows the engine to pass but does not set the engine to the proper control state. If the engine would still be in "AUTO_SIGNAL" mode, it will not 'see' the consist, as the logic has set it as to have a clear path to the next signal.
For that, it would indeed be very interesting to see the F5 - Dispatcher Hud screenshots.
I would suggest to start with a screenshot when the engine is held at the signal, a next shot when the signal has been cleared and the engine is just starting to move, and a further shot as it approaches the consist.

Regards,
Rob Roeterdink

[mauried]

Ive solved this problem by either using signal sets that allow the block check function in sigscr.cfg to be bypassed, or by modifying the scripts myself.
This is part of a common script for Absolute signals.

if (!enabled || // Not enabled/cleared to show natural state?
block_state() !=# BLOCK_CLEAR || // Block ahead not clear?
!route_set())

Then set the signal to red (Sigasp_stop).

The 2nd line which does the block check simply needs to be commented out, so no block check is done.
It does seem to work OK , but Im not sure if by doing this Im creating problems for ORs AI Dispatcher.
Is this type of solution OK?
Thanks

[roeter]

This change could easily lead to collisions, and actually disables the function of this signal.
A better way is to change that line to block_state()==#BLOCK_JN_OBSTRUCTED: that will keep the signal at danger if the route is blocked (e.g. a switch is set for another route), but will allow a train to pass the signal when the track ahead is occupied.
This turns it into a 'permissive' signal. The problem is that it will always allow trains to continue, not only when going forward to attach.

Regards,
Rob Roeterdink

[Csantucci]

mauried, have you tried the other solution inserting the double reverse point (not in the same section where the attached train lies) after the signal?