Locomotive headlights causing extreme lag

I’ve found on a small minority of locomotives, turning on full headlights causes sessions that otherwise run smoothly to lag. At around 1 frame per 30 seconds or so. Is there anything I can do to debug/identify the cause or has anyone else seen this before. I’m playing on build 110491 on a pretty much brand new gaming laptop, 8GB RAM, 4GB VRAM and and quad core i5. Like I said I have no performance issues running the game or most other tripleA titles.

Many thanks in advanced for any help!

It would be helpful if you provided the KUIDs and names of the locomotives in question because there are a gazillion assets in Trainz and it's kinda difficult finding out without testing a lot of them.
If you know the names of the locomotives, you can search for them in Content Manager. Once found, highlight them, press CTRL+C, or choose Copy from the edit menu, and then paste that information here in the forums.

The issue may or may not be a known one, or it may be related just to those particular assets. In the case of built-in assets, you can then use the same information to report the problem to the helpdesk and they can possibly get those assets repaired.

It’s generally 3rd party payware/freeware, but since it seems to be across multiple creators I expect it’s not an issue with the individual items. Examples are DB 182 kuid:202789:1587, DB 182 (freeware) kuid:550864:101398 or kuid2:132952:3 DBSRP 3E locomotive

I’m not getting any actual errors or logs, so my question was also is there anyway to generate these so I can try and identify the issue?

DominikB said:

It’s generally 3rd party payware/freeware, but since it seems to be across multiple creators I expect it’s not an issue with the individual items. Examples are DB 182 kuid:202789:1587, DB 182 (freeware) kuid:550864:101398 or kuid2:132952:3 DBSRP 3E locomotive

I’m not getting any actual errors or logs, so my question was also is there anyway to generate these so I can try and identify the issue?

Click to expand...

No logs are necessary. This is a performance issue of some kind. This could be related to your laptop graphics card, or it could be endemic to the assets. There's no way to find out unless someone else tests these assets. If they don't have the problem, then it's your system hardware. Laptops are nice, but don't always play graphics-intensive games well and adjustments are needed such as lowering graphics detail settings and such to accommodate the hardware.

That seems odd to me, as the sessions play fine at 30+ FPS on the High preset with just some locomotive lights breaking them. Also I have no issue playing most modern release games including Cyberpunk/Read dead 2 at 30+ FPS on High/1080p settings. I’ll try reducing all the graphics settings to low and seeing how I get on though

Edit: I’ve just done a test, and can confirm I’m not even close to full usage of my RAM, CPU or VRAM

Is there anyway to rule out that it’s a ‘bug’ that’s causing the resource usage to skyrocket?

Apparently there is a 3rd party script that a lot of European locomotive content uses that has a but in it which causes this behavior. If you search around on the forum here you can find a fix, which involves editing the script file for each locomotive. If you don't feel comfortable doing that, your only other option is to wait & hope the locomotive creator releases a fix (you could reach out to the person and kindly let them know).

peter

PerRock said:

Apparently there is a 3rd party script that a lot of European locomotive content uses that has a but in it which causes this behavior. If you search around on the forum here you can find a fix, which involves editing the script file for each locomotive. If you don't feel comfortable doing that, your only other option is to wait & hope the locomotive creator releases a fix (you could reach out to the person and kindly let them know).

peter

Click to expand...

I work in IT so happy to give it a go, would you know what to try searching for? Many thanks, as these are all European locomotives

I believe this is the original thread, although you might have to look for the answer there. The last few posts mention some fixed assets already on the DLS, but before that it gets off topic. I believe there is a fix in the thread somewhere though.... https://forums.auran.com/trainz/showthread.php?161617-An-open-letter-to-N3V-engineers

Thanks for the link, this is defo the issue I’m having and can see there’s quite an ongoing undertaking to fix the issue. Do you happen to know the difference between .gs and .gse script files? I assume the latter are encrypted versions, used for payware?

gse files re encrypted, so you won't be able to do anything with them, just wait & hope.

There's only like 3 lines you need to delete out of the script file... one of Laurinlaki's posts in that thread tells you which lines (I can't seem to find the post now...) I ran into the problem, that the 2 locomotives I tried to do it on, didn't have the lines in it.

Peter

This is not the correct way to solve a problem
end-users should not be forced to change scripts.
What if they use that loc in their session, then share that route/session, then every user of that also needs to edit scripts.


If at a sudden build of trainz, suddenly scripts stop working or cause errors, then who should change?
not the end-user, not the content-creator, but the one that changed the base code that started causing the error.


stop changing the rules all the time, it hurts Trainz.
greeting GM

I’ve managed to get some to work, pasting a working locos light script over - although it’s a bit of a fiddle to turn the lights off but they’re usable. About the .gse, that’s a shame but understandable that pay ware hides their hard work! Just gotta hope the creators fix it.

Thank you everyone for your help on this, glad it’s not just a me problem!

Hi All
Unfortunately there are some very poorly written headlight scripts which are written in such a way as they will run in a constant loop. Effectively when you turn the headlight on, the script then tells the headlight to turn off; then tells it to turn on, then tells it to turn off, and repeat. A missing message resulted in this not happening, but after this was resolved, assets that were configured this way would run in a constant permanent loop and would cause this performance issue. Removing this message isn't an option for us, as it is essential to other functions to now run correctly. This means the only option is to fix these very flawed scripts.

G.M. said:

This is not the correct way to solve a problem
end-users should not be forced to change scripts.
What if they use that loc in their session, then share that route/session, then every user of that also needs to edit scripts.


If at a sudden build of trainz, suddenly scripts stop working or cause errors, then who should change?
not the end-user, not the content-creator, but the one that changed the base code that started causing the error.


stop changing the rules all the time, it hurts Trainz.
greeting GM

Click to expand...

The rules are essentially unchanged. Scripts should not be written in such a way that they end up in a continuous loop. If the script takes control of the headlight, then it needs to be smart enough to know when to turn it on or off. It should not be configured that when the headlight turns on, it then tells itself to turn the headlight off, then tells itself to turn the headlight on, then tells itself to turn the headlight off, and repeat forever.

This means that to fix this, the creators will need to fix their script. We can't just magically fix this; removing the message isn't an option for us, as the flaw is specifically in the scripts that cause this issue.

In this case we have assisted creators by providing an updated version of the headlight script, but of course it will still require the creators of locomotives to actually update their locomotives, and these updates to be installed.

Regards

There is also something else causing this, namely trainz itsself.
Try an unscripted train (with a.lightx points) and my Set-driver-control-rule
I made a button to turn all lights on for all trains in a session
if you turn them on, trainz will turn them off unwanted in a few seconds when driving under AI
When leaving a station trainz will flash the headlights.
when a train stops at a station, headlights and nightmode gets turned off (unrealistic)


Trainz should leave the headlights in the state the user wants, not switch all the time
In the trainz code is a loop(yes) that constant meddles with and checks headlight state.


Scripts don't have to turn them on/off if trainz native code would not mess with headlights unwanted
So we have a constant fight between a script and trainz.
It's unfair to blame all on Content Creators, for something that was wrong in the trainz code for 2 decades.
greetings GM

Thank you again all for the replies. I had a follow on question, I’ve got a locomotive that gets thrown into Emergency when swapping to the roaming views. I expect this is in its script somewhere, would anyone know what to look out for in the script file that’s monitoring this camera change event?