News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Balance suggestion: Massive demands and little capacity

Started by Jando, December 04, 2013, 10:46:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Jando

Started the game in 1870, it's now 1878. Industries demand massive amounts of cargo, just an example in the screenshot with a coal merchant ordering 12.577 tons.



However the capacity of warehouses and docks is in no way able to deal with that amount of goods: docks hold 32 cargo, largest warehouse that can be built holds 128 cargo. Thus I'd need about 100 warehouses (esp. at the harbours) on the route from the collieries to the coal merchant if I want to avoid overcrowding. And that's just for a single coal merchant ... Thus practically all my harbours and freight yards are constantly overcrowded.

Suggest to massively increase the capacity of warehouses or to tone down amounts of cargo generated and demanded. For example increase capacity of warehouse from 128 to 2000 (2048 if binary matters :) and of docks from 32 to 1024.

jamespetts

Thank you for this. Will have to look into what a coal merchant (etc.) would actually have demanded in real life. Do you know whether this is confined to certain sorts of industry, or is it a general problem? Also, is this an industry that you placed manually as public player, or was it placed by the game?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Hello James!

From what I've seen all industries can show this behaviour, but not all industries necessarily show it all the times. Here's a screenshot of the 2 Builder's Yards on the map showing their demand for planks:



The left yard ordered 10.341 planks, the right yard 488. The monthly demand of the two yards is the same 1.760 units per month. Each of the two yards has it's own sawmill as supplier. The left yard was connected and supplied 3-4 years before the right yard.

Here's another screenshot showing 2 Hardware Shops and their ordering pattern:



Both of the shops order their demand for 7-8 months in a spike and then do nothing until they have used their storage, then order again. And I get the feeling that consecutive spikes are getting ever higher, sadly I can't prove it cause the graphs only cover the last 12 months. The left shop started to get supplies roughly a year before the right shop.

And finally a screenshot of a Furniture Shop that now has about 20 times it's monthly demand on order:



On this graph you can just see the end of the previous spike, if I remember right it spiked out at about 1200 units.

All industries shown here were placed by the game during map creation. Only change to the Simutrans Config was to reduce the City Car level from 11 to 4. :) In general it seems to me that the demand of an industry has actually little to do with their consumption but instead follows some other pattern.

jamespetts

Ahh, this concept of "ordering" is somewhat misleading: industries demand goods until their input capacity is full. The real issue here appears to be excessive storage capacity for some of these industries. I shall have to look into that.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Junna

Looking at the screen shots the actual storage capacity does not seem particular out of line as compares to the consumption, rather, it seems that these fluctations are the product of slow transport and piling up of goods in the process of being transported. I suggest that you lower the setting for what percentage of the total demand to allow in transport before stopping it to somewhere around 350-500% to avoid the excessive build-up (by default this setting is set to 0, meaning unlimited amounts of goods can be stuck in the transit and more continue to build up)

jamespetts

Ahh, thank you for your helpful analysis - will bear in mind.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: Junna on December 06, 2013, 11:40:51 PM
Looking at the screen shots the actual storage capacity does not seem particular out of line as compares to the consumption, rather, it seems that these fluctations are the product of slow transport and piling up of goods in the process of being transported. I suggest that you lower the setting for what percentage of the total demand to allow in transport before stopping it to somewhere around 350-500% to avoid the excessive build-up (by default this setting is set to 0, meaning unlimited amounts of goods can be stuck in the transit and more continue to build up)

Thanks. That makes a lot of sense to me.

Many of the goods shown in the screenshots are carried by ship for some part of the voyage, thus having long travel and loading times. Like to the harbour by ship from their origins, and then rail transport from the harbour to a freight hub and to their respective consumers from there. Even rail transport isn't really fast, with the fastest freight car available going 56 km/h.

Jando

Like in another thread I compared my Standard game (Pak128) with my Experimental game and noticed a couple of things:


  • The Standard game does not show this wild fluctuations in cargo.

  • The capacity of ships in the Standard game is far lower than in Experimental.

  • The capacity of docks and warehouses is far higher than in Experimental.

  • The max units per month setting of industries in Standard is generally lower than in Experimental.

  • The storage capacity of industries is by far higher than in Experimental.

  • The ratio of max units per months to input storage capacity is very different between both versions. In Standard the input storage capacity is usually by far larger than the max units per month, in Experimental it's the other way round, the max units per months is by far larger than the input storage capacity.


Edit: And I still think we need an absolutely massive increase of the capacity of docks and warehouses. A clipper holds 1050 units of cargo, i.e. roughly the equivalent of 8 warehouses per ship.

jamespetts

Thank you for your observations: that is helpful. Do you know what the maximum in-transit percentage in Standard is? That may well affect things. Also, do you happen to know what the real life capacities of warehouses and docks were?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on December 12, 2013, 11:06:46 AM
Thank you for your observations: that is helpful. Do you know what the maximum in-transit percentage in Standard is?

I have no idea. :) I'm only a user reporting my findings. I know nothing about the inner workings.

Quote from: jamespetts on December 12, 2013, 11:06:46 AM
... Also, do you happen to know what the real life capacities of warehouses and docks were?

Likewise, I have no idea. :) But I doubt the question can really be answered, since there are obviously all sorts of warehouses in history, for all sorts of cargo and capacity.

If I'm allowed to make a suggestion, I would take a pragmatic approach: If there's a ship in game able to ship 1.000 units of cargo then there should be a dock able to handle that amount as well. Let the user build multiple docks if he has multiple shipping routes. Likewise, if a steel mill can handle 2.000 units per month then a warehouse should too.

BTW, I checked some historical numbers about capacity of ships, and Experimental is very nicely balanced in this regard. Good job!

Jando

Some additional information.

Game just spawned a new power station near my main freight yard. Easy to connect, only needed to expand the station by 2 tiles. Within a minute of connecting it already ordered roughly 20 times it's monthly capacity.


jamespetts

#11
The relevant part of the .dat file for the power station is as follows:


Obj=factory
name=CoalPowerStation1882kraftwerk
copyright=James
intro_year=1882
intro_month=4
retire_year=1909
retire_month=12
level=5
pax_level=9
passenger_demand = 160
mail_demand = 3
climates=rocky,tundra,temperate,mediterran,desert,arctic,tropic
Location=City
distributionweight=3
Productivity=7
Range=6
passenger_boost=700
mail_boost=50
MapColor=135
InputGood[0]=Kohle
InputCapacity[0]=300
InputFactor[0]=100 


As you will see, the "productivity" number is much lower than the "input capacity" number. The idea is that the coal power station is capable of having a large stockpile of coal so that it does not run out if there are any delays in transport. This is intended to be realistic. Do you have real life information about the size of storage yards that coal fired power stations actually have so that I can calibrate this any more realistically?

Bear in mind also: do not think of the supplies in terms of game months - think of them in terms of game hours, as it is the shorter scale within which industries are working. A shop is not ordering, say, 6 months' worth of goods: it is really ordering only 6 x 6.4 hours' worth of goods, or 1.6 days' worth of goods.

Edit: To reply to Junna:

Quote from: Junna on December 06, 2013, 11:40:51 PM
Looking at the screen shots the actual storage capacity does not seem particular out of line as compares to the consumption, rather, it seems that these fluctations are the product of slow transport and piling up of goods in the process of being transported. I suggest that you lower the setting for what percentage of the total demand to allow in transport before stopping it to somewhere around 350-500% to avoid the excessive build-up (by default this setting is set to 0, meaning unlimited amounts of goods can be stuck in the transit and more continue to build up)

the trouble is that the larger in transit percentage is needed for long routes to industries/shops with low storage capacities: see the comment in the simuconf.tab file:


# How much amount in transport is sent before further distribution stops
# This is only enabled when "just_in_time" is enabled
# The limit is given in percent of factory storage (0=off)
#
# This needs to be very high.  Many factories have low storage numbers (like 30)
# and high production per month (like 600).  Long, slow ship routes can take 6 months
# to cross the map.  To keep a steady flow, we need a setting like 6 * (600/30) * 100% = 12000.
# Make it even larger to avoid breakage.
maximum_intransit_percentage = 16000


The point is more, I think, that, provided that the industry has enough cargo coming in to fulfil its actual usage, the player can ignore the fact that it is capable of accumulating a larger stockpile when setting the route's capacity. That is the reason that it is not correct to think about the industry "ordering" any particular amount of goods. There is no concept of "ordering" in Simutrans: only of demand.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on December 21, 2013, 11:28:25 AM
... The idea is that the coal power station is capable of having a large stockpile of coal so that it does not run out if there are any delays in transport. ...

But James, there will be no transport at all for a long time when the stockpile has been delivered. The power station (and the other industries) will consume their stockpile and not demand any new cargo for many hours/months/1-2 game years.

Here's a screenshot of another power station to show what will happen:



Pictured are the in-transit (bright red) and storage (dark red) graphs. Industry demanded a large stockpile of coal and will now be burning that stock for the next game-year, with nothing in transit, no new demand and thus also nothing to transport.

Edit: Heck, I don't even mind these spikes, makes for interesting gameplay, although one has to babysit every single industry. :) After all I only made this thread to ask for some massive increase in dock- and warehouse capacity.

jamespetts

Hmm - I see. I have looked into the capacity of the goods rail stations and extensions, and increased it somewhat on the Github branch to 150 for the goods rail stations other than the basic sidings (which remains at zero capacity) and 250 for the extension buildings, such as the bulk loading bunker. Does this seem sensible?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on December 21, 2013, 07:43:09 PM
Hmm - I see. I have looked into the capacity of the goods rail stations and extensions, and increased it somewhat on the Github branch to 150 for the goods rail stations other than the basic sidings (which remains at zero capacity) and 250 for the extension buildings, such as the bulk loading bunker. Does this seem sensible?

It's certainly a step in the right direction. :)

Max. amount of cargo demanded by an industry I've seen was around 18.000 units, screenshots here in this thread show demands of around 10.000 and 12.000 units. With a capacity of 250 for an extension building that would call for 48 extension buildings (12.000/250) at the harbours and freight yards to avoid overcrowding. Needs more capacity. :)

Like I wrote earlier in this thread, I'd suggest either toning down industry demand or a massive increase of storage capacity of docks and warehouses.

BTW, just a fun fact: in some cases now I've bulldozed track after a spike to an industry has been delivered. The 70 lb/yard freight track costs 320 cr to build and 60 cr per month to maintain, thus when I see that an industry will not demand any new cargo in the coming 10 months or so it's cheaper to bulldoze the track and later build it new than to let is sit there and pay the maintenance. :)

Edit: and thanks very much for the new release, James. Will download it at once. With all my bickering it needs to be said: you're doing a splendid job here!

jamespetts

Hmm - but you don't need to store an entire industry's storage capacity in a single warehouse en route, do you? The ideal should be you supplying the industry at approximately the rate at which it actually consumes goods. The industries themselves, meanwhile, need to be calibrated in their demand and storage capacity to realistic levels to keep everything else in balance.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Here's an example screenshot:



Kingston New Station is a stop on the Piece Goods & Food Network. :) There's a bakery in Kingston, and when the bakery demands flour it gets delivered to Kingston New Station. Horse-drawn carts will bring the flour to the bakery from the station. If I want to avoid overcrowding at Kingston New Station it needs a storage capacity roughly equal to what the bakery demanded - cause that's the amount of flour that will soon show up at the station.

jamespetts

Thank you for that. I am planning to look into the rebalancing of the warehouse capacities in due course. However, I have noticed that a new feature has just been added to the Standard nightlies that might be relevant: see this discussion. I should be interested in your views on how this change might assist this sort of situation.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on January 12, 2014, 06:55:45 PM
Thank you for that. I am planning to look into the rebalancing of the warehouse capacities in due course. However, I have noticed that a new feature has just been added to the Standard nightlies that might be relevant: see this discussion. I should be interested in your views on how this change might assist this sort of situation.

Hello James! Good day to you! Personally I believe this "in-transit" limiter is not the right way to deal with the issue.  But I don't know the code - and I could probably not even read the code anyway.

From my experience the issue is almost certainly connected to how industries demand goods from their suppliers. As far as I can tell industries demand goods when their storage capacity isn't completely filled. And - as long as their actual storage is lower than their storage capacity - the industry continues to repeatedly demand new goods.

- These repeated demands cause that the amount of goods demanded is directly related to how fast goods are transported to the industry from it's respective supplier. The industry will continue demanding until their storage is completely full. Thus the longer the journey the more goods they demand.

- The actual consumption of goods is irrelevant it seems - only whether the storage capacity is full or not counts.

- The storage capacity of an industry in Experimental is rather low, certainly when compared to the consumption/production rate. Take my last screenshot with the bakery as example: storage capacity is 60, max. monthly consumption is 80. Thus when the bakery starts demanding it has less than a month of goods left. Thus almost all industries will run out of goods at a point.

- Sadly increasing the storage capacity alone cannot solve the issue as well: since the industry demands goods until their storage capacity is full increasing storage capacity will have the effect that industries demand even more goods.

---

Privately 8) I believe fiddling with in-transit limiters or storage capacities is just playing with symptoms. If I were free to design a system I would tie demanding new goods to actual consumption instead of to an arbitrary storage capacity: every industry - at the end of the month - should demand the amount of goods they consumed during that month.

Of course that leaves us with the problem that at the start of a game (or when a new industry spawns) they cannot consume anything because they have nothing to consume and thus cannot demand anything. Thus I would just spawn all industries with a full storage - and then let them demand what they consumed in the past month. :)

jamespetts

Thank you for your thoughtful reply. Those are interesting thoughts, but I fear that such a system would not work well with what is planned here, as what the industry consumed in the last month is likely to have been affected by the number of customers and the number of workers as well as supplies, which might well end up producing deadlocks (e.g., industry X demands nothing in month A because no customers have visited; no customers have visited industry X in month A because no goods were supplied to industry X in month A and there was thus no reason to visit).

The best way of looking at this issue is to consider how actual industries deal with this in real life, to which the answer is that demand at is based on predicted consumption. That, sadly, is complicated to implement because the prediction of consumption is inherently complex (the illustration of a deadlock above gives a good example of why a simplified model of demand prediction is unlikely to work). This is an inherent issue with simulating industrial production and transport, and solving it fully is no easy task.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Yes, I know that deadlocks can happen with what I suggested. Not only because of the planned visitor feature, but also when a player erroneously deletes a station tile or removes the last vehicle on the route and thus also the industry link. Wasn't really meant as a complete suggestion, was just meant to illustrate my little train of thought. :)

What we currently have is:

- Speed of transportation to the demanding industry determines amount of goods demanded.
- Industry's storage capacity determines when demand starts and ends.

What I would like is:

- Amount of consumed goods determines amount of goods ordered. (With the industry demanding the amount of goods that fit into it's storage capacity in case the storage is empty and no goods are yet on order - this to take care of the possible deadlock situation. :)
- End of month is when new goods are demanded.

---

Imagine a shop getting it's wares per truck from the station where the goods arrive per train. For normal operations it makes sense to have just enough trucks on the line to deliver a few more goods to the consumer than it consumes. After all there's no use to have dozens of trucks (and their loading bays) in a frenzy for 4 weeks and then sitting idle for the next 2 years.

However, this normally sensible behaviour causes that industries demand more and more goods - because they get little more goods than what they consume their internal storage fills up slowly - and they only stop demanding when their internal storage is completely full.

jamespetts

Quote from: Jando on January 13, 2014, 06:15:56 PM
Imagine a shop getting it's wares per truck from the station where the goods arrive per train. For normal operations it makes sense to have just enough trucks on the line to deliver a few more goods to the consumer than it consumes. After all there's no use to have dozens of trucks (and their loading bays) in a frenzy for 4 weeks and then sitting idle for the next 2 years.

However, this normally sensible behaviour causes that industries demand more and more goods - because they get little more goods than what they consume their internal storage fills up slowly - and they only stop demanding when their internal storage is completely full.

This is the part that needs analysing at present. Suppose that you have a situation that you describe, a two industry chain, with a two mode link: a railway and a road. Industry A produces at a rate of 100/unit of time (T) and industry B consumes at a rate of 10/T. Industry B has a storage capacity of 50. If your train carries cargo at an average rate of 10/T, is that not sufficient to prevent what you describe as a "frenzy"? There is no need to lay on rail capacity sufficient to carry 50/T. There is no need to attempt to keep industries' internal storage full at all times just because the system will let you do so in some cases if you able to do so.

Incidentally, why do you think that it is advisable to place such significance on a month boundary? The "months" and "years" used in Simutrans-Experimental are really only relevant to the progress of long-term time (introduction/retirement dates of buildings, ways, vehicles, etc.). For everything else, the other time scale is used, which, at default settings in Pak128.Britain-Ex, equates to 6.4 hours (that is, 6 hours 24 minutes) per "month". Everything to do with supply and demand needs to be calibrated to this time scale, rather than that of months and years, since all of the actual simulation uses this time scale. The suggestion becomes, in effect, to set demand based on the last 6 hours and 24 minutes' worth of demand, which would not seem to calibrate well.

In any event, I do not see that there is any way around the difficulty that any system in which demand is based only on previous consumption will create deadlocks. Can you see any means of obviating this difficulty? If not, the idea is unworkable in principle.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on January 13, 2014, 06:38:30 PM
This is the part that needs analysing at present. Suppose that you have a situation that you describe, a two industry chain, with a two mode link: a railway and a road. Industry A produces at a rate of 100/unit of time (T) and industry B consumes at a rate of 10/T. Industry B has a storage capacity of 50. If your train carries cargo at an average rate of 10/T, is that not sufficient to prevent what you describe as a "frenzy"? ...

I have no way to limit how much the train will carry. At least not unless I have a dedicated train for every single newsagent, butcher or grocer with a single piece goods van. :) And that would be highly unrealistic. Also, to the production rate of the producer. In general in Simutrans we have huge excess production capacity. I'd estimate that industries can produce roughly 5-10 times the demand on any given map. No big deal really, probably even necessary to make sure that demand can be met at all times.

Quote from: jamespetts on January 13, 2014, 06:38:30 PM
... There is no need to attempt to keep industries' internal storage full at all times just because the system will let you do so in some cases if you able to do so.

Here I respectfully disagree. Trying to keep an industries' internal storage full is the only way I know of to keep it from demanding more new goods. And the producer will have lots of excess capacity to provide the goods.

Quote from: jamespetts on January 13, 2014, 06:38:30 PM
Incidentally, why do you think that it is advisable to place such significance on a month boundary? The "months" and "years" used in Simutrans-Experimental are really only relevant to the progress of long-term time (introduction/retirement dates of buildings, ways, vehicles, etc.).  ...

The charts, the finance screen and the "monthly" maintenance costs certainly operate in terms of months and years. And as a greedy transport baron I don't like to pay 24 monthly maintenances for infrastructure that won't be used for 153.6 hours because the consumer shop won't demand any new goods before that. :)

Quote from: jamespetts on January 13, 2014, 06:38:30 PM
In any event, I do not see that there is any way around the difficulty that any system in which demand is based only on previous consumption will create deadlocks. Can you see any means of obviating this difficulty? If not, the idea is unworkable in principle.

Please understand me right, I happily accept your judgement in these things anyway. I really appreciate your work and dedication. I was just trying to think about how the fluctuations and spikes in the cargo business could be reduced.

Junna

Quote from: Jando on January 13, 2014, 08:36:28 PM
Here I respectfully disagree. Trying to keep an industries' internal storage full is the only way I know of to keep it from demanding more new goods. And the producer will have lots of excess capacity to provide the goods.

I toyed with your save-game a bit, and it seems that a lot of it is due to the slow ships and all. Have you tried what I recommended earlier, to limit the maximum amount of in-transit to a different level? You can change this by pressing i I believe to open the settings tab in-game, and then you save and reload to see the changes. You can toy with the setting until you find a good balance.

[TSC] Miles

Sometimes you're trying to help out people on some stuff, with your own knowledge. Then you end up here; and you don't understand a single word.

I'm out.
Baie-comeau trans canadien

Jando

Quote from: Junna on January 14, 2014, 06:07:47 PM
I toyed with your save-game a bit, and it seems that a lot of it is due to the slow ships and all. Have you tried what I recommended earlier, to limit the maximum amount of in-transit to a different level? You can change this by pressing i I believe to open the settings tab in-game, and then you save and reload to see the changes. You can toy with the setting until you find a good balance.

Hello Junna, thanks a lot. I'm sorry, I misunderstood your original post about lowering that specific number. I thought your earlier post was directed at James (or developers in general). I didn't even know that a end-user like me can change that value, thus I didn't realise it was addressed at me. :)

Thanks for pointing that out.

Just checked my save game and the value is set to 16000 - I will experiment with much lower numbers.

How did you like the save-game? Newbie gameplay?  ;)

Edit: and some initial success as well. In that save-game was a power station that had almost 17.000 units of coal in transit and was still demanding more (saw it go up to demanding 23.000 units on a fast-forward run). As a wild shot I reduced the in-transit limiter value from 16.000 to 1.000 - and the power station has stopped demanding more coal.

Junna

Quote from: Jando on January 14, 2014, 07:30:16 PM
How did you like the save-game? Newbie gameplay?  ;)

Ah, not at all really. Are you from a OpenTTD background? I noticed the one-tile turns on those RORO-stations, but aside from that I generally liked what you did there, I don't think I've ever run as many goods services...

You can probably increase how much passengers you carry by providing local 'buses or trams within cities - in case you didn't know, having several stops within closer than the 15-tile coverage isn't really a waste as long as the service is faster than 5km/h walking speed, and although the city service might itself lose money, it can bring in more money indirectly through increased passenger loading.

Jando

No background here, no. Tried Open TTD once or twice but I like Simutrans, and Experimental, much more.

Yes, I'm aware I could do more with passengers. My focus on that map is on cargo - I've set me the goal to deliver goods to all shops on that map. That needs my full attention for now. :) And it's very profitable as well, at least it makes what I'd call loads of money.

Edit: just downloaded a brand-new complete version of Experimental to a new directory. Maximum in-transit percentage as stated in settings is 16.000 there as well.

Edit: Catched a bakery demand cycle now. With a value of 1.000 as limiter the bakery (monthly demand 80 units) stopped demanding after it had around 600 units of flour in transit. Reasonable value? Plenty of flour at the grain mill available and plenty of capacity in the station there as well, thus the bakery could have demanded more.

Junna

Quote from: Jando on January 14, 2014, 10:18:07 PM
Edit: Catched a bakery demand cycle now. With a value of 1.000 as limiter the bakery (monthly demand 80 units) stopped demanding after it had around 600 units of flour in transit. Reasonable value? Plenty of flour at the grain mill available and plenty of capacity in the station there as well, thus the bakery could have demanded more.

1000 limits the in-transit to 800 or so. More will be allowed in-transit once the first load arrives. You could perhaps raise it a bit if you feel it is too low. The limitation will however avoid too much stacking up without being delivered (so there won't be 20,000 tonnes waiting at one station when some delivery is a bit slower than the others).

jamespetts

I have been considering this issue in some detail to-day, and the discussion and testing above is consistent with the conclusions of my thoughts so far, which is that the "max_intransit_percentage" is in principle the way to control this. It is heartening that the tests so far undertaken have shown this to be so. However, things are not so simple: merely reducing the number in simuconf.tab will cause other problems in some cases as the comments warn us:


# This needs to be very high.  Many factories have low storage numbers (like 30)
# and high production per month (like 600).  Long, slow ship routes can take 6 months
# to cross the map.  To keep a steady flow, we need a setting like 6 * (600/30) * 100% = 12000.
# Make it even larger to avoid breakage.


That is an explanation of why the number is so large; but what is described does not apply to all industries: it is only relevant where the lead time is very great (6 "months" at 6:24h per month is 38:24h). In other cases, the "max_intransit_percentage" can be much lower; however, the current code does not permit a separation like this. It would be helpful, therefore, if the lead time for each individual industry could be taken into account and this value adjusted for each industry based on that lead time.

Another way of reaching the same conclusion is this: in reality, not only the demand rate, but also the current stock and the lead time on orders would determine when a business demands stock. A business would try to ensure that it never ran out of stock, and so would order replenishments when stocks were running low in time for them to arrive, given the anticipated depletion rate. This will depend on three variables: (1) the anticipated depletion rate; (2) the lead time (time that they take to arrive from being ordered/demanded); and (3) the current stock level.

Currently in Simutrans, only the third variable is considered. The "internal storage" number, incidentally, is not actually a limit of how much stock that can be stored; rather it is the level of stock below which a business will demand more stock until that level is exceeded. There is no limit on the amount that can actually be stored. The max_intransit_percentage modifies this behaviour, but does not take into account the other variables.

Jando's earlier suggestion was to use recent demand as a proxy for the anticipated depletion rate in an attempt to add one of the missing variables, but this is problematic because in the proposed system, demand might itself be curtailed by lack of stock, creating a deadlock. That variable is best taken into account in a cautious way by using the maximum demand of the industry rather than its customer and staff adjusted demand figures, when those systems are introduced.

Then there is the lead time. I will need to look into the code in more detail to see how easy that it is to measure this. This would, in effect, be the journey time between the origin industry and the destination industry. It is possible to compute this, but this requires reconstructing the path between origin and destination, which could not be done too frequently (as in every step, or anywhere near) as it would be computationally intensive. I shall have to consider how this would be stored.

Finally, there is the question of how the three variables interact and how, if at all, the current "max_intransit_percentage" value is used. What I provisionally propose is this: for each consumer industry, the effective max_intransit_percentage applicable to that industry should be multiplied by the ratio of the lead time to the amount of time at peak demand that it would take to consume the level of stock below which the industry will demand goods (the input storage amount, in other words). So, suppose that the "max_intransit_percentage" figure in simuconf.tab was set to 100% in an industry whose input storage amount is 100 units. Without modification, that would mean that 100 units can be in transit to that industry at any one time. Suppose further that, at peak demand, the industry could use 200 units per hour, and the lead time is one hour. The lead time is thus twice the time that it takes at peak demand to consume the contents of the input store. Accordingly, the max_intransit_percentage applicable to that industry would be doubled from its base figure, here to 200%.

Adjusting the "max_intransit_percentage" individually and automatically for each industry in this manner will allow very long, slow goods routes to work whilst not breaking the "max_intransit_percentage" system for other industries, which, as demonstrated above, works effectively when the value is low enough for it to be meaningful.

I should be very interested in comments on this proposed solution to this issue, and additionally on whether, if such a solution is implemented, any further substantial (i.e., by orders of magnitude) reconsideration of warehouse sizes is needed and also suggested values, if any, of the what the base max_intransit_percentage should be if this system is adopted.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Great post, James, will consider this some more tomorrow. (getting late for me)

Vladki

Nice long post saying much of my thoughts. I have an idea how to estimate the delivery time.

Each industry would get a new counter for each input goods. At the beginning it would be set to the same value as input storage and that would be also the maximum for that counter. Lets call it demand counter. Suppliers will send at most demanded amount of goods and decrease the counter immediately when the goods are on the suppliers station.
Demand counter will increase at the same rate as goods are consumed. If input is empty demand will still increase at the theoretical consumption rate without pax mail and electricty. If production stops because output is full demand will stop increasing too.

No need to calculate intransit limiter and delivery times. I think it could be simple to implement in both standard and experimental

Sent from my GT-I9000 using Tapatalk 2


jamespetts

Hmm - how would that idea work when supplier industries are supplying more than one industry with goods, or where there is a constant supply? Would each packet not then have to have a counter?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Now industries send goods in packets of 10 units. I'll keep that, so that the decision is separate for every 10 units. If there are multiple recipients, send 10 units to the recipient with highest demand counter. Decrease the counter, and for next 10 units do the check again.

jamespetts

So there would have to be a separate counter for each set of 10 units in this system, and each set of 10 units would have to be tracked individually to know when to start and stop each counter?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
I have been considering this issue in some detail to-day ...

Great that you give that topic so much thought, James. It's much appreciated!

Quote from: jamespetts on January 15, 2014, 12:04:37 AM

# This needs to be very high.  Many factories have low storage numbers (like 30)
# and high production per month (like 600).  Long, slow ship routes can take 6 months
# to cross the map.  To keep a steady flow, we need a setting like 6 * (600/30) * 100% = 12000.
# Make it even larger to avoid breakage.


Funny that this is a comment in the code because I think it's actually wrong. To keep a steady flow what would needed is an industry steadily demanding goods - something an industry in Simutrans does not do. Industries demand goods in spikes, gated by whether their stock is lower than their internal storage number or not. The max_intransit_percentage limits how much they order during a spike. But it's still a spike, no matter how low or high that number is.

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
Another way of reaching the same conclusion is this: in reality, not only the demand rate, but also the current stock and the lead time on orders would determine when a business demands stock. A business would try to ensure that it never ran out of stock, and so would order replenishments when stocks were running low in time for them to arrive, given the anticipated depletion rate. This will depend on three variables: (1) the anticipated depletion rate; (2) the lead time (time that they take to arrive from being ordered/demanded); and (3) the current stock level.

This is absolutely true in the real world for some industries, mostly for smaller ones, but for far from all. It's a method for supply chain management but not the only one. This method of supply chain management is mostly used by medium and smaller industries where actual consumption of supplies changes over time, mostly due to sales - it's not used by larger industries where consumption of supplies over time can be predicted with some degree of certainty.

In Simutrans secondary industries like grain mills, hardware or furniture factories, cement works and brickworks all would work quite well with this type of supply chain management I think - their consumption is unpredictable because it depends on whether their respective customers (tertiary industries: builder's yards, bakeries, shops) demand goods or not.

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
Jando's earlier suggestion was to use recent demand as a proxy for the anticipated depletion rate in an attempt to add one of the missing variables, but this is problematic because in the proposed system, demand might itself be curtailed by lack of stock, creating a deadlock. That variable is best taken into account in a cautious way by using the maximum demand of the industry rather than its customer and staff adjusted demand figures, when those systems are introduced.

I agree with you that the suggestion of using recent demand is too dangerous because of possible deadlocks. I offcially withdraw my earlier suggestion. :)

The maximum demand, however, is a problematic one too. Not for tertiary industries, for those it should work reasonably well, but here the secondary industries are the problem: their maximum demand might be sky-high (2.400 units for a grain mill) while their actual demand might be zero: no bakery has demanded flour thus the grain mill doesn't demand any grain at all.

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
Then there is the lead time. I will need to look into the code in more detail to see how easy that it is to measure this. This would, in effect, be the journey time between the origin industry and the destination industry. It is possible to compute this, but this requires reconstructing the path between origin and destination, which could not be done too frequently (as in every step, or anywhere near) as it would be computationally intensive. I shall have to consider how this would be stored.

I believe that the lead time is the most difficult thing to get right. Many industries in Simutrans will have multiple suppliers - and those might be all over the map. One supplier to a power-station might be half an hour lead time, a colliery 20 tiles away with a direct rail link, the other might be half a map away with slow ship travel, perhaps even linked to the power-station via a quarry on the dark side of the moon. :)

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
Finally, there is the question of how the three variables interact and how, if at all, the current "max_intransit_percentage" value is used. What I provisionally propose is this: for each consumer industry, the effective max_intransit_percentage applicable to that industry should be multiplied by the ratio of the lead time to the amount of time at peak demand that it would take to consume the level of stock below which the industry will demand goods (the input storage amount, in other words). So, suppose that the "max_intransit_percentage" figure in simuconf.tab was set to 100% in an industry whose input storage amount is 100 units. Without modification, that would mean that 100 units can be in transit to that industry at any one time. Suppose further that, at peak demand, the industry could use 200 units per hour, and the lead time is one hour. The lead time is thus twice the time that it takes at peak demand to consume the contents of the input store. Accordingly, the max_intransit_percentage applicable to that industry would be doubled from its base figure, here to 200%. ...

That's a very smart suggestion. I need more coffee before I will be able to comment on that.

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
I should be very interested in comments on this proposed solution to this issue, and additionally on whether, if such a solution is implemented, any further substantial (i.e., by orders of magnitude) reconsideration of warehouse sizes is needed and also suggested values, if any, of the what the base max_intransit_percentage should be if this system is adopted.

As to the balancing of warehouses/docks I'd suggest to wait with it until we know more about the future supply chain management. There's a big chance that the amounts of goods in the transport system will change - and it seems like wasted time to rebalance capacity when we already know that capacities will likely change in the future.

I hope there's at least a tiny snippet of usefulness in my above ramblings. :)

Vladki

Quote from: jamespetts on January 15, 2014, 12:45:07 PM
So there would have to be a separate counter for each set of 10 units in this system, and each set of 10 units would have to be tracked individually to know when to start and stop each counter?

Oh no. There will be only one counter per input storage of each industry. E.g. grocery in pak128.britain accepts fruit and vegetables, so every grocery will have two new demand counters. One for fruit and one for vegetables.

Lets have an example game - two orchards O1, O2, three groceries G1, G2, G3, with different consuptions and capacities, connected: O1-G1,G3 and O2-G2, G3.
At the beginning we connect only O1 with G1. Grocery immediately orders full stock, and orchard sends all of it. Counter goes to 0, and cargo is on loaded on the train/truck/watever but conwoy is not full yet. Grocery continues ordering (increment the counter) more fruit according to its production rate. Counter goes up and down as more fruit is loaded on the train until it is full and departs. Ordering continues (up and down), cargo is stored on the station, but the rate is dependent on grocery consumption (in contrast to current behavior that would be dependent on orchard production). When cargo arrives to grocery, the demand counter will continue to increase but it will follow the real consumption.

Now we connect G3 to O1. It immediately ordes full stock, while G1's counter is near zero (it has already some stock delivered and some on the way), so O1 starts to send cargo to G3, until G1 and G3 demand counters are equal. If O1 has production high enough to satisfy both, it will continue to send each of them exactly the right amount of goods. If not, it will run out of stock, and G1 and G3 counters will start rising to their max values (input storage size), but still the supply will be balanced so that both groceries will get some goods in proportion to their consuption.

I can elaborate more on G2 and O2 if wanted :)

I can write the algorithm for that. I didnt try hacking simutrans code yet, maybe I should try... However I did not code in C/C++ for quite a few years...

Jando

The charme of Vladki's suggestion is certainly that it works both with theoretical (maximum) and actual consumption of an industry.

jamespetts

I am afraid that I am having some difficulties following this. What precisely is this counter counting? I had earlier gathered the impression that it was intended to measure the lead time, but the impression that I get from the above post is that it is intended to count demand. In precisely what conditions is the grocery's internal counter for fruit (1) incremented; and (2) decremented? What happens if, for example, there are two or three or more convoys with fruit on the way to the grocery at any one time?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

It does not maesure the lead time, I should not have said that. It just measures the demand for some goods.   

The counter is incremented when:
a) if the input storage is not empty, it is incremented when unit of input goods is consumed (sold or processed to produce some output good)
b) if the input storage is empty, it is incremented when a unit of input WOULD be consumed according to theoretical production rate.

The counter is decremented when producer moves produced goods from internal storage to nearby station and assigns a destination for them. The counter is decreased on the destination factory.

The amount of cargo on convoys, or waiting on stations does not affect anything. Also it does not matter how many convoys are on the way, or how much stuff is in input storage.

jamespetts

Ahh, I think that I see. Is the idea that the concept of an input store would be replaced entirely with a demand counter, that the demand counter would start at zero on creation of an industry and increment according to the production rate until it reached the level defined for what is currently the input store, which would act as a cap on the demand counter?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Yes, the demand counter will replace the input store and in-transit counters. (they could remain just for eye-candy). The demand counter can start at zero or full at industry creation, I think it won't make much difference.

jamespetts

Hmm - one possible issue with this is that the demand counter will keep increasing when an industry is being supplied with one type of product and not another where both are needed for the industry to function; or is the idea to have a separate system to prevent this?

Another issue is what happens to the counter when goods are discarded en route.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on January 15, 2014, 11:29:40 PM
Hmm - one possible issue with this is that the demand counter will keep increasing when an industry is being supplied with one type of product and not another where both are needed for the industry to function; or is the idea to have a separate system to prevent this?
If there is no production, then the counter will increase only if input storage is empty.
If there is some stuff in input storage, then the counter will follow real production.
So in your case the counter for available input goods will stop increasing when the first convoy arrives, and the counter for not available input goods will cap at input store capacity.

Quote
Another issue is what happens to the counter when goods are discarded en route.
Nothing happens. The counter was decreased when the goods were sent. New stuff will be ordered instead. We could increase the counter for lost goods, but I think it is not worth the trouble

jamespetts

Ahh, very interesting. I have posted a topic in the extension requests forum discussing this suggestion as, as you indicated earlier, this could apply to Standard, too.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#45
I hope you don't mind me jumping in to this discussion :)

I think it sounds as a great idea with a demandcounter.
In the real world, people go to the store to buy a new book or two. After the deal, the bookstore needs new books to replace the sold ones which they order from the printing press. When 100 people later, the bookstore is ordering appr 100 books from the factory. If the player then decide for instance to wait for a month with transporting the books, the book pile grows big and the player can use bigger vehicles and make it cheaper to transport.

The negative part of it would be if you for some reason get stuck vehicles, the orderlist from the store would grow and grow. Maybe from a certain time threshold or amount of ordered books with no books arriving at the bookstore, it could cut of new orders until the already ordered get delivered? Look at it as the store is completely sold out.

Either the bookstore could use actual visitors already transported there by the player, or it could simulate the customers by it self.

Any way the bookstore is not 'activated' until it has a connection with the delivery factory.

In order to make it a little easier for the player to calculate their new investments in vehicles for the book-line, the factory window could show what it assumes to consume pr month or hour. Since this all would have to be calibrated in some way, it should be easy to calculate or specify what it in large numbers expects.

One aspect of doing it this way is that you make the player focus on the end factory first, not the raw material factory. The end factory starts demanding goods from "Middle factories" which in turn demands from raw material factories. Then all factories along the path would know what is wanted from them, and they would order what they need.
To please those who prefer establishing a good rawmaterial factory connection first, all factories on the map could also start with some kind of "start demand". For instance one month's or hour's precalculated needs.

Just my two cents :)


Edit: you posted while I was writing, move this to that new extension requests if you think it adds something new to the discussion and should go there :)

Vladki

Quote from: ViolinVictor on January 16, 2014, 12:54:00 AM
The negative part of it would be if you for some reason get stuck vehicles, the orderlist from the store would grow and grow. Maybe from a certain time threshold or amount of ordered books with no books arriving at the bookstore, it could cut of new orders until the already ordered get delivered? Look at it as the store is completely sold out.
Stuck vehicles could cause some problems. Eventually cargo will fill all vehicles and the source station and supplies will stop automatically. However, cargo could pile up on some transfer station on the way, but that can happen in current system as well. Then the option of not routing over crowded stations would help. If the orders cannot be satisfied, the counter will rise to a max value (input storage size) and won't grow any more. It is hard to distinguish if the vehicle is stuck, or it just takes long time to travel around the world. What you suggest is in-transit-limit and that is what I want to avoid.

Quote
Either the bookstore could use actual visitors already transported there by the player, or it could simulate the customers by it self.

In order to make it a little easier for the player to calculate their new investments in vehicles for the book-line, the factory window could show what it assumes to consume pr month or hour. Since this all would have to be calibrated in some way, it should be easy to calculate or specify what it in large numbers expects.
Factories already do show monthly production/consuption (and it changes according to pax/mail/electricity). That is the rate that should be used to increment the demand counter.

Quote
Any way the bookstore is not 'activated' until it has a connection with the delivery factory.

To please those who prefer establishing a good rawmaterial factory connection first, all factories on the map could also start with some kind of "start demand". For instance one month's or hour's precalculated needs.
Unconnected factories will gradually increase their counter to input storage max value and stay there. At the moment of connection, they'll order full store at once.

jamespetts

Quote from: jamespetts on January 15, 2014, 12:04:37 AM
What I provisionally propose is this: for each consumer industry, the effective max_intransit_percentage applicable to that industry should be multiplied by the ratio of the lead time to the amount of time at peak demand that it would take to consume the level of stock below which the industry will demand goods (the input storage amount, in other words). So, suppose that the "max_intransit_percentage" figure in simuconf.tab was set to 100% in an industry whose input storage amount is 100 units. Without modification, that would mean that 100 units can be in transit to that industry at any one time. Suppose further that, at peak demand, the industry could use 200 units per hour, and the lead time is one hour. The lead time is thus twice the time that it takes at peak demand to consume the contents of the input store. Accordingly, the max_intransit_percentage applicable to that industry would be doubled from its base figure, here to 200%.

I have just been testing this system, and provisional results show that it seems to work very well (with the base max_intransit_percentage figure ideally set to 100% or slightly higher). I still need to finish one part of the code before I finalise this, which is the part relating to the calculation of the monthly consumption. This system requires no increase in the saved game number and can thus be incorporated into the next minor release.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

scamps

My opinion is that for the most part, problem can be solved by pakset balancing. Intransit percentage should indeed be reduced to 100% (200%?) and input storage balanced accordingly.
In real life, a dairy (greengrocer, newspaper agent) would not store more milk than it could sell in a day. But that amount it must be able to store, because it can't rely on several deliveries per day. Here we are talking about maximum possible consumption, taking in account possible electricity, mail boosts. If a transport company transports milk for longer than 24 hours, it probably does something wrong anyway.
On the other hand, steel mills or textile factories should run fine with weekly deliveries.
Above examples are my guesses, feel free to correct.

One problem can arise when map generator connects a cattle farm and a dairy 100 miles away in year 1800. That can be partially fixed with max_factory_spacing_percentage parameter, but it seems not to function now. Would be even better, if max distance could be set for different production chains independently, but that is whole another extension request.

scamps

By the way, I am trying to think in ingame days, not months. It is hard in trems of production. Some industries (shops) work 8-12 hours a day, some work 24 hours a day (I guess steel mills work this way even in Great Britain). How many hours is a day?

jamespetts

In Experimental, we simulate the active hours of a day and ignore the dead of night (as we do not have cyclical passenger transport demand), so we work on the assumption that a "day" (without the night) lasts 16 hours.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I have now pushed my solution to this issue (the one involving the scaling of the maximum_intransit_percentage based on the maximum consumption rate and lead time) to the 11.x branch (see this commit). In the process, an issue relating to the computation of demand in small industries (a possible set of compounded rounding errors) has been identified (see here for discussion), which seems to result in small industries consuming too much, and doubly so when fast-forwarded, which might make the calculation inaccurate for the actual consumption rate of smaller industries until the issue is fixed. (To gauge the magnitude of the issue: a market that ought to have a consumption of 16 units per month actually consumed 20 units, or 41 when fast-forwarded).

However, that aside, the new system should enable the maximum_intransit_percentage safely to be set to a much lower level than formerly (I have set 110% as a default) without causing problems with industries with long lead times, so as to enable players to gain the full benefits of the maximum_intransit_percentage feature, which is, I think, sound in principle and reflects how industry demand actually works more or less.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Great news, James, and thank you very much for your efforts.

I can hardly wait to try it on my cargo-heavy Baringstone map. :)

jamespetts

11.16, with this new feature, has now been released. You will need to update the max_intransit_percentage manually for the being pending the release of new configuration files (and in any event with existing saved games): this can be adjusted in the advanced settings dialogue box (key "i" in Pak128.Britain-Ex). 110% is the recommended value for the present, although I should be interested in any feedback following testing as to what might be a more optimum value.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Some quick first tests show that the new algorithm indeed leads to a much better, more constant demand from industries, without the spikes we've seen in the past. Gratulation, James.



In-transit figures shown, at the left of the graph is a spike from the old mechanism, then no demand while the furniture shop sells off it's stock, now in the last 3 months with the new algorithm a constant demand of roughly the monthly maximum of the furniture shop. Very good!

In a few cases I saw negative in-transit numbers, oddly with those industries still receiving goods, no idea whether bug or feature. :) Will investigate more.



Pictured are a fishmonger with negative in-transit and a train delivering fish to that fishmonger. :)

Save-game from the fishmonger screenshot at http://simutrans-germany.com/files/upload/Baringstone_Fishmonger.sve

jamespetts

Glad that the system is working! Thank you for testing so thoroughly.

I had noticed the negative in transit figures - but I think that that is a feature (or bug, as the case may be) from Standard, or arising from the interaction of the code in Standard and Experimental (I suspect that it occurs when goods are thrown away en route). I have not changed the calculation of the in transit number itself, so this should be unaffected by the latest change.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I have negative in-transit numbers in standard as well. Maybe lost cargo was subtracted form in-transit twice...

Jando

Oh, didn't know, never seen it before.

I don't lose cargo, I'm a responsible transport baron.  8)

MCollett

Quote from: jamespetts on January 20, 2014, 01:16:35 AM
11.16, with this new feature, has now been released.

How long should it take for an industry to adjust its in-transit allowance for actual lead times?  I'm six months into a new 1750 game using 11.16, supplying milk by ship to a dairy with a lead time of about 7 hours, which would require an in-transit allowance of about 400 units for a steady supply, but the amount in transit is still stubbornly capped at the original 75-80 crates.

Best wishes,
Matthew

jamespetts

In principle, this should adjust at the next end of month once a trip time has been registered. A trip time is registered after (1) a convoy makes one complete end to end trip; and (2) thereafter, the path explorer is run (this automatically happens periodically). If this does not appear to be happening, this might be a bug, and it would help me if you could upload a saved game for me to investigate.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

MCollett

Quote from: jamespetts on January 22, 2014, 10:38:17 AM
it would help me if you could upload a saved game for me to investigate.
Here it is:
http://simutrans-germany.com/files/upload/Billinge_175000014_1750-11.sve
The dairy I mentioned is in Stockton-on-Tees, but there are other factories showing similar symptoms, including the fishing port near Rotherham.

Best wishes,
Matthew

zook2

Quote from: Vladki on January 20, 2014, 08:16:38 PM
I have negative in-transit numbers in standard as well. Maybe lost cargo was subtracted form in-transit twice...
Apparently, that has been fixed.
http://forum.simutrans.com/index.php?topic=13133.msg130427#msg130427

jamespetts

Thank you for pointing that out. That will have to wait for the next major version, I think: the code to which that is applied is quite different to the current code, and manually merging only those parts that apply to the current code does not actually fix the problem.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

MCollett

11.17 has improved things: in the game I uploaded earlier the dairies, the fishing port and the builders yard now all seem to be responding in the right way (though perhaps not quite as much as expected).  But even after a few months of running with the new code, the markets are all stubbornly sticking to their original order level for fish, even though it really needs to be increased by a factor of 4 or so.

Best wishes,
Matthw

jamespetts

Hmm - that is odd. I thought that I had fixed the problem in 11.17 (albeit that the fix will not have effect until the next month). Can you upload a saved game? Incidentally, if some industries' maximum intransit percentages are a bit too low, you could always simply raise the base maximum_intransit_percentage figure (key "i" to reach the advanced settings dialogue: it is in the "economy" tab).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

MCollett

Quote from: jamespetts on January 26, 2014, 01:40:31 AM
I thought that I had fixed the problem in 11.17 (albeit that the fix will not have effect until the next month). Can you upload a saved game?
Here is the same game as previously, rerun from March to November using 11.17:
http://simutrans-germany.com/files/upload/Billinge_175000014_1750-11a.sve
Looking at either consumption or in-transit graphs for either of the dairies shows the expected behaviour: a slow couple of months initially (running under 11.16), jumping to a good proportion of the capacity thereafter.  But looking at any of the three markets being supplied with fish shows no change under 11.17: the low initial throughput remains.

QuoteIncidentally, if some industries' maximum intransit percentages are a bit too low, you could always simply raise the base maximum_intransit_percentage figure (key "i" to reach the advanced settings dialogue: it is in the "economy" tab).
Yes, I might push that to 300 or so.  Does the dynamic in-transit allowance decrease from the default when turn-round time is short as well as increasing when it is long?

Best wishes,
Matthew

jamespetts

Quote from: MCollett on January 26, 2014, 03:38:08 AM
Here is the same game as previously, rerun from March to November using 11.17:
http://simutrans-germany.com/files/upload/Billinge_175000014_1750-11a.sve
Looking at either consumption or in-transit graphs for either of the dairies shows the expected behaviour: a slow couple of months initially (running under 11.16), jumping to a good proportion of the capacity thereafter.  But looking at any of the three markets being supplied with fish shows no change under 11.17: the low initial throughput remains.

Thank you - I will look into that.

QuoteYes, I might push that to 300 or so.  Does the dynamic in-transit allowance decrease from the default when turn-round time is short as well as increasing when it is long?

Yes, indeed - it scales both ways.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.