Phase I and II here;
http://forums.auran.com/trainz/showthread.php?t=76129
Main problem with Trainz is it was originally designed to simulate small model railroads, and they never programmed in a "player bubble" subroutine that most simulator games have. Anything inside the player bubble, usually a circle 1 to 3 times the maximum view distance, gets all the heavy duty number crunching while anything outside the bubble gets a simplified low memory and CPU usage approximation calculation program. The high level processing doesn't kick in until it gets close to the point where it's actually needed, thus saving system resources for where they are needed close to the player's viewpoint.
Since Trainz loads and fully processes the data for every car and loco and train in the entire session regardless how far away, one solution to the loose consist problem is the "sleep script" described in post 12 and 13 of the above linked thread.
Next problem is AI traffic trains, the sleep script doesn't hurt any but it's no help for AI trains either.
30FPS at the start of the session, one 6 car player train and three 6 car AI trains.
With one AI train spawning from each end every six minutes, at the 54 minute mark there are 21 six car AI trains running - none are in view, only 3 or 4 are within the 2500 meter visibility radius of the player, but the framerates are down to 16.6FPS due to the CPU loading down with all the calculations for all 21 running AI trains.
Solutions, nothing practical as yet. I've tried cloning engine specs and chopping out all but the basics to make an AI only specific engine spec, can't see that it makes any difference in framerates. Using CPC emit train on trigger would solve the problem for a rapid transit route by limiting the number of AI trains to only the ones near the player, but that would require something ridiculous like 100 spawn and destination portals with triggers and short connecting tracks on both sides every mile or so, along with several weeks or even months of tedious programming and debugging to get it all to work.
The most practical answer is probably some kind of script, but what? The default parse interval near as I can tell is 0.03 seconds, is there a way to script it so the interval is 1 second until it's within 10,000 meter range of the player, then kick over to 0.03? Without derailing or running off path, obviously, I suspect it's possible to increase the timestep to some outrageous number like every five seconds, but that would result in a lot of missed signals and track markers outside the trigger radius.
http://forums.auran.com/trainz/showthread.php?t=76129
Main problem with Trainz is it was originally designed to simulate small model railroads, and they never programmed in a "player bubble" subroutine that most simulator games have. Anything inside the player bubble, usually a circle 1 to 3 times the maximum view distance, gets all the heavy duty number crunching while anything outside the bubble gets a simplified low memory and CPU usage approximation calculation program. The high level processing doesn't kick in until it gets close to the point where it's actually needed, thus saving system resources for where they are needed close to the player's viewpoint.
Since Trainz loads and fully processes the data for every car and loco and train in the entire session regardless how far away, one solution to the loose consist problem is the "sleep script" described in post 12 and 13 of the above linked thread.
Next problem is AI traffic trains, the sleep script doesn't hurt any but it's no help for AI trains either.
30FPS at the start of the session, one 6 car player train and three 6 car AI trains.
With one AI train spawning from each end every six minutes, at the 54 minute mark there are 21 six car AI trains running - none are in view, only 3 or 4 are within the 2500 meter visibility radius of the player, but the framerates are down to 16.6FPS due to the CPU loading down with all the calculations for all 21 running AI trains.
Solutions, nothing practical as yet. I've tried cloning engine specs and chopping out all but the basics to make an AI only specific engine spec, can't see that it makes any difference in framerates. Using CPC emit train on trigger would solve the problem for a rapid transit route by limiting the number of AI trains to only the ones near the player, but that would require something ridiculous like 100 spawn and destination portals with triggers and short connecting tracks on both sides every mile or so, along with several weeks or even months of tedious programming and debugging to get it all to work.
The most practical answer is probably some kind of script, but what? The default parse interval near as I can tell is 0.03 seconds, is there a way to script it so the interval is 1 second until it's within 10,000 meter range of the player, then kick over to 0.03? Without derailing or running off path, obviously, I suspect it's possible to increase the timestep to some outrageous number like every five seconds, but that would result in a lot of missed signals and track markers outside the trigger radius.