Favourite rules other people may not know about?

GreyAreaUK

New member
Morning.

Like many, I make fairly heavy use of the DLS, and check it most mornings/evenings to see what's new. But I tend to focus on 'physical' items - trees, buildings, rolling stock etc. It occurs to me that I'm missing out on a lot of additional functionality, and I was wondering if people could post their favourite rules and associated things (like track markers that do 'stuff').

Many thanks, and happy Trainzing.
 
Thanks for the links, I had not noticed those pages. Is there something similar for Driver Orders? I looked for it using the search engine, but with no results.

I also noticed the list does not include two of my favourite rules: Un-portal and Un-portal 2: I use them a lot to generate random trains appearing the route map or strings of cars in sidings or yard tracks.

I also love other rules that allow making sessions different every time they are played (e.g. Variable Random) even though this makes beta-testing the sessions a long process.
 
Thanks for the links, I had not noticed those pages. Is there something similar for Driver Orders? I looked for it using the search engine, but with no results

Strange that you asked. Just a couple of days ago I started creating a Driver Commands List wiki page. It is proving to be harder than the Rules pages were so progress is slow, just a few commands in it at the moment. In researching the commands (i.e. testing them) I have discovered that my initial ideas about what some of the commands did was wrong. I have also found a few on the DLS that do not work well in TANE so I will not be adding those.

It could be a while before it is ready for public consumption.

I will have a look at the Un-Portal rules.
 
Thank you in advance, it would be a very valuable addition to the Wiki for session creators.

I understand the magnitude of the task: there are many rules on the DLS that come with no instructions about their use :(.

As regards to the Un-Portal rules, I discovered a pair of glitches in the "Un-portal" rule:

https://forums.auran.com/trainz/showthread.php?122612-Portal-generated-trains-are-they-really-random

This one is not very importantand its effects can easily be mitigated by assigining the most common trains to the most frequently spawned slots.


https://forums.auran.com/trainz/showthread.php?24258-Un-portal-problems&highlight=un-portal

This other, conversely, can really ruin your day: the only solution I found so far is adding a driver order to every spawned train so that it increases the value of a dedicated variable by one (driverless trains have no orders, so they wouldn't affect the variable value). The variable is then compared with the expected number of generated trains: if the values do not match, the session is terminated. It's crude, but it is the only way I found to deal with this issue.

I do not know if such issues are also present when "Un-portal 2" is used, as ascertaining it would require observing the portal behaviour for a long time.
 
I have added the Un-Portal Rule to the Trainz Session Rules Wiki pages. Unfortunately I could not get the Un-Portal 2 Rule to work in TANE (beta build 97285) but I could not really see any differences between the two.
 
Hi

The difference between the two rules is in the way that they produce consists. The Un-Portal Rule behaves like a normal portal and produces consists that are moving and gradually emerge. Un-Portal 2 produces the whole train immediately and it is stationary. One thing to be careful of though is that there is enough space for the whole train to be placed at once otherwise the consist won't show.

Un-Portal 2 is ideal for populating sidings on a route. Produce the consist, decouple the loco and delete it. You are then left with a consist that can be shunted, added to a passing train or just used as scenery. If you enter a number of consists in the portal you can use the option to produce one randomly from the list which will give a different look to the session each time it runs.

The big advantage of these rules is that you can place a trackmark to be used as a portal anywhere that you want in the session layer which is ideal for built in locked routes.

Regards

Brian
 
As regards to the Un-Portal rules, I discovered a pair of glitches in the "Un-portal" rule:

The second of your two "glitches" has been reported with some other portals (but not all) as well so it may not be a unique feature of Un-Portals.

As for the non-random glitch, have you tried placing the Randomize Rule near the top of the session rules list? This may resolve that issue.
 
Is the un-portal supposed to work in TRS19? The Add Portal dislog box is empty even after I added a new TrackMark. Saved and closed the route/session. Re-opened same and still nothing in the dialog.
 
Is the un-portal supposed to work in TRS19? The Add Portal dislog box is empty even after I added a new TrackMark. Saved and closed the route/session. Re-opened same and still nothing in the dialog.

I just tested it on TRS19 (build 97923) and it is working fine.
 
I added a trackmark, named test1.
In the un-portal edit box, I click on Add Portal and nothing is showing.
Am I missing a step?
TRS19 97923 un-portal TM.JPGTRS19 97923 un-portal add portal.JPG
All this in 97923
 
No, you don't seem to be missing a step as that is exactly what I do and the dialogue box window is filled with all the trackmarks I have added to the layout.

A few thing to check and/or do (I have no idea if they will be useful or not but when you are clutching at straws ...)


  • Was the trackmark added in the Route Layer group or in a Session Layer?
  • Perform a DBR
  • Test the procedure in TANE (although your screenshots like like TANE your post said TRS19)
  • Howl at the full moon
 
Last edited:
1 Does it make a difference? Added another trackmark in the session layer. Still nothing
2 Doing a DBR now. We'll see later.
3 It's in TRS19, I don't think TANE has the ground bolts. Tried it in TANE 94916 SP3 and it works
4 Will have to wait until Friday, Nov 23

2 later, didn't help
So unless something better comes along, will try #4
 
Last edited:
I now have a Driver Command List Wiki page up and running at http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List

So far I have only about 30 commands of the hundreds available, built in or on the DLS. It is slow going as I test each command to see how it works first. Documentation is not always a strong point in Trainz script creators and I have found (and reported) a few that do not work or work differently in TANE and TRS19.
 
I now have a Driver Command List Wiki page up and running at http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List

So far I have only about 30 commands of the hundreds available, built in or on the DLS. It is slow going as I test each command to see how it works first. Documentation is not always a strong point in Trainz script creators and I have found (and reported) a few that do not work or work differently in TANE and TRS19.
So far an excellent job. If I would have known several of these explanations, I would not have to open new threads asking for things. Thank you very much for doing what Auran should have done long ago.
 
I now have a Driver Command List Wiki page up and running at http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List

So far I have only about 30 commands of the hundreds available, built in or on the DLS. It is slow going as I test each command to see how it works first. Documentation is not always a strong point in Trainz script creators and I have found (and reported) a few that do not work or work differently in TANE and TRS19.
Your work is appreciated. However, as you said, it is slow going and there are hundreds. Isn't this something N3V should be doing? When a creator comes up with a new Rule, That Rule should be submitted to N3V along with documentation of what the Rule does and how to implement it. After evaluation (by N3V or dedicated testers), N3V should put it up on CM and simultaneously post the documentation.
 
When a creator comes up with a new Rule, That Rule should be submitted to N3V along with documentation of what the Rule does and how to implement it. After evaluation (by N3V or dedicated testers), N3V should put it up on CM and simultaneously post the documentation.

In an ideal world yes. The same complaint is made of creators who upload routes and sessions with only a scant description "My great route, try it you will love it". There is a freeware forum where more detailed documentation can be posted and questions asked but this is little used. I suspect that imposing such a requirement would see contributions almost totally dry up. Besides, experience has shown that programmers often make poor documenters.
 
Back
Top