Please, Help with Session Rules and Indentation?

[Chris004]

Hello,
I was wondering if I can have more than one instance of a rule activate the same indented block? Like several Directional Trigger Checks that activate the same Progressive List? Or do I have to duplicate that same list under each trigger-check rule. (A "go-to label" could work...Doesn't need to come back... Hmm, not seeing any "Go-To" or "Jump" rules)

I'm probably recreating a "Path Rule" or some-such, but I want it to do explicitly what I need it to do (I'm never sure what, exactly, I have asked the more complex rules to do). Besides I think it will be a good exercise in session-rule logic for me. I think solving this puzzle will give me a better idea of why these rules seem so complicated.

Basically, I am creating an exclusion block - a section of single-track mainline with a handful of entrances, where I will want trains to wait until the whole section of track is clear before proceeding.

//// OR, maybe, help finding links to these:

https://en.wikibooks.org/wiki/Trainz/Driver_Sessions_and_Rules mentions (but provides no links to) the following:

TRS2006 Sessions & Rules Guide (downloadable from Auran's web site)
Covers the subject in detail, except that it has no information about how to create Rules, only how to use them. Most of the material in this document is also applicable to TRS2004.

TRS2004 SP2 Variable Rules Tutorial (downloadable from Auran's web site)
Explains the usage of the variable Rules which were introduced with TRS2004 SP2. The downloadable package includes a sample tutorial route and Driver session.

A google search for those terms leads back to https://en.wikibooks.org/wiki/Trainz/Driver_Sessions_and_Rules

I did find:
Guide to Trainz… SIGNALLING at http://trainz.drucifer.net/Trainz_Signalling.htm I read this back in '07... didn't understand much. Definitely worth another read.

Thanks helping me learn all this stuff,
Chris

 

[Pendolino]

I think you can use variables and a "Variable Check" rule to achieve what you want, even though I am not sure it works to handle traffic on a single track line and to have trains waiting in sidings. (every ">" represent one indentation).

Directional Trigger Check #1
> Variable Change (setting: change variable "activate" to 1)

Directional Trigger Check #2
> Variable Change (setting: change variable "activate" to 1)

...

Variable Check (setting: check if variable "activate" is equal to 1, every second)
> Variable Change (setting: change variable "activate" to 0)
> Progressive List
>> Rule 1
>> Rule 2
...

When a train hits DT#1 or DT#2, it will set "activate" to 1; the "Variable Check" rule will then recognize that "activate" is now equal to 1 and execute the child rules (the first one resets "activate" to 0, and the progressive list is executed simultaneously with it). There is a little chance that two trains hit a DT at the same time, but this should not be a problem unless you run a very high-traffic operation.

It would be advisable - at least during the session development - to have a "Display extended HUD" and a "Variable Show" rule to monitor the value of the "activate" variable. Once you are sure everything works as intended, you can remove these two rules.

P.S. You can also force signal status (unless the signal is a scripted one) with the "Set Signal Extended" rule.

 

[Kennilworth]

Hi Chris

Another way of doing this would be to use a driver command called "Token Management 2" by trev999. This is available as part of the Shedmaster package of rules and driver commands which is available free from the Potteries Loop Line website http://www.potteriesloopline.co.uk/

This allows a train to take control of a token for a section of track on a first come first served basis and prevents any other train from entering that section until the controlling train releases the token. In effect it works in a similar way to the real token system used on a single track railway.

The Shedmaster rule also contains other very useful driver commands so make sure that you also download the pdf that explains how these commands are used.

Regards

Brian

 

[Chris004]

Most Helpful, Thanks

Hi, Guys,
Very helpful and very on-point.

... use a driver command called "Token Management 2" ... allows a train to take control of a token for a section of track ...

I came across this while first working at this problem. Reading the description gave me the basic logic to implement the parts of this I need with just a handful of much simpler rules.

The Shedmaster rule also contains other very useful driver commands so make sure that you also download the pdf that explains how these commands are used.

And, since it is a very powerful rule, learning how to use it might take more time than duplicating the small bit of it that I need right now. Also, I think it will be a good exercise in coding session-rule logic.

(And, until you provided me with the link, I couldn't find all the pieces. I thought it was a payware package. I look forward to building a session around it, until now I've always had to use one dedicated AI train per task).

Directional Trigger Check #1> Variable Change (setting: change variable "activate" to 1)
Directional Trigger Check #2
> Variable Change (setting: change variable "activate" to 1)
...
Variable Check (setting: check if variable "activate" is equal to 1, every second)
> Variable Change (setting: change variable "activate" to 0)
> Progressive List
>> Rule 1
>> Rule 2
...

Of Course! I am going to use a variable: BlockInUse. It didn't occur to me to have each of the trigger-tests set a variable to show if a train is waiting (and encode which trigger it is waiting at? ... Hmm).

I think I have a work around for simultaneous arrivals... I'll just walk it through to see:
...

All signals at the entrances are initially set STOP.

WHEN a directional trigger (located just ahead of the signal at an entrance to the block) is activated by a train going IN:
THEN:
-- IF BlockInUse == false (0)
-- THEN:
-- -- The signal associated with that particular trigger is set PROCEED
-- -- BlockInUse is set to true (1)

WHEN a directional trigger just inside an entrance signal is activated by a train going IN
THEN:
-- The associated signal is set again to STOP

WHEN a directional trigger just inside an entrance signal is activated by a train going OUT
THEN:
-- BlockInUse is set to false (0)​

Wow, that's it? I thought there was going to be a lot more to it than that... so, of course, I would have made it way more complicated than that. Eeewww... I left out the bit about the junctions... tomorrow then. Does a 'Set Junction' session rule override a driver's lock on a junction?... And the code for that would need to know where he's going?... Oh, yeah... definitely tomorrow. It seems there's a 'Schedule Library' with a 'Copy commands from', an 'if{}else{} driver-command' and a 'wait for green' in my future...

I see now that my original question is moot: Each trigger will need its own progressive-list code-block, since each works with a different signal. (Maybe when scripting I can use something like an array of pointers to "type signal." Not gonna try it here in session-rules.)

And, ok, not quite 1st come 1st served - the train at the trigger that gets checked 1st will get served 1st - and there is no way to allow another train going the same direction to follow behind (which Shedmaster can do). But the section of track has so many ways in and out, that the definition of 'same direction' is pretty squirrelly. (Never mind devising a test for it)

Sorry, non-native speakers of American: Squirrelly - Complicated to the point of making ones head spin. Hmm... Dictionary says: eccentric, erratic, darting, unpredictable. Sound like anyone we know? Maybe if I get some sleep I'll be alright.

Can you imagine what a mess my code would look like if I hadn't tried to describe it here?

Thanks again.
Chris

 

[Kennilworth]

Hi again Chris

Have you looked at the SCS2013 rule? This contains over 100 driver commands including such conditional ones as "If, If Else, If End" and "Select, Select Case, Select Case Else, Select End" and "Goto", "Label" and "Gosub", "Return" amongst others. It also has comprehensive variables including "Y/N" and "Integer" which can be used with the conditional commands to automate many tasks. It has a command to load a variable with the size of a queue at an industry which can then be compared to a second variable to decide when the industry requires replenishing. This can be done without having to edit the industry.

If it interests you then have a look at this thread http://forums.auran.com/trainz/show...ike-to-try-SCS2013-for-TS12&highlight=SCS2013 which gives you a link to download it along with other information. Be aware though that it is quite unlike the usual driver commands and has a fairly steep learning curve as it has an external editor for entering the commands into the threads. Once mastered though it is far more versatile than the usual driver commands.

Unfortunately it doesn't work with T:ANE as the editor needs to scan the route into its database and it can't read the new file format used in T:ANE.

For what you are describing possibly two variables would be needed, one Y/N to indicate direction of travel and an integer one for the block where 0 would indicate the block is clear and anything over would indicate the number of trains within the block. Nested "If" commands would enable the two variables to be used together to decide if an approaching train can enter the block.

Regards

Brian