News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

enable factory_max_input_capacity to be set from config files

Started by jk271, January 28, 2012, 06:57:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jk271

There is a hardcoded maximum amount of input ware stored in factories today. However is it not enough in some cases.

It is set in simfab.cc on line 64 by statement
static const int FAB_MAX_INPUT = 15000;

This patch enables to set this number in configuration files. So pak developers could modify this value in settings without need of recompiling program.

Example of configuration from simuconf.tab:
# factory_max_input_capacity
factory_max_input_capacity = 25000

There is some discussion about it. (And the reason, why I made such a patch)
http://forum.simutrans.com/index.php?topic=8943.0



Edit:
Here 32-bit Linux binary can be downloaded. Unfortunately I am not able to make crosscompilation for windows.
http://simutrans-germany.com/patches/download.php?file=sim20120128_factory_2.zip

prissi

Setting this value higher gives inernal overflows. Play without "just_int_time", if you do not want this.

TurfIt

Where is it overflowing? I can't seem to find...
It should be good upto 2^21.

prissi

Ok, maybe the guys in the german forum were too greedy who reported this. Well, ok we could set it to 2^21-1. Although I could not imagine a working economy with this.

TurfIt

IMHO there should be a sensible limit to avoid abuse of the storage space. If a factory has 1000t of storage, then it should store 1000t period. But, as the JIT mechanic treats full storage as the 'reorder level', some amount over needs to be permitted (unless JIT behaviour is changed some...). Hence, my suggestion in the other thread of a hard limit at 2x max storage.

jk271


Quote from: TurfIt on January 28, 2012, 08:47:24 PM
IMHO there should be a sensible limit to avoid abuse of the storage space. If a factory has 1000t of storage, then it should store 1000t period. But, as the JIT mechanic treats full storage as the 'reorder level', some amount over needs to be permitted (unless JIT behaviour is changed some...). Hence, my suggestion in the other thread of a hard limit at 2x max storage.


Using twice max capacity works well with factories having huge input capacity.
edit: (blue)
On the other hand it can bring some undesired behavior (throwing away delivered goods) to factories having very small input capacities (e.g. factories in 19th century from pak128.Britain).


I do not desire having factories behaving like in openttd (withou just_in_time enabled). My intention was to avoid such a situation:
pak128: I have a steel mill with input capacity of about 15500. (Built automaticly not manually.) With a limit of 15000 it behaves like with option just_in_time disabled. Delivered iron ore is thrown away. Iron ore mines do not stop production, because of input capacity of steel mill is not full.

And what about another problem it solves: Imagine having a cargo for some reason with many small units (e.g. crude oil in barrels as units instead of m3, bulk cargo in metric cents or kilograms instead of tonnes). 

The best solution would be to stop unloading in case of lack of free input capacity and wait with unloading until there is some free space, but it is more difficult to make.

prissi

In that way I consider some factories in pak128 broken for a long time. But anyhow, the limti will be increased.

And setting up you transport chains, that you just transport about what is needed is a big part of the challenge. However, making the production just stop after twice is filled, it would be the same as if it is just twice the incomeing storage size, and would not change anything. Or I understood your request wrong.

TurfIt

Quote from: jk271 on January 28, 2012, 09:42:53 PM
On the other hand it can bring some undesired behavior (throwing away delivered goods) to factories having very small input capacities (e.g. factories in 19th century from pak128.Britain).
Why are the input capacities so small? I would presume the intent would be for deliveries to be made with small capacity vehicles then too. i.e. the vehicle and factory capacities need to be considered together when balancing the pak.
If the pak is created with small factory capacities, one must presume that's on purpose. So why should the game code override that design with an effective huge (15000) storage?


Quote from: jk271 on January 28, 2012, 09:42:53 PM
pak128: I have a steel mill with input capacity of about 15500. (Built automaticly not manually.) With a limit of 15000 it behaves like with option just_in_time disabled. Delivered iron ore is thrown away. Iron ore mines do not stop production, because of input capacity of steel mill is not full.
That is the problem to be fixed. I'm sure when the 15000 limit was imposed, no factories had storages of such values.


Quote from: jk271 on January 28, 2012, 09:42:53 PM
The best solution would be to stop unloading in case of lack of free input capacity and wait with unloading until there is some free space, but it is more difficult to make.
This is something on my todo list to try out someday. Also unload to the station instead of the factory directly, giving a reason to build high level stations at delivery points and expand the storage.


Quote from: prissi on January 28, 2012, 10:31:17 PM
However, making the production just stop after twice is filled, it would be the same as if it is just twice the incomeing storage size, and would not change anything. Or I understood your request wrong.
My suggestion (see patch in other thread) was to change the hardcoded 15000 limit to use 2*eingang.max instead before it starts throwing away delivered goods. Nothing to do with stopping production.

prissi

The factories in pak128 have this limit since their beginning. The ore mine is almost impossible to be saturated using trucks. The first try of an AI using pak128 with realistic number of cars ended up buying 4600 something 2t trucks in 1930 for the ore. Of course nothing was moving, as they all blocked themselves. This I set the limit for the AI to 255. Thus storage as well as production are often way off. this was made to give an easier start, when the initial coapital was still fixed at 200.000. (And this tells you that that predates my contributions to the code.)

jk271


Quote from: prissi on January 28, 2012, 10:31:17 PM
... However, making the production just stop after twice is filled, it would be the same as if it is just twice the incomeing storage size, and would not change anything. Or I understood your request wrong.

I did not suggest doubling capacity. It was response to Turfit's suggestion to use "2*max_input_capacity_of_factory" (as a limit value) instead of fixed value (of 15000 or something else as a limit value). I gave a notice, that such change has also unwanted consequence - lower limit for many factories. (for example "food market?" in pak28.Britain)



Increasing limit in the source file in a solution too. If value of limit is high enough, no new settings entry in simuconf.tab is needed.




Quote from: TurfIt on January 28, 2012, 10:42:10 PM
Why are the input capacities so small? would presume the intent would be for deliveries to be made with small capacity vehicles then too. i.e. the vehicle and factory capacities need to be considered together when balancing the pak.
If the pak is created with small factory capacities, one must presume that's on purpose. So why should the game code override that design with an effective huge (15000) storage?

The huge storage limit (not capacity)  enables to enforce correct production/consumption rate. Having low limit enables player to transport much more items to destination (than is needed by factory) as items are thrown away. Such a behavior of destination factory looks like as a "black hole" instead of just in time.


Quote from: prissi on January 28, 2012, 10:59:52 PM
The factories in pak128 have this limit since their beginning. The ore mine is almost impossible to be saturated using trucks.
It nicely shows differences between road and railway transport.

TurfIt

Quote from: jk271 on January 28, 2012, 11:32:41 PM
The huge storage limit (not capacity)  enables to enforce correct production/consumption rate. Having low limit enables player to transport much more items to destination (than is needed by factory) as items are thrown away. Such a behavior of destination factory looks like as a "black hole" instead of just in time.
Ah yes, for destination factories high storage limit works this way. However for intermediary factories, like the steel mill, a low limit would help enforce the correct delivery rate. Having a high limit here allows the player to transport way too much, and stockpile way over the storage capacity for later use. Whereas a low input limit would trigger throwing away the excess iron/coal and hence lose out on steel production.

Making the storage capacity a hard limit and disallowing convoi unloading when factory/station full seems the 'best' solution so far...

isidoro

Just an idea:  why not free space reservations?

Example: coal mine and power station.  Two players (A and B) linking both:

           CA (station player A) ============== PA (station player A)
Coal mine                                                             Power station
           CB (station player B) ============== PB (station player B)



       
  • The coal mine produces at its pace and fills CA and CB store space, but not a single ton more.
  • A vehicle of player A reserves space at PA and loads only the amount of coal corresponding with the reserved space
  • The vehicle goes to PA and always find space to unload because it previously reserved it
  • The same for player B
  • The power station takes coal from PA and PB to fill the internal buffer, which is also a hard limit
This way, storehouses would make sense.  Materials only occupy real physical space.

VS

Please do not consider pak128 as something set in stone - I (finally!) know that these numbers are wrong, I'm just waiting to see how this is resolved.

I think vehicles could unload cargo to station first and let it flow to factory as the internal storage is freed (reverse process to filling station from industry). And wait for unloading everything. Thus the complete unloading chain would be vehicle->station->industry. That would solve the problem with many vehicles arriving at once, they would simply have to wait. Also, one more reason to build warehouses, if you want to have the vehicles leave faster. However, this is quite a change... In the end, do as you see fit.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!