Conwoy loading time

[Vladki]

Hi, I'm not sure if this is a bug or feature...

I have noticed dramatic increase in loading times in nightlies (standard) since few months ago. Somewhere between 6781 and 6884. Before that change, the loading took just about a second of real time, now it seems to depend on the number of passengers/cargo. Is there any documentation to this? What affects the loading time? Is there any configuration option or dat file option (for goods or vehicles) ?

[TurfIt]

r6882 started enforcing the loading_time parameter for vehicle .dats. Specifies the time in ms for a full load.

However, the implementation doesn't make sense to me. The time for each vehicle loading is summed up into how long the entire convoi waits. But passenger trains (atleast commuter trains) load their cars in parallel. I think there needs to be another parameter to control sequential/parallel loading... ?

[Vladki]

Oh, that explains why my long express trains take ages to load, while buses have acceptsble delays. Please could someone change it so that conwoy load time is not sum but maximum of load times of its vehicles? At least for passengers. Sum may be acceptable for cargo trains which are loaded sequentially, but passengers load in parallel.

And plese move this to bug reports.

Another question is if it would be possible to show the un/loading progress (like TTD does). It would make the loading time more enjoyable and understandable.

And at last. What happens if there is no load-time spwcified in dat file?

Sent using recycled electrons.

[Ters]

And at last. What happens if there is no load-time spwcified in dat file?

Default loading time is 1000 ms. It has been for two years, so paks should have had good time to prepare. The issue of sequential loading time has been discussed a while ago as well.

[Vladki]

After long search i finally found rather short discussion where (iirc prissi)  decided for sum of loading time saying that pax trains should adjust loading time accordingly. May I ask how?

Enforcing loading time has quite spoiled my current game pak128.britain. I run about 12 express trains 12-tiles long and they run almost full one after another and still barely manage to get all the passengers. After upgrade trains started to load for very long time and queue up at stations. Adding more trains does not help much. The queues are just getting longer. Commuter lines (6-tile long Emus) are affected as well. Stations got overcrowded quickly.

Setting extremely low load time could fix it, but does not make sense. Long pax trains load approx the same time as shorter ones in reality.

I think about splitting long trains in half, to shorten the load time, but I'm not sure if so many trains will fit on the line.

I just wish if the parallel loading could be reconsidered at least for passengers.

Sent using recycled electrons.

[prissi]

Long passenger trains take longer (although not so much) because the platforms take longer to clear, more doors to be checked and so on.

If passengers are loaded parallel, then good trains would be at disadvantage for a spoke and hub distribution. There the same would apply. Furthermore, the freight platforms are as long as the trains, hence the loading could be done parallel too.

I am open to discussion on doing a max of the longest individual loading time. Your input please.

[Leartin]

I am open to discussion on doing a max of the longest individual loading time. Your input please.

How about this:
Let's suppose waiting pax are distributed evenly at the station, but only for the length of the train (because there are nifty signs which show them exactly how long the train will be). When the train arrives, each passenger tries to enter the wagon next to him/her. Therefore, the total number of passengers waiting to enter the train divided by the length of the wagons, multiplied by the length of one wagon is the number of people who try to enter that wagon.
The loading_time divided by the number of maximal pax in a wagon is the time one pax needs to enter that particular wagon. For example, a wagon with space for 100 pax and standard loading time of 1000ms allows one pax to enter every 10 ms. Multiply that number by the pax who try to get in the wagon, and you get that wagons loading time. Look for the wagon with the highest actual loading time and add a penalty for each wagon, which might be set in the simuconfig.

Seems complicated? Think about this:
1) A train loads from front to end. So saying you just use the highest loading time of all the wagons means to use the loading time of the first wagon, or whichever wagon is filled at that particular station, and if it is at least a wagonload, it's always 100%.
2) I have not tested this, but because of (1) I assume it is true: If you combine wagons with different stats, it matters in which order you put them. For example, a 50pax-wagon and a 100pax-wagon with standard loading time, 100pax try to enter. It takes 1 or 1.5 seconds, depending on which wagon is the first.
3) It is difficult to calculate the "perfect" distribution of passengers in different wagons anyway. Going on with the two wagons in (2), perfect distribution would be 66.6 in one wagon and 33.3 in the other, resulting in 666ms loading time per wagon, which seems easy, because these are the numbers you get when both wagons are equally filled. However, it does not work with other loading times. For example, 100pax-wagon with 2000ms loading time paired with the 100|1000-wagon would cause a loading time of 1 second, because thats how long 50 passengers take. Again, the perfect distribution would be 66.6 and 33.3, Because 100|2000 is pretty much the same as 50|1000. But this does not work with 25|500... now this is just talking about two wagons. Obviously, it would not be that hard for a computer to wrap it's brain around that, but I don't think it would be less complicated than my suggestion with wagon length.

[Ters]

In my experience, long passenger trains only take longer time to load proportional to length if there are reserved seats, and there is a high proportion of passengers that aren't familiar with the train (these things tend to go hand in hand) or where the type of train isn't very predictable. Passengers will then have to move to the right car, which a (slight) majority tend to do before boarding rather than inside the train. (Some trains are even made of coupled EMUs/DMUs that don't allow passengers to walk from one to the other without exiting.) Longer trains mean more conductors/guards to check the doors, so that isn't much of an issue.

With trains that don't have preassigned seats, or where there is a huge number of frequent riders (commuter trains typically), passengers tend to spread out more evenly along the platform before the train arrives. It is also more normal to walk inside the train looking for a seat, which doesn't delay train departure. I can imagine that on some really packed trains, internal movement will be impossible, so passengers will have to walk the length of the train looking for a car with free capacity before boarding. But I have never experienced such trains.

The platforms themselves may have as much to say about loading time as does the vehicles.

[TurfIt]

If passengers are loaded parallel, then good trains would be at disadvantage for a spoke and hub distribution. There the same would apply.

Can you expand on the issue with goods trains? I'm not following.
Of course in real life, the train cars wouldn't be unloaded if they were just switching trains, but shunting is beyond simulation scope.

Furthermore, the freight platforms are as long as the trains, hence the loading could be done parallel too.

I wonder if the loading/unloading system shouldn't be changed so that all cars in a train load, not just those in the platform. All those in a platform would load in parallel, then the next batch, and so on. Then if you wanted faster loading, build your station with platforms long enough to fit the whole train. Also, platforms could specify a modifier to the loading rate - incentive to invest in higher level platforms to get even faster loading. Or, maybe this is getting too complicated!

I am open to discussion on doing a max of the longest individual loading time. Your input please.

Leartin points out the problem with using max of longest loading time, the loading pattern would need to be changed so all cars fill equally, not from front to back as currently done.

A couple technical issues:
I don't think use of wait_lock is correct for this. At a minimum the times should be scaled by bits per month.
It also suffers the same exploit as was mentioned with Experimental - open the schedule and the convoi leaves immediately.
I think it would be better to just load the appropriate amount each step(). This would also provide feedback as players could see the train slowly loading, rather than currently where it jumps to full load, and then just sits there.

Also, I wonder if the default should be set to 0 for better compatibility with older games/paks?

[Ters]

I wonder if the loading/unloading system shouldn't be changed so that all cars in a train load, not just those in the platform. All those in a platform would load in parallel, then the next batch, and so on. Then if you wanted faster loading, build your station with platforms long enough to fit the whole train. Also, platforms could specify a modifier to the loading rate - incentive to invest in higher level platforms to get even faster loading. Or, maybe this is getting too complicated!

I think this is getting very complicated. Especially if one also is to consider platforms at the end of the track. In real life, this would work fine, with just a bit of shunting, but how is Simutrans supposed to emulate this shunting?

I think it would be better to just load the appropriate amount each step(). This would also provide feedback as players could see the train slowly loading, rather than currently where it jumps to full load, and then just sits there.

It is equally strange that the train empties immediately, while loading happens incrementally. So either unloading would have to happen in step()s, or leave it as it is. Or perhaps split wait time in two, one part for unloading, and one part for loading.

Also, I wonder if the default should be set to 0 for better compatibility with older games/paks?

This would lead to some unbalance in a mixed set-up where main pak set has set loading times, but add-ons don't have any, or vice versa. Having an ability to set the default loading time in simuconf.tab might work for loading old paks, but would not affect old dats compiled with new makeobj, unless a special value is used to signify "use default from simuconf.tab". (Arguably, any default could cause inbalance.)

[Vladki]

I would not over complicate things.
- Cars that do not fit on the platform should not load at all. There's no reason to change that.
- All cars should load in parallel, whether pax, mail or goods. I know that goods trains usually do not load in parallel in reality, but what they really do is that they drop off cars to be (un)loaded while the train continues its journey, picking and dropping cars, or (in case of long-distance trains) gets at some point disassembled and reassembled into new trains that go to other directions. NO I DON'T want to do that in simutrans (yet ). What simutrans does now is, that goods transfer between trains just like passengers do, so I think that the same rules should apply for loading time as well. Just keep consistent.
- I would be satisfied if the current code is minimally fixed just so that it simply takes the max(loading_time) instead of sum(loading_time). However I'd really love the un/loading code to be changed to behave similarly to OpenTTD, just as TurfIT already suggested. Just count how fast the cars un/load = payload/load_time, and for each car unload the right amount of cargo every loop until all cargo destined for station is out and then start loading. This would enable the player to see the progress, avoid the exploit mentioned by turfit, lead to more even distribution of pax/cargo on the train and also would allow for simultaneous unloading of one car while loading another.

[kierongreen]

Some goods does load and unload in parallel - mail for example but also piece goods in vans. Containers load serially because crane has to travel up and down train. Passengers at terminal stations might load serially as they walk along the length of the platform, but those at intermediate stations will load in parallel. Passengers on commuter trains certainly load in parallel.

There's no simple rule, but I've said before I favour assuming parallel loading.

[Leartin]

Is there an discussion about this somewhere else? If yes, please move, I just remembered this thread...

Wouldn't it be nice to not only have trains with different loading times, but stations as well? Not sure if there should be a calculation and the minimum of train and station is the actual value for pax to get on the train, or like a multiplier (100=100% of the trains loading time, higher for longer loading, lower for quicker loading.) - anyway, just an idea

[prissi]

Since the minimum loading time is still 2s, I think most vehicle in pak64 (and the other paks) will behave again as before (with parallel load as of r7089).

[hreintke]

LS,

Detail but..
As hat_gehalten can called multiple times during loading, shouldn't the wait_lock = time; at the end of the routine be : ïf changed_loading_level {wait_lock = time} ?

Herman

[Leartin]

May I ask how it is done now? (as in, how it is calculated, not how it is implemented)

[prissi]

This is the same time as it was before, with the added loading time. But it is called exactly once per step. If no loading level is set, this is the only call.