Hi all, just bringing my two cents into debate - source format of the script is working in my loco as it should, but compiled version isn't. With compiled .out script version, it looks like OnControlValueChange function does not set variables correctly when associated controler is changed. But it works with source script version (.lua) without any problems. Therefore I guess it must be something with compile process, it just doesn´t behave properly. Definetely has something to do with latest update, implementation of newer LUA didn't go well I guess.
Sort of... virtalRailroads locos have issues... I think it's being looked into atm. Btw I wish the devs would not compile their scripts, would make bugfixing easier for us
I see your point, however, that´s the only way authors protect their hard scripting work As it is the heart of every advanced loco, many times as payware Anybody can make a 3D model after few hours of studying tutorials, but to script something - that is a completely different task.
Sorry but that's "dangly bits". Anyone who intended to profit from another authors script would find a way to decompile it anyway, all compiling really achieves is stopping the home user from editing a few values here and there, which is 99% of the time for personal use. The train sim environment is so niche and closed do you honestly think anyone would get away with using someone else's work nefariously? Just ask Ben Penhalligan. Nope, compiling scripts has nothing to do with protecting double dutch (to most) scripting and more to do with maintaining full control.
where is the actual .lua interpreter? In which .dll? AFAIK, TSC dev docs from 2015 or so prescribe a certain, older, version of luac.exe to tokenise plain text .lua into obfuscated .out files, while most devs use a newer version of luac.exe, with more functionality and certain lua functions that they've found got interpreted all right. Perhaps TSC has backdated their lua interpreter, perhaps even inadvertently, so now some more advanced .out scripts do not work anymore? There is still a certain need to de-obfuscate those .out scripts, as some devs have set DEBUG to TRUE, which means LogMate will get flooded with debug messages from signals.
First of all, I really do not get that value changing you´re describing here. Why would you do that anyway? Author knows very well why he put those in script and modifying them may cause some script block stop to work properly and as intended. And personal use or not, that´s not important. And of course, for such change you must study script very carefully and must understand it. I wonder how would you do that with script with 10 000 lines (like mine, for example). No chance. And that decompiling is also not fro everyone and is not so smooth. Decompiler will never construct script from compiled bytecode to make it look like the original source code. Or, at least, I never saw such clever one. Secondly, I really do not know who is Ben Penhalligan And honestly, I do not care Either way, this topic is about something else.
Absolutely understand that the script is the "heart" of the engine. If it's done properly. Someone just pointed out for example on the DTG Class 142 Pacer, the headlight selector also affects the rear end of your train, but not in the correct way, so you have Daylight markers on on both ends. If the script wasn't compiled this could be fixed easily by most modders, for example the lights were broken on the old RSC EMD SD75 - seeing the script was plain .lua I could just fix it myself.
Having issues with several steam locomotives ( most can't fill the boiler with the injector and run out of water) and some advanced scripted diesels.Searchlight Simulations SD40-2s. On the CP AC4400 you couldn't install the reverser handle, SS made a patch available so you could drive it. NOTE to DTC: Put it back the way it was, tinker with it at home.
