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