Atomic Systems

I've come across an interesting issue with the current project - on my test routes (which are simple) all my cab controls initialise like I would expect. But once I load the train into a "proper" route, probably 5 or 6 controls don't initialise properly. They are set to the correct value internally, the the cab animations are either stuck half-way, or in the wrong place. For example the driver key should either be on the desk, or in the slot. The internal value is set to '1' meaning the game thinks it's in the slot, but the animation shows it floating in mid-air because the animation has either stalled or bugged out half way through the initialisation.
Other switches - simple on/off switches - are set to 'off' (visually) when the game thinks (internally) they're set to 'on'.

Anyone seen this before?

Only when loading "saves" of half-completed scenarios

--Tim

Ok well that at least gives me some (little) confidence that it's not something I've ballsed-up in the model. In my case it does it even at the start

These are common issues since i know TS and there are some tricks to prevent it (but not on every situation). There is no standard receipt for how-to. It depends on the levers, animations and scripts. But on all cases u need to use the concept of late/delayed initialisation.

MaikG wrote:These are common issues since i know TS and there are some tricks to prevent it (but not on every situation). There is no standard receipt for how-to. It depends on the levers, animations and scripts. But on all cases u need to use the concept of late/delayed initialisation.

I have some delayed initialisation for some functions but not for animations. What do you suggest? Go through and read every control value and re-set it to the same value to force the animations into the correct place?

That makes it sound like it's a timing issue.

On a very bare test-route, TS initialises and calls your script init code rapidly enough because there's nothing else to load.

On a real route, initialisation of the world takes longer, therefore your script init code is called later, different things happen in different order, and you don't get to set the controls on time in the way you expect before another part of initialisation code takes over.

By explicitly delaying the initialisation, you give TS time to do it's own thing and all other controls and values should be set up to their defaults before your scripts set them to the desired state.

Does that kind of make sense with the symptoms you are seeing and the proposed fix from Maik?

--Tim

Tim. It makes sense. I'm just not sure how to force the game to delay the init function. I mean there's hacky ways of do it with timers and such. But what's weird is that the values are right for every control. It's just the animations for some controls that are all either in the wrong position or in a half way state. I had the same problem with the Flirt3 and it's cropped up again with the RS1. I did try putting a 30 second wait timer in just to see what would happen but then I fell foul of the bug they introduced in TS2015 where OnControlValueChange ignores some controls, and where setting a value via the script sometimes doesn't cause the cab control to visibly change.
I swear fully 50% of my scripts are just coding around the most irritating bugs

So how did you deal with it in Flirt3, Chris?

And yes, you're not the first developer who says a lot of coding effort is spent just to workaround TS bugs...

Honestly in the Flirt 3 I gave up and just left it and hoped nobody would complain. There were only three controls in there that suffered the problem. In the RS1 there are seven and it's always the same seven. I think it might be something to do with the number of keyframes. I might try re doing the cab with less of them (15 instead of 120) and see what happens. For the gauges and switches etc the number of keyframes really doesn't matter when you're mostly going from 0 to 1

As i said it depends on the specific script, blueprints and animations. Without seeing what you tried to do i can't help. The most time of scriping goes into workarounds of bugs. At first try to prevent the async init of TS, what is of course a bug. Often it happes that the script will be put on the stack before the RV was loaded completely. It directly fires up the initialize() as the asset was refenced into the game. It does not wait for loading it. So it fires its lua calls into the empty space what causes errors and maybe stops the script from working or causes stack overflows and crashes TS.

Signals have always done next to nothing in Initialise and deferred everything else to the first call to Update.

To this end, gInitialised is set to false in Initialise and BeginUpdate is called there.

Then through all of the run of the scenario, many times per second, Update asks
if gInitialised then do the regular stuff, like progressing animations
else gInitialised = true and we do the deferred initialisation.

At least signals get their first call(s) to Update at 0:00, so there is no problem other than the slightly wasteful asking whether this is the first call or not.

I know nothing about engine scripts, so you need to translate the above to engines yourself. I just wanted to assure you that among the signal scripters, no one ever tried to do meaningful stuff in Initialise. I guess there is even a comment in the original scripts saying that the world and thus the track network is not set up yet when Initialise is called.

Signal scripts are way different to the engine scripts and there are much more problems within the engine scripts. The initialize() works but you should never do a Call() inside them except the BeginUpdate. But you can init your own vars or such stuff. Not needed at all of course. I do use the Initialize() to set up my classes only. The class (or maybe call it modules) are laoded before so this will work as it has nothing to do with the RV itself. But if you do stuff that involves the RV you can run into trouble.

Simplies way to run a delayed init is to start the update, have a var with a number in it (a '1' is good for this), then create a init section within update() and check if the scenario time greater than that number and then runn your stuff once.
Also prevent to fire up some functions before init was done wit a simple if(.. and secondInitRun == true ...) on the important functions and code blocks.
To sync the animations you need to create a table with your controls and interate them in the second init run like this: Call("SetControlValue", controlName, controlINdex, Call("GetControlValue", controlName, controlIndex));

Thanks for the tips. The re-init of the animations is what I was doing already. Basically read and set in the same call. My delayed initialisation is not using your trick of the 1 frame delay but it is otherwise the same with a Boolean called gFirstRun. I like that 1 frame delay idea. I'll give it a try.
The one thing you did write that caught my eye was not doing a call during the init function. I do a single call in there ( I think to grab a start time for a clock display). What's the problem with doing calls inside init? It *seems* to work but I'm curious about your insight into this.

It's not a frame but a second. And it should be "GetSimulationTime" not "GetScenarioTime" what is only working within scenario scripts but delivers the same value: seconds.ms since scenario start.

You do can have Call() in the standard init function but do not call things like "SetTime" on a animation, or stuff for emitters and sounds. They are not there in most cases when the init is running. Controls are often there but the animations are not loaded at this time. If you try to set an animation to a specific time at this point you will get an not found error for that animation name. But you don't need a single call in the standard init when you are using your own init implementation with delays. I'm using two delayed inits on the newer expert lines. Also you need to delay the resume stuff. It's the timing that you should care of. For example do not fire up delayed init and resume stuff at a resume. So delay the resume stuff to be applied after the delayed init what also comes up at resumes. Or you do totally different init procedures for both situations. But that blows up the code a bit for none reasons.

On what controllers the animation does not initialize correctly? What values are in there vor min and max and how long is the animations time? Take care of the dependency within controller values and animation lengths. It does not scale the expected way some times. It also depends of the fps settings and frame count of that animation. Also try to set the control with "SetControlTargetValue". But this works not on all controls.

It's tricky at all. Not easy for some things that could be implemented but at the end will not be because it's to time consuming to find out the right way around the bugs of TS. A lot of functionality that i have planned for some locos never got into them because of that. Hope this will change with TSW.

Thanks for your response. The controls that don't initialize their animations properly are mostly simple on/off switches with values from 0 to 1. I think it is more to do with the number of frames though , like you said. My cab model has 120 frames in it so most controls are at zero in frame zero and one in frame 119. This is the first cab I've done with this many frames and generally it's not needed. Normally my cabs have 15 frames of animation but I was trying to simplify my wiper controls this time by having the same number of frames for the outside wiper as the inside one. I might just go back to a multiplier in the script for the animation times and reduce the number of frames in the IA files.

One last question. You mention not doing the 1 second delay on resume (instead of on new game). I didn't know you could detect the difference via script.

When I get back from vacation I'm going to change the anims and move some more items into my delayed init and see what happens.