.
Page 3 of 3 FirstFirst 123
Results 31 to 43 of 43

Thread: Unified Driver Surveyor Feedback (pre-beta)

  1. #31
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    Seems ok to me. Can't use it yet.

  2. #32
    Join Date
    Oct 2007
    Location
    New Zealand
    Posts
    186
     

    Default

    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.

  3. #33
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    Quote Originally Posted by pguy View Post
    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.

  4. #34
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    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

  5. #35
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    25,186
     

    Default

    Quote Originally Posted by pitkin View Post
    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
    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 by JCitron; May 24th, 2019 at 10:18 AM.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019: 98592

  6. #36
    Join Date
    Nov 2006
    Location
    Netherlands, for now in, Montreal, CA
    Posts
    5,108
    Blog Entries
    1
     

    Default

    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?


    70337:
    TRS19 build 98592| Win10 Pro 64 bit, i7-7700 3.6GHz 16 GB, GTX 1070 Ti

  7. #37
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    Quote Originally Posted by martinvk View Post
    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?).

  8. #38

    Default

    Quote Originally Posted by pitkin View Post
    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
    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.

  9. #39

    Default

    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.

  10. #40
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    Quote Originally Posted by pguy View Post
    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.

  11. #41
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    447
     

    Default

    Quote Originally Posted by pguy View Post
    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.

    Good point. I have experienced from time to time 2 traincars that are overlapping each other. This was from trying to reuse older sessions. I assumed the session stores the coordinates of each car.

  12. #42
    Join Date
    Nov 2006
    Location
    Australia, n.s.w, Woronora
    Posts
    544
     

    Default

    Quote Originally Posted by Tony_Hilliam View Post
    We've released a sneak peek video of the upcoming feature that allows you to instantly switch from Driver to Surveyor. There's also a short blog entry here.

    We've taken a fairly extreme approach to editing in the short video, and we really can't wait to hear your feedback on more practical uses you come up with.


    There are still a few more tasks to tidy up before we get the first build out to our Gold Class members for testing in the coming weeks.


    Feel free to ask questions and give your feedback here on what you've seen so far.
    I may be wrong but wasnt the first ever Trainz like this.

  13. #43
    Join Date
    Nov 2006
    Location
    Australia, QLD, Brisbane
    Posts
    6,997
     

    Default

    Quote Originally Posted by Sean_lee View Post
    I may be wrong but wasnt the first ever Trainz like this.
    Nope. The original Trainz edition (circa 2001) supported multiple modules open in their own sub-windows, but not swapping back and forth between the modes on a single route. My theory was that we might want to be able to open a "development plan" for part of a route, edit it, and then apply the edits back to the original route which was still in operation. It's not something that we ever developed, and so we dropped support for the module sub-windows since they were kind of pointless without that capability.

    chris

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •