Setting Default Driver Commands

[boleyd]

How do I set a list of driver commands so that they apply to all sessions without being required to load them individually for each session?

 

[pware]

You could try configuring either a Driver Setup Rule or a Schedule Library Rule with the commands you want and copy that from one session to another. I have copied the Driver Setup Rule between session but have not tried copying the Schedule Library, but in theory that should also work.

Tips and pitfalls can be found at http://online.ts2009.com/mediaWiki/...Session_Editor#Copying_Rules_Between_Sessions

 

[boleyd]

How do I set a list of driver commands so that they apply, in all routes, without being required to load them individually for each route?

A standard set of driver commands that can be used within any new route. So, if I download a route I will have available the specific driver commands I normally use and not have to re-select them. As an example Drive To would always appear in the list of commands available for any session.

 

[pware]

Do you mean a set of commonly used (by you) driver commands that are immediately available for selection in the Driver Setup Rule or for adding directly into the driver command bar in Driver mode without having to use the Driver Command Rule first?

If so then what you want does not (yet) exist. Perhaps add this to a post in the Suggestions Forum.

 

[ecco]

Do you mean a set of commonly used (by you) driver commands that are immediately available for selection in the Driver Setup Rule or for adding directly into the driver command bar in Driver mode without having to use the Driver Command Rule first?

If so then what you want does not (yet) exist. Perhaps add this to a post in the Suggestions Forum.

It's been requested in the Suggestions Forum. It's been requested in Beta test feedback. The entire implementation of the driver commands interface is really awkward and poorly thought out. That's indicative of Trainz emphasis being on creating and driving compared to creating managing (letting the AIs do the actual driving). The interface might have been OK with three trains running on four baseboards. For a large layout stretching 20 miles of baseboards, 50+ industries and a dozen trains, it is extremely awkward.

Creating strings of driver commands is like writing computer programming code. I don't know of any language that does not permit copy/paste or search. I don't know of any programming language that does not allow a printout of the entered code. I don't know of any language that lets you see only about 20 instructions at once.

I'm not holding my breath for any changes to the driver interface.

 

[JCitron]

See this for my workaound.

https://forums.auran.com/trainz/sho...Commands-for-All-Routes&p=1793122#post1793122

 

[pware]

Creating strings of driver commands is like writing computer programming code. I don't know of any language that does not permit copy/paste or search. I don't know of any programming language that does not allow a printout of the entered code. I don't know of any language that lets you see only about 20 instructions at once.

While I take your point, in my researches for several technical works I have come across a number of "programming languages" that fit your descriptions above - mostly in the multimedia, graphics and gaming areas.

With Trainz driver commands the "programming", as it was originally created, was totally linear and this works well within the confines of the "game" and the requirements of the vast majority of users. Some users with more advanced needs, such as trev999, have created driver commands that add branching capabilities ("Jump to Label", etc) that were never intended by the original game designers. I have come across very few sessions that make use of these more advanced driver commands.

The question will ultimately come down to one of "useability" vs "complexity". I have created some very complex sessions in the Session Editor (where cut, copy and paste are available) but the idea of printing them out would serve no useful purpose and would be a waste of effort and paper. Ditto Driver Commands.

The current system of "programming", and I include the Session Editor and Session Rules in that definition of "programming", certainly has its limitations, but it is no different from other "multimedia/gaming" user languages that I have come across. In my view, it still meets the needs of the vast majority of Trainz users. Certainly there will be users who are very experienced at using modern procedural and event driven languages who could be very creative and productive if such capabilities were available in Trainz driver commands and the Session Editor. In those cases, the features you are requesting would be of some advantage, but I would put this well down the list of priorities for N3V.

Perhaps we may see some incremental developments in this area.

My thoughts.

 

[Kennilworth]

Hi Dick

Try copying the Driver Commands rule that you have previously set up and pasting it into the new session, after removing the existing rule of course. I regularly copy and paste such as the Driver Commands, Schedule Library and Input Table rules between sessions to avoid rewriting long lists of commands and variables. You just need to delete any schedules or variables from them that you don't need in the new session. You can copy the Driver Commands rule between sessions in different routes too (I've just tried it in TRS19).

Regards

Brian

 

[pware]

Brian

Your solution is correct but the OP has asked why you cannot have a default set of driver commands, selected by the user, that are automatically loaded every time a new session is started without needing to copy and paste. It is a worthwhile suggestion but, I think, it will be well down the list of priorities. In the meantime, your solution is the one that we must use.