Spontaneous Consist Fly Apart (TRS22 SP1)
- Thread starter deneban
- Start date
I see consist 6303 ?, I rarely reach over 1k
The current game has a few nasty hardcoded limits
For instance the "new" Async. search we are slowly being forced to use has a hard limit of 1000
totally unusable for anyone driving big routes with many trains/junctions/signals/triggers/trackmarks
Place/use too many industries and it no longer works.
When ever I bring it up, I am being ignored or treated like some disruptive element lol.
Hope they fix/increase the limits, our PC's can handle it.
hope you find what caused it
greetings GM
The current game has a few nasty hardcoded limits
For instance the "new" Async. search we are slowly being forced to use has a hard limit of 1000
totally unusable for anyone driving big routes with many trains/junctions/signals/triggers/trackmarks
Place/use too many industries and it no longer works.
When ever I bring it up, I am being ignored or treated like some disruptive element lol.
Hope they fix/increase the limits, our PC's can handle it.
hope you find what caused it
greetings GM
When you have the TRS22 re-brokened portals, and 5 of them, that keep launching zombies and partial consists that must be eradicated by the UDS feature to preserve the simulation, the simulation will rack up over 1000 consists quite quickly. The time stamp on the prior game save was only 35 minutes into the simulation before the kablam.
If your theory were correct, then the problem should keep occurring further on in the simulation, i.e. string storage getting too large for the simulation to handle - but it doesn't. After reloading the prior save, things went on normally with higher string numbers. That is why I chose the Physics module as the culprit. Study the pattern in the screenshot - the front and rear remain unscathed.
This being the 3rd instance of this for me, all with heavy trains, as Class I RR American trains tend to be. They always fly apart in the center of the consist while the train is going up an extended gradient. This evidence would suggest somethings wrong with the train physics. I theorize a "stress wave" is created that oscillates back and forth through the consist, ever intensifying, until it overcomes coupler allowed stress in the physics model. The center of the train has to absorb the fastest momentum shift caused by the wave front coming back from the opposite direction, thereby explaining why the center cars fly apart. The cars fly away from the center with varying force, causing varying displacement among them - they are not nearly in the order they were coupled together originally.
Perhaps the Trainz physics needs to be tested with heavy American freight trains.
If your theory were correct, then the problem should keep occurring further on in the simulation, i.e. string storage getting too large for the simulation to handle - but it doesn't. After reloading the prior save, things went on normally with higher string numbers. That is why I chose the Physics module as the culprit. Study the pattern in the screenshot - the front and rear remain unscathed.
This being the 3rd instance of this for me, all with heavy trains, as Class I RR American trains tend to be. They always fly apart in the center of the consist while the train is going up an extended gradient. This evidence would suggest somethings wrong with the train physics. I theorize a "stress wave" is created that oscillates back and forth through the consist, ever intensifying, until it overcomes coupler allowed stress in the physics model. The center of the train has to absorb the fastest momentum shift caused by the wave front coming back from the opposite direction, thereby explaining why the center cars fly apart. The cars fly away from the center with varying force, causing varying displacement among them - they are not nearly in the order they were coupled together originally.
Perhaps the Trainz physics needs to be tested with heavy American freight trains.
Tony_Hilliam
Trainz Plus - enjoy Trainz from just 20 cents a da
Firstly, if you can reproduce the issue, that would be the biggest help. "Something" happened to cause this, so the challenge will be to figure out what.
Regarding async searches, the aim is to avoid lengthy game pauses and allow theoretically unlimited tracks and trains (and that is surely a good thing). It does put the responsibility on the script writer to figure out the best way to search for something. If you're having to search for every instance of something on the entire route, you're probably not thinking enough about how you could narrow down the search.
The 1000 limit makes a lot of sense when you think it through. The UI search limit is a good example. You're trying to find "something" and you don't want to scroll through 100 results, let alone 1000. So the answer is to improve your filter to reduce the number down to something manageable.
Put another way, scripts are slow, so asking for more than 1000 results means you haven't really defined what you're looking for well enough.
Regarding async searches, the aim is to avoid lengthy game pauses and allow theoretically unlimited tracks and trains (and that is surely a good thing). It does put the responsibility on the script writer to figure out the best way to search for something. If you're having to search for every instance of something on the entire route, you're probably not thinking enough about how you could narrow down the search.
The 1000 limit makes a lot of sense when you think it through. The UI search limit is a good example. You're trying to find "something" and you don't want to scroll through 100 results, let alone 1000. So the answer is to improve your filter to reduce the number down to something manageable.
Put another way, scripts are slow, so asking for more than 1000 results means you haven't really defined what you're looking for well enough.
Tony_Hilliam
Trainz Plus - enjoy Trainz from just 20 cents a da
Deneban, our posts crossed so I will answer more directly to the issue now.
My suggestion is to use Test Track and run your train there on a similar track segment. You can show coupler stress, and all sorts of other parameters. If there is some sort of oscillation going on, it should be easy to identify.
From there, try with other cars to see if there is something in the config (e.g. "max-coupler-gap").
There are also coupler stress rules you could add to your session to see if anything pops up.
My suggestion is to use Test Track and run your train there on a similar track segment. You can show coupler stress, and all sorts of other parameters. If there is some sort of oscillation going on, it should be easy to identify.
From there, try with other cars to see if there is something in the config (e.g. "max-coupler-gap").
There are also coupler stress rules you could add to your session to see if anything pops up.
I did the tests with Async and the old search method
8000 signals get found in less time than it takes to blink your eye (using World.GetSignalList()
there is no need to cap it at 1000, atleast crank it up to 10000.
If you want to speed up the game, search it else where, like in the loading.
Loading 300mb textures has a much larger impact (EG. n3v commissioned cabs/trains)
Sadly I heard the lead programmer does not really play this game,
hence he/she does not know how it will perform as we users experience.
Not trying to be your pain in the behind, just telling how it is in my eyes.
Please fix the game we all love, before introducing more unfinished stuff
8000 signals get found in less time than it takes to blink your eye (using World.GetSignalList()
there is no need to cap it at 1000, atleast crank it up to 10000.
If you want to speed up the game, search it else where, like in the loading.
Loading 300mb textures has a much larger impact (EG. n3v commissioned cabs/trains)
Sadly I heard the lead programmer does not really play this game,
hence he/she does not know how it will perform as we users experience.
Not trying to be your pain in the behind, just telling how it is in my eyes.
Please fix the game we all love, before introducing more unfinished stuff
Hi Tony, thanks for your response ( we were writing simultaneously). In fact reloading the game save just before the kablam did not result in any problem. To me this means the incident is the result of physics computations rather than software limitations. Small mathematical variations between the two simulations caused a different outcome. Its like the drop of water on Jeff Goldblum's knuckles in the original Jurassic Park. Sometimes the drop falls toward his fingers, sometimes the drop falls towards his wrist. As he explains, small variations in initial conditions can cause very different outcomes. You can read my post #2 for my theory as to why this happens. My recommended remedy would be to test the train physics with the heaviest trains anticipated on a long grade.
Ok will pursue that.
In all fairness there is a delicate balance of resource management between new development to remain the state of the art, and refining what has been released to keep the installed base happy. Far be it from any of us to put ourselves in Tony's shoes to best manage this balance.
,