"Lua Scripting for Train Simulator: An Overview"

[gptech]

I'd argue that scripting is not programming; when scripting you're calling for an already supported feature rather than writing that feature. Once again, any documentation (and isn't a web page with pointers, tips, examples just a modern day document?) can only be a good thing, even if it's a duplicate of what could be found if you had the "brains" to look for it, and know where to look.
Maybe it's just me, but every time scripting crops up in the forum it seems that those who know how it's done strive to keep it a secret.

[Juanillo99]

Yes, but many users know nothing about programming in LUA, and if DTG unveil us the functions in TS and what is achieved with them, maybe we would encourage to learn how to program scripts, and it would not start learning completely from scratch.

Which brings me back to my point on functionality as opposed to practicality. Those who don't know how to program shouldn't be looking for advanced system calls, they should be looking at how to actually program first... I never went looking for all the calls when I first started, I just messed around with changing control values and adding simple features that got me familiar with how the game works with scripts.

Basically you have to learn to walk before you run...

Kev

Yes, but if the documentation is null or non-existent, users who don´t know program script, we never will encourage to learn.

Also, for a while now is not only DTG who compile their scripts in *.out, but also virtual Railroads and Armstrong Powerhouse. Why they hide us the scripts?
Perhaps they are afraid that the "mortal users" learn to programming and we substract their market?

[metrobus]

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

[Juanillo99]

Maybe it's just me, but every time scripting crops up in the forum it seems that those who know how it's done strive to keep it a secret.

You're not the only person who thinks so. I think so too.

[metrobus]

The same reason why the code for many other games is secure and secret, so nobody nicks it!
Edward

[MaikG]

Maybe it's just me, but every time scripting crops up in the forum it seems that those who know how it's done strive to keep it a secret.

You're not the only person who thinks so. I think so too.

Believe me, if i want to give you the scripts e.g. from the latest BR120EL, you will get nothing you can use. The .out is not a hiding function, it is a precompilated code to load faster on runtime. That's all. The BPE outputs .out as standard format, so we don't care about. It has to work on the users side and nothing else. The other problem with open scripts is, that users bengin to manipulate scripts with no brain and then attacking the support channels of developers.

The totally other side is, that LUA calls are just one little peace of the whole thing. Scripting locos for TS means to know all its bugs, positive behaviours, negative behaviours and so on. Knowing all about the blueprints and their uses too. And if you want to control some sounds from the scripts, then you need to understand the even tricky sound engine stuff in TS. Only with scripting you will not get a good loco.

I'd argue that scripting is not programming; when scripting you're calling for an already supported feature rather than writing that feature.

Maybe this is the case in Unity, UnlrealEngine and other big Game/Engines. In TS the few API Calls are not really big functions. Set a Control, get a Control, gather some instable values from the simulation, sending messages along the consist (what is real tricky), and a few signal dependend things (incl. the Calls to get track speeds and restrictions ahead, what is the nex big challenging thing to sort out what you get returned). All the needed routines and processes, you need to script a functionality that is not provided by TS itself, have to reinvented from scratch by your hands and brain. Nothing of them is documented anywhere.

[gptech]

Nothing wrong with keeping the finished script a secret Edward, but not how to create your own script in the first place.

[Irishrailguy]

I've never had any interest in keeping code secret from others, but I don't see why this is something people suspect others of doing. the fact is that even before the .out system (which was entirely DTG's doing, the community never asked for it to my knowledge) some developers (Oovee for example) would copyright stamp a script at the top, which as far as I'm aware isn't legally binding. Code is a grey area for copyright, which means that rather than seeking a legal copyright on algorithms (which doesn't make sense anyway), the creators of the code will hide it instead. As I've already stated, what DTG can provide in documentation won't reveal much new vocab, but it's main aim will be to have a single place to access the info required. I'm all in favor of that, but it's not impossible to learn the TS interface with Lua as it currently stands. Most of what will be in those Docs are already available on pages throughout this forum, or other places (David's reference guide lists what will be most of the stuff that will appear in DTG's docs already: https://docs.google.com/document/d/19gn ... flcdE/edit).

I'd argue that scripting is not programming; when scripting you're calling for an already supported feature rather than writing that feature.

Well that's the case with pretty much all languages. C is definitely a programming language but you're calling pre-defined functions from headers in order for that program to compile and run...

As it stands the learning material is available and just needs to be collected by the user, all I need is in my bookmarks here on Chrome. Saying that someone new to scripting/programming would be deterred by a lack of documentation won't change the fact that they really need to learn a proper programming language first (I started with Python), in order to understand what one would be getting themselves into when it comes to scripting in TS.

Kev

[ChrisBarnes]

Looking from both points of view being expressed...

I agree that documentation of the scripting calls is important, as it will explain to users what those calls actually do. As Edward points out above, I believe most of these can be seen in Tankski's Google document. Simple scripting is a great way of learning how to do simple coding, in my opinion. University taught me alot more about how code is read, compiled and various other bits and pieces, but my first scripting project was TPR Leander before I even started uni and looking at programming. Less than a year of teaching myself, basically, as well as asking for other's advice and help, trial and error (not really advisable) and of course, by having a look at other scripts, just to try and understand how it all goes together, and what calls did what etc. No copying though, because the code is the property of those who wrote it, which I'll come back to later. If the right documentation was available then I don't think it would be necessary to follow by example of others.

I also agree with Kevin and Maik that just learning the call functions and what they do is not going to be enough, not one bit, unless all you want to do is turn particles/lights on and off. As they say, 99% of a script is your own code implementation and application of the call functions. The vast majority of a complex script is your own methods that you have designed yourself - the call functions are just the tools required to affect the game.

So what is the solution? A guide that includes a lesson in Lua syntax, a TS call function dictionary like the Google doc, then worked examples to show how to use these call functions, and how to make a script for either an engine, a signal or a scenario. Just like a good Java or C++ for beginners book. With enough information and some practice, people can then go away and start designing their own code and methods.

I have expressed interest before in writing a TS Lua guide for beginners or even just those wanting to learn something new. The problem, though, is that there is alot of things I would like to do, but I don't have the time to do them all, so unfortunately this is at the bottom of my rather long to-do list at the moment. Perhaps someone else will make a start, and I will gladly contribute when I can, but I wouldn't be surprised if other scripters are too busy as well - not just developing their own scripts, but living their real lives.

The *.out file format for exported code is, in my opinion, a blessing for commercial scripters, and a curse for those who want to learn. Perhaps selfishly, I'm of the opinion that it's overall a good thing, because scripting has become the bread and butter of what makes a product stand out in an increasingly competitive market. Unfortunately, if the code was open source, not everybody would respect other author's copyrights and would quite happily copy someone else's hard work for their commercial gain. I would hope that nobody would actually do that, but do you take that risk? Commercial code is usually closed for good reasons.

Kind regards
Chris

[crumplezone]

I think that is on of the points people are making. Alot of you are saying "the documentation is available at A B and C, but you need D and E to make it useful". Shouldn't there be a central index for all the various snippets of information rather than telling "well just go look, its available in various locations"

Its the one thing which has surprised me about TS in any of its guises over the year, there has never been any real central location for information. In other moddable games, which is affectively what DLC is doing but on a payware term, there is vast wikipedia pages of information, community lead sites with information and clear and concise modding sections and also youtube videos. Same really can't be said for TS.

Honestly with all the money revolving around DLC its hardly surprising people will begin to suspect developers of covertly hiding information or scripting for the sake of stifling competition.

[gptech]

Chris and crumplezone---agree completely with your posts, the call or desire for documentation, tutorials et al in one place to assist those interested in the features that lua scripting can offer is all that's been requested.

[37114]

I know nothing about lua scripting so any documentation, even just a list of valid functions, would teach me something. IT workers generally have the mind set that allows them to fill in the missing pieces, but not everybody works in IT. Stating or implying that you need to know everything intuitively is not going to encourage mere mortals to investigate scripting, and will only intensify the mystery that seems to surround the more technical aspects of the game.

The sooner the documents are released, the better in my book.

Well said that man.

[37114]

Yes, but many users know nothing about programming in LUA, and if DTG unveil us the functions in TS and what is achieved with them, maybe we would encourage to learn how to program scripts, and it would not start learning completely from scratch.

Which brings me back to my point on functionality as opposed to practicality. Those who don't know how to program shouldn't be looking for advanced system calls, they should be looking at how to actually program first... I never went looking for all the calls when I first started, I just messed around with changing control values and adding simple features that got me familiar with how the game works with scripts.

Basically you have to learn to walk before you run...

Kev

Totally disagree. You don't need to learn how to program. Have an understanding of it yes. If example scripts are provided it doesn't take a genius to suss out how to do basic modifications to suit their own use.

[MaikG]

Totally disagree. You don't need to learn how to program. Have an understanding of it yes. If example scripts are provided it doesn't take a genius to suss out how to do basic modifications to suit their own use.

Totally disagree. You definetly need to learn how to program, especially for TS. There are so much little bugs (even in the script implementation) and unstable values from the simulation, that you really need some experiences in coding with a simple language like LUA. First thing you will stop
getting results from that you expect are the OCM and OCVC events in the engine script.

[Irishrailguy]

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

But I can see where you're coming from 37114, however scripting is a specialized variation on general programming with lower-level languages. Lua isn't like the standard programming languages that you can learn and build on with documentation (like C and Java), Lua is an oddball language which is syntactically common but specialized to every program it runs off of. As a computer science student I've learned to decipher between the types of languages you can start as a novice, and the ones you need prior programming experience to work with. Generally the more specialized languages (like Lua, Unreal Script and even C++ in certain applications) are not a good platform to build off of because the documentation focuses on the specific abilities of that language as opposed to how to program with it in the first place. As we know that once you learn a language, general syntax rules apply in most other situations, therefore the creators of these specific languages expect users to have done the basics so they can deal with the parts that the language in question focuses on. If I was creating an application specific language like the TS version of Lua, I wouldn't want to spend my time teaching prospective users how to program, I'd want to tell them what they can do with that language with regards to built-in functionality.

For example, I got a book in December on writing DirectX game engine code with C++, the book told me on the first page that if I couldn't program, then this was not a subject for me to even consider. Although it's not the same degree of complexity, Lua for TS isn't a practical language to learn to program with, there's no application of the language outside of it's game boundaries. I mean, you can't even print the addition of 2 numbers to the console, because there isn't even a console

Kev