It is best to control quantities between arrivals.
I give up my efforts to have my pleas for a, reconsideration of the just_in_time operation, heard, with a humorous problem.
Let your country house is 1 hour away by your car. Your wife claims that your garden needs 10 crates of dirt. You say 'that's ok, our car can carry 2 crates each time.' 'Fine', replies your wife, 'get start the transfer tomorrow at 7:00 and you will be back for launch at 12:00' When you return, next day, for launch, you say 'Sorry, I was wrong...' Your jealous wife kills you but your last words were ' # crates per hour'.
At what time did you return? What was the number in your last words? What could be considered as goods in transit in any given hour? Could the lead time of 1 hour be of any use before start of transportation at 7:00?
Feel free to delete this post if it seems offensive or irrelevant to the goals of simutrans – extended.
Thank you all that got to the trouble to reply on my posts.
At last! It seems i can play simutrans as i want.
Since i think i found a solution, excuse me one more post.
In market (424, 681) i noticed that maximum allowed goods in transit was 4 crates. I use, as you notice an intermediate stop, so this should concern the previous from market stop and not the whole chain up to the source. I consider wrong design to use the source of production for that purpose. As storage of market was 1 crate, i already planned to deliver, 1 by 1, 4crates/month, as market wants. From source to intermediate stop i use 6 capacity vehicles. That 6 > 4=maximum allowed goods in transit, is the reason that fruits refuse to load. To allow only 4 crates in transit is anti-scientific, forbids from the players the right strategy and forces them to unprofitable transports. Maintenance costs of vehicles are perfect to restrict an abuse of some too large capacity. They do not need such a hard restriction to the quantity of goods in transit.
So, the key is in maximum_intransit_percentage = 110 parameter. Storage will be consumed in "storage/demand" time. The ratio that parameter represents is "storage/(demand*lead_time). In case of market, storage=1, demand=4crates/month and lead_time=1. So, maximum_intransit_percentage=1/4. One might assume that the sooner the storage is consumed, the most goods in transit should be allowed. But even this is taken inverse by game's algorithm. The inverse of 1/4 is 4 and that is what games allows to a player as maximum goods in transit. The right value from best strategy for the parameter equals to "2*storage/(n*q)", where "n" is the number of convoys and "q" is their current cargo lower or equal to their capacity. That approximates to "storage/goods_in_transit". So, since "storage" is constant, the more goods in transit we want to allow, the less the maximum_intransit_percentage should be. Initially i tried to decrease it to lower than 10. The result was inverse of what i expected. The allowed goods in transit became only 1 crate!!. But, as i said, game's algorithm use the inverse meaning of that parameter too. So, instead of 110 i raised it 100 times more to 10000.
The allowed goods in transit raised from 4 to 400 and at last my scheduled plan work like a clock!! I have never overstock, because i planned to do so, and production and consumption are as they should. Only minor problem is that consumers take almost 7 months (about August) to arrive to market.
Watch the save from post (https://forum.simutrans.com/index.php/topic,21862.msg201429/topicseen.html#msg201429) by editing the maximum_intransit_percentage = 10000 to see the difference.
The control over "goods in transit" is theoretically a terrible mistake.
Terrible because it is so simple do discover that should not last more than few weeks.
Control over "goods in transit" is equivalent to control over velocity and number of convoys in a line. As one could not think to limit the volume of water that should exist in a pipe network or to forbid either slow moving trunks with large capacities or fast moving vehicles with smaller capacities from a transport network, so the control on "goods in transit" should not exist in the simulation. Even if you insist on that control, it belongs to some "goods AI" and never its falsely or right results should infiltrate in the simulation itself.
Beyond the above, from a line such as Source-A-B-C-Destination, the game struggles to evaluate the lead time from Source to Destination while, from the perspective of economy, only the last C-Destination should be of some interest. There is no need to spent huge amount of unnecessary CPU sources. If "goods in transit" is shown as a help to the players, then the game should evaluate the duration time in each one of the legs of the line and not only the misleading and useless lead time from source to destination.
By an extreme raise of maximum_intransit_percentage parameter, I bypassed in great degree your theoretical mistake, but it seems it is not enough. The unnecessary to calculate lead time from source, affects, for very long time, the start of production. I transported meat 40km away in 1750year, when velocities are low. Despite the fact that the demand is known or a contract should be assumed that already exist, the production do not start until either my convoys, or some virtual convoy, cross the distance. That take months. As a result, my line needs about a year to stabilize and that is too long for a game play. Additionally it seems that the falsely used lead time affects anyway the demand that, in return, affects production, perhaps because other developers use the results of "goods in transit" algorithm unmodified anyway. So, I can have my planned production and transport, that would be impossible if I did not bypassed the control over "goods in transit", but production pattern drops from my maximum planned value to almost zero sometimes, in a predictable pattern (I watched it for over 5 game years).
As it is, your game acts accurately only if one uses exactly 2 convoys on some line and in such velocity that the line can be crossed in 1 month. In all other cases, the falsely implemented control over "goods in transit" hurts the profit of player and most importantly the production and subsequently the world's economy. Because of the unnecessary need for calculation of lead time, one should plan lines that need about a month to cross, if he does not want to wait too long the production to start. In year 1750, where velocities are small, that restricts the transportation activities to only local ones.
Same seems to happen to pax and mail transportation too. When one starts it is natural to have a lot of "no routes found". As one develops the network, these "no routes", in their majority becomes "too long to wait". Somewhere in wiki I read that, in extended, the tolerance is about 90min and to me it seemed wiki was right. So, in pax and mail too, simutrans extended acts locally.
From the above locality, one might want to use small maps that do not need too much time to cross, depending on the timeline start and velocities he will use.
The simulation itself do not need it. A "goods AI" might need the frequency of arrived quantities. That means a "goods AI" need more information than that the lead time and "goods in transit" contain. That is why the control on "goods in transit" actually control the missing information and, consequently, the 'best' transportation network that players struggle to build. I think that all games and world economy are doomed to fail because of this, despite the future developers' attempts to achieve a balance that can not really exist.
I do not regret for my spent time to simutrans-extended, as my theoretical notes can help to any transportation game I will decide to play. However, for the reasons above, it is time to switch to simutrans standard, where I hope that the patently wrong idea, to use the "goods in transit" in simulation, is not infiltrated yet.
Thank you.
I think he's right, there are severe problems with this. This is making it impossible to get livestock and meat lines going in early game; they're throttled by goods_in_transit incorrectly. Some of the livestock drover routes take months to complete but the slaughterhouse is refusing to allow generation of more livestock while they're in transit. So it's not possible to fully supply the slaughterhouse at its production rate: after a few livestock are generated, the goods_in_transit rule throttles it. Similar problems happen with the meat line.