Is there a "Variables" or Token system I can use in DriverCommands AND Session Rules?

[davidbird]

Is there a "Variables" or Token system I can use in DriverCommands AND Session Rules?

I'm trying to get a session running in which the main focus is the player driving a train, with other trains as "moving scenery".

I have a situation where I need a Token - in the UK railway meaning of the word. I can use a variable to replicate this.

The problem is this.

I need an AI train to set the variable (or request the token), which is easily done by inserting driver commands in the Driver Setup rule.
I then need the player train to check the token/variable in a series of Rules/Child rules (for example CheckTrigger -> Check Variable -> Set route)- if I use Driver Commands, manual driving is not available.

Each seems to be easily achieved on it's own, but combining the Rules and Commands seems harder. Is there a system I can use that is accessible from both Commands and Rules?

Thanks

 

[trev999]

Hi David - The fact that the player is manually driving a train does not preclude the use of driver commands. Particularly, when the player train is stopped at a signal then I don't see why the player could not issue a token request driver command. When the train is moving then driver commands issued do cause the throttle to be set at zero, an undesirable situation, I agree.

A couple of questions, David: Do you own Potteries Loop Line route or have you downloaded the freeware driver commands from the PLL web site? Useful commands are:
Token Management 2, Set Selected Signal State, Shunt Sequencer and some others.

Have you been reading the TANE Forum discussions about a simple token system, or are you familiar with Token Management 2 driver command?


If you are willing to go to some trouble to set things up then an alternative is to have a 'proxy' loco manipulate the driver commands for the player. By that I mean, a loco that stands innocently in a yard somewhere waiting for a trigger actuated by the player train and then executes a few commands, then waits for the player train to trip another trigger and does a few more commands.

Under normal circumstances a player-driven train should be governed by signals and instructions from the guard, and possibly by the possession of a token to proceed. I did a little research and came up with this scenario:

The player train arrives at a signal which is set against the train. In doing so it passes a trigger. The train waits for the signal to clear and proceeds to the next signal etc.
The signal is controlled by a proxy loco which, on seeing the trigger, sets the signal to red and then requests a token for the section of track to be traversed.
When the token is granted, the proxy clears the signal and waits until the player train reaches a trigger at the other end, indicating that the token can be released. I haven't gone into full detail as yet but think that 'Wait for Trigger' could do duty here.

Regarding the setting of the route, there are many ways to that. Part of the PLL commands package included with the Deep Pit Circle DRIVE add-on contains two methods of setting the path. One is by using Way-points and Route Selector assets, and the other is by using the Shunt Sequencer and its HUD. Both methods are aimed at player-driven trains.

In the waypoint method, the chain of destinations is first issued to the player train by a series of driver commands before the player takes control. Then as the train approaches a route selector (that looks like a blue trackmark) the path is set according to the current waypoint name. Then a new waypoint is brought to bear and the train drives to another route selector until the destination is reached.

In the Shunt Sequencer method, a HUD with active links on it can be clicked by the player to select a range of paths, set signals or uncouple a particular vehicle, counted from one or other end of the train.

Another approach is to use 'Schedule at Trackmark'. A player train arrives at a red signal and comes to a stop. As it does so it passes a trackmark that inserts some driver commands into the schedule to request a token and then set the path. Player then takes over again.

These are just some ideas on how to tackle the job. If I can't find a way to do it then I often make my own method. Anything of this type will always require setting up, though

Best Regards - Trevor

 

[davidbird]

Thanks Trevor.

I've been investigation the Token Management 2 , although as it uses driver commands, I'm trying to steer clear of that. I'm intending to simulate the driving of a real train, in which the driver only controls the throttle and brakes and obeys signals, not issuing routeing commands. Issuing a drivercommand, even when the train is stationary, causes the control to be returned with the brakes fully applied, possibly not what is intended.

I'm not concerned about route setting, I've got that sorted with ITs, although the Shunt Sequencer sounds as if it may be useful elsewhere.

The precise situation is this...

                    |-------------S2---\            /--------S4--------platform 4
       --------S1-----------------------\----------/----------S3--------platform 3

S1, S2 are signals controlling approach to a station from left to right, S1 is a main 3A running signal, S2 is a gpl shunt signal, S3, S4 control exit from the station, right to left.
A loco is sitting at S4. A train approaches S1, sets an IT path S1-S3, and clears the path, stops at P3.
Loco sets path S4-S2, clears path, reverses direction, sets path S2-S3, couples onto rear of train in P3.

All so far, so good, I have this sequence working perfectly.

The key point is this. The siding, with signal S2, is a virtual siding, with invisible track, coincident with the main line, so a loco sitting at S2 appears to be on the main line.

A 2nd train approaches from the left. If this 2nd train calls for the S1-S4 path, before the LE calls the S2-S3 path, it will prevent the LE from leaving S2, and will appear to visually pass through it...

A token, issued to the LE, and also called for by train 2, will prevent train 2 from requesting path S1-S4 until the LE has completed its shunt and released the token.

As I'm intending one of the trains to be entirely player-driven, and so wish to avoid using drivercommands, I need a token (or a variable) that can be accessed by both AI (drivercommands) and Session Rules (for route setting)

Hope that makes things clearer

 

[trev999]

Hi David - I've done some research and come up with this solution, but I don't know if it is going to work when coupled with Interlocking Towers.
You don't state which train is to be player controlled so I am assuming that the LE is AI controlled. There are a couple of unknown factors.

The name and value of a variable accessible from rules is stored in what is known as a session variable. This means that the info is stored along with the session and will be restored when resuming a session.

The default variable is named 'score' with a default value of 0. Let's adopt that as our token, although you can change the name if you prefer. You can make it visible in the HUD if needed by adding a Variable Show rule to the session.

Set up the Input table to manipulate the value of score by driver command.

Input Table:
svar,score,inc,1
svar,score,eq,0
svar,score,eq,1

The first entry provides a menu option for the command ChangeSVariables to add 1 to score.
The other entries provide menu options for the command WaitUntilSVariable to test the value of score is this should prove necessary.

We can use a Variable Check rule to examine the value of score and set Signal S1 to Danger if score = 1 using a Set Signal child rule. A second Variable Check rule is needed to check if score is greater than 1. If so it must set Signal 1 to automatic and also reset score to zero.

The value of score starts at zero, advances to 1 while the token is taken and progresses to 2 while the signal is cleared and then goes back to zero.

If the LE is present at S4 and there is a train at platform 3 then S1 will be at STOP.
The LE increases the value of score to 1, taking the token and forcing S1 to remain at STOP. It then moves to S2 and back again.

If the train at platform 3 has since lost its loco then the LE can couple to it otherwise, before coupling to the train the LE must issue another driver command to increase the value of score to 2 so that it can clear S1 and return to zero.

It would seem that the player train 2 would not need to take the token as it can only pass S1 when the token is free. If it does indeed need to change the value of score then a trigger needs to be placed at a convenient spot and rules Trigger Check > Variable Check > Variable Modify can be set up. In that case, Variable Check prevents setting score to 1 if it already at that value.

In a test run the Set Signal rule failed to hold the signal at Danger after the LE passed the junction at S3. By that time the track was clear for train 2 to proceed.

Best Regards - Trevor

 

[davidbird]

Thanks again Trevor. From what you've said, it's plain that a "variable", as used in Variable Check rule is the same as a "sessionvariable" as used in WaitUntilSVariable command. The use of the terms "variable" and "session variable" had obviously confused me into thinking they are two different things.

I should be able to get this to work, as I have previously used variables successfully in another situation.

Incidentally, the siding is an invisible, virtual siding in order that the 3A signal S1 always "reflects" the aspect of the signal at the rhs end of the platform. If I had left it as a real track, and had the IT paths setup as S1/S2/S3 as a single path, then if S5 (not on the diagram but at the rhs of platform 3) was red, S1 would be green; and if P3 was occupied S1 would still show a yellow proceed aspect. Both of these situations are just wrong, and can only be avoided by removing S2 from the path.

Thanks again for your help, this is turning into a useful distraction from the in/out/shakeitallabout that's on the TV just now...

 

[davidbird]

Thanks Trev. All working fine now.

 

[trev999]

Glad to be of assistance, David. I was quite intrigued by your use of invisible track at S2. Why did you find it necessary to adopt such an unusual approach?

It's late at night now and mid-winter so I will not stay up to look for your reply tonight.

Cheers - Trev

 

[davidbird]

Glad to be of assistance, David. I was quite intrigued by your use of invisible track at S2. Why did you find it necessary to adopt such an unusual approach?

...
Incidentally, the siding is an invisible, virtual siding in order that the 3A signal S1 always "reflects" the aspect of the signal at the rhs end of the platform. If I had left it as a real track, and had the IT paths setup as S1/S2/S3 as a single path, then if S5 (not on the diagram but at the rhs of platform 3) was red, S1 would be green; and if P3 was occupied S1 would still show a yellow proceed aspect. Both of these situations are just wrong, and can only be avoided by removing S2 from the path.

The signal S1 ia a 3-aspect main running signal, S2 is a 2a GPL "running shunt" signal. For S1 to show "proceed" (yellow OR green), S2 must also show "proceed". Sig S2 is included as an External Object to a S1/S3 path. I could have included it in a straight path S1/S2/S3, but this would have "increased" the aspect of signal S1, as I said above, or even allowed S1 to show proceed when S2 is at stop.

It's all concerned with getting the running shunt signal to behave within the rules, as part of an attempt to recreate Nottingham Midland Station, in 1980 condition, as in this diagram here

[URL=http://s1354.photobucket.com/user/davidjbird/media/NotMidWest_zpssmaepznt.jpg.html][/URL]

The whole thing is inverted, north is downwards on this diagram and S1=TT288, S2=TT281, S3=TT276, S4=TT275.

 

[trev999]

Hi David - Thanks for clarifying that, and sorry for not taking more notice of your earlier explanation.

I had in the back of my mind the idea of creating a special type of repeater signal that echos the state of a specified signal. Probably too much effort to go to as there would be very little demand for that facility, so I guess your solution is easier to implement.

Cheers - Trev

 

[davidbird]

...
I had in the back of my mind the idea of creating a special type of repeater signal that echos the state of a specified signal. Probably too much effort to go to as there would be very little demand for that facility, so I guess your solution is easier to implement.

Cheers - Trev

Yes, I had that idea as well, and also came up with the "too much effort - this is probably easier" way of doing it. The former would be more satisfying, though.