TRC 4 trigger values don't "stick"

[frogpipe]

TRC 4 trigger BUG! - radius values change unexpectedly

EDIT: See my post at the end for the cause AND fix.


Specifically the trigger radius which I set to 0 for automatic triggering. Randomly the $&#! things keep changing that radius to 1600 (the maximum)

I've tried several tests to try and figure out what triggers the change, no joy.

It isnt saving and reloading (route or session), nor hiding the layer they are on, editing track or adding removing other track objects nearby.

It does seem to be limited to where I'm working, but sometimes its every trigger on the route.

Usually I find out its gone wonky when playtesting and noticing a long line of waiting cars (its a slow route) and when I see that or realize I'm hearing crossing bells fade in from way to far away I jump to surveyor and check and sure enough 1600s all over the place.

 

[JCitron]

The radius to zero? The ones I use only go down to 50 and the ones I changed, I set to 100. When I checked, everything was where it should be from last night. Here's the method I used:

Edit the trigger setup in the route not the session.

Force the values to stick by appending a space after the name, applying, then open up and remove the space and applying.

 

[frogpipe]

I'll try that name trick, I have had instances where I had to -blank the name, -close the window, -open the window and give it the name I wanted, -close the window to get things to "register" with the trigger as part of the group.

As to the zero setting, V4 has and automatic mode which is set by giving the radius a value of zero.

 

[nugget2225]

I have all mine set to 0 as well for Automatic trigger's and mine keep going back to 1600 as well, i haven't found a solution for this. I have 60 crossings , so i understand.

 

[1611mac]

And stating the obvious... you have tried using "(If needed, click here to refresh the list)" - that has worked for me in the past but I also at times have to use "rename" method as already mentioned. See last text line in the photo attached above.

 

[frogpipe]

You missed something. This is about the settings changing on their own, not it loosing track of grouped items.

FWIW when it has lost track of other grouped items, I find refresh does nothing, only unnaming and renaming the missing asset gets it to register with the trigger. But again, this is about the trigger radius chaning it's self from 0 to 1600.

Recently it hapoened again and in this case I was changing a couple train stations from one asset to a new asset. Now I've set one crossing to 250m to see if that one still changes to 1600 or if it only affects ones set to 0.

 

[frogpipe]

Found the problem:

Paging Vincentrh

The trouble is due to the Unified Driver Surveyor. You set the front and rear radius to 0 (automatic) and then switch to driver. The code reads the values (FrontRadius and RearRadius) but when it sees 0, it changes them to 1600 and sets a boolean flag for automatic calculation of trigger distance.

THEN when you switch back to Surveyor, those 1600 values follow you and the setting is changed.

My solution was to change to a temporary variable between lines 233 and 540, and changed lines 233 and 234 to:

233:           if(IsDistanceAuto==true) {tmpFrontRadius=1550; tmpRearRadius=1550;} 
234:           else {IsDistanceAuto=false; tmpFrontRadius=FrontRadius; tmpRearRadius=RearRadius;}

tmpRearRadius and tmpFrontRadius obviously being my temporary local variables, defined on the same line as the other ints above line 233.

As far as I can tell the trigger works exactly as it did before, just no longer changes the radius values without my consent. (oh and the 1550 was just to verify that's where the changed values were coming from, they can be 1600 of course)

 

[vincentrh]

Very interesting conclusions.
But if you read the script in detail, you will note that the concept of 'front radius' and 'rear radius' only concern a radius of detection of an incoming train. In 'automatic mode', behavior of the crossing and its gates is only affected by the speed of an approaching train, and not at all by rays of detection which are, mathematically, only a calculation interval.
I agree that seeing 1600 m instead of 0 is not very reassuring. But it shouldn't have any effect on the operation of the TRC trigger.
But I note your comments and will correct this small defect in a future version.

Vincent

 

[frogpipe]

Its been a few months but IIRC the altered value was causing gates to be permanently down. The changes I made eliminated the problem. It fouls up the conditional statements. This may have been in non-automatic mode.

 

[vincentrh]

OK. I have noted that.
At present, I'm working exclusively with Trainz 2019 because I cooperate with a team whose members are reluctant to adopt Trainz 22. But as soon as my work with them is done, I'll come back to TRS 22 and I'll fix the bug as you suggest. Thank you !

Vincent

 

[frogpipe]

All good.

Just to clairfy I too am in 2019 and am reluctant to adopt 2022. So this us occurring in TRS19.