"Lua Scripting for Train Simulator: An Overview"

[MaikG]

Totally disagree... (Just saying it for effect at this point )

...
... I mean, you can't even print the addition of 2 numbers to the console, because there isn't even a console

Totally disagree ...

There is a console, the LogMate, but that's only usefull for "debugging" output. And at this point it comes where the "programming customers" are can be a massive pain. As an example, i had a need to debug the LZB code fpr 120EL on the HH-H route and not on a self created one. So every start of a scenario (QuickDrive in this case to have a clean new run every time) sputs out massive useless debug stuff from signals and dispatcher errors because they can't find the tracks (maybe he has to look at the route to find them... ). This overflows the maximum amount that LogMate can display. So you need to clear the log repeately while loading. And then, if you reach the end of that loading pain, you got the luck of an bad scripted vehicle, placed in the world, that sputs out massive lua errors and then the test is over before he was beginning -> next try .. and so on. Most users who start scripting for TS make such code and provide it to the users. They just put code snippets together and hope it will work. But they never start LogMate oder debug their code to finde hidden errors or endless loops or something. At the end we have alot of assets that provide defective code and that code even causes our loveley Dump.file error (not only but it can and it does).

[RudolfJan]

There is not much you can learn from the docs. A few calls that can be counted on two hands. The rest can't be documented. Scripting comes from the brain and not from a documentation.

You never did any scripting, I think. You need documentation not on how to learn programming, but about how the interface (API) with TS is designed. You only can learn that from proper documentation or reversse engineering. TS lacks any documentation, all we got is some samples.

[RudolfJan]

In terms of loco functions they are practically all already known and documented here.
https://docs.google.com/document/d/19gn ... u0moiqd5sc
Scenario scripting is however not well documented, but scenario scripts are not usually in the .out format so you could just go look inside the .lua file for the scenario and have a look at the various functions.
regards
Edward

I believe only a very small part of what is possible is now covered in samples.

[tnleeuw01]

Well well, interesting discussion, and I was not in the position to join it easily...

In my experience, you do need documentation - you need to know what calls are available, what the parameters are, and what they do.

But to achieve anything interesting, you need to know a whole lot more than just the available calls - like MaikG said, you will add your own functions, and use mostly those, and as your program grows you will probably develop your own set of higher level functions that wrap the native API calls in various ways to achieve something which you want to do.

The difference between "scripting" and "programming" is, to me, somewhat blurry and vague.

If you add a few lines here and there of script to achieve some effects, yeah, it's scripting.

But as your scripts grow and you start adding your own functions, it becomes more and more like "proper software development", even though you use the very same language for the coding, and that's kind of a sliding scale.

Now I believe that MaikG has done a lot of coding, on TS and on other environments, so he knows what he's talking about.

And from the conversation so far I gather that most of the function calls that are of interest to him are already long published, and so well known to him, that for purposes of loco development he doesn't care much about "more documentation" -- it's all in his head already and mostly a couple of "gets" and "sets" on some variables to him already well-known, or added by himself for his loco.

But for scripting scenarios there might be a lot more functions to call, or objects to interact with - I don't know and until that documentation is published, neither will most of us.

And even if it's mostly the same functions, there's the question still of what variables are available, and how do you go about achieving something interesting with it? Some examples would be nice!

Cheers,

--Tim

[MaikG]

There is not much you can learn from the docs. A few calls that can be counted on two hands. The rest can't be documented. Scripting comes from the brain and not from a documentation.

You never did any scripting, I think. You need documentation not on how to learn programming, but about how the interface (API) with TS is designed. You only can learn that from proper documentation or reversse engineering. TS lacks any documentation, all we got is some samples.

No, never. That's right. Im just playing around with the letters and numbers...

The things written in that google doc is near the full documentation of the TS API. There is not more in to care about. Even the scenario scripting is really rare packed with callable funktions. For TS and good results you really need ideas to make proper stuff with that few possibilities. I wish we had a API like Unity or UE (not Trainz, it's also not really good for locos and wagons), but at the end on the day we have near nothing. The ideas around the code are the golden stuff and no one will talk about it. It needs alot of time to find out what is possible oin TS and what's not. So these are "secrets".

I think most people talking here about scripting in TS never wrote a line or have a real idea what TS is able to do and of course what TS can't do.

I'm out here .. to much

[tnleeuw01]

I think most people talking here about scripting in TS never wrote a line or have a real idea what TS is able to do and of course what TS can't do.

I'm out here .. to much

Well - true indeed for me, I have years of experience in software development, enough that the thread interests me and that I feel I can contribute an opinion on what might be needed or not, but indeed have never ever touch a single line of LUA scripting neither for Trainz nor for TS



--Tim

[37114]

Shall we just all agree that some documentation is better than no documentation?

[metrobus]

I think that was agreed 2 pages ago

[Irishrailguy]

I think that was agreed 2 pages ago

We did, but this discussion has come about as a result of some (not in this thread particularly) who feel that the lack of documentation is what's preventing them from getting started with and understanding Lua for TS. In which case I say that they are looking to run before they can walk, as the DTG docs won't provide tutorials on how to program (which is what a newcomer needs to know before investigating the 'vocab' of the language in question). It wouldn't make sense for the docs to take the reader by the hand and walk them through the aspects of programming/scripting for TS in it's entirety (which is what some seem to think it will do). Remember that the only people up to this point who have seen that documentation are fully employed software engineers and programmers, who have probably known how to program for many years and studied it at 3rd level.

Kev

[gptech]

Surely proper documentation, written to be of use to those with the brain/experience/knowledge would immediately show to those looking to run before walking that they needed to start off lower down the ladder?
To me that's of more use than the throw away hints in threads along the lines of "well yeah, a little bit of scripting would do that", often posted with the implication "but I'm not going to explain further as that's just for us elite users"

[scefhwil]

Wow! When I started this thread I had no idea that the subject could possibly be controversial. What harm can correct documentation do to anyone? Can't believe the "snobbery" it's unearthed.

To me that's of more use than the throw away hints in threads along the lines of "well yeah, a little bit of scripting would do that", often posted with the implication "but I'm not going to explain further as that's just for us elite users"

Totally agree with that observation and sentiment there Gary.

[jalmar]

Hi,

Being a professional programmer it would be interesting for me to learn lua. What i need is a proper explanation of the RW related syscalls.
To give an example , I know that this piece of script does something with the weather. I even know what it does. But recreating this on another route i found that it does not work.
Why ? I do not have any idea what these named syscalls do, neither is known to me what effect of the the arguments is.

That's why I need documentation.
Albert

if event == "storm1" then
SysCall ( "WeatherController:SetCurrentWeatherEventChain", "FirstChain" )
return TRUE
end
if event == "storm2" then
SysCall ( "WeatherController:SetCurrentWeatherEventChain", "SecondChain" )
return TRUE
end
if event == "storm3" then
SysCall ( "WeatherController:SetCurrentWeatherEventChain", "FinalStorm" )
return TRUE
end
if event == "rainbow" then
SysCall ( "WeatherController:SetCurrentWeatherEventChain", "PrettyRainbowAhh" )
return TRUE

end

[Irishrailguy]

Wow! When I started this thread I had no idea that the subject could possibly be controversial. What harm can correct documentation do to anyone? Can't believe the "snobbery" it's unearthed.

I stated that I was fully supporting the release of the docs to the public, however my side point on those asking for something that they don't understand seems to have been taken with a bit too much weight. There's nothing wrong here at all, I just made the observation that these documents are being treated as the "Holy Grail" of scripting in TS, when they probably won't create as much of an impact as some predicted.

With regards to what Gary said, there can be devs who allude to the ability to do something via scripting and deliberately hold back, but aside from ego there are many reasons why they won't just throw code out to the subject...

-The person who wants to create a feature will have given said dev no background info on what they are doing (it's not practical to describe all the control values being used, each animation, the object node names etc. anyway).
-If there's no info to work off of then the dev can post pseudo-code, but that's just a text-based flowchart and no real code is being used.
-The dev might not be free to write the snippet up and text to see if it works (there's no output without having a pre-exiting project to work off of, which isn't something you can just create on the fly, especially is it's a loco)
-It's generally the case however that the person who wants to make that particular feature doesn't actually know how to program/script, so it's not going to help if someone gives them a code snippet that they don't know how to implement.

In any case Gary, I don't think it's fair to say that those who can use Lua on this forum are being elitist about their skill set. It's not as easy as throwing code up for someone because they want to do something with TS, you have to consider the context of the situation too.

Kev

[MaikG]

Best example that a code snippet doesn't work stays in the post of jalmar about the weather event chain. It helps nothing to have a code snippet. You need to understand the technices behind. So for the weather event chain you have to know how the chains and the weather itself works in TS. All extended functionality in TS is not only in LUA code, but also in blueprints and so on.

And the problem with the missing documentation and the people that want to have one is, that they think they get a book of neat stuff to start coding with best results in TS. Nothing. The whole thing is a 5 page doc if using a 12ppi font size. Also with alot of air between the lines. After getting that docs you have nothing more that now if you take a look in the above linked google document. So what did you guys think what you will get with the documentation. That's TS not .NET FX with tons of docs and examples. If you are not experienced in programming you will not got results. Thats a fact.

[37114]

Wow! When I started this thread I had no idea that the subject could possibly be controversial. What harm can correct documentation do to anyone? Can't believe the "snobbery" it's unearthed.

Totally agree.