Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
I have a fast pax line which traverses my map. I ran it over the map with the simulation running triple speed. These are for the same trip (leaving one station and arriving at the next, with a full pax load both times)
On the "full/slow" version, the trip took 1min 41secs in real time.
On the "cargo reduced" version, the trip took 1min 9secs in real time.
So there is definitely a big difference between the two.
Cheers,
Chris.
The real statement is that cargo is negletable to PAX.
1 Person has around 10x more/longer route calcs than 1 cargo, especialy if private car.
the only empirical "measurement" would be viewed in the debug render time window.
I play cargo-heavy maps (and notably with very long ship lines with hundreds of ships) and there is definitely a performance impact. CPU ops are CPU ops, it doesn't matter much where they come from. It's just that passengers require more of them, but even a cargo-heavy / passenger-light map can have performance issues.
Kudos on the test effort. It's that kind of testing that revealed that the Fall update has lower performance than the previous version. If you want harder numbers in your tests and you have nvidia GeForce Experience installed (or whatever it's been renamed now), just do your ridealongs while logging the data. It dumps .CSV files so you can then make comparison plots in Excel or whatever for FPS, CPU and GPU load, etc.
Yes that is strong evidence that the level of cargo significantly effects performance. I've got a couple of questions about things I'm not clear about from your test report, but before that I have considered something I said about this in my post the other day which may be wrong.
I had made an assumption that the loading/unloading graphic and the code behind it would only run if the vehicle in question was within the current viewport. Thinking about this that might be wrong because it may not be possible to recreate the visuals of the load/unload procedure elegantly (or anything like elegantly) should the player suddenly scroll or zoom to a station where trains were currently loading cargo (I've never programmed games or serious graphics so I've got no feel for this really).
If that was so the implication is load/unloads need to be individually tracked, one wagon at a time, in real time across the map regardless of what the player was looking at. That in turn means that if you increase the amount of cargo carried by each train six fold, thereby increasing the length of time it takes to load/unload them also six fold, you will increase significantly the number of trains that are simultaneously being loaded and unloaded thereby eating a lot more RAM and CPU time.
That theory could be tested by modding the game to dramatically increase load/unload speeds although that might be a lot of work since each wagon has it's own load/unload rate, I don't know if there is a convenient global factor that also affects this rate.
Anyway the questions I have to fully understand your test are:
1. I don't understand what "use the sandbox mod to turn "inputs off" for all town demand production" means.
2. I'm not clear if your test involved turning off the mod in question or just adjusting the mod's settings/parameters. Either way what this mod does exactly is a significant variable in interpreting these test results since it will be injecting additional code into the game.
Just have every producer mix its goods with everything else, and let the game sort out which consumer (and ultimately city) gets what.
On the other hand, it's also very easy to NOT have cargo impact performance. Just have your trains drive from one producer to one consumer. This still is playing the game as intended, since you can still supply cities without complicated cargo pathways.
The important distinction is that there's no way to do the same for passengers. If your cities grow performance is gonna tank. (Cities grow because the number of connections increase). The only way to keep the game running decently is to cut connections, which basically means NOT playing the game the way it is intended.
This is why you might hear "cargo doesn't impact performance while passengers definitely do".
You CAN make cargo impact performance, and you CAN make passengers not impact performance. That does not mean the preceding claim isn't true.
The sandbox mod allows you to (among other things) turn off "inputs" for each factory. This allows you to generate the produce "machines" for example, without having to supply either of the steel and plastics usually required for a machines factory to produce.
I did not turn off the mod in question, it was on in both tests. Yes, this mod injects additional code, essentially increasing the max output of factories from 400 to whatever you configure, the default being a max of 6400. I generally only allowed mine to increase to 1600.
Cheers,
Chris.
I'm not convinced that this would have that much of an effect, although it is an interesting idea. I will admit that I run my maps with hubs, collating multiple goods for delivery into the towns. Each hub will serve generally around 4 towns, which might mean 6 or 7 different supplies are being distributed from the hub. I use multi-consist trains to deliver from the hub to the town.
I generally run maps with small numbers of towns, and I generally have one factory supplying one hub, so generally around 4 towns.
So we know that every item produced is tagged with it's destination at the point of production. In a 1 factory 1 town situation becomes a very simple decision. In a 1 factory 4 towns, the decision is not that much harder. Incrementally harder yes, but not orders of magnitude harder.
The same would be true for calculating the path. In 1:1 that's a simple calculation again. In my 1:4 the calculation is a 2 step process. One step to the hub, another step to the town. So again, incrementally harder, but not orders of magnitude harder.
The issue with a pure 1 factory 1 town scenario is the ability to supply all your towns. On the maps I've played, there's generally one factory for every 4 to 6 towns.
So if you have one factory supplying 4 towns, each with their own unit trains, then the calculations become a lot closer either way.
That's just my initial thoughts, I'm not sure I can do any testing on this, as I don't play that style.
Cheers,
Chris.
Interestingly it seemed that each wagon had two parcels of logs/planks to load unload, the implication being there isn't a direct relationship between actual cargo carried and the graphical units loaded/unloaded on screen at the platform. Each graphical parcel seemed to represent 2.5 units of actual cargo but it's quite quick so I might not have been able to see a half parcel being slipped in.
Would be interesting to see how long it takes to load/unload longer trains especially with bigger capacity waggons, I don't have a save suitable to do that at the moment. Whether for example a ten capacity waggon unloads two 5 cargo parcels in exactly the same amount of time or four 2.5 cargo parcels in twice as much time etc.
Anyway 10 seconds is a long time in computing terms for a function to be sitting on the stack (i.e. high memory) orchestrating a procedure like this and it's got a lot of graphical work to do. It might go quite a long way to explain the increase in RAM usage as a result of a six fold increase in cargo being moved around between trains and platforms. I'd say this procedure may be a lot more expensive in compute resources than a train just chuntering down the track for example.
Before I start explaining, let me know you guys that my pc spec is one of the top notch pc; i9 13th gen, RTX 4080.
My map is a megalomaniac map with 9.3 h game time(Simulation), very hard game difficulty, 24k passengers transported and 6.2 mil cargo transported. And also 40k pop and 350 km of tracks. And $ 1.9 T.
I had about 100 trains on 6 lines on the same track. But! Those trains are 1800 m long. Yes, longest station length is 840 m, so trains are longer than stations.
First, I thought that there are too many models(objects). That's why the game was lagging. So I increase load capacity. For example, a gondola could carry 20 capacity in vanilla game. I increased it to 10,000 capacity. so I had to pull with 6 locomotives on each train. You see, that changed the models count by 50 to 1. 6 loco + 1 wagon. And still lagging. So clearly, it is not graphic issue. I can't do more than 10k capacity per train because profit will be negative due to game's mechanic.
Second, I changed loading speed to match 10k capacity. I changed 4 loading speed to 1,000 loading speed. Then the game Freeze! About 4-5 seconds freeze and millisecond move and freeze again.
8-13% CPU usage, about 7 GB memory usage, GPU usage is vary; about 25% when freeze and about 85 % when move.
So clearly, CLEARLY! It is unloading/loading cargo issue.
What I don't understand is that all the goods are already determined where to transport when it's popup into the map. Lagging should be there, not when loading/ unloading the goods.
Another thing is that loading/unloading time of 10k capacity on a single goods is 10 times longer than 1k capacity each on 10 types of goods, totaling 10k capacity. Loading speed is counts on the quantity of goods types but not on wagon's capacity/loading speed. Really strange.
So, If you have any idea to solve that unloading/loading freeze issue, lay it on me please.
Thanks.
(P.S) It took about 40 mins to write this post yet one of my trains only traveled 1/3 of the map.
Does the load speed shown in data card affect the rate cargo is loaded/unloaded? I routinely see it displaying a different number than it shows when you purchase it. Some modifiers to that somewhere?
That's very interesting. My quick observation yesterday led me believe that the standard time unit for loading/unloading is 0.1s. A 2x loading speed wagon takes 0.2 seconds to load and 0.2s to unload. A 4x load speed wagon 0.4 seconds for each.
Or it could be the standard loading time is 1s and x2 makes it 0.5s, x4 0.25s etc. Or it could be 0.8s which would match my eyeball estimate of 0.2 load + 0.2 unload for a x2 wagon. Or it could be some other calulation altogether, I haven't had a chance to look at bigger wagons with x4 load ratings yet. Whatever, I think it's something like that.
The loading function does two things, first is controls how long it takes to load/unload trains in real time (i.e. it delays the load/unload of each wagon using a timer) and second it choreographs calls to the graphics engine to remove/add boxes and bundles from the wagons (if they are open ones) and platforms, again in real time.
By increasing the load rate to x1000 you have decreased the time between graphics engine calls (per train/truck currently unloading) from 0.4s to 0.4/250 or 0.0016s. If you had 10 trains average loading at the same time that would make it every 0.00016s. It is possible this has overwhelmed the graphics pipeline (causing it to fall on it's back and wave it's hands and feet in the air) since it wasn't designed to operate at this speed.
If you changed the wagons load rate to x8 it will probably avoid the freezing and you may see an improvement in overall game performance due to trains being turned around faster therefore less of them in station at the same time. Or you may not, who knows until it's tried. If that did work you could try x12, x16, x20 etc.
There are 2 sizes of cargo units shown in stations. The small ones are a single unit of cargo, and the large ones are 10 units. A small unit occupies 2m X 2m on the platform. Platform capacity is limited by the physical space (except for sea ports where the devs hid half the cargo in the water beneath the dock 😂).
Vehicles are more "black box" where the creator sets the capacity directly instead of it being based on actual volume. So there's some liberties taken there to make the game playable.
Load speed is supposed to represent the number of access points (doors etc) available for loading.
The difference in RAM would be explained by a significantly reduced number of cargo items in my reduced set. Even though the number of items transported is only approx 6 times more in the "slow" map, because the "fast" map is only transporting finished goods, and no source cargo, there would be an order of magnitude fewer cargo present on the map in the "fast" map. (remember, all my primary industries are on level 1 and secondary are not producing anything).
Loading and unloading are certainly likely culprits. The more cargo you have, the more time spent loading and unloading, and if the code for this isn't optimised, then that has a compounding effect.
Cheers,
Chris.
@avhk, firstly, I think that you have changed the parameters so far out of "expectations" that I'm not surprised you're having performance issues, even on that rig. The coders will have made certain assumptions when coding the game, and tried to optimise the code within those assumptions. Travelling too far outside of those assumptions can have a compound effect on performance.
I am not surprised by the freezes when you changed the loading speed. To load 10 items within a second, for example, is really quite easy for the game to handle. Load 1, "sleep" for 100 milliseconds, load another. To load 1000 in a second, there would be no time at all for the "sleep". And these "sleeps" is where the program goes off and does something else (like respond to mouse moves).
This is not necessarily true. You have changed the wagon count by that amount, but there are several orders of magnitude more "models" in the game if you're counting all cims, cars, trucks, cargo etc as models. I suspect your RAM usage didn't change by a factor of 50 to 1
My question to you is this. How are you getting enough cargo to fill those trains?
I suspect you're using one of those "increased production levels" mods, and there is no doubt in my mind that these are a source of cargo performance issues. I stopped using these a while ago, and I can go a lot further into my maps now than I did before the performance starts to lag.
Cheers,
Chris.
I tested with the same trains(now I have 69 trains) and unchecked all load goods. After all the unloading/loading trains were finished(which took 4 hours) the game became smooth as a feather! No freeze, in fact, I can play with x3 playtime back again.
Now, I will test another possible solve.
@numbat
I thought it was a graphic issue. That's why I tested that way. Now I know it is not.
About the "sleep" thing, I can understand that. But your scale are so off. For example, my CPU is a 4.3 GHz, 4,300,000,000 Hz. With your analogy, It should handles 1,000,000 of goods per second easily, if not billions of goods.
@RadiKyle
There are 4 sizes of goods icon. 1, 10, 100 and 1000.