News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Industry demand counters

Started by jamespetts, January 15, 2014, 11:34:33 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

An interesting suggestion has been made regarding industry demand and production in a discussion on the Experimental subforum which seems to me to be equally applicable to Standard: see the discussion from here onwards.

In essence, the idea is to replace the current input store with a demand counter system. Each industry has one counter for every type of input demanded. The counters start at zero when an industry is first created. They are incremented at the same rate as the industry consumes the relevant input type, up to the limit of the number now used as the input storage. In the meantime, they are decremented whenever input goods begin their journeys towards the industry (e.g., if 200 widgets have just left factory X's output store and are in the player's station heading for shop Y, shop Y's widget input counter is decremented by 200).

The idea is to even out spikes in demand and supply in a simple way and do away entirely with the need for the "max_intransit_percentage". It would require an increment to the saved game version, however, as the demand counters would have to be saved and reloaded. Two possible issues (which might or might not easily admit of a solution): (1) imbalances might arise where an industry is supplied with one type of input but not another; and (2) the system may be miscalibrated when goods are discarded en route (for example, because there ceases to be any route from their current halt to the destination).
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.

Ters

I think it makes more sense if the demand counter starts at maximum, because there are some inputs that are consumed so slowly that it would take a long time before demand is high enough to fill a train or ship. If goods get lost en route, they should be added to the demand just like they now must be subtracted from the in-transit amount. I'm not 100 % sure there is any real difference between this proposal and the way it is now. The demand number sounds like storagein-transit, except that that number currently starts at capacity rather than 0.

Vladki

Yes the demand couter was meant to start at max. Maybe it got lost in the discussion.

The difference is noticeable if you have a consumer with small input storage and long distance to supplier. Current system will send more and more goods until the input store is full. By that time a huge amount of goods will be in transit. Supplier stops production. It may take months to consume the excess supply. When the input store gets below max new supplies are sent, but the consumer may run out of stock before supplies arrive. In transit limiter helps a bit, but it is impossible to set it right if distances vary too much.

This proposal does not care about in transit cargo and neither cares about input store being over max. Just orders the same amount of goods that (would) have been consumed.

Imagine a producer in middle between two consumers. One train serves both. Now if cargo can be sent to more customers it is sent to the one that has least cargo waiting on the stop. Thus the convoy has to wait for the cargo to load it immediately to steal it from the other customer. After leaving the stop and coming back at most half of the waiting cargo will be for the next destination. My proposal will always send cargo in proportion to consumption

Sent from my GT-I9000 using Tapatalk 2


prissi

In the end, such a demand counter should enforce that a supply factory does not produce faster tha the receiving factory. That open several questions:

First: That will render any means of transport useless, that can load more than the input storage of said factories. I.e. fish swarms will never ever load a fishing vessel.

Second: How to start up a second chain. You need the ggods first to start up the chain. If those are delivered to another factory (because at the beginning you only have one), then these will not be delivered.

This leads to thrid: Every packet produced must be already have a consumer in mind, otherwise these will be routed to the next factory in the loading schedule (even though demand was generated by another factory, which is connected by not served by the current factory. So the factory will have an output per each connected consumer (maybe hidden, but internally this is needed). Doable, but looks like a lot of careful bookkeeping is needed for that.

It also take challenge out of the game, i.e. deal with congestions and balance your chains correctly. The AI are dumb, but they you the right capacity and their convois are mostly moving.

Jando

Quote from: Ters on January 16, 2014, 05:38:56 AM
... I'm not 100 % sure there is any real difference between this proposal and the way it is now. ...

Oh, there is a really important difference: in the new suggestion from Vladki industries can demand new goods continously, i.e. whenever they consume goods, either by selling something or by using goods for production. The existing mechanic has demand for goods gated by input storage instead, typically that leads to a short but high spike in demand followed by long times on no demand at all.

Here's a screenshot of a bakery from my current (cargo-heavy) Experimental game:



Pictured are the graphs for in-transit (bright red) and storage (dark red) of flour for the bakery. At the left side (8-11 months ago) you see the end of the previous spike: in-transit goes down while storage goes up because the remaining flours from the last spike are delivered to the bakery.

In the middle of the 12-month period you see no flour in transit, thus nothing can be delivered. The bakery has enough flour in storage and consumes the goods delivered, storage slowly goes down. Just 2 months ago now the bakery demanded new flour and started a new spike.




prissi

I consider it rather part of the game to find out how much to transport. Simply transport everything is so boring. Just transport what the consumer needs. It would take some of the fun if I just can hook up the largest stuff I found and then just throw in everything, cause simutrans will figure it out.

Still if a too large convoy is used, and the consumer runs dry, then under this proposed model the factory will be starved forever. So it is no carefree either. If one wants to avoid this, i.e. allow piling up demand: voila spike again.

Vladki

Quote from: prissi on January 16, 2014, 10:27:07 AM
In the end, such a demand counter should enforce that a supply factory does not produce faster tha the receiving factory. That open several questions:
First: That will render any means of transport useless, that can load more than the input storage of said factories. I.e. fish swarms will never ever load a fishing vessel.
No. If the input storage is empty, factory will continue ordering more at the theoretical rate (displayed in factory info), so the bigger vehicles get loaded eventually. If the input storage is not empty, then the orders will be equal to actual consumption.

Quote
Second: How to start up a second chain. You need the ggods first to start up the chain. If those are delivered to another factory (because at the beginning you only have one), then these will not be delivered.
See my post about grocery and orchard here. http://forum.simutrans.com/index.php?topic=12919.msg130050#msg130050.
The trick is that a well supplied industry will have its demand counter near zero, because as soon as it demands some goods, the producer will send it and decrease the counter. New industry (or starved one) will have the demand counter at maximum. Suppliers will first send to factories with higher demand counter

Quote
This leads to thrid: Every packet produced must be already have a consumer in mind, otherwise these will be routed to the next factory in the loading schedule (even though demand was generated by another factory, which is connected by not served by the current factory. So the factory will have an output per each connected consumer (maybe hidden, but internally this is needed). Doable, but looks like a lot of careful bookkeeping is needed for that.
No no. Goods that are yet in the output storage of producer do not need to know their destination. Destination will be assigned when the goods move to the station to be loaded. Just as now, only the decision where to send them would be different. Well I should write the algorithm somehow to make this precisely clear.

Quote
It also take challenge out of the game, i.e. deal with congestions and balance your chains correctly. The AI are dumb, but they you the right capacity and their convois are mostly moving.
If you have direct, dedicated and not extremely long connection between factories than you can do this by tuning the number of convoys, their capacity and speed easily. Thats what AI does - use dedicated link for everything. But if you want to play "nice" maps - get cargo to hubs, use various modes of transport, use the same convoy for multiple industries, carry mix of goods in both ways, then it starts to be a really tough challenge.

Leartin

Quote from: prissi on January 16, 2014, 03:09:33 PMI consider it rather part of the game to find out how much to transport. Simply transport everything is so boring. Just transport what the consumer needs.

While this is absolutely true (imho), the game keeps telling you otherwise. If you only carry as much as is needed, prepare for "Station Overcrowd" messages every month. Even if a player does not know about Simutrans and starts by transporting just in time, he'll quickly change this behaviour as soon as these messages come in, because via those the game tells you that you should transport more. On the other hand, the game never says anything about factories which were supplied too much goods, so if you don't try to optimize everything, you would not even find out that anything could be wrong with transporting everything. (Even if anyone asks why his trains don't transport stuff anymore on the forums, he is just told that the end producer has enough goods, but nobody says that the user himself made the mistake of having too many trains on the route.)

My approach to "solve" the problem would be this:
1) Get rid of "station overcrowd" at stations which are overcrowded by a nearby producer. I mean, if you have your own storage facility right next to the station, why would you try to put more goods there then there is space? If you'd just fill it, but not overfill it (not trigger the message) a gamer would think "great, they can fill the station again before my train comes back", not "oh ****, they produce so much, hurry and get rid of all those goods!"
2) A new message showing up whenever a factory has too many goods and therefore stops ordering. These might get as annoying as those station overcrowd messages, but at least if you turn them off you can't miss anything of importance. (Like an overcrowded pax station, which far more often IS a problem)
With these two, while not really altering how the game works, you could guide players in the right direction and demand spikes would not happen, or rather, if they happen, the player is instantly aware of them and knows HE has to fix something (not the game).

Ters

Quote from: Vladki on January 16, 2014, 07:58:30 AM
Yes the demand couter was meant to start at max. Maybe it got lost in the discussion.

The difference is noticeable if you have a consumer with small input storage and long distance to supplier. Current system will send more and more goods until the input store is full. By that time a huge amount of goods will be in transit. Supplier stops production. It may take months to consume the excess supply. When the input store gets below max new supplies are sent, but the consumer may run out of stock before supplies arrive. In transit limiter helps a bit, but it is impossible to set it right if distances vary too much.

This proposal does not care about in transit cargo and neither cares about input store being over max. Just orders the same amount of goods that (would) have been consumed.

If there is no max, which I get contradicting statements about, the demand can continue to grow and grow. It must stop at some point, or we will get insanely high numbers and eventually an overflow. If there is a max, I still can't see how this effectively different from doing something with in-transit limit.

Currently, demand is effectively capacity + in-transit limit minus in-transit + storage. Storage is decreased at the rate of production, leading to a corresponding increase in demand, and in-transit increases as suppliers send something, leading to a corresponding decrease in demand. The change from in transit to in storage doesn't change the equation.

ӔO

Shouldn't it be possible to calculate, roughly, how much capacity you need to have if you know time taken for trip, vehicle capacity and factory demand?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Jando

Quote from: ӔO on January 16, 2014, 05:42:21 PM
Shouldn't it be possible to calculate, roughly, how much capacity you need to have if you know time taken for trip, vehicle capacity and factory demand?

But you cannot tell in advance from what supplier the factory will demand goods - and the trip times and capacities from different suppliers to a consumer may vary wildly.

ӔO

I think something like...

(factory demand)(time per month)
______________________________ = vehicles necessary
(vehicle capacity)(full trip time taken)

However, my math is rusty.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

I am following this with interest: there is much well considered material to consider here. Apologies, incidentally if, in my initial summary, I did not fully understand the original suggestion and did not summarise it accurately in some respects; hopefully Vladki has now corrected any errors that I might have made.
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.

Ters

Quote from: ӔO on January 16, 2014, 05:58:15 PM
I think something like...

(factory demand)(time per month)
______________________________ = vehicles necessary
(vehicle capacity)(full trip time taken)

However, my math is rusty.

The problem is finding "full trip time taken". In a complex interconnected network, there may be several possible parallel routes, each made up of one or more links with different vehicles. Furthermore, should it adapt to the actual route, or try to force the player to construct a direct route.

jamespetts

Quote from: Ters on January 16, 2014, 06:41:23 PM
The problem is finding "full trip time taken". In a complex interconnected network, there may be several possible parallel routes, each made up of one or more links with different vehicles. Furthermore, should it adapt to the actual route, or try to force the player to construct a direct route.

It is possible to reconstruct this in Experimental, where the trip time is used to determine the route taken, but I expect that it would be more difficult in Standard.
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

#15
Uff, I did not expect that it will be that hard to explain. Maybe my english is not as good as I thought. I'll try to write down two algorithms. One is how I understand the current simutrans behavior, and the other how I want to change it. Then I will deal with above questions.

Current algorithm. (my guess)

New factory created:
1. all storages (input and output) are empty, in-transit counter zero.

Production loop:
1. calculate how much is produced based on factory productivity and boost (pax, mail, ele)
2. if there is enough input goods and free space in output storage go on and produce the calculated amount of goods
3. increase the output storage and decrease input storage accordingly

4. if there is more than 10 units in output storage find suitable customer
5. customer has to be connected by transport, its input storage must not be full, and optionally in-transit counter below limit
6. check how much cargo is waiting on connected station(s) for each customer (only those that fit condition 5.)
7. if the station is not overcrowded, send 10 units of cargo to the consumer with the lowest amount of cargo waiting on the station(s)
8. increase the in-transit counter, decrease the output storage.
9. If there is still more than 10 units in output, goto 4.

Cargo arrival:
1. decrease the in-transit counter, increase input storage.

----------------------
New algorithm (my wish):
Changes are in bold and overstrike
----------------------

New factory created:
- all storages (input and output) are empty, in-transit counter is not needed.
- demand counter is set to input store capacity (for each input good)

Production loop:
1. calculate how much is produced based on factory productivity and boost (pax, mail, ele)
2. if there is enough input goods and free space in output storage go on and produce the calculated amount of goods
3. increase the output storage and decrease input storage accordingly
3.1. increase demand counters for input by the same amount as input storage was decreased
3.2. if nothing was produced because some input is empty, increase its demand counter by the calculated amount. Only for the empty input!
3.3. if nothing was produced because output storage is full - do nothing
3.4. maximum value for demand counters is input storage

4. if there is more than 10 units in output storage find suitable customer
5. customer has to be connected by transport, and have demand counter at least 10  (modified Jan-17)
6. sort the demand counters of customers that fit condition 5.
7. send 10 units of cargo to the consumer with the highest demand counter (if the station is not overcrowded)
8. decrease the output storage, decrease customer's demand counter, in-transit counter is not needed
9. If there is still more than 10 units in output, goto 4.

Cargo arrival:
1. in-transit counter is not needed, increase input storage.

=============
That's it.

Now to previous posts and questions. Leartin has really good point about overcrowded stations. When I played for the first time, I got scared by those messages and tried to do everything to get all the coal to the power plant. Really the overcrowded message makes sense only for pax and mail. A message for overcrowded input of factory would be useful as well as a message when factory runs out of stock.

QuoteTers: Currently, demand is effectively capacity + in-transit limit minus in-transit + storage. Storage is decreased at the rate of production, leading to a corresponding increase in demand, and in-transit increases as suppliers send something, leading to a corresponding decrease in demand. The change from in transit to in storage doesn't change the equation.
Good point, equation is fine. Maybe the step 7. in above algorithms is what makes the difference - the decision who is going to get the produced goods. Further there is limit to demand counter - it shall not exceed input capacity. Moreover demand is increased even if the factory runs out of stock. Goods may be sent to factory with overfull input storage, but still I'm pretty sure that there will be no spikes. Only some fluctuations caused by pax/mail boost and traffic congestion.

To others about the trip time calculations. I hope that the above algorithm will do that as a side effect. Let's have an example:
Grocery orders fruit from orchard. Initial demand (input capacity) is 100 t. The train is not waiting for full load, so it takes the 100 t and begins the journey across the map. Grocery continues to order more fruit which is piling up on the orchard's station. After some time fruit arrives to grocery, train turns around, and all fruit is sold before the train gets back to orchard. Orders are coming all the time (at the same rate if there is no pax boost), and when the train arrives for more fruit there will be the quite a lot of fruit waiting at the station. How much? Exactly the same amount which would be sold during one round trip of the train. No need to calculate it in advance! The next time the train gets to the grocery, it will deliver just enough to keep it selling during the next trip. However if the first batch is bigger than round-trip consumption, then the grocery will have some spare supply to keep it running even if the train gets stuck or pax/mail boost increases production. However further deliveries will closely follow round-trip-time production.
As prissi pointed out, you can achieve this by using a train of the right capacity. But it gets complicated if there are goods for other factories on the same convoy, or goods have to switch convoys.

ufff, I hope I have clarified the issue now.

Hmm, just reading before posting. Ters has really good equation. Almost the same effect, that I'm trying to achieve, might be done just by changing the steps 5,6,7 and using Ters' equation to find factory demand in step 6. It won't be the same, but close enough and with less changes in code.

prissi

That would only work for factories in 1 to 1 relation. Assume for instance an oil rig, that supplies three refineries. However, currently only one refinery is connected, but the other two get there input from other players. Hence, those would lack input and the oil refinery produces as hell, until the only connected refinery is overflow. Then now production is halted again for months. Hence, one needs an output for each connected factory.

Second remark: If there is not a limit what will be produced, then we end up again with spikes. Imagine somewhere in the network a large train. Goods pile up until this is filled. Then the factory is overflow and production is halted for a long time.

Now getting more constructive: Message of overflow limiting to pax and mail are a very sensible one!

Second: What about a system, where a train cannot unload more than what fits into the storage. I can then either "wait for unload (0%)" or drive back half filled. (However, one needs to avoid getting money for this, so the payment for distance setting needs to be 1 or 2.)

Jando

As far as I can see we have spikes because industries demand goods in spikes, i.e. when their stock is below the critical number called input storage capacity. Then the industry will demand a large amount of goods. A producer can never cause a spike because the goods from a producer never enter the map without a consumer demanding these goods first.

isidoro

Quote from: prissi on January 16, 2014, 11:03:25 PM
Second: What about a system, where a train cannot unload more than what fits into the storage. I can then either "wait for unload (0%)" or drive back half filled. (However, one needs to avoid getting money for this, so the payment for distance setting needs to be 1 or 2.)

That seems very sensible to me.  I support that.  Although it can complicate things a bit.

And the interface: to combine "wait for loaded", "max waiting time", "wait for unloaded",... that could also be combined in the same stop.  Sometimes, one can use the same train to transport goods back and forth to increase the profit...

Jando

Quote from: prissi on January 16, 2014, 11:03:25 PM
... Second: What about a system, where a train cannot unload more than what fits into the storage. I can then either "wait for unload (0%)" or drive back half filled. (However, one needs to avoid getting money for this, so the payment for distance setting needs to be 1 or 2.)

I'm not sure what could be achieved with this. Sounds pretty much like a consumer orders goods from a factory, tells a transport company to bring him the ordered goods, the train with the goods arrives, and the consumer refuses to take what it ordered. :)

Wouldn't it be better not to demand goods it cannot take in the first place?

Isaac Eiland-Hall

So there's a contract... As soon as the goods/etc are loaded onto the convoi, then they are deducted from the demand of the receiver? And they'll get there when they get there. If they disappear en route, either that's a loss, or it can be tracked and added back to the demand?

prissi

Quote from: Jando on January 16, 2014, 11:35:58 PM
As far as I can see we have spikes because industries demand goods in spikes, i.e. when their stock is below the critical number called input storage capacity. Then the industry will demand a large amount of goods. A producer can never cause a spike because the goods from a producer never enter the map without a consumer demanding these goods first.
No, the producer halt production, when there is no demand at all. To generate spikes, you have to have a producer which supplies more than one factory (or can supply). Then you need a slow (or long) connection to a factory, and switch off the in_transit counter.

If the producer production is below the consumers consumption (e.g. coal mines) you cannot generate spikes. Same if you actually supply to all consumers.

If you have a consumer and a long connection, you can generate spikes also with a demand counter unless output is strictly produced per consumer (i.e. nothing can be rerouted in the output storage).

Vladki

First -- I made a small fix to the algorithm above - do not deliver cargo to a factory with demand near zero (<10)

Quote from: Isaac.Eiland-Hall on January 17, 2014, 01:05:57 AM
So there's a contract... As soon as the goods/etc are loaded onto the convoi, then they are deducted from the demand of the receiver? And they'll get there when they get there.
Yes, almost exactly. Deduction from demand happens when cargo moves from producer factory to the station. It does not have to be loaded on convoy immediately. Arrival time does not matter.

Quote
If they disappear en route, either that's a loss, or it can be tracked and added back to the demand?
I think it is not worth the trouble to care about lost goods. The worst that can happen is that the consumer will run out of stock for a while, but will be resupplied anyway.

About the spikes - if you try hard you can make some spikes in my system as well - just by delivering a huge train of goods to a small shop. But OK, the shop will have huge amount of stock, and will still order more, but slowly - only at the rate of its consumption. So the huge train will wait for long time to load. It will be full only when the shops input storage will become almost empty and will arrive right in time to refill the shop. Production of both supllier and consumer will be smooth, only the storage will have spikes. And by doing this the player will punish himself - expensive train standing uselessly and occupying station, payig the maintenence and having no revenues.

Problem with in-transit is that the optimum is different for every pair of factories. The farther they are from each other, the bigger in-transit value is needed. It helps to reduce spikes, but spikes still happen.

Cargo in output storage does not have to have destination. See the algorithm. If there is something in the output storage, find consumer with highest demand and send it. Even if the output storage is full, you'll never send all stuff to one of them, but send it in proportion to customers demand.

Prissi: I didn't understand your example about oil rig and rafineries, could you clarify it a little?

About unloading cargo: I think I saw such proposal already. What I would propose is, that when the cargo is unloaded, it first has to enter the station storage, and only after that it is moved to factory input store (if not full). This could cause overcrowded station, and this time WITH warning. Then the player could decide if he wants to play with "avoid overcrowding" and "no routing over overcrowded stration" options or not.

prissi

QuoteCargo in output storage does not have to have destination. See the algorithm. If there is something in the output storage, find consumer with highest demand and send it. Even if the output storage is full, you'll never send all stuff to one of them, but send it in proportion to customers demand.

So you suggest, that the consumer demands goods. A stations is connected to the producer, so loading can proceeds to the consumer which has the highest demand until whatever consist is filled. At this point every packet must have an origin and cannot be rescheduled. (That was introduced to avoid a blocked station for a second factory, when there is no mean of transport for immediate loading there.)

So you want to decrease the demand then at the time of loading. Imagine a long connection. Now, instead of overflowing, you will starve the consumer. Or, if the demand slowly continues while in transit, then the transport will find a huge heap of goods waiting, generating a spike then on the second trip.

About Oil riggs: Imagine there are three connected factories, but only a transport link to one. Since factories do not know, whether transport is available or not (or they would not produce at all at the beginning) the oil rigg will produce whenever there is demand in any of the three connected refineries. However, the Oil gets only transported to one of them. Voila, a spike each time. (Not that this work in the currents system any better, but that is not the issue.)

If you want to avoid spikes, you need to produce with the customer in mind. Then you can properly cease production, when consumer is overflow and still producing for the others.

jamespetts

I should note that I have now implemented in Experimental my version of the solution to the original issue, involving scaling the maximum_intransit_percentage based on the consumption rate and the lead time (see here). I realise that this may not be a good solution for Standard, where it is not easy to measure the lead time (which is based in Experimental on data generated for the routing system). My tests seem to show that this works well, albeit subject to a possible bug which might well arise from Standard (and seems to be based on rounding errors; see here for details) relating to consumption rates of small industries.
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.

prissi

Standard scales the in_transit base on the output storage (in the nightly since a month or so) of all connected suppliers. That seems to work out surprisingly well in my trials, better than an attempt on distance (which is probably not very different from time in experimental).

jamespetts

Interesting - I wasn't aware of this. What is the basic formula behind the scaling?
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.

prissi

Iterate over all supplier whener the connections are changed.

Take the sum of suppliers.ouput*in_transit_erpcentage for all.

Vladki

Quote from: prissi on January 17, 2014, 03:22:25 PM
So you suggest, that the consumer demands goods. A stations is connected to the producer, so loading can proceeds to the consumer which has the highest demand until whatever consist is filled. At this point every packet must have an origin and cannot be rescheduled.
Right, that is what I want.

Quote
So you want to decrease the demand then at the time of loading. Imagine a long connection. Now, instead of overflowing, you will starve the consumer. Or, if the demand slowly continues while in transit, then the transport will find a huge heap of goods waiting, generating a spike then on the second trip.
Well, even for a long connection, I will starve the consumer only for the first delivery, because on the second trip the huge heap will be just right to keep the consumer producing during the third trip. There will be spike in storage, but not in production.

Quote
About Oil rigs: Imagine there are three connected factories, but only a transport link to one. Since factories do not know, whether transport is available or not (or they would not produce at all at the beginning) the oil rig will produce whenever there is demand in any of the three connected refineries. However, the Oil gets only transported to one of them. Voila, a spike each time. (Not that this work in the currents system any better, but that is not the issue.)
AFAIK, even now will the oil rig store the oil in its output storage if there is no transport available, and cease production if output is full. I do not want to change that. If only some connected factories have transport link, then only demanded amount of oil will be moved to the station and assigned a destination. If the factory produces more than the customers can use, it will just keep filling its output storage - thus decreasing production (and its own demand for supplies).

Quote
If you want to avoid spikes, you need to produce with the customer in mind. Then you can properly cease production, when consumer is overflow and still producing for the others.
This is all about producing with the customer in mind - I just want to produce at the same rate as he is consuming. I just do not like the fact that deliveries stop completely, when consumer is overflow, because that is what leads to starvation. (in combination with small input storage and long distance).

jamespetts

Quote from: prissi on January 19, 2014, 08:58:47 PM
Standard scales the in_transit base on the output storage (in the nightly since a month or so) of all connected suppliers. That seems to work out surprisingly well in my trials, better than an attempt on distance (which is probably not very different from time in experimental).

May I ask - where in the code is this? I am working on merging my latest changes into the Github branch into which Bernd  has merged the latest changes in Standard, and I want to be able to avoid any possible conflict here.
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.

prissi

It is add_supplier and remove_supplier (or function named very similar) in simfab.cc (much to the end of the file). There is something called "max_transit" which was added. It contains the maximum intransit amout for a certain good for a factory.