With this patch convoys, consisting of several vehicles, will load a mix of goods at stops. Without this patch the train on the screenshot will only load good with same destination and therefore some goods won't be transported ever. It is usefull in situations, when you can't build anymore trains, since the net is working to capacity.
(A similar approach is used in fabrik_t::verteile_waren).
[attachment deleted by admin]
I personally do not like this; because the system with first loading all goods for next stop, then goods for next next stop and so one is intentionally introduced to allow a mixture of local and express line on the same conenctions. With this patch the effect would be counterproductive, sinc ethe local would load more long distance express goods. It is one of core the players task to provide enough capacity.
With the patch of isodoro to avoid loading stuff for overcrowded stops, this would be solved in a more matching way.
No, convoys will only load goods for the next stop, if there are any. But they will load several goods, if there are waiting more for the next stop.
But if more than one convoi is loading per interval (very likely) those still may never reached. Maybe a real random is needed. I submitted with real random.
(Although alternating backward and forward would do the trick too.)
Too tired.
The function still loops over the whole warray, but has a different starting point. So all ware_t are reached.
I think, it's random enough, since the offset is the same for all haltestelle_t.
;)
I think random is better, because in multiplier game this must be initialized properly. Also if the convoi in question is a bus, it can be that it rarely loads the other goods. Just imagine the are sitting only one away. The cahnce geeting this call with eaxactly the same (count+1) are extremly slim. It would only happen, when exactly count convois loaded+1 before. However, with random, there would be still a 1/count chance each time.
Although I admit random is some overhead too. But the constant division has much more time consumption than a simple random call.
It's initialized with 0.
I didn't get this.
But then you also need a division, if you want to loop over the whole warray, don't you?
Imagine a bus coming to your station. There are sixty packes there, 100 in paket 54 and 100 in packet 55.
counter is lets say with 18. Starting value 3, thus all in packet 54 are loaded. Next time it will arrive, the counter is 56. All in packet 54 are loaded. The only chance is, that eactly 54 cars are gone. With random offset, you have at least a reproducible 2% chance that the correct stuff is loaded.
And for network games it must be init before the a new game.
An alternative would be using the step counter. The is deterministic and random at the same time. But since the loading will be called only every 2s per vehicle, random seems pretty acceptable there.
Now I get it. But with a random offset you have the same problem.
Ok. So using the step counter is maybe the best choice.
An other idea: We could reorganize haltestelle_t::waren and save the ware_t sorted by their next via stop. Then we can pick a real random package.
This might be a good choice; would be easy to use a hashtable with the next stop id as key. Since hole_ab is also the second single non-trival time expensive routine, optimisations here are worth thinking too.
My suggestion for this list would be the following:
For each catg_index we save a sorted list of the IDs of the via_halts and for each entry we have a list of ware_t.
This approach I already used for the cached routes:
cached_good_routes = new vector_tpl< pair_tpl< halthandle_t, halthandle_vec > >[ warenbauer_t::get_max_catg_index() ];
We would then have something like
waren = new sorted_vector_tpl< pair_tpl< halthandle_t, vector_tpl<ware_t> > >[ warenbauer_t::get_max_catg_index() ];
True randommizing was incorporated some time ago.
But I think, the routine has a problem, discussed some time ago: If you have 100 packets, 1-98 are unfeasible, 99-100 are feasible. Then the first feasible packet has a chance of 99/100 and the other only 1/100.
However, I had the idea of sorting the simhalt_t::waren[] with respect to the next transfer stop. This would also speedup some routines (especially the hole_ab). Do you think it's a good idea?
Edit: I've read the thread again - at least you thought it's a good idea :)
YOu are free to make a hashtable instead of the waren arrays. Should I move this back to patches?
I think I will open a new thread, when a patch is ready. But maybe I'll wait until you and Knightly have finished with the rebuild_destination.