Variables - Instructions?
- Thread starter boleyd
- Start date
Kennilworth
Active member
Hi Dick
Have a look at post #8 in this thread http://forums.auran.com/trainz/showthread.php?131525-Simple-working-token-system-for-T-ANE
Regards
Brian
Have a look at post #8 in this thread http://forums.auran.com/trainz/showthread.php?131525-Simple-working-token-system-for-T-ANE
Regards
Brian
. I think the shunting session does it based on unloaded cargo.I looked at the Variable Check Rule. I assume that the language/structure is that used for scripts. While I can understand most of it I hope to not have to write one of these. I remain confused as to how you incorporate(use) one of these rules in a set of driver commands. There seem to be several of them to manipulate and examine variables. But, How do you initially setup and "register" the variable for these rules/commands to act on?
As far as I know, the only way to change the set of driver commands associated with a driver is having its trains pass on a trackmark, and then activating a different "ScheduleAtTrackmark" rule (which appends a set of commands to the driver) depending on the value of a given variable.
Kennilworth
Active member
Hi Carlo
The driver commands "Insert Buff Label", "Jump to Label", "Skip if S-Variable" and "Wait Until S-Variable", all by trev999 allow you to jump forward to commands in different parts of a schedule depending on the value in a variable.
Dick - the variables are initially set up in the Input Table as explained in the post that I linked to above.
Regards
Brian
The driver commands "Insert Buff Label", "Jump to Label", "Skip if S-Variable" and "Wait Until S-Variable", all by trev999 allow you to jump forward to commands in different parts of a schedule depending on the value in a variable.
Dick - the variables are initially set up in the Input Table as explained in the post that I linked to above.
Regards
Brian
Ok, thanks.... I should be ok now.... Haven't programmed for 30 years. Univac-1's were a bit simpler. I miss machine language. These many "styled to purpose" languages and structures are something I never messed with. Stopped at Cobol. TANE has now offered a proper platform but setting up a complex "real" railroad has not kept pace. Lots of great pieces but each in their own realm. Input Table - seems logical NOW...
What's this Input Table rule all about?
Among the ways to control a train are Rules and Driver Commands.
Rules usually have an effect on all trains passing a certain point on the track, such as a trigger or trackmark.
Driver commands usually have an effect on only the train that issues the command.
When rules are scripted it is possible to present the player with a text box (field) into which they can type a value, numeric or alphabetic at Surveyor level.
When Driver commands are scripted, the facility to type in variable data is not available. Instead, a tier of menus is presented from which the player chooses one option on each tier. In order to allow some control over the contents of a menu, a very clever man by the name Atila Barut invented the Input table, a work derived from that of an equally skilled man going by the handle of Brummfondel. The Input Table is a rule, so the user can type in variable data, i.e. information that can be changed.
Driver commands can be made to look up the current value of a piece of information (a variable) by going to the Input Table rule* and finding the value assigned to a tag, or identifier, and presenting that info in a menu tier.
Each driver command that makes use of the input table has its own set of identifiers used to store and retrieve the information.
* Actually, the information captured into the Input Table is stored in the session files and driver commands need to dig out the required information based on the identifier.
Among the ways to control a train are Rules and Driver Commands.
Rules usually have an effect on all trains passing a certain point on the track, such as a trigger or trackmark.
Driver commands usually have an effect on only the train that issues the command.
When rules are scripted it is possible to present the player with a text box (field) into which they can type a value, numeric or alphabetic at Surveyor level.
When Driver commands are scripted, the facility to type in variable data is not available. Instead, a tier of menus is presented from which the player chooses one option on each tier. In order to allow some control over the contents of a menu, a very clever man by the name Atila Barut invented the Input table, a work derived from that of an equally skilled man going by the handle of Brummfondel. The Input Table is a rule, so the user can type in variable data, i.e. information that can be changed.
Driver commands can be made to look up the current value of a piece of information (a variable) by going to the Input Table rule* and finding the value assigned to a tag, or identifier, and presenting that info in a menu tier.
Each driver command that makes use of the input table has its own set of identifiers used to store and retrieve the information.
* Actually, the information captured into the Input Table is stored in the session files and driver commands need to dig out the required information based on the identifier.
Hi Dick - A variable is registered by adding a rule to the session: Variable Modify. Then Edit the rule to set it up. All the underlined words in the rule window can be clicked to change their setting. For example, if you click the word score then an input box opens to allow you to type the required name.
A variable starts out with a value of zero. You can set a value by Adding 1 to it or by Changing the value to whatever you want.
To make the variable visible, add the Custom HUD (Heads-up Display) to the session.
Then add another rule: Variable Show. Edit it and change the variable name from score to whatever you want. Also change the label to something you will recognize when it is displayed in the HUD.
The Variable Check rule allows you to carry out some action based on the value of the variable. This is done by adding a child rule, such as a Pop-up Message. Child rules are always offset to the right of the parent rule so that they only come into effect when the parent tells it to.