Maximum in transit can be zero

[jamespetts]

Excellent - this looks very interesting. I shall look forward to the UI developments.

[Vladki]

Correct. They were initially stocked by the company who built them without our help. If they can build such a huge industry without any help, they can also stock it initially.

Or just to make thing simpler - a factory with 0 input stock and 0 items in-transit and 0 orders, will place orders in the amount of its input storage. From then on, it will order only what was consumed.

@James - some time ago you have made a change for mail that it is not counted in big bags, but smaller bundles (IIRC 1 bag = 10 bundles ?), and adjusted all station and vehicle capacites accordingly. I don't know the exact reason behind that, but I suppose that 1 bag of mail was indeed too big, and a smaller unit was neccessary to simulate the flow more accurately. Would't it them be simlar with cargo, where 1 ton is too much for early transport, and using units of 100 kg would allow for better accuracy ?

[jamespetts]

Or just to make thing simpler - a factory with 0 input stock and 0 items in-transit and 0 orders, will place orders in the amount of its input storage. From then on, it will order only what was consumed.

@James - some time ago you have made a change for mail that it is not counted in big bags, but smaller bundles (IIRC 1 bag = 10 bundles ?), and adjusted all station and vehicle capacites accordingly. I don't know the exact reason behind that, but I suppose that 1 bag of mail was indeed too big, and a smaller unit was neccessary to simulate the flow more accurately. Would't it them be simlar with cargo, where 1 ton is too much for early transport, and using units of 100 kg would allow for better accuracy ?

I do recall the change from bags of bundles of mail; this was because mail could not realistically be accumulated in units as large as bags within any reasonable time.

For goods, this gets much more complex, as bulk goods have units of tonnes, and, unlike with mail, there is no distinction between types of capacity for goods: one cannot have a goods stop, for example, with capacity for 10t (10 units) of coal or 10t (1,000 units) of piece goods; the capacity would be either 10 units of either coal or piece goods or 1,000 units of either coal or piece goods. This would make any such adjustment much, much more difficult than for mail.

[Ranran(retired)]

As I have observed, max intransit tends to be limited to 1 when trying to transport low demand items nearby.
This is why there are a lot of fish max intransit and few vegetables and fruits on the market. Because fish take longer to carry, they are ordered in larger units. Order nearby vegetables or cattle one by one. I will never order the next product until the factory receive one.
And if it has multiple connections, like a vegetable farm, it's split and it might be worse.

For this reason, I think that vegetable farms, grain farms, saw mills, sheep farms (for livestock) tend to have max in transit limited to 1.
I don't think orchard is likely to fall into this trap because orchard has only one connected though the market has the same demand as vegetable.

As a result of players being forced without knowing to carry one at a time, they may not make a profit by using units that do not make a profit unless they carry two or more, or may wait for an eternal 100% load.

[jamespetts]

Splendid, thank you for this analysis: this is consistent with the system working as designed, but the design not taking adequate account of what would in the real world be minimum order quantities.

Do you still suggest that we wait until your new UI be implemented before investigating further, or are you now content that you have a sufficiently complete description of the issue for the matter to be addressed at this stage?

[neroden]

Aha.  James, this is the major problem I'm having with a 1750 start and markets (in addition to the worker problem described elsewhere.)

So, there's a brute-force solution to this which will work.
(1) Do not limit the goods in transit based on stock capacity.  With long routes, or very slow routes like the livestock drover, this is just incorrect.  It is *necessary* for goods in transit to be significantlly higher than the stock capacity in order to maintain steady supply.
(2) Do not limit the goods in transit based on demand per month.  It is fine for them to be significantly higher than the demand per month, again, because of long and slow routes.  It may be necessary to have many months of product in the pipeline.
(3) Raise the minimum input stock capacity for all consumer & manufacturer industries to the capacity of the early-game vehicles.  No more of these "1 capacity" and "0 capacity" markets.  Raise it to 32, the livestock drover's capacity.  It should be possible to programatically figure out the available delivery vehicles for a given type of goods in the current pak at the current year, and use this as a minimum.  A factory should *always* be able to accept a full load of the lowest-capacity vehicle.
(4) Order enough production to supply the *rate* of production, without reference to the stock.
 (4) Stop ordering new production based on stock only when this stock capacity is actually full.

This is probably simpler than whatever is being done now.  What's being done now isn't right: it breaks transport chains.  It's most obvious with the livestock drover, who can only drive one head of cattle at a time now.  This is because of the low capacity of the input stock of the slaughterhouse, plus the limit on goods in transit, with the cattle farms refusing to send another head of cattle until that one arrives, which can take months.

It should be much easier to implement this than what's being done now, and what's being done now doesn't work conceptually or in gameplay.

[neroden]

OK, so I didn't have the energy to do anything fancier, but I did come up with a code patch which is a workaround.

Basically, I force the minimum factory capacity to 7 for all goods, if the calculated capacity would be lower.  This allows for loading or unloading an entire truck in pak128.britain.

The code around here is really ugly: there are far too many "scaling factors" and it took me several hours to figure out how to do this.  Better patches may be possible in the future but this will at least get out of the "capacity 1"/"capacity 0" hole.

Since the maximum in transit is based on the maximum storage capacity, this should relieve the capacity choking and allow a full stage wagon in transit (though not a "full" livestock drover -- for that I'd have to force capacity to 35).

This is on the "minimum-factory-capacities" branch.
https://github.com/jamespetts/simutrans-extended/pull/611

EDIT: tested, it's working.  Unblocked the slaughterhouse & everything else.  I think this is a "good enough" fix.

[jamespetts]

Thank you very much for this. Before integrating this (and in any event, I do not want to integrate too many things the same day in case there is an unforeseen problem in one of the patches), can I check what you tested? In other words, does the modified system in your patch not only work better for the smaller industries, but does it also work at least as well for larger industries with a constant demand, such as coal fired power stations?

Also, can I clarify what you mean here by "factory capacity": are you referring to the input capacity of consumers or the output capacity of producers?

[neroden]

I did it for both the input capacity of consumers and the output capacity of producers.

The modified system in my patch makes low-production-rate stuff work.  For larger industries, the input capacity of consumers and output capacity of producers was already at least 7, so it changes absolutely nothing about their behaviour.  It only increases capacity if the computed capacity would have been lower than 7.

I still feel it is a bit of a brute-force hack. 

For one thing, it should reference a setting in the pak (probably in simuconf.tab), a "minimum factory capacity" setting, which should be set to be the size of the smallest-capacity routinely-used vehicle -- so that every factory will allow for a full truckload to be loaded or unloaded.  I hardcoded "7" based on pak128.britain, but it really should be read from a setting in the pak (though 7 is a great default if the pak doesn't set it).  Paks might be designed with smaller vehicles or larger vehicles.  I did not have the time or energy to write that code to add the setting, though it should be straightforward.  You might write it as "minimum factory input capacity" and "minimum factory output capacity" if it turns out there's a reason to make them different.

I initially tried to change every single industry file to fix this but I got lost trying to compute the "capacity recorded in the dat file" from the real capacity in the game (there are TOO MANY scaling factors being applied here), and it was hitting way too many files, so I don't think that's the way to go.

I still don't think computing max in transit based on the storage capacity is right long term, but I don't have a proposed solution for that at this time.  This was the minimum change I needed to do to make the game *playable*.  I gave up on several games before fixing this, and now I'm happily playing through 1750-1760.

I think setting a minimum factory capacity, for both inputs and outputs, around the size of one truckload is correct in any case even if we make additional changes later; a lot of weird things happen if the factory capacities are lower than that.

In practice, these old low-production, low-consumption industries had HUGE buffer and warehousing areas -- they were the opposite of "just in time" operation -- so I also feel this makes it more realistic.

[neroden]

OK, so in addition to the main code patch (which is still here https://github.com/jamespetts/simutrans-extended/pull/611 ) I have a patch specifically for slaughterhouses for pak128.britain.  The livestock drover has a very high capacity so it basically needs to be special-cased regardless.  We want it to be possible to make a full delivery of a full livestock drover. 

I cleaned this up, it's independent of everything else and it's at https://github.com/jamespetts/simutrans-pak128.britain/pull/154

I would like to get the main code patch reacting off of a pak setting rather than a hardcoded value, I just haven't had the bandwidth to do that.  Writing in new pak settings is tedious.  I hope I don't have to update the save game version.

[jamespetts]

OK, so in addition to the main code patch (which is still here https://github.com/jamespetts/simutrans-extended/pull/611 ) I have a patch specifically for slaughterhouses for pak128.britain.  The livestock drover has a very high capacity so it basically needs to be special-cased regardless.  We want it to be possible to make a full delivery of a full livestock drover. 

I cleaned this up, it's independent of everything else and it's at https://github.com/jamespetts/simutrans-pak128.britain/pull/154

I would like to get the main code patch reacting off of a pak setting rather than a hardcoded value, I just haven't had the bandwidth to do that.  Writing in new pak settings is tedious.  I hope I don't have to update the save game version.

Thank you for that; I have now merged the slaughterhouse capacity patch. The issue about minimum industry input/output storage capacities I believe is now being discussed here and I do not duplicate here what I have written there.