Learning Lua

[eyore]

The many and varied posts on the subject of scripting has emphasised how useless I am at it.

I consider myself a competent programmer but I can't seem to get my head round lua. I've bought the manual, tried a few internet tutorials, but continue to struggle with it.

Can anyone recommend anything I may have missed that may help my old brain get to grips with it?

[Nobkins]

The only thing I can advise (and not having done anything other than hack about in LUA) is to have a project to learn LUA for.

Without a project it is hard to put anything into practice.

Not much help I am afraid. If you do have a project and maybe some code already started please do post it. We might be able to get it sorted together.

Jim

[cjbarnes5294]

What sort of thing do you want to script? Locos, signals, scenarios? Manuals and tutorials are excellent and will teach you lua syntax and conventions, but unfortunately you also need to know how Lua works with the host program, in our case TS. I've been thinking about writing a guide on scripting for locos myself, but I think that's going to be a summer project if anything.

I have no experience of scripting signals or scenarios, but I can probably help you with locos and rolling stock if that's what you need?

Chris

[VictoryWorks]

It's probably hard to just learn lua without an objective as I can't think of something to just write in lua for practice - unlike say C# where I could suggest 100 projects to learn the basics and beyond.
I learnt it for the 56xx by starting with an "original" very basic script (I think for the default Black 5) writing everything in pseudo code to do what I wanted, and then translated that into lua/TS function calls by googling and a few UKTS threads where people (mostly Ben Laws) talked about available lua calls.

For example, I wanted to hide a few objects so I wrote my pseudo code - just program type language that I understand but with no specific language syntax.

Code: Select all

mylist = an array ("LeftLamp", "RightLamp", "TopLamp", "BottomLamp")
iterate each object in mylist
  Hide object


So I head to google for 3 searches: lua arrays, lua iterate array, Railworks lua hide object.
Translate the pseudo code and end up with this:

Code: Select all

local mylist = {"LeftLamp", "RightLamp", "TopLamp", "BottomLamp"}; -- create a lua array of strings
for index,value in pairs(myList) do -- iterate a lua array
  Call( "*:ActivateNode", value, 0); -- TS function to hide model a node (0 is off, 1 is on)
end


Do that for a whole loco and by the end of it you've learnt loads and have your own nicely commented reference for the next one. Do 3 or 4 with scripts of 1000+ lines and you can do most of it from memory

If you look at the old scripts they are pretty self explanatory as to the default functions..

Initialise() - Called when the loco first loads, this is called before the 3d model is initiated so you can't hide model nodes here, but you can turn emitters off and set up any global variables you need. You need Call ("BeginUpdate") in here to get things started. Most people place a one time call in the Update function (code that runs once, then sets a variable to say it's done and not to run again) to handle the bits that Initialise can't.

OnControlChange(name, index, value) - Called when a loco control changes SOME of the time, certainly when a key is pressed for a control. It's often better to keep a global note of a control's value and look to see if it's changed during each update call for which there is a function

Update(time) - this function is called numerous times a second, with the parameter "time" being how long since it was last called. This is where the meat of your script is called from.

There are other functions for specific tasks (consist messages, signal messages, camera view change, etc) but those 3 are your basis for every script. You can also write your own functions (just code blocks with parameters in and out) for things you need to use frequently or just to keep your script tidy.

So a very simple example of the Update function would be:

Code: Select all

gTotalTime = 0; -- This variable is outside of a function and is global so can be called from anywhere in the script and retains it's value

function Update(time)
  gTotalTime = gTotalTime + time;
end

This will give a globally available variable that will increase with every Update function call to give the total time since the update function started repeating.

To take it a step further:

Code: Select all

gLastSpeed = 0; -- Global variable to store the last speed query

function Update(time)
 local speedNow = Call ("GetSpeed"); -- local variable as once it's used here we store the value in the a global variable. GetSpeed is a TS function call to get the current loco speed in m/s
 local speedDiff = speedNow - gLastSpeed; -- Get the difference in speed from the last Update function call to now
 local acceleration = speedDiff / time; -- Acceleration simply from speed difference divided by time in m/s/s or m/s(squared)
 gLastSpeed = speedNow; -- Store the speed now globally so we can query it in the next Update function call
end

In truth there is a function call "GetAcceleration" that returns the same thing, but just calling that doesn't teach us anything

Hopefully that's provided enough basic framework to start doing something. Like I say, get a basic script from an old loco and start writing in pseudo code to do exactly what you want - as I say to people when I begin a web design project, don't limit yourself to what you think is possible at this point just put down what you want to do (we'll figure out later if it's possible or not). Then get started on translating it into TS lua and see how you get on. If all else fails, ask

[cjbarnes5294]

Great post, Pete.

Chris

[eyore]

It's probably hard to just learn lua without an objective

The only thing I can advise (and not having done anything other than hack about in LUA) is to have a project to learn LUA for.

I suspect you have hit the nail on the head there guys.

Some time soon I need to start on some signals for the Stainmore route, so I suspect a perusal of Mark Brinton's scripts will be a good starting point.

[AndiS]

When dealing with signal scripts, you dig through three different subjects:
Lua itself;
Collaborative multi-agent systems;
Faking the prototype under pretty dire circumstances.

Each system is a member of a team of software agents, communicating with others by sending and receiving various messages. Together, they perform actions that resemble the actions of real signals in a certain set of cases. Looking at a signal alone does not tell much. In addition, the script is event-based which means that you don't look at code that is executed top to bottom (it is, but only to initialise variable). Instead, there are various functions that get called at specific times:
Initialise is called once before route set-up is complete.
Update is called on a regular basis (if you called BeginUpdate before).
OnConsistPass is called for every train within 1250 m from any track link, for every train and every link, regularly (as often as Update).
OnSignalMessage is called when a message from another signal arrives.
So all the actions of a signal are divided up between these functions, which themselves distinguish lots of different cases (different messages arriving, different directions of train movement). It is no wonder if you get lost.

Even with all the brain power invested into the scripts, there are certain limitations put forward by the basic game design. Signals don't know what the train will do next. They don't know when switches will move next. AI does not wait for signals to clear and it does not react to messages sent by signals. Trains cannot send messages to signals.

One way to study the signal script is to go through the list of messages and search all their occurrences, one after the other. Doing so, you take notes (in any shape you like), to document for yourself what they do. Next, you go through all occurrences of the state variables that you came across, and see where they are changed and where they are read.


The completely other approach to this nightmare is that you put down what you really need to achieve. Many people achieve a lot by modifying a bunch of lines somewhere in this jungle, even at the head of the file if you are lucky. So it may not at all be necessary to understand all of the stuff.

[Rockdoc2174]

I'm told that it is somewhere between difficult and impossible to make a coloured-light distant work with a semaphore home signal. Is that true and, if it is, why is it and can you work around it?

Secondly, how do feathers and route indicators 'know' which route has been selected?

Keith

[AndiS]

I think everyone dealing with signal scripts is too busy to do mundane stuff like CLS distants for semaphores. The default scripts are full of "funny parts" which you discover when you try to expand them. The semaphore distant scripts are funny on their own. Rewiring that to animate a CLS is not a nice job. And doing so, you start fixing stuff instead of doing the humble little thing. At least that is what happened to me.

Each signal has its own script. Much of the script content is the same for a whole group, e.g., all UK semaphores. But so lines are specific, which is the reason d'etre for these individual scripts. In this individual part, you find stuff like "if the path is set to track link 1, then illuminate finger 1; else if the path is set to link 2, illuminate finger 4" etc. etc.

For route indicators, you can define the mapping in the script, or you can do it like the German one (Zs2), where you enter a letter in the signal properties fly-out (one per route actually), and this letter is shown using a texture set that contains all the letters.

[Tankski]

I'll just jump on this thread to mention the old TS2013 Scripting Manual that I set out to create many moons ago: https://docs.google.com/document/d/19gn ... flcdE/edit - Collates most information throughout the net that is available on the TS scripting side of things.

EDIT: Changed link to work