Using UDS with session development

I sprung for TRS19 Platinum. So I have the UDS system.. My major activity is writing sessions for routes on the DLS developed by others (primarily Philskene). So, the route cannot be changed.

It seems now that UDS is not useful in developing and walking through a session. For example, if I run a freight into a town, then decide I want to add more scenery cars on a siding, then saving the session is no problem. But if I pick up a car in the town, then I cannot save the session because the freight is now in a new position from the beginning of the session.

The only method I have come up with is to open 2 edit sessions. First session is a clone of the session I am developing. The second one is the original, to make changes only to assets that will remain in their position. Maybe someone of you will see a way around this.

I've run into the same issue and ended up with a mess with all my consists out of starting position and other things in the session that were never right afterwards with modifications not showing up in the route. In the end, I use the UDS for route development and testing such things as ATLS crossings and ASB crossovers, signals, and other things that need to be addressed, but not for session development.

During my testing, I don't save anything and go back and make the changes in the route that need to be updated.

JCitron said:

I've run into the same issue and ended up with a mess with all my consists out of starting position and other things in the session that were never right afterwards with modifications not showing up in the route. In the end, I use the UDS for route development and testing such things as ATLS crossings and ASB crossovers, signals, and other things that need to be addressed, but not for session development.

During my testing, I don't save anything and go back and make the changes in the route that need to be updated.

Click to expand...

Thanks for sharing your experience. Probably no magic bullet I am missing. If we could move layers from one route/session to another, there may be some procedure that would work.

pitkin said:

Thanks for sharing your experience. Probably no magic bullet I am missing. If we could move layers from one route/session to another, there may be some procedure that would work.

Click to expand...

Yes, I think that definitely would be helpful. It would be nice too if the reset session rules could be updated to reset session. Just resetting the rules and commands is as useless as a brain fart because the consists are all still over the place and industries are all in different weird states. Having the option to not only return the driver commands and industry queues back to starting position, but also all the consists as well would be really helpful because that could get everything back to square-one should things get messed up. The ability to make this optional too, meaning a session author can set the option or not as required so that driving sessions with goals and what not can't be changed.

Since that fateful day that I got burned, I keep an easily accessible backup of my driving session should I make an unrepairable error. I learned my lesson the hard way.

A bit surprised at the lack of response to the question. I myself have also wondered how UDS could best be used for session development. I have also always been surprised at the lack of quality sessions for routes. Perhaps the cumbersome methods of creating sessions is why.

pitkin said:

It seems now that UDS is not useful in developing and walking through a session. For example, if I run a freight into a town, then decide I want to add more scenery cars on a siding, then saving the session is no problem. But if I pick up a car in the town, then I cannot save the session because the freight is now in a new position from the beginning of the session.

Click to expand...

The added scenery cars on the siding were put into the session layer and then saved as session. The moved vehicles will also be saved at the position they have moved to and will not be at their default starting position when the session is loaded at another time. It is not fun when this happens . This is when a previous cdp backup of the session working correctly comes in really handy.

Personally, while driving, I would make a note of where the scenery cars are to go. Then later (when finished driving) add the cars via "Edit Session" if wanting them in the session layer.
There are no moving track vehicles in "edit session".

If the scenery cars are wanted in the Route layer and you have bounced back to surveyor using "Surveyor Mode" via uds, the default session highlighted in the Layers tab is still session.
The session layer (in layers tab) will need to be changed to "Route and the save is "Route only" and "not the session" before going back to driving. This way the moving vehicles are not effected.

Content that is added to the session layer will not be visible if working on the route through "Edit route" via the Driver/Surveyor screen.

I use UDS for only minor "route" content amendments. Depending on what is being worked on, 99.9% of the work is done either via "Edit route" and "Edit session".
The world/environment is made in "Edit route". Track vehicles, commands and rules in "edit session".

Anyway, we all have our own way of doing things in getting the end result, and what may suit me may not suit somebody else.

Personally me I never use the USD system at all since it just messes everything up when you go back to driver mode and its useless as you can't save anything without saving the train at that location.
The only real time I will ever use it is when I need to debug something because something in the rules is stuck. It allows me to scan the rules that have already been fired and the rules that haven't yet - this is the only time USD is useful.

Personally I just revert back to standard edition on my Steam version by removing my login details so I get the traditional quick drive rather than the USD system (IMO there are more benefits for the Steam version with creation than there are with N3V's version). And when I want the USD system, i just enter the login details in the Steam version and I'm 'upgraded'.

Cheers

Hi All
In terms of modifying and updating sessions, it's not currently suited to this as any save of the session after you have started running the session will save at that point in the session. We hope to improve this in the future, but it's a matter of time and priorities.

In the mean time there are a number of things it can be useful for.

* Testing session rules. Specifically, if something isn't working, you can jump into Surveyor and actually see where it's getting stuck and potentially try out adjustments and fixes (you'd need to exit and then edit the original session to actually make the final changes, but for testing it is very useful).

* Trying out ideas that you might want to add into a session, without needing to actually alter the original session.

In both options, you do need to ensure that you don't save when exiting, or at least that you save a new copy of the session.

Another useful thing you can do is actually let the session run for a few seconds in Driver then save. This will allow the session to load with AI trains already moving (if they are following suitable commands).

Note that UDS does not stop you using Surveyor in the more traditional way (ie load the session using Edit Session, make your changes, save, then go to driver mode to then drive it). The main thing is that after you start driving, you should not 'switch' back to Surveyor mode if you intend to make permanent changes to the session.

Another thing to note is that you can make changes to the route itself (make sure you change to the route layers before adding any items though) and then save without saving the session. This can be useful if you are testing a session and notice an object out of place, or decide to add another object you might want on the route.

Yes, there are definitely some traps for the unwary, and we do hope to improve this in the future. But once you learn these, it can be a very useful tool in the creation and testing of routes and sessions.

Regards

The best advice I have recently received (needed lots) was to not use UDS. What N3V does not yet seem to understand is that a properly operating product sells more product. The greatest mistake they make is adding features on top of problems. Invariably these create more issues that "volunteer" customers have to find.

The forum is a double-edged sword. It will show positive accomplishments and achievements of customers adding items to the product. But it also shows problems from the simple to the complex. If I were a potential new customer I might skip a purchase since I do not need problems from a hobby-tool that constantly creates problems.

When a person with a marketing background makes decisions they invariable fall into the NEW category. They are fixated on that. If a former programmer were in charge they would stress stability and use-ability. Does New sell? or does "Stability" sell? When New impacts stability, as UDS does, then you have to re-balance your thinking. Maybe it is time to fix the foundation and skip that new coat of paint????

Managers are paid to achieve a balance and thus improve revenue. New on top of old, over and over will fail.

PS: Why are customers returning to TANE?

Dick not Nixon

I have been using the UDS since I purchased Platinum (in fact it was one of the reasons why I got Platinum) and the UDS is my favourite new feature. I have been using it for both route and session development without any problems, after an initial learning curve. There are some simple rules that should be followed to avoid some of the traps that some posters in this and other forums have mentioned.

I have created a Trainz Wiki page that explains the rules and techniques that I use. See https://online.ts2009.com/mediaWiki/index.php/How_to_Use_the_UDS_Interface

PS: "Why are customers returning to TANE?"

I am certainly not - I have uninstalled TANE from my system and will not be resurrecting it. There have been a "few" (a relatively small number) of posts in these forums from users who have decided to do that, but that also occurs after every new version of Trainz has been released and even after a new SP update. Users will base their decisions on a wide range of factors. Of all those who posted back when TANE was first released (and that was a very troubled birth - have we all forgotten?) that they will be going back to TS12 and will never use TANE again, how many have kept that "pledge"?

pware said:

I have been using the UDS since I purchased Platinum (in fact it was one of the reasons why I got Platinum)

Click to expand...

I did as well, and the ability to tap into the TCCP

pware said:

I have been using it for both route and session development without any problems

Click to expand...

As long as you know when to save and what, it's working great

pware said:

I have created a Trainz Wiki page that explains the rules and techniques that I use. See https://online.ts2009.com/mediaWiki/index.php/How_to_Use_the_UDS_Interface

Click to expand...

Thank you for that!

pware said:

PS: "Why are customers returning to TANE?"

Click to expand...

It may be that they just have TANE, and have not made the leap yet, and that's just how they are spinning it?

Currently I am targeting TANE SP1 with scripts, rules, drivercommand, etc. I think it's build 4.3, it allows them to run on TMR17 as well, so I keep TANE and TMR17 to test them. I can still edit them TRS19, which is nice. Otherwise, I'm done with TANE. Everything else is TRS19, very happy

Thank you for that support Christopher. The problem with the UDS, as is often the case with many new Trainz features, is one of user education. The information from N3V on how to correctly use it was there in the Trainz Wiki long before I posted my page (see https://online.ts2009.com/mediaWiki/index.php/Unified_Driver_Surveyor by Tonyhilliam and Pw3r and was the source for my "Dummies Guide to Using the UDS") but, as is usual with technology subjects, the important details are often buried in a mass of content and jargon. There is a lot of detail there that you have to wade through.

@pware :The problem with the UDS, as is often the case with many new Trainz features, is one of user education.


I don't think the scenario that I posted to start this thread can be overcome with user education. But I am enjoying reading the responses. As a side note, I have always suggested on the forum that rolling stock be in the session.

pitkin said:

As a side note, I have always suggested on the forum that rolling stock be in the session.

Click to expand...

That has also been my position. In TRS19PE and Trainz Plus it is also N3V's recommended practice for placing all rolling stock because the positions of all consists are stored in the Session data, regardless of where the consists are actually placed. This is one of the main reasons why users have been posting about problems with consists being out of position when they reload a session after editing a route. My recommended methods to solve this "problem" are to either not save the session (unless you want to save the consists in their new positions) or to save the session with a new name so that the original is not overwritten.

Isn't this explanation of the UDS process and example of the complexity of the process leavingopen an opportunity for a mistake:


You can add additional trains and replace existing ones when in Surveyor before switching back to Driver but make sure that you:-

1. have hit the P key or select Pause from the Tools menu first to stop all train movements, and
2. reset the Driver Setup Rule in the Session Editor before switching back to Driver

I am not sure I will remember this process when my attention is on different instructions needed to operate an AI train. Couldn't a single step accomplish this? Once you get into 2 or more steps to "do something" the reliance on the customer having a good memory rises.

Push this button and then a different button to do something seems open to errors that some programming might avoid.
-or-
Warn the customer, based on current conditions, that they should push the second button if Adding or Replacing Trains.

Thanks for writing the instructions. They are certainly a valuable asset and reveal some info on what the the sessions contain.

boleyd said:

Isn't this explanation of the UDS process and example of the complexity of the process leavingopen an opportunity for a mistake:


You can add additional trains and replace existing ones when in Surveyor before switching back to Driver but make sure that you:-

1. have hit the P key or select Pause from the Tools menu first to stop all train movements, and
2. reset the Driver Setup Rule in the Session Editor before switching back to Driver

Can I add new trains or replace existing trains after switching to Surveyor mode?

I am not sure I will remember this process when my attention is on different instructions needed to operate an AI train. Couldn't a single step accomplish this? Once you get into 2 or more steps to "do something" the reliance on the customer having a good memory rises.

Push this button and then a different button to do something seems open to errors that some programming might avoid.
-or-
Warn the customer, based on current conditions, that they should push the second button if Adding or Replacing Trains.

Thanks for writing the instructions. They are certainly a valuable asset and reveal some info on what the the sessions contain.

Click to expand...

The instructions are now outdated! The program automatically pauses, our request was granted during testing, when switching between Driver and Surveyor and back. This makes it a whole lot easier than having existing AI drivers mucking around as you're placing consists down. I've actually used this process to untangle the dweebs that have decided that skipping a station stop is more fun than following the instructions.

I don't see the purpose of resetting the rules in this case. With all the consists out of place, resetting the rules sends the rules back to the beginning, but the AI drivers are now out of position. This, as I've found out the hard way myself, wreaks all kind of havoc on the operation because the AI start backing up, switching tracks randomly, and getting stuck all over.

Introducing another consist is relatively easy if the rest of the AI are left to their schedules. With the program paused, simply add in a new consist using the Surveyor mode. Switch back to Driver, click on the consist, and then add in the rules, schedules, and what not for the new driver. It's situations such as this that are really helped with the Schedule Library and Copy Commands from combo. Once everything is setup, start up the session again by unpausing.

JCitron said:

The instructions are now outdated! The program automatically pauses, our request was granted during testing, when switching between Driver and Surveyor and back. This makes it a whole lot easier than having existing AI drivers mucking around as you're placing consists down. I've actually used this process to untangle the dweebs that have decided that skipping a station stop is more fun than following the instructions.

Click to expand...

Thanks for that info. I have updated the Wiki page.

JCitron said:

I don't see the purpose of resetting the rules in this case. With all the consists out of place, resetting the rules sends the rules back to the beginning, but the AI drivers are now out of position.

Click to expand...

Problematical. I can see both sides of this and my own experiences indicate that resetting can be useful. The Session Editor does give users the option of resetting all the rules or only selected rules. I have reworded that entry in the Wiki.

Peter

boleyd said:

I am not sure I will remember this process when my attention is on different instructions needed to operate an AI train. Couldn't a single step accomplish this? Once you get into 2 or more steps to "do something" the reliance on the customer having a good memory rises.

Push this button and then a different button to do something seems open to errors that some programming might avoid.
-or-
Warn the customer, based on current conditions, that they should push the second button if Adding or Replacing Trains.

Click to expand...

It's a double edged sword. If you start to automate operations to avoid users having to remember sequences of steps then you risk the accusation of becoming a "Nanny state" as well as reducing some flexibility. This way users have the option to Pause or not if that is what they wanted. It is not a situation that is unique to Trainz either.

Agree, but if you have a no Nanny button that allows you to leave your stroller and walk down the street should you so choose? Try the new world. Nanny (N3V) follows behind, with the stroller, always allowing you a safe harbor with a second push of the button. The second push is only a simple foolproof save of when you left the stroller.

N3V staff can then awaken Monday morning not dreading the fallout from what they thought was a really "cool" feature. Angry forum messages are reduced. Potential customers reading the forums are not "put off" and we can all relax when we try the UPDATE.

PS: I dislike "Grand" updates. Frequent, and less comprehensive updates are STRONGLY suggested. Charlie's fix may hurt Sally's fix under some odd circumstance. You have to risk this, but within reason. The BIG FIX can be a BIG PROBLEM.

I broadly agree with much of what you have stated. The BIG FIX can lead to big problems but can also lead to many benefits (and I have no doubt that there will be those who will disagree). While SP updates have traditionally been seen as "bug fixes" with some new enhancements, the general trend in the software industry over the last few years has been to use SPs or similar to introduce new features and feature updates as part of an incremental process.

Unfortunately the commercial pressures of competitors, deadlines, finances and customer expectations (right or wrong) reduces the time between update releases and the time available to test them before release.