Confusion on waypoints visibility

lucstef

New member
Good day all.
I'm starting to wrap my head around the logic - and quirks - of the session rules, still a long way to go but I can now make some nice switching and road switching sessions without much of a trouble, and the next learning experience will be about objectives soon.

There's one thing about waypoints I can't still catch though, that is sometimes I can see an unload icon from miles away, other times I can't see it even in the nearby siding unless I have all the switches set and the train moving toward it.

In one occasion I had a coupling task followed by a move forward in the same navigation set that was working perfectly, i.e. having the forward transparent icon before the coupling and full icon afterward, until I made some mistakes and I had to redo the coupling task with a different car, now the forward waypoint doesn't show up until I'm really on top of it (and in a couple of tests didn't even fire, all the rest being the same).

I'm using TRS19 Plus non-beta 103369, I'm not loading 10's of moving trains nor using portals at this time, the issue is independent on the way I setup the nav sets as it happens from the same set or from different sets.
There are no "nav point complete" rules around, too, and the problem appears in all routes I used, even in a Philskene single baseboard route.

Is there anything I must be aware of here? Thanks in advance :)

P.S. - I'm sorry if that issue is/was being discussed before, I tried the search but I was overwelmed by lots of "freeware announcements" and "screenshots of the month" threads, plus unrelated threads about how to setup timetables......I really need to learn to use Google search maybe :eek:


Luca
 
103369 is a beta as 100240 was the last non beta. 103369 operates in a different way to earlier versions so more info may be needed.
 
Thanks for the reply.
Actually there is a Plus-beta stream available, although I didn't join it.

It's a long time I haven't used the 100240 stable version, but I recall having the same issue occasionally.
I will install a 100240 version later at home and check what happens.

Otherwise, what more info may be needed?
TY again.



Luca
 
I have had a lot of experience using Navigation Points in sessions but there are things in your description that I do not fully understand.

... sometimes I can see an unload icon from miles away, other times I can't see it even in the nearby siding unless I have all the switches set and the train moving toward it.

That is not sort of behaviour that I have experienced. However, in the video tutorial on Navigation Points (which is a few years old now) it was mentioned that there is (or was) a bug that can sometimes prevent the appearance of a Navigation Point (I will call them NPs to save typing) if your loco is already too close to it - but i have not ever experienced that.

I would suspect that a lot can depend on how and when the NPs are being activated - i.e. when the Navigation Set Show/Hide Rule activates a set. I never have the NPs visible for miles ahead of the consist and usually use a trigger to show a set when the consist is a reasonably close distance away.

In one occasion I had a coupling task followed by a move forward in the same navigation set that was working perfectly, i.e. having the forward transparent icon before the coupling and full icon afterward, until I made some mistakes and I had to redo the coupling task with a different car, now the forward waypoint doesn't show up until I'm really on top of it (and in a couple of tests didn't even fire, all the rest being the same).

Once a navigation point has been completed it is removed from the session and cannot be displayed again. The "forward transparent icon" indicates to me that that particular NP is not the next one that has to be completed. In the Navigation Display Rule that creates the NP sets, you have the option of forcing the player to complete ALL NPs in their set order (no skipping over NPs), completing them in the set order but allowing any to be skipped over (but no going back to missed NPs), or completing all NPs but in any order. The icons shown solid are the next available NPs to be completed. Those shown transparent are NPs that are further down the list order.

I'm using TRS19 Plus non-beta 103369, I'm not loading 10's of moving trains nor using portals at this time, the issue is independent on the way I setup the nav sets as it happens from the same set or from different sets.
There are no "nav point complete" rules around, too, and the problem appears in all routes I used, even in a Philskene single baseboard route.

103369 is the TRS19 Non-Plus version beta.

There are "nav point complete" rules available already built into TRS19.

May I suggest that you look at two Trainz Wiki Pages first.

http://online.ts2009.com/mediaWiki/index.php/How_to_Use_Navigation_Point_Rules - to give you an overview of the different NP rules, and
http://online.ts2009.com/mediaWiki/index.php/How_to_Use_Navigation_Point_Rules_(Applications) to give examples of how to use them
 
Last edited:
I have had a lot of experience using Navigation Points in sessions but there are things in your description that I do not fully understand.

Ok, I'll try to break up everything with images.

First off, the first "display" rule:

m9Brffr.png



As you can see, two consecutive waypoints to be completed in sequence, a coupling and a load at an industry.
After the coupling, I leave the flats and get ready to backup the hoppers under the loading chute, and this is the outcome (the shed in the background is the position of the second NP):
dihbmSY.png



Then I throw the switch, and slightly move backward:
p3gzRBH.png


The second NP appears, BUT....if someone other than me is playing this session, he would get completely lost before realizing where the second NP is.
I know I can add the location in the instruction messages, but that's nullifying the entire NP idea.

Now for the real surprise, some switchings later:
eeKbO9a.png



Can you read the distance? It's 5.22 MILES..................
And this is where I lose my mind completely. I mean, what's up?
You would say, "wait, that's on the same track"....sure?, let's see:
pu2xBmQ.png


No, it's in a spur, and if you look closely it's the same situation as the wheat load NP from before (reverse spur).

Ok, that distant NP was on itself on a separate nav display rule....what about this?
w9Ela9Z.png


And this is what I see when I trigger it:
Gzl6YKH.png


I can clearly see both NP, with the second faded in the background as expected and clearly showing its position, even with the switches on different paths (my train is still on the mainline and it hasn't reached the yard entry switch).

That's how I setup my session, just a snippet:
RFbVJxE.png


I just subdivide the session into simpler tasks and make them trigger one after another, when the previous is completed.
(The "navi set clear" rules are there just to clean up any instance of the "nav display" rules that may have been left over from a previous test, and have nothing to bear with the actual session breakdown).
Last but not least, the session works as intended to the end, other than these NP issues.

I only noticed that those problems happen in one place only, that is Ashleigh Yard in UMR2019, and nowhere else down to Gladston.
In addition they aren't consistently appearing, in another session involving two unloads and one load in that same yard I can see all the NPs I've set from anywhere on the track the moment their rules are triggered.

The "NP not showing until the train approaches it/the switches are on its path" issue appears in The Bidye Traction Railroad for TRS2019 too, this is the only other route I made a session for.

I hope I've clarified what is the problem I see.
If you counsel me about a file sharing site I can use, I would gladly upload both sessions on UMR2019 for you to check (needs everything installed from Gold membership).


103369 is the TRS19 Non-Plus version beta.

Sorry but....not what appears on my install :) :

8ugLhop.png




Luca
 
Unfortunately have to depart shortly so I will take this up in about 10 hrs. My patch stream is shown below:

Stream-103369.png
 
Hi, Luca,

Looking at your snippet I'd expect the limeandexit nav set to be created as soon as the wheat is loaded, so I'm not surprised if it's showing you the next nav point at a destination 5 miles away. Perhaps I have not understood your observation correctly?

I haven't been able to reproduce the case where the navigation point doesn't display until the path is aligned.

I will pm you about your sessions, I would like to have a look. In the meantime I will download UMR2019.
 
Hi Rob.

The distant point is alone in a set after limeandexit, it's not showing in my snippet.
You're correct though, limeandexit triggers after the wheat loading section completes.

I'll answer your pm soon :)



Luca
 
Ok, back at my Trainz computer and I have run some tests with a simple route and session. Something appears to have changed.

Firstly, I cannot get the NPs to appear at all despite using correctly configured Navigation Display Rule and Navigation Set Show/Hide Rule to make the NPs visible. The setup is extremely simple but I cannot see what I have done wrong (if anything).

Secondly, I loaded in a TANE created route and session with lots of NPs and it works correctly with all the NPs behaving exactly as they should. No need to switch points to make them appear.

I am booting this up to N3V QA for them to look at. It has me beat.
 
Hi Pware.

I know UMR is a beast of a route, but if you want to remake my steps, try this:
1) one NP to couple a car in the far north sidings in Ashleigh, then another NP to load wheat in the nearby Ashleigh Silos chute (you will need a track marker), both in the same set
2) after this is complete, another set pointing at Lyle Lumber, just one NP far away

If you lose the load NP until you align the switches but can see the 5-6 miles away lumber NP afterward, then it's not just on my part.
(I'm wondering if there's something wrong with the railwork...).


Luca
 
I'm only a year into this but shouldn't sessions made for distribution be made using the latest "official" release (100240) - Won't users of 100240 have problems with sessions made in 103369??
 
I'm only a year into this but shouldn't sessions made for distribution be made using the latest "official" release (100240) - Won't users of 100240 have problems with sessions made in 103369??

Sessions created in earlier versions should run without any problems in later versions but the reverse is not always true. Specifically TANE SP1 (I believe it was) routes would not work in TANE the original version because of a major change to the way that the terrain maps were stored in SP1.

I was able to create routes and session in TRS19 build 103369 (SP1 beta) that worked perfectly well in TRS19 build 96000 so I would not expect users of build 100240 to have any problems - but you never know. That is what makes beta testing so exciting :'(
 
More weirdness incoming.....

I made a very simple test route with a couple spurs and one runaround track, this time using TRS19 stable 100240.

I then made a navigation points set, this one:
qfKvwBr.png


Just a note: the "spur" NP are in a spur (du?) so they are reachable in one direction only, while the RA is in a runaround track that's obviously connected to the main track in both ends.

Passed the first NP, and I see this:
kTHauwj.png


Alright, the next NP "spur1" plus the following transparent "3", just like expected.
Then I need to switch the junction, right?
LHGZQFy.png


Poof, the "3" NP is gone from the screen.
I know where it is, so let's complete the spur1 NP, and I approach it:
4WyYbVQ.jpg


Uh? Is that the case of the crazy navigation point? As soon as I near the "spur1" NP, the "3" reappears...oh well....

I complete the spur NP and move toward the 3:
YjeXBsx.jpg


...and from a greater distance too:
5RwxrfG.png


...add insult to injury, let's switch the junction from before:
sww2Kc3.png


That's interesting: the runaround NP is not in the path (note the switches), but it's still showing from anywhere.
Going to test the same set with single display rules, will surely be refreshing ....

EDIT:
setting all NP in each own display rule, they are showing all together whatever the junction positions are.
That means the issue can be only found while using a display rule with multiple nav points, and that's even inconsistent.

ADDENDUM:
I managed to import route and session into Plus-103369...and the "NP not showing when it's not in the path" issue is back again, even when using rules with one single NP.
***GRUMBLES***



Luca
 
Last edited:
Long post with screenshots

Ok, I have run some simple tests using a single baseboard layout with a straight track, two sidings, a loco and two wagons. Each wagon has a Navigation Point "attached" via the Navigation Display Rule. Each Navigation Point has to be completed in order.

Test 1: Route and Session created in TANE build 102323 and Session is run in TANE build 102323

Screenshot 1: Start of session. Both wagons have visible Navigation Point icons. The one of the right is the first to be completed and is shown solid, the other icon is the second in the list and is shown semi-transparent.

Navtest-TANE-1.png


Screenshot 2: Loco has coupled with the first wagon. Its icon has disappeared (as expected) and the second icon is now shown as solid as it is now the next Navigation Point to be completed.

Navtest-TANE-2.png


Screenshot 3: The loco and first wagon have coupled with the second wagon and its icon has now been deleted (as expected). End of Session.

Navtest-TANE-3.png





Test 2: Route and Session created in TANE build 102323 and Session is run in TRS19 SP1 beta build 103369
Note that this is the TRS19 non-Plus version SP1 beta

Screenshot 4: Same setup as before. The result in TRS19SP1 is no different from what was seen in TANE

Navtest-TANE-in-TRS19-1.png


Screenshot 5: Same setup as before. Again TRS19SP1 is no different from what was seen in TANE

Navtest-TANE-in-TRS19-2.png


Screenshot 6: Same setup as before and same result.

Navtest-TANE-in-TRS19-3.png


Now for the interesting part.

Test 3: Identical Route and Session created in TRS19 SP1 beta build 103369 and Session is run in TRS19 SP1 beta build 103369
Note that this is the TRS19 non-Plus version SP1 beta

Screenshots 7 and 8: The Session Editor and Navigation Display Rules created new in TRS19SP1 beta build 103369. These are identical to those I used in the TANE version.

Navtest-TRS19-SP1-Rules.png


Navtest-TRS19-SP1-Nav-Display.png


Screenshot 9: The above Session is started in TRS19SP1. As you can see there are no Navigation Point icons shown above the wagons.

Navtest-TRS19-SP1-1.png


Screenshot 10: It has been suggested in this thread that because the switches (points) at the siding junctions have not be set to allow the loco to move into the sidings, that that may be the reason why the icons are not showing. In the screenshot below, the points to the first wagon have been correctly set and no icons are visible.


Navtest-TRS19-SP1-1a.png


In my discussions with N3V QA over this matter, the following was suggested ...

"To fix the problem, click "Restart all rules", then resave the session."

I can understand the need for such an option "Restart all rules" in the Trainz-Plus SP1 version but, as hard as I have looked, I cannot find any such option in my "non-Plus" version of TRS 19.

Now if someone can explain all this to me, even if it is entirely "operator error", then I would be extremely grateful and can get on with my life.

Thank you for your time.

EDIT: N3V QA did email me with instructions on where to find the "Reset all rules" option but I missed their email before posting this. For those with non-Plus versions of TRS19SP1 it can be found by right clicking on a rule in the Session Editor and if the option appears in the menu list then it can be selected. It will also show with a colour coding and the presence of a "Restart All Rules" option. So far none of these options have shown themselves to me.

EDIT 2: (Note to self - I should read emails more carefully) N3V QA have acknowledged that there is a bug here and a task as been raised.
 
Last edited:
"Restart all rules" can be done with a button in the rule editor of the Plus version, and I doubt it has any usefulness without the integrated surveyor/driver interface.

Your findings are identical to what I showed before and continues to happen in my tests in Plus 103369, while the stable 100240 version works alright.



Luca
 
Last edited:
Yes, an interesting option that I suspect will cause some problems. I can see why it is needed in the Trainz Plus version of TRS19.

If you are able to save a Driver Game and load it into Surveyor for editing then obviously at the point that the Game was saved some of the Session Rules would have been completed, some would be in the process of being executed (but not completed) and some would probably not have been started. So when the edited Driver Game is restarted the state of the Session Rules could cause some problems.

There has always been a little known issue with Trainz that not all the Session Rules have their state saved when a Driver Game is saved - the Hide/Show Layer Rule, for example, will default to all layers shown when a saved Driver Game is restarted ignoring any layers that were hidden when the game was saved.

I suspect that this option will provide a way or resetting everything in the edited and saved game to get around some issues but I suspect that some users will not be happy when they discover that the Rules in the restarted game, with or without using this option, do not behave correctly.

Interesting times.
 
And what happens if you create the session in the bug version, and then install and run it in a "good" version (non-beta version)? I ask because I have noticed in several posts that users are creating sessions with beta software. Shouldn't stable versions be used for session creation (if they are going to be distributed)?
 
Last edited:
Interesting question, I admit I never checked 103369 Plus sessions in 100240 Stable.

Up to now I'm just learning, so my sessions are for my own use therefore I don't care about versioning.
In my back mind I knew already I need to check/build on the stable version(s), thanks to many years passed hunting for bugs solutions in various pieces of software that I use both at home and at work, and if I will start sharing my "creations" I will surely try to maximize compatibility.

On the other side, if I hadn't tried session building on a new version I wouldn't have started this entire bug issue that Pware finalized, and it may have been taken over any new stable SPx in the future.
So sometimes using a beta version has its use :)


Luca
 
And what happens if you create the session in the bug version, and then install and run it in a "good" version (non-beta version)? I ask because I have noticed in several posts that users are creating sessions with beta software. Shouldn't stable versions be used for session creation (if they are going to be distributed)?

I have been importing routes without sessions from build 103369 into build 100240 for some time now without any problems.

I just tried importing the test navigation point session I created in build 103369 into build 100240. I had to delete the Navigation Display Rule from the Session Editor in build 100240 because it was marked as "Faulty - load failure" (hint: this may be a clue to the problems covered in this thread). I then replaced it with the Navigation Display Rule from build 100240 and configured it exactly as before. The imported Route and Session then ran perfectly.

Because build 103369 (both non-Plus and Plus version) contains code for the common Driver/Surveyor interface (which is disabled in the non-Plus version) then it will most probably mean that sessions created in build 103369 may have problems in build 100240.
 
Back
Top