AI traffic train performance revisited

sniper297

Coconut God
Started with this;

http://forums.auran.com/trainz/showthread.php?74677-AI-traffic-framerates

Never really got anywhere since nothing I tried works as advertised. A solution that might help if it could be made to work somehow;

29036149.jpg


D is destination portals, S is spawning portals, T is triggers. The idea is to take big routes and break them up into sections, where AI trains run only in the section the player is currently in, and nowhere else on the route - any AI train not seen by the player is a waste of resources, and Trainz doesn't save resources outside the "player bubble" so either a Cray or some kind of workaround is needed.

What would help is if the "emit train on trigger" could be designed so that the portals on the red line spawned trains every X number of minutes as long as the player train remains in that section, and when the player passes a trigger it shuts off the portals for the section he's leaving and starts up the portals in the section he's entering. Obviously if the player shuttles back and forth across the trigger it could create problems, so either some really great coding or some skull sweat by the route creator designing the connecting tracks and trigger placement would be a must.

I don't even know if this would be possible, but testing on a big route with just the player train versus dozens of AI trains running all over the route, the difference in performance is astonishing. Some way to get 2 to 4 AI trains continually running where the player is, and nowhere else on the route, keeping up with the player movements so that the section he's in is always busy and everywhere he's not at the moment is always empty, would solve a lot of session creation headaches.
 
Back in TRS04 days you could do pretty much exactly that using TPR's Scenario Creation System. AI trains appeared only when and if required, and only ran through the part of the route occupied by the player train. IIRC you didn't even need Portals, the AI trains simply spawned and disappeared at defined trackmarks just out of current camera view. The Company broke the system with TRS06 (or was it 09?). Anyway I know the creators tried to figure a work-around to keep what was a very very good system alive, but afaik The Company broke it so thoroughly it was pretty much unfixable.....
 
"The Company" is what the CIA is usually referred to as, I assume you mean N3V or their predecessor. :cool: In any case that's an unwinnable argument, they don't need to optimize the performance, the customers need to ignore the minimum specs and buy the latest bleeding edge hardware to overpower the inefficient code. Since I don't have the scratch for that, I'm looking for something that works with the current code to run AI trains only where they'll do the most good. MSTS had (like most 3D simulators) a "player bubble" just a little larger than the max visibility circle, everything that moved inside that bubble got first priority for system resources, everything outside the bubble was approximated with simple math until it got within the range where closer calculations were needed. The simplest fix would be to run an all over the entire route traffic pattern with some kind of script which made the program do rough position calculations outside 5000 meters from the camera and switch to real time when it got to 6000 meters or so, dunno if that's possible with Trainz either.

What I know we do have is emit train on trigger, the problems I had trying that;
1. It emits a train on trigger but then goes into normal emit every X minutes and there's no way to shut it off, and
2. The max trains on route can't be turned off, the "yes-no" button is broken, the max set to 99 counts every loose consist on the route as a "train" so if there are 100 loose consists in the session it won't emit on trigger.

So the trick is to find an alternative or a way to fix the yes-no button so it allows any number of trains and emits on trigger without counting existing trains at all, and preferably some way to turn it on and shut it off with triggers.
 
This thread has my interest. I'm an ex software engineer and tracking a non visible AI train including its compositon, location, speed, etc should be a piece of cake. You can do this as a lower priority thread within the progam.
The higher priority would be the visible assets that I assume would be in the "bubble". But I guess it depends on how the program (Trainz) is designed - i.e. the architecture.

You don't need a Cray to do this. I was writing multi tasking software (threads) back in the 80's to run on 16mhz (I think!) 80386 computers.

I'm surprised you cannot change the values in your points 1 and 2. I shall have to go and look.
 
@ Snipes '2.' above - there is a script currently available which turns a 'loose consist' into what is in effect a scenery object and takes it out of that particular loop. Pretty sure it is in most recent JR rolling stock and also pretty sure I have read a couple of places that they are happy to have folks use it in other RS. I assume it can be inserted into existing stock, but I guess that doesn't help if you want to do a distributable session - unless you start cloning lots of stock.....
 
I have mentioned once or twice regarding threading in Trainz, and WindWalkr did say that Trainz is not multithreaded (or something similar), although I am aware that certain operations do operate on different threads.

Shane
 
....The idea is to take big routes and break them up into sections, where AI trains run only in the section the player is currently in, and nowhere else on the route - any AI train not seen by the player is a waste of resources, and Trainz doesn't save resources outside..........
What would help is if the "emit train on trigger" could be designed so that the portals on the red line spawned trains every X number of minutes as long as the player train remains in that section, and when the player passes a trigger it shuts off the portals for the section he's leaving and starts up the portals in the section he's entering. Obviously if the player shuttles back and forth across the trigger it could create problems, so either some really great coding or some skull sweat by the route creator designing the connecting tracks and trigger placement would be a must.
..... Some way to get 2 to 4 AI trains continually running where the player is, and nowhere else on the route, keeping up with the player movements so that the section he's in is always busy and everywhere he's not at the moment is always empty, would solve a lot of session creation headaches.


If we are talking about the ''scenery trains'', (i call them so, because they are on the track to make the visual effect for traffic dense, but not have any task to do) then i agree that unportals are not accurate, because they emit trains without control. Combination of the rules Trigger check-CPC Emit train--UnPortal don't work properly and i don't see any other solution for the routes where we have not portals.

On the route with portals is the best solution using timetable. Emiting the trains with pguy's Quick Portal Manager v2 or v3 is very good solution. Of course this solution demand that we synchronize the movement of player and AI trains.
 
Getting sidetracked here, the freight cars I'm talking about ALL have the sleep script, when they're outside the player's camera view they have no effect on performance because the physics aren't loaded.

http://forums.auran.com/trainz/showthread.php?76129-Now-commence-Operation-Framerates

Problem is if you look in the map you see this;

66549763.jpg


None of those have an engine coupled on, all have the carfizzix script so all are "asleep" and the program does not have the physics loaded, so when they're out of sight they don't degrade performance in any way. However;

42066056.jpg


Each consist is counted as a "train" by the CPC emit train on trigger rule. You can set it to not delete existing trains, but the max allowed on the route is 99, if it sees more than 99 loose consists it counts them all as "trains" and won't emit a train on trigger.

And like I say there seems to be no way to turn it off except to set the portal interval to something weird like 999 minutes, otherwise once it starts it acts like a regular portal and repeats the spawn at whatever interval it's set for. So set for 999 and there's no way to set a trigger delay, if the player passes back and forth over the trigger it spits one out every time he hits the trigger even if it's 30 seconds later. Assuming less than 50 loose consists, of course.

My thinking on this is if there's no way to make it toggle on and off by trigger an alternative control would be to festoon the entire mainline with triggers so whenever the player move he activates one, with some kind of delay where the portal will ignore triggers until 10 or 15 minutes after the previous spawn.

However it's done the first priority is getting rid of the max trains on route limit so you can have a reasonable number of loose consists for switching (shunting).
 
Have so many ''asleep'' consists is unproductive and is the matter of route or session maker. I don't see any reason to have so much of them on the track. But if they are in the function of scenery then the quote must be reasonable.

CPC and UnPortal are unreliable because they emit train without sufficient control and soon or later the problem arise, because the TS is not capabile to manage this quantity. It is much better to use time for emit.
 
Last edited:
"unproductive" is a matter of opinion, for switching activities on large routes with many many many industry spurs and yards, 1000 loose consist freight cars can be a bare minimum. Which is exactly what the sleep script was designed for, if those 1000 cars are all sleep script cars it has no impact on performance. If you have a small route with 20 or 30 loose consist freight cars you won't get any benefit from the sleep script.

All irrelevant to this issue, the problem is the way CPC views every consist as a "train" whether it has a locomotive or not.
 
... the problem is the way CPC views every consist as a "train" whether it has a locomotive or not.

It's not CPC that is at fault. The code just calls the World function GetTrainList that returns a list of "train objects" on the route. I guess train objects include loose consists. By loose consists I mean trucks and carriages sitting in a siding somewhere basically being scenery.

The maximum of 99 trains is controlled by the CPC browser and the associated properties code. It could be changed but there would probably be a performance hit if it went too high.

Perhaps the CPC script(s) could be modified to examine the list of trains and ignore those those that are "dormant". Frankly I don't know if that is possible. "Dormant" would need to be defined and recognisable.

You could try contacting the author (sforget) but he doesn't seem to be posting much recently.
 
"probably be a performance hit if it went too high", I think that's understood, if it's possible to remove or disable the check for current number of trains on the route it would be up to the session creator to do whatever it takes to keep it within limits. With an open ended ("freestyle") session there's no way to tell where the player will be when, so either some really clever placement of triggers or preferably some kind of countdown timer to disable the trigger for X number of minutes after each activation would be needed. That's why I'm thinking the "sectional" idea is the most workable, design the route so the player crosses a trigger or series of triggers which shuts off the spawning portal(s) in the section he's leaving and turns them on in the section he's entering.

Obviously the current practice of having a spawning portal at each end of the route sending trains over the entire length of the route is simpler to set up, but the longer the route the more trains will be running way outside the area where the player will see or interact with them. For really complex routes like Chicago Metro it's an even bigger waste of resources, I start at 40th Street yard and run up to the Milwaukee yard, go east on the Bloomingdale line to Goose Island, meantime there are trains running back and forth down south on the Burlington that don't need to be there unless I go down there.
 
... if it's possible to remove or disable the check for current number of trains on the route it would be up to the session creator to do whatever it takes to keep it within limits. ...

I guess you could clone the CPC asset and adjust the "99" figure in the code first to see what difference it would make. Removing or disabling the check is harder because there is a variable called MaxTrains that is used in a number of places in the scripts. Removing or messing with that may have unintended consequences.

If you are interested I will clone the asset and play with the 99 value to see if it can be easily increased. Then I'll post the changes.

But it would be up to Steven (sforget) to modify CPC for wider usage.

ps - I confess I'm not particularly savvy with portals although I have used them. Its the problem that interests me. :o
 
That was the idea behind starting this thread, see how many brains we can get working on the problem since we'll be ice skating in hell before N3V does anything about optimizing the game. One suggestion (I forget who) was the quick portal manager v3, trouble with that is there were apparently 21 updates, all except;

Quick Portal Manager v3,<kuid2:61392:5012:8>
Quick Portal Manager v3,<kuid2:61392:5012:10>
Quick Portal Manager v3,<kuid2:61392:5012:12>
Quick Portal Manager v3,<kuid2:61392:5012:19>
Quick Portal Manager v3,<kuid2:61392:5012:20>

Are unknown location - the latest on the DLS is 21, but that one won't download in content manager and the FTP option isn't there. I assume it's still a work in progress, but at the moment there's no way to even try it out.
 
I have Quick Portal Manager v3,<kuid2:61392:5012:210> on my system and could send you the cdp if you want. Just PM me with a throwaway e-mail address. I appear to have downloaded it on the 9th Nov. Probably the last time I tried to clear the update queue.

I've cloned CPC and my first attempt at modifying the max trains value didn't work but I'll keep plugging away at it.
 
OK, I figured out how to increase the maximum number of trains.

As I said before, you will need to clone CPC. There are two script files in the asset: mpc.gs and mpcinfo.gs. You need to edit mpcinfo.gs with a text editor or an editor that will save as plain text.

Go to line number 221 and 222. The code at those lines should be:

Code:
else if (propertyID == Prop("MaxTrains"))
      return "int,0,99,1";

Add an extra 9 to the "99" to make it "999" so it looks like:

Code:
else if (propertyID == Prop("MaxTrains"))
return "int,0,999,1";

Save and commit into Trainz.

If you already have a session using MPC then it would be very wise to make a copy of it and change the copy.

In your copy of the session remove MPC from the session rules and add your clone instead. You should now be able to increase your maximum number of trains up to 999.

I haven't tested this beyond changing the max number of trains and then exiting and reloading to make sure the changed number is still there. Which it was.

MPC is used to create portals so, if it is removed, those portals may also be removed. In that case you may need to modify CPC instead of the clone.

No idea if this will fix your problem but it might worth a try. All at your own risk of course. :wave: Please don't blame me if Trainz explodes or something else nasty happens.
 
kuid2:61392:5012:210 seriously? Two hundred ten updates? I don't think I want to even look at it unless it has all the solutions to all the problems and can be programmed in a few simple steps by a non rocket scientist. I was gonna download it to see if it (1) had coherent instructions on use and (2) was designed for these types of problems and (3) actually worked, but with all the updates and problems I suspect it would be just more wasted time to even find out if it's relevant.

I'll try the CPC hack, if 999 don't make it explode maybe 9999 will. :cool:
 
It was a typo and was intended to be 21. It's hot here (100f) so that's my excuse. Maybe a cold beer will help.
 
Further to my earlier post about the code changes. Replacing CPC with a clone in a session will lose the portals and consists defined in CPC. So you have a number of portals hacking the original may be the preferred option.
 
Sniper

You said:
''One suggestion (I forget who) was the quick portal manager v3''

It seems that you don't read the post in your own thread. (look post #7)

You said:
''I don't think I want to even look at it ( Quick portal manager v3) unless it has all the solutions to all the problems and can be programmed in a few simple steps by a non rocket scientist. I was gonna download it to see if it (1) had coherent instructions on use and (2) was designed for these types of problems and (3) actually worked, but with all the updates and problems I suspect it would be just more wasted time to even find out if it's relevant''.

It would be good that you try the rule first and then express your opinion. If something you don't know, this don't mean that don't exist and if you something don't understand it doesn't mean that it's no good.


You can find the example of the use of Quick portal manager in the session ECML KC-Nc cargo.

BTW, using 99 trains or even 999 is absurd, TS has limitations, running at once 15 trains is almost the upper limit in the big route.

Edit: another sulution is Portal Manager made by brummfondel. It use random, siquential or time for emit
 
Last edited:
Back
Top