Again you're completely missing the point. I'm not looking to run 999 AI trains, if I was I would just leave it the way it is with AI trains spawning 20-30 minutes apart from 4 different portals and running over the whole route. The 999 trains would be one player train, 8 AI trains, and 990 loose consists. The 990 loose consists have zero effect on performance because all the cars have the sleep script, the problem is CPC wants to count those 990 loose consists as "trains" for the purpose of limiting the number of trains on the route. To help performance, which it does not help because 990 of the "trains" it's counting are not trains.
AI traffic train performance revisited
- Thread starter sniper297
- Start date
And, finally managed to get the latest Quick Portal Manager 3 (update 21) installed and working - Celjie, that has no triggers in it, totally useless for this, I think you don't understand what the problem is or what we're trying to do here.
"this solution demand that we synchronize the movement of player and AI trains." But Quick Portal Manager has nothing remotely like that.
"this solution demand that we synchronize the movement of player and AI trains." But Quick Portal Manager has nothing remotely like that.
Sniper297. You've mentioned the "Sleep" script a few times but I'm not familiar with it and I cannot find a sleep.gs in my TS12 folder. So I guess its contained in another script. Can you identify an asset that uses it?
I was thinking of writing or amending a script to count the number of trains and then see if I can identify the number that are dormant (or sleeping)
I was thinking of writing or amending a script to count the number of trains and then see if I can identify the number that are dormant (or sleeping)
Set CM filter for Author sniper297 category rolling stock, all my freight cars have it. Name of the file is carfizzix.gs, what it does is turn off the physics for cars equipped with it until a locomotive couples on, then it activates the physics. Justin and I tested for several weeks with up to 4000 cars on a route at one time, couldn't find any problems. Uncouple on the fly to kick or hump the car the physics are still active until it rolls to a stop. Behaves like any normal car except when it's standing still either by itself or coupled into a string of cars with no locomotive. Even helps when mixed in with regular cars - got a 40 car string sitting in a yard with 10 regular cars and 30 "sleep" cars, the physics for the 10 normal cars are loaded to memory and constantly worried over but the 30 sleep cars are treated as scenery. The only strange thing is that everyone doesn't use it, it's a tremendous performance gain when there are a lot of loose cars in the session and there's no downside to it.
OK got it, thanks. I was thinking of a "monitor" session rule asset that every minute or so, pops up a message giving the number of trains on route, the number active and the number sleeping. If it works then the calculation could be embedded in CPC as a function to determine the number of active trains.
This might take a couple of days.
Cheers
This might take a couple of days.
Cheers
What I have on the test route at the moment is a clone of the CPC rule with the max trains allowed set to 9999 which pretty much disables that part of it. Delay is set for 999 minutes, which is 16.65 hours, so essentially no repeat it just spawns a new train each time the player passes over one of the triggers. Obvious problem with that is there's no repeat delay, if the player train reverses back and forth over a trigger you get a constant parade of new trains spawning. What's needed is either:
1. A forced delay on the spawning or the trigger so it disables the trigger or spawn for a set amount of minutes after each time it's triggered, IE spawn one train from portal and ignore any more triggers for 15 minutes.
2. An on-off type trigger so when the portal(s) is(are) activated they work like a normal portal spawning a new train every 15 minutes, then stop and go inactive with the next trigger.
The second one would be preferable since the route could be sectioned, with the player running over a trigger that deactivates the portals in the section he's leaving and activates the portals in the section he's entering. If that's not possible the first option with the delay would need many triggers in each section to create a reasonable traffic flow in that section as long as the player train continues to move around in that section.
1. A forced delay on the spawning or the trigger so it disables the trigger or spawn for a set amount of minutes after each time it's triggered, IE spawn one train from portal and ignore any more triggers for 15 minutes.
2. An on-off type trigger so when the portal(s) is(are) activated they work like a normal portal spawning a new train every 15 minutes, then stop and go inactive with the next trigger.
The second one would be preferable since the route could be sectioned, with the player running over a trigger that deactivates the portals in the section he's leaving and activates the portals in the section he's entering. If that's not possible the first option with the delay would need many triggers in each section to create a reasonable traffic flow in that section as long as the player train continues to move around in that section.
I think I can see where that might be achieved in the script.
That, I think, would be harder because it would require another portal attribute that would need to be added to the portals property page in the browser. Plus I'm not sure if portals can be turned on and off. But I will have a look.
This remains of interest to me but I can foresee this getting out of my depth especially as my knowledge of portals is diddly squat. Testing this would require a significant route and session although there are probably some available on the DLS. I still think you should try and contact Steven (sforget). If he is not interested AND is willing for me to "take over" CPC then I might be prepared to have a crack at it.
Perhaps I could manufacture a clone that does you want but I would be really uncomfortable giving the clone to someone else.
Looking over all the different rules, I know some prefer CPC or Quick Portal just so they don't have to fly all over the route setting up each spawning portal individually. To me it seems simpler to set each portal then move to the next one and set that up, the whole CPC process is so complicated it really doesn't save any time. With that in mind I looked at the basic Auran portal, and to me it looks like it would be much simpler to clone that portal and add triggers and some kind of on/off feature to the script for the portal. Where it really gets rather discouraging is looking over the Chicago Metro and seeing how many new portals I have to add just to divide the traffic pattern into smaller patterns for each section, there's a lot of different mainlines involved. What I'll probably do over the next few weeks is forget the main part of the freight and commuter lines and just focus on the rapid transit lines, see if there's enough performance increase using multiple triggers and portals on those lines. The current limitations would actually work better for rapid transit anyway, being a pure passenger operation there wouldn't be the same kind of back and forth moves you get with freight switching and way freight operations.
There a number of portals on the DLS so perhaps one might have the features you want? But I guess you have already checked them out.
I found CPC a bit confusing as well given that there are two assets controlling the same portal and I wondered if there were conflicts. Brighter minds than mine have probably already figured that out.
I couldn't get my session rule code to work as there are no functions to query the physics state of the train that I could find. Seemed a bit odd that you could change the state but not query it.
So I'm going back to working on a script for Konni to animate his tender/loco brakes. Thats a bit easier than this topic! Sorry I couldn't solve your problem.
Cheers
I found CPC a bit confusing as well given that there are two assets controlling the same portal and I wondered if there were conflicts. Brighter minds than mine have probably already figured that out.
I couldn't get my session rule code to work as there are no functions to query the physics state of the train that I could find. Seemed a bit odd that you could change the state but not query it.
So I'm going back to working on a script for Konni to animate his tender/loco brakes. Thats a bit easier than this topic! Sorry I couldn't solve your problem.
Cheers
No, I haven't investigated many alternatives, mainly because of the lack of documentation. Download, install, place on route, connect, configure, try to figure out how to use it and what makes it different from a standard portal, when you finally understand it you discover it's not designed to do what you want, there goes another wasted day. Kinda like quick portal manager. Built in;
iPortalTunnel,<kuid2:30671:23500:1>
Description: iPortalTunnel
Instructions: none.
So what's it for, how is it different from a regular portal, would it have a feature that might be relevant to the problem I'm currently trying to solve or not? Google the wiki articles and try to make sense out of those, or trial and error it, either way another wasted day.
iPortalTunnel,<kuid2:30671:23500:1>
Description: iPortalTunnel
Instructions: none.
So what's it for, how is it different from a regular portal, would it have a feature that might be relevant to the problem I'm currently trying to solve or not? Google the wiki articles and try to make sense out of those, or trial and error it, either way another wasted day.
I think that the proposed changes are easy to implement.
There is no need to limit the number of trainz, just define what would your max number be and the CPC should take care of not spawning more than that, the player would assume the risk of so many running trainz.
How to count the number of trainz? just add some property to all trainz spawned at the portals and count only those trainz with that identifier, do not use World.GetTrainList() because it will include all consists in the map even those without a loco.
Adding a new trigger to turn CPC on/off would be similar to my new directional triggers.
It would be much easier if we can modify CPC, if we can get his permission. If not, we can find another suitable item, or even start from scratch.
I will try my first coding one of these days, today is my last vacation day and right now believe or not I am re-installing TS12, somehow it got screwed, no routes, nothing, only a green screen with the top-left menu, not even options. Of course, the only thing visible was N3V advertisement
cheers,
--José
There is no need to limit the number of trainz, just define what would your max number be and the CPC should take care of not spawning more than that, the player would assume the risk of so many running trainz.
How to count the number of trainz? just add some property to all trainz spawned at the portals and count only those trainz with that identifier, do not use World.GetTrainList() because it will include all consists in the map even those without a loco.
Adding a new trigger to turn CPC on/off would be similar to my new directional triggers.
It would be much easier if we can modify CPC, if we can get his permission. If not, we can find another suitable item, or even start from scratch.
I will try my first coding one of these days, today is my last vacation day and right now believe or not I am re-installing TS12, somehow it got screwed, no routes, nothing, only a green screen with the top-left menu, not even options. Of course, the only thing visible was N3V advertisement
cheers,
--José
Actually CPC is nothing more than a menu to configure all the portals without moving around, and I find it more difficult to use since you have to figure out and remember the portal index number for each portal. The Emit Train on Trigger rule is the part that might have potential, would be better if it wasn't tied to CPC and had more versatile configuration options.
Again, the best solution would be normal timed spawning which could be turned on and off by a trigger. The session creator on a large route could set up different sessions by section or "zone" with only the portals in that zone spawning AI trains, but then if the player drives to some other zone he would see no AI traffic at all, while the AI traffic continues to run in the zone he's no longer in. The way Trainz is programmed that's wasted resources, so having a trigger that turns off the spawning portals in the section the player is leaving and turning them on in the section he's entering would be the simplest and most efficient way to have reasonable traffic volume without tanking the framerates.
Again, the best solution would be normal timed spawning which could be turned on and off by a trigger. The session creator on a large route could set up different sessions by section or "zone" with only the portals in that zone spawning AI trains, but then if the player drives to some other zone he would see no AI traffic at all, while the AI traffic continues to run in the zone he's no longer in. The way Trainz is programmed that's wasted resources, so having a trigger that turns off the spawning portals in the section the player is leaving and turning them on in the section he's entering would be the simplest and most efficient way to have reasonable traffic volume without tanking the framerates.
Last edited:
Got it! it sounds much simpler now, just a trigger, right? I'll give a shot, I am almost done with re-installing TS12. Hopefully by the end of this week I'd have something working.
Not really "just a trigger", the CPC emit train on trigger rule starts a portal, then the portal works like a regular portal after that spawning trains at whatever frequency it's set for. What's needed is a trigger that will shut it off so it doesn't continue spawning trains when the player is no longer in that section. Preferably the on and off triggers (could be a toggle or two different triggers) would work with the portal itself without requiring complicated stuff like CPC or any kind of check on how many trains are already on the route. Set up properly the AI train limit would take care of itself, with only the portals for the section that the player is currently in spawning trains you would have a maximum of 4 to 6 running at any one time. That's the problem with the current system on really big and/or complex routes, for the player to see 2 or 3 AI trains in a 10 minute period wherever he is, you need 40 or 50 running at the same time.
That's the part that got me confused because the emit frequency is in the portal. I couldn't see the overall relationship between CPC and the portal and I wondered if the portal was actually emitting more trains than the specified interval. I probably would have built a test rig to check it out.
Plus I thought Sniper297 wanted to move away from CPC or other high level controllers and have a portal with a "enable/disable" method and the standard features.
The portals that I looked at seemed to have a common software architecture. There is a main file that does the work and a "...info.gs" file that contains the browser for portal control. I'd probably start with the Auran basic portal and build on that.
Hey pcas1986,
did you see this statement in baseportal.gs?
I am starting to peruse the portal code and I saw that statement above and I am surprised with that hardcoded limit of 16, I don't get it.
Also I couldn't find the handler for this statement:
PostMessage(me, "PortalTunnel", "EmitTrain", 0);
anyways, I am getting to know the code better....
did you see this statement in baseportal.gs?
Code:
int num = m_productionList.size();
if (num >= 16)
{
Interface.Log("PortalTunnel.AddProduceTrain> too many trains in list");
return;
}I am starting to peruse the portal code and I saw that statement above and I am surprised with that hardcoded limit of 16, I don't get it.
Also I couldn't find the handler for this statement:
PostMessage(me, "PortalTunnel", "EmitTrain", 0);
anyways, I am getting to know the code better....
I try not to look inside the private stuff but I agree it looks a bit odd. Maybe it never gets called. I usually only look at the API. Note that I have found methods and functions in the N3V scripts that don't appear on the WiKi.
Regarding handlers. I've looked at a few scripts recently where a general handler is used for quite specific messages. i.e. the handler handles the message but doesn't test the msg.major ("PortalTunnel" for example) or the msg.minor.
Sniper297's carffix.gs script is an example:
Regarding handlers. I've looked at a few scripts recently where a general handler is used for quite specific messages. i.e. the handler handles the message but doesn't test the msg.major ("PortalTunnel" for example) or the msg.minor.
Sniper297's carffix.gs script is an example:
I haven't tested this but my off the cuff guess is that 16 has nothing to do with number of trains running, it's a limit on how many different consists can be spawned from one portal. I generally have a max of 4 or 5 per portal, even if you run a session for 4 hours with a 10 minute spawn rate it should be enough variety for most people.
Yes, we have luck of understanding. I was not talking about trigger-CPC combination, i suggested a different approach by using Quick portal manager (QPM). QPM has no triggers, it use time (clock, hh:mm if you wish) and the movement of player and AI trains is synchronize with hh:mm.
Example:
section AB, lenght e.g. 5 km, portal1 at point B and portal2 at point A, both portals on the second track
When Driver arrive to point A at 10:15, portal1 emit first AI train at e.g 10:01, second at 10:04, third at 10:09 etc. You can use any time you wish. All AI's have equal schedule 'Navigate to Portal2'.
I will not involve in this discussion anymore.
regards
Last edited: