Locos and LUA scripting

[dtrainBNSF1]

Ever since TS2014 was released, I've always wondered just what are the limits of LUA in scenario writing. So far my only experience with it is making text boxes. I feel like I want to try tackling other things, like in game videos. However one thing has remained on my mind:

Can LUA scripting affect a loco's performance during a scenario?

For example, would it be possible to shut off one or more of the locos in a consist during a scenario? Like what happened in this video for example when an intermodal train shut down after cresting the summit of Cajon Pass: https://www.youtube.com/watch?v=9H2uwmm0vVs

[arizonachris]

Can LUA scripting affect a loco's performance during a scenario?

For example, would it be possible to shut off one or more of the locos in a consist during a scenario?

Yep, they (RSC/ DTG) have already done it in several scenarios on a couple of the newer routes. But someone else will have to chime in with how-to-LUA, I'm just a driver.

[RudolfJan]

You may want to have a look at the Scenario scripting guide in te download section. It will not answer your question, but I hope it encourages you to do some experiments and share the results

[Kali]

The only limits to what you can do are imposed by the interface the game gives the lua engine and your creativity at making the most of that - to be fair you can do quite a lot, you just run into brick walls sometimes. The big issues I have currently are you can't talk to the trackside from the train, and you can't do much with the UI - I think the steam scripting guys have rather more concerns...

Not tried a recent version, but last time I looked at remotely shutting down an engine it's possible to depower it, you'd just have to script the engine RPM audio yourself too to get it to go back to idle when it's technically at full regulator.

[_o_OOOO_oo-Kanawha]

Has anybody ever looked into GameManager.dll, the core of the simulation?
Are there cleartext hooks, tables, etc. that can be patched to give more reastic behaviour or physics.

[Kali]

Not properly - I go through it every release to look for new lua calls, but I don't try and take it apart properly ( mostly because I don't write windows code so I have no tools ). You can write your own dlls & have the lua engine load them, I know that much - iirc Ben Laws did some camera tricks years ago that way, so that shows you can insert your own code into the engine. It is full of what I think is C# symbol text ( could be some modern C++, I don't know ) so I guess someone who knows what they're doing could make more use.

Power behaviour is predictable ( either TE = MaxPower/V*Regulator or literal use of the graphs depending on the blueprint type ) and for braking you can just set it to Direct & script everything else; doing more complicated things like delayed application/release down a consist would take quite some hacking I suspect, given the multiple functions you'd have to replace... and given how odd consist behaviour is - vehicles are independent when it comes to couplers/bumps but not for brakes or adhesion - I am not sure I'd want to put my fingers in that nest.

[dtrainBNSF1]

You may want to have a look at the Scenario scripting guide in te download section. It will not answer your question, but I hope it encourages you to do some experiments and share the results

I downloaded it, read through it and I figured it out just this morning

In the lua script you have to type in the following lines after setting up an event:

if event == "(customized name here)" then -- kill engine (I don't think you have to type in "-- kill engine" here; more likely it's just a note for the programmer)

SysCall ( "PlayerEngine:SetControlValue", "Startup", 0, -1);
return TRUE
end

After that compile your MD5s to link the event to the scenario, play through your scenario and activate your event. As you pass through where the event takes place the emergency bells go off in the cab, the prime mover falls silent and on the F4 HUD rpm steadily drops to 0. You can restart your engine by pressing "Z" on the keyboard.
One thing to keep in mind: when running with multiple engines the SysCall will shut off your engine and while you are in control of that engine it will shut off the other engines in the consist. But if you switch controls to a different loco in the consist the all of the engines will turn on again. If you switch back to your original engine then they'll all shut off again. Perhaps to shut off all the others where it says "PlayerEngine" replace it with the other loco's numbers (so if I was driving loco 4569 that would be "PlayerEngine"; if my 2nd engine in the consist was 4723 then type in "4723:SetControlValue" etc. in the next line). I haven't tested that out yet but I probably will in the future.

[dtrainBNSF1]

Tested my theory and yep that's how it works. You have to write a SysCall for every loco in your consist you want to shut off, identify it as either "PlayerEngine" or by loco#, and then command it to set the control value "Startup" to "0, -1". You can put multiple SysCalls in the same event I've discovered.

[RudolfJan]

Thanks for your test. Still not sure this works for every loco type. The command names are very configuable by the developer of the loco. This makes using lua to do loco/consist settings very hard. Fortunately there are many other interesting applications. I just developed aa advance speed restriction script for Albula (thes Swiss signs are very small and don't show up in the HUD). Antoher thing I consider is a script to make AWS audible outside the cab. Coming someday in the next update of the scripting guide.

[RudolfJan]

One mote thing:

Code: Select all

-- kill engine

is just a comment. No real need to copy this, just for documentation purposes.

[dtrainBNSF1]

Figured out how to get the weather working for WLoS and Sherman Hill by the way :) For WLoS it's just as you said in the guide. For Sherman Hill you need the code you mentioned in the guide and you need to have "SH Clear to Thunderheads" and "Thunderheads" selected in game. So far testing has shown that it won't work for any other combination. Sherman Hill has 3 storms, "FirstChain", "SecondChain" and "FinalStorm". "FirstChain" is just a sprinkling, not much and lasts for 10 minutes then fades. "SecondChain" begins like "FirstChain" but after 5 minutes intensifies into a downpour then at the end of its 20-minute cycle reverts back to "FirstChain" and fades out. "FinalStorm" is a full on thunderstorm and begins within seconds after its code activation for Sherman Hill but for WLoS the storm begins a few minutes after code activation. For both routes the storm lasts for 20 minutes then fades out. The Sherman Hill storm has more rain and actually causes the screen to darken. Because of how quickly the weather for Sherman Hill activates it would be best to wait for about 15 minutes into the scenario before activating any of the storms to allow the skies to animate properly and put the thunderheads in place otherwise the weather looks like something from a SciFi flick and doesn't convey the type of realism I'd personally expect. Because of the time delay of the storm for WLoS the thunderheads conceivably already move into proper position before the storm begins so you can start the scenario with the "FinalStorm" code on WLoS with no problem.
Another thing to note is that the storms DO NOT mesh together if you activate one after the other. The simulator causes a short break between the storms before activating another storm, clearing the skies for a few seconds. Not too realistic.
As expected if you want to use these storms on other routes the appropriate blueprints have to be selected in the scenario editor.