Unified Driver Surveyor Feedback (pre-beta)

Hi.

The possibility to switch back from driver to surveyor to fix something on the route not correctly defined and then again to driver to continue the current session would be certainly a great feature and a major enhancement for every trainzer.

But may be I will take the risk of being somewhat a rabat joy, I wonder a lot on how N3V will manage some implementation details and the interaction with scripting, as currently there are many scripted asset, rules and driver commands, which rely that in driver mode, after initialisation, the route map objects (except driver, vehicles and consist) do not change and rely on some internal data built at session initialisation (with no further update) based on the current route map object configuration... And every body knows that to support such new functionality the devil is always in the details.

For example, if I switch back from driver to surveyor and add or delete some junction, signal, crossing, … along a currently active path, the path will now be broken with an extra or a missing object along the path. How the interlocking tower will be warned when returning after the update from surveyor to driver of this update done on the fly, and will update its own internal data to support this update on the fly … And another example without any interlocking towers for trainzers that uses standard AI : if I move a trackmark or an industry which was in front of a train to somewhere else at the back, how the scripted AI command will be informed of the update and can reschedule itself to go now backward instead of forward to its target destination ...

So I see some major impact on scripted objects, on scripted rules and scripted driver commands, that will need to have their script updated to be ready to take in account any updates done on the fly ...

Again, such new supported functionality will be a major and great enhancement for developping a lot of things. So it is worth to support it and made all the changes needed to scripted assets. But N3V needs to gives to third party scripters some clues and more detailed information on how this will impact current scripted rules, scripted driver commands and other scripted assets, so that third party script developpers can update and adapt their assets to support this new functionalities. May be the Trainz plus program is also to enable scripters to adapt in advance their assets to these functionalities before they are included in normal releases ...

Only my scripter thoughts.
Regards.

Pierre.
 
I am an avid route builder, too, and I would like to echo the concerns of Pierre. It will be interesting to see how these issues are overcome. So....on with the adventure!
 
Very interesting. I'm thinking of those times when I've been trying to smooth out bumps in the track that are invisible in Surveyor but very much there in Driver.
 
.. scripted asset, rules and driver commands, which rely that in driver mode, after initialisation, the route map objects (except driver, vehicles and consist) do not change and rely on some internal data built at session initialisation (with no further update) based on the current route map object configuration...

This obviously depends heavily on how the script in question behaves and isn't something that we have direct control over. We will notify the scripts of the module changes, and the scripts will need to respond appropriately. In the vast majority of cases we don't expect any real problems here, but there are definitely going to be edge-cases (perhaps even some popular ones) which handle it poorly and will need a script update.

For example, if a script handles the module change to Driver by updating its view of the world, then (at least in Driver) it will always have up-to-date information. On the other hand, if it ignores such module changes after the first, then it will be prone to errors if substantial changes are made to the route. In the worst case, if it completely corrupts its own internal state in the presence of multiple changes (say, by appending the route data to its internal state, rather than overwriting it) then it's not going to be usable without an update.

As with any change, there will likely be a mix of outcomes:
* All assets will still be fine for Driver-only usage, or a single Surveyor-to-Driver transition.
* Most assets will keep working as-is even in the presence of multiple transitions.
* Some assets handle post-driver edits poorly, so will start to have problems after any significant live route edits.
* A few assets will fail to handle multiple transitions at all, resulting in completely incorrect behaviour, script errors, or etc.

From those, the usual fixes apply:
* We'll work internally to fix content that we think is most problematic.
* We'll work with external creators to ensure that in-active-development content handles the transitions correctly.
* The DLS Repair Group may (at their discretion) opt to fix specific out-of-development content.
* Some seldom-used content will likely be abandoned. (As above, it will still work if used in the traditional manner.)

For people who aren't really familiar with scripting and/or content creation in general, I should also point out that this probably only applies to a narrow subset of fairly-heavily-scripted assets; scenery, interiors, locos, textures, engine specs, signals, etc. are unlikely to be significantly affected. "System" assets such as Interlocking Towers, signalling control rules, and things like that are more likely to be affected.

It's too early to talk full specifics of script APIs; at this stage the answer is that we already have a module-change notification and you should be paying attention to that. I agree that we'll likely want to introduce some new mechanisms for monitoring live changes in Surveyor, but we're taking a wait-and-see attitude there - we'll see how things work out in practice, and build APIs to solve actual problems rather than proactively based on speculated problems.

Finally, we offer a mechanism whereby the user can reset rules manually; this is intended for other purposes but may help work around problematic scripts in some cases.


.. how the scripted AI command will be informed of the update and can reschedule itself to go now backward instead of forward to its target destination ...

Definitely an interesting question. The "AI" already has some fault-tolerance mechanisms built in which may be enough to handle this, but if we decide that it's too big a problem to leave alone in practice then we might perhaps adopt something similar to the Signal systems, where searches are monitored and the object notified if something changes within its search scope. One good thing about this area is that the common AI operations are N3V-controlled, so we have the capability of making any necessary changes internally without having to worry about how third-party assets will respond.


In short: all good points, stay tuned.

chris
 
I really like the idea, and look forward to its introduction.
As a builder rather than driver, I own my copy of 2019, so goodness knows when that will be.
It’s a shame that those of us who merely own, but arguably, as route builders with little interest in the usual Gold Class benefits, would have a major use for the new tool, will have to wait.
I can see the commercial reasoning though, but it won’t persuade me to rent.
Best wishes
Ian
 
Tony,

This looks like a brilliant feature and major step forward.

A quote from your blog
"We're also very excited about opening up the powerful editing tools to those who haven't ventured far out of the Driver mode (yet)"

Which made me wonder how many gold members are serious route bulders, or are they mostly drivers?
Don't you need seasoned builders/testers who are not Gold members (like clam1952) to test this major step forward for you?
I am sure that TRS19 would benefit from their inclusion and that testing would be both quicker and thorough.

OK I admit defeat, just signed my life away, this sort of stuff is too important to miss out on. With 2 free months and my lifetime FCT discount, for a yearly subscription it comes out to just over £8 per month, as I probably won't be using the freebies, that goes to support Trainz future development. My comment about those who can't afford a sub still stands though ;o)
 
OK I admit defeat, just signed my life away, this sort of stuff is too important to miss out on. With 2 free months and my lifetime FCT discount, for a yearly subscription it comes out to just over £8 per month, as I probably won't be using the freebies, that goes to support Trainz future development. My comment about those who can't afford a sub still stands though ;o)

The smile on Tony's face is probably ear to ear, the strategy is working perfectly.
 
Got to admit that it's a smart business move, members paying to be a beta tester, who would have thought that could happen in Trainz ? :)
 
I agree full heatedly. Not everyone can afford to be a member and reap the benefits that the mere peasants who own their copy can not.
I am not into just running a train on someone else's route. I get more enjoyment form designing and running on my own routes.
Until NV3 can provide a way to remove the "Bloat Ware" that unjustifiably increase's the storage demands on a HDD or in my case SSD, I will not give any additional cash to the "NV3 tax collectors"

In saying the above I enjoy TRS19 as I have done with a multitude of previous versions.

BTW, NV3 spend some of the taxes on improving the terrain editor and the please give us a "Square paint tool as well as the circle. The square would be great for fine edging etc.

My moan and groan is over.
 
Hi.

The possibility to switch back from driver to surveyor to fix something on the route not correctly defined and then again to driver to continue the current session would be certainly a great feature and a major enhancement for every trainzer.

But may be I will take the risk of being somewhat a rabat joy, I wonder a lot on how N3V will manage some implementation details and the interaction with scripting, as currently there are many scripted asset, rules and driver commands, which rely that in driver mode, after initialisation, the route map objects (except driver, vehicles and consist) do not change and rely on some internal data built at session initialisation (with no further update) based on the current route map object configuration... And every body knows that to support such new functionality the devil is always in the details.

For example, if I switch back from driver to surveyor and add or delete some junction, signal, crossing, … along a currently active path, the path will now be broken with an extra or a missing object along the path. How the interlocking tower will be warned when returning after the update from surveyor to driver of this update done on the fly, and will update its own internal data to support this update on the fly … And another example without any interlocking towers for trainzers that uses standard AI : if I move a trackmark or an industry which was in front of a train to somewhere else at the back, how the scripted AI command will be informed of the update and can reschedule itself to go now backward instead of forward to its target destination ...

So I see some major impact on scripted objects, on scripted rules and scripted driver commands, that will need to have their script updated to be ready to take in account any updates done on the fly ...

Again, such new supported functionality will be a major and great enhancement for developping a lot of things. So it is worth to support it and made all the changes needed to scripted assets. But N3V needs to gives to third party scripters some clues and more detailed information on how this will impact current scripted rules, scripted driver commands and other scripted assets, so that third party script developpers can update and adapt their assets to support this new functionalities. May be the Trainz plus program is also to enable scripters to adapt in advance their assets to these functionalities before they are included in normal releases ...

Only my scripter thoughts.
Regards.

Pierre.


Is Trainz going to send out some sort of message so we know in our scripts that something(s) have been added/deleted? This coming after async may truly be another earthquake.
 
So if a track is moved, I assume this will break any and all sessions that had vehicles placed on it. The more I think about this functionality, the less I like it:confused:
 
So if a track is moved, I assume this will break any and all sessions that had vehicles placed on it. The more I think about this functionality, the less I like it:confused:

This is why I cloned my TRS19 and setup a Trainz-Plus test folder with a full clone of my content. With this I can try the new features and not ruin my original installation and if this doesn't work, well no harm done, but the only way to find out is to try. This is something I learned more than a decade ago in the IT world. Setup an identical test environment so that things can be replicated and if things work fine, they can be moved into production. In my case, my 'production' version is the regular version and not my Trainz-plus clone.

The point you bring up here is a good one. We have to wonder how many times have we moved a track mark even a few meters only to have the AI drivers go ape sh*, ignore that track mark, and require us to edit schedules all over again. But... the only way to find out is to test it, and hopefully we'll be pleasantly surprised.
 
Last edited:
Since we are the omnipotent being in all our routes and sessions, we must take responsibility to not make any changes that could damage a session or route. No different from what happens currently if you change some track in a route, any session that was based on the previous state of that route will be damaged. The new on-the-fly feature will just make it easier to damage or make corrections, depending on your point of view. Nothing prevents people from not using this feature if they feel that the risk of damage is too high.

As for scripts getting confused, perhaps a process could be included to re-initialize any active scripts in a session when switching back to Driver. Would this have a downside?
 
Since we are the omnipotent being in all our routes and sessions, we must take responsibility to not make any changes that could damage a session or route.


True, but developers seem to have enough trouble now whether they are in session or route layer. This new function allows casual users of a session to modify a route ( I guess?).
 
So if a track is moved, I assume this will break any and all sessions that had vehicles placed on it. The more I think about this functionality, the less I like it:confused:

Hi Pitkin.

From my own surveyor route/session experience, you cannot move a stretch of track if there is some vehicle on the stretch of track. Only stretch of track with no vehicle on it can be moved. So surveyor or edit mode has already some protection mechanism to avoid breaking by error some tracks.
Regards.
Pierre.
 
Hi.

About scripts being notified of changes done on the fly, I have just discovered by looking at the script directory coming with current Trainz plus 2019Q1 version, that Trainz Plus supports already a new type of gameobject : AsyncObjectSearchMonitor , that enables to monitor objects in a specific category (either trackmark, interlocking tower, trigger, industry, … ), and when monitored it seems that the monitor will inform on demand any registered listeners scripts of any addition or deletion of any gameobject of the specific monitored type ...

This gives me the impression that N3V has already implemented something for scripts to be informed of objects creation / deletion on the fly, but as it happens often with scripting there is not already any documentation about it and scripters needs to find how to use it by trial and error as it is often the case with advanced scripting. But may be the scripting interface will be described and documented in the wiki before the new update on the fly is released in Trainz plus.

Any way when this new functionality will be released, all scripters will need to check their scripts compatibility and probably update some of their scripts to support the new functionality …

Regards.
Pierre.
 
Hi.

About scripts being notified of changes done on the fly, I have just discovered by looking at the script directory coming with current Trainz plus 2019Q1 version, that Trainz Plus supports already a new type of gameobject : AsyncObjectSearchMonitor , that enables to monitor objects in a specific category (either trackmark, interlocking tower, trigger, industry, … ), and when monitored it seems that the monitor will inform on demand any registered listeners scripts of any addition or deletion of any gameobject of the specific monitored type ...

This gives me the impression that N3V has already implemented something for scripts to be informed of objects creation / deletion on the fly, but as it happens often with scripting there is not already any documentation about it and scripters needs to find how to use it by trial and error as it is often the case with advanced scripting. But may be the scripting interface will be described and documented in the wiki before the new update on the fly is released in Trainz plus.

Any way when this new functionality will be released, all scripters will need to check their scripts compatibility and probably update some of their scripts to support the new functionality …

Regards.
Pierre.


Sounds encouraging.
 
Back
Top