The International Simutrans Forum

 

Author Topic: Suggestion for JIT mechanics revision.  (Read 57394 times)

0 Members and 1 Guest are viewing this topic.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #140 on: December 02, 2014, 11:18:15 PM »
Quote
To the papermill issue - In my (theoretical) version of JIT2 this was dealt so that - in case of non-producing factory - inputs are ordered only if they are not in stock at all. In other words, if there are some goods in input, and the factory is not producing, there is no need to order more. The reason for not producing might be either lack of other inputs or full output.
No that is not the way they work because that would stall the freight pipe-line. It orders exactly at the rate of consumption independent of what is actually consumed. It might take a long time for goods to reach the factory in which case a large in-transit amount will build up however when they do arrive it should mostly be a continuous production chain with goods arriving as they are consumed. If the output is fill it does not order anymore because it is producing nothing (in which case the in-transit amount will eventually cause an overflow to occur as it collapses). If you stop one of the goods then it will keep trying to order that good (and all other goods) at the rate of consumption until the demand buffer caps out (demand buffer equals the maximum storage). Other goods may overflow during this time but that is the result of a pipe-line stall rather than incorrect ordering logic (its ordering the right amounts, just suddenly nothing is being delivered for one of the goods). It cannot be abused because always you will ship more fulfilling the demands properly so that production is constant.

Quote
If you dont want to change that, you can set max demand to some low value. Some time ago I have fiddled with one of the early versions of JIT2 patch, and modified it so that the input buffer max was always 10 (I used some constant - min cargo amount delivered or something). It worked just fine as with max buffer = max input. It might help in cases like this paper mill.
Yes in this case it would help. In fact the best would simply be set the demand buffer max to the minimum factory storage amount of all inputs (internal units, not readable units) since that way if production was to stall then it would fill up at an appropriate amount and avoid excessive overflow due to the storage imbalance. However if you actually tried to keep the paper factory working as opposed to trying to find faults with the order logic it makes no difference still it will still order at exactly the same rate. It also is no worse than JIT1 where you could get a factory flooding itself with 15,000 units of coal and overflowing the hard maximum just because you connected it to a lot of coal mines far away.

One could also ask why a paper mill stores 3 months of chemicals yet not even 1 month of pulp-wood in a JIT driven market... As I stated it could also be something for pak authors to consider in future since currently most paks were designed with over-sized input storage to accommodate the bursty floods of JIT1 (pak64 seems an exception with large factories/consumers often having too smaller input storage for their production rate).

Quote
With the code stabilising, maybe one should consider consolidate the single and multiple into the same routines?
I thought this was already done until yesterday when I noticed that the original code was still being used while tracking down the source of the problem. I could possibly prepare it over the next few days.

It would be very useful if people could test the multiplayer stability of the feature. Instead I still see game severs running legacy builds.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #141 on: December 06, 2014, 06:30:00 PM »
I have revised the code a bit as requested. All single input/output logic has been removed, being replaced with usage of the multiple logic (which was tested to be working fine). I also pulled out some constants and documented them for possible later adjustment. The logic for scaling output production in JIT2 was pulled out and turned into a separate method to reduce code duplication. The result was the removal of a considerable number of lines and hopefully will produce smaller code as well.

I also got fed up with some of the compile warnings that were being thrown at me during debugging. As a result I took an attempt at fixing them (simply adding explicit casts in most cases). These do not have to be included or could be a separate commit. The JIT2 revision was only with the factory cpp/h files, all other files were these warning fixes.

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #142 on: December 08, 2014, 09:54:27 PM »
I have a few more bugs for JIT2 (r7403). In the game I play I have one hardware factory (planks+steel = hardware). It was producing at 100%, but there were more shops and oversupply of planks and steel so I decided to connect it to power. I expected that the production will go up from 572 to about 1000 (consumers total 1080). But it went up only to some 700. When you watch the info box, you will notice that the factory often runs out of planks, even though the sawmill can supply much more. If you watch carefully, you will notice that it orders less planks than it consumes. Sometimes it "forgets" to increase the demand counter.

Another is mentioned earlier with screenshot - I have 4 printworks. 3 of them (bunched together) produce books and newspapers at almost 100% and consume also almost 100% paper. But the fourth one (not electrified), produces only books, but consumes too much paper: 381 boxes/month to make just 152 boxes/month of books. As the production says input 100% paper, output 80% news, 20% books, which totals 100%, I would expect 1:1 ratio for consumed paper and produced books, if no newspapers are printed.

Save game is here: https://uran.webstep.net/~vladki/simutrans/autosave01.sve

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #143 on: December 09, 2014, 12:44:46 AM »
Quote
But it went up only to some 700. When you watch the info box, you will notice that the factory often runs out of planks, even though the sawmill can supply much more. If you watch carefully, you will notice that it orders less planks than it consumes. Sometimes it "forgets" to increase the demand counter.
That is not what I am experiencing. The Hardware Factory has more than enough planks and always has planks in storage but is lacking steel. The two steel mills cannot produce enough steel to supply it (one of them has insufficient coal supply). JIT2 mechanics will only place orders for factories if none of the inputs is under supplied (demand counter exceeds input storage). Since there is too little steel, the plank ordering will be bottlenecked at the rate of steel ordering.

Depending on the transport infrastructure used, there is a chance that there may be steel and no planks. However this time is meaningless since it fits into the production lost due to insufficient supply (the factory cannot always be working as there are not enough resources available). If sufficient steel was to be provided so that demand was satisfied then eventually both a plank and steel buffer would build up at the factory and it will operate at 100% (or less if the product is over supplied).

Quote
Another is mentioned earlier with screenshot - I have 4 printworks. 3 of them (bunched together) produce books and newspapers at almost 100% and consume also almost 100% paper. But the fourth one (not electrified), produces only books, but consumes too much paper: 381 boxes/month to make just 152 boxes/month of books. As the production says input 100% paper, output 80% news, 20% books, which totals 100%, I would expect 1:1 ratio for consumed paper and produced books, if no newspapers are printed.
That is due to the definition used for the cost of an output. Each output is assigned an equal share of the factory work done (in this case 50% of the consumption will go to each product). This means that 764 units (the amount of paper consumed if producing at 100%) will get split into 382 paper each output (764 / 2). Since books are produced at 20% of the production rate only 152.8 books will be produced (764 / 5). These match the values both you and I experience in game so the system is operating as intended.

This even makes logical sense. If you look at the product weights of newspaper (50 kg) and books (900 kg) each newspaper unit must obviously use less paper units than books. Sure the amount is not balanced perfectly (no way to adjust output weights, not that any pakset would use that feature immediately anyway) but it makes more sense than a newspaper using as much paper as a book. Eventually weight adjustment support could be added however for most cases equal weighting will work.

EDIT : In case it was missed, I did attach a JIT2 revision above which simplified some of the code a bit.
« Last Edit: December 09, 2014, 01:00:35 AM by DrSuperGood »

Offline Václav

  • Devotee
  • *
  • Posts: 3325
  • formerly VaclavMacurek
  • Languages: CZ, EN
Re: Suggestion for JIT mechanics revision.
« Reply #144 on: December 09, 2014, 05:26:52 PM »
I enabled JIT2 from game - through (hidden) game setting dialogue - to test it.

It is good that JIT2 decreases energy consumption in some cases (under JIT1 net calls 1025MW, with JIT2 it calls only 593MW) but currently (with nightly 7408) it leads to break in production of all factories (it means that factories stop production even if they have no reason to do that).


I beg your pardon if I missed topic - and placed this question here, instead bugs board.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #145 on: December 09, 2014, 06:01:27 PM »
Quote
It is good that JIT2 decreases energy consumption in some cases (under JIT1 net calls 1025MW, with JIT2 it calls only 593MW) but currently (with nightly 7408) it leads to break in production of all factories (it means that factories stop production even if they have no reason to do that).
I already explained why this is happening ages ago. Live conversion is not supported due to a lack of ability to re-compute critical values. You can convert a map following these simple steps.
  • Enable live changing of game constants using hidden menu function.
  • Open JIT0/1 map you want to convert.
  • Change the constants of the map so that "JIT = 2" and "Maximum In Transit = 100". The in transit limit is used to clamp the garbage values that are saved.
  • Save the map. Use a different name to prevent loss of data in case an error happens.
  • Load the freshly saved map.
  • Change the constants of the map so that "Maximum In Transit = 0".
  • Save the map. Use the same name as the previous save as this is now the converted file.
  • Load the map a last time and conversion is done.

When resuming the save so that JIT2 works you may need to load it once, change it back to JIT2 and then reload it so that it loads JIT2. I am not sure why this is necessary but it is along the lines of the constant not saving due to it being a nightly.

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #146 on: December 09, 2014, 09:58:01 PM »
@DrSuperGood: thanks for explanation. Printworks are now clear to me.

However the problem with steel seems so be very strange.
The map has just enough coal supply (+32t) as demanded by steel mills and power plant. It is the iron ore that is in short supply (-216t), so I would expect the stell mill to run out of ore, not coal. Maybe the deliveries are not smooth enough, I'll try to optimize.

I still see the hardware factory to run out of planks, not steel. Just watch the game longer. I think the problem is here: there is indeed shortage of steel (and abundace of planks). The demand counter for steel will sooner or later hit the maximum, while planks demand will be satisfied most of the time. But when stell counter is at max, planks counter will not grow either (and stay negative). Then when some batch of steel is available it is sent, but without the accompanying batch of planks. Thus the factory will always have some steel in input storage, but run out of planks. Perhaps the same is happening in the stell mill.

I think the logic when to stop orders needs some more thought. If I understand corectly now it is so that the orders stop if any input demand counter is at max. I would recommend to stop orders when the relevant input is full - it won't be for long - only until production is resumed. This will also quickly solve the previous issue with paper mill (only one input supplied). Oversupplies are discarded so the input cannot be overrun, and thus the time to recover will be short, and hopefully some stuff wil be still in transit.

The issue with supplying only one input on multiple factories was not an attempt to "cheat". But usually if having such a factory, you start by bulding supply links one by one. If the factory orders too much extra, you get money for nothing (and can use it to fund the remaining links.). Normally such link should stop deliveries quickly until you deliver the rest of required inputs.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10828
  • Languages: De,EN,JP
Re: Suggestion for JIT mechanics revision.
« Reply #147 on: December 09, 2014, 11:05:47 PM »
I did not submit the full warning patch, since some of the conversions are rather compiler dependent. I mainly look at MSVC, Dwachs uses CLang (I think) and then there is gcc is different flavours. Those three all differ broadly in fuzzyness, epcecially when conversions and signedness is concerned.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #148 on: December 10, 2014, 01:09:28 AM »
Quote
It is the iron ore that is in short supply (-216t),
That means it is in oversupply. Negative demand means it has fully satisfied demand (it is demanding a negative amount or nothing at all). Such a large satisfaction number could be the result of a conversion artefact or an oversized shipment or even just a transient result as the system stabilizes.

Positive numbers mean there is a demand. If a steel mill has +32t coal that means it is trying to order an extra 32t of coal but is struggling to as the connected suppliers have none available for shipping.

The reason + represents demand and - over supply is that it makes sense next to the in-transit amount. Demand wants to try and add to the in-transit amount while oversupply appears to want to take away. I thought it would be more logical but I am hardly a UI expert. Then again it took me weeks to understand JIT0/1 simutrans industry metrics so I guess this is no surprise.

Quote
But when stell counter is at max, planks counter will not grow either (and stay negative). Then when some batch of steel is available it is sent, but without the accompanying batch of planks. Thus the factory will always have some steel in input storage, but run out of planks. Perhaps the same is happening in the stell mill.
It will always be negative because it is fully satisfied. The only time demand counters should be positive and larger than 10-20 is if there is insufficient supply. Both steel and planks appeared to be ordered at the correct rate matching each other.

Quote
I think the logic when to stop orders needs some more thought. If I understand corectly now it is so that the orders stop if any input demand counter is at max. I would recommend to stop orders when the relevant input is full - it won't be for long - only until production is resumed. This will also quickly solve the previous issue with paper mill (only one input supplied). Oversupplies are discarded so the input cannot be overrun, and thus the time to recover will be short, and hopefully some stuff wil be still in transit.
There are two order logics. Factories order all inputs in appropriate quantities to assure continuous production (+/- some rounding error). Eventually oversupply should self-correct due to the overflow mechanics with only the odd fractional unit of production being lost at most. It is completely pointless ordering more product if you cannot order more of another of the inputs since you need all inputs to produce something as a factory. If your proposal was implemented it would start the issue of a pipe-line collapse continiosuly and basically revert mechanics back to JIT1.

Consumers order each input separately and will do so all the time except when demand counter maxes out in which case consumption will be lost (as expected for insufficient supply).

Quote
The issue with supplying only one input on multiple factories was not an attempt to "cheat". But usually if having such a factory, you start by bulding supply links one by one. If the factory orders too much extra, you get money for nothing (and can use it to fund the remaining links.). Normally such link should stop deliveries quickly until you deliver the rest of required inputs.
Which is what they do if you start a map in JIT2 mode/found new industries in JIT2 mode where all demand counters default to max (so a factory cannot order more until all inputs are starting to be supplied). The issue with the paper mill is purely if a supply is suddenly cut or if you are using a converted map. In the case of cut supply it is obvious it will happen and hardly abuse able (you still make more money supplying everything). In the case of conversions (the paper mill) then it will eventually correct the demand counters so that the correct amount of product is arriving (none at all in your example as there were no chemicals being supplied).

Quote
I did not submit the full warning patch, since some of the conversions are rather compiler dependent. I mainly look at MSVC, Dwachs uses CLang (I think) and then there is gcc is different flavours. Those three all differ broadly in fuzzyness, epcecially when conversions and signedness is concerned.
The corrections were made for MSVC (an oldish version now, need to update...) and should not suffer fuzziness anymore than before since all conversions are explicitly defined. Currently they are only implicitly defined relying on the C++ standard to do them correctly (which normally it will since they are hardly ever in borderline conditions).

That said I did spot a number of alarming numeric range discrepancies with some functions. For example maintenance being returned as 64 bit but added to players in 32 bit which I would view as a specification error (no explicitly defined range for the numbers resulting in a single usable type for the situation). Another was that the storage type list only uses 8 bit indices yet the number of storage types is returned as 16 bits which implies from an interface point of view that there can be storage types not accessible (rage mismatch). However these are non-critical and should probably be fixed when/if the code is revised.

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #149 on: December 10, 2014, 07:30:23 AM »
The numbers I posted (-216 for iron ore and +32 for coal) are not demand counters, but sum of mine production - sum of stell mill (and power plant) production. So there really is shortage of iron ore and slight oversupply of coal, but the steel mill behaves as if it were the other way round.

For stopping orders, I wanted to say - stop orders only if the relevant demand counter is maxed out or if the relevant input is full. This will allow the factory to build some storage of all goods and be prepared for the moment where the last missing input is delivered. Demand counters should not affect other inputs. Now you order even if input is full, and stop ordering if other inputs demand is at maximum, that's IMHO wrong and causes the effects I experience. BTW the paper mill with chemicals was spawned long after converting the game to JIT2.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #150 on: December 10, 2014, 03:24:54 PM »
Quote
The numbers I posted (-216 for iron ore and +32 for coal) are not demand counters, but sum of mine production - sum of stell mill (and power plant) production. So there really is shortage of iron ore and slight oversupply of coal, but the steel mill behaves as if it were the other way round.
It is not like that in the save you sent me. You are using 2 steel mills linked to the same 3 coal mines which are exclusive suppliers. Each coal mine produces exactly 1,124 tons/month of coal. This means your total coal supply is 3,372 tons/month.

One of your steel mills is un-powered and consumes 1,496 tons/month while the powered one consumes about 2,744 tons/month. Since both inputs are at 100% this means both require 4,240 tons/month of both coal and iron ore to operate fully. This means you are 868 tons/month (4240-3372) short on coal for 100% production.

However with iron ore you also have 3 mines but each produces 1,344 tons/month. This sums to 4,032 tons/month. When compared with the steel mill production this means that you are short 208 tons/month iron ore.

However since you are short 868 tons/month on coal the iron ore shortage does not mater since the coal will bottleneck steel production and the iron ore will remain satisfied (since it is not under supplied for the supply of coal provided).

Since the steel mill production is not equal (powered vs no power) but distribution is the powered steel mill will be bottlenecked more than the unpowered one. Running the game several months while I wrote this proved these results with the unpowered steel mill working at 100% while the powered steel mill is bottlenecked by coal as predicted above. Due to a lack of steel the hardware shop slowly builds up a steel demand which will limit production.

Anyway while running this test I noticed a pretty major error. At the beginning of the year the JIT2 flag is reset to JIT1! Yes new year starts and boom suddenly from JIT2 it is running in JIT1. This is not meant to happen.

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #151 on: December 10, 2014, 03:57:06 PM »
The powered steel mill is connected to one more coal mine on the other side of map

Sent using recycled electrons.


Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #152 on: December 10, 2014, 05:57:36 PM »
Quote
The powered steel mill is connected to one more coal mine on the other side of map
That is the problem, it appears to not be connected to it. That coal mine is not sending anything to the steel mill so the steel mill is running out of coal. The map is so confusing it is hard to track down the links the coal should be taking.

The cause appears to be due to corrupted pakset information. The boats used to move the "bulk" from that mine do not exist properly so cannot move bulk. As such the coal mine is not connected to the steel mill. I will try and reload the save with the latest pak128 Britain but am getting assertion errors trying to do so with the latest nightly.

EDIT:

Sorry but I cannot load your map without errors. You are not using a standard build of pak128 Britain. As such every time I try to load it I get missing convoy errors which break the lines. Specifically 1.14 lacks the barge needed for the coal mine in the other side of the map and 1.15 lacks the trains used to ship the bulk between stations.

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #153 on: December 10, 2014, 06:41:46 PM »
I will post the paks i use when i get home. I have fixed the coal boat. There was a bug in dat file.

UPDATE: Necesary addons are here: https://uran.webstep.net/~vladki/simutrans/addons.zip
Other wise use the pak128.britain 1.14, the game does not work well with half-height versions.

« Last Edit: December 11, 2014, 07:34:32 PM by Vladki »

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #154 on: December 12, 2014, 04:30:54 AM »
Quote
Other wise use the pak128.britain 1.14, the game does not work well with half-height versions.
I was using 1.14 but I lacked your addons. Now it works fine.

Quote
The numbers I posted (-216 for iron ore and +32 for coal) are not demand counters, but sum of mine production - sum of stell mill (and power plant) production. So there really is shortage of iron ore and slight oversupply of coal, but the steel mill behaves as if it were the other way round.
That is because you are delivering coal too inconsistently. Shipments larger than the input storage arrive causing an overflow (which becomes lost demand). The result is the steel mill working sub optimally due to an under supply of coal. In other words the steel mill is applying a penalty for bad delivery service (the huge goods train delivering to a tiny shop problem).

If you were to increase service frequency it should solve the problem. Alternatively it could be considered a pakset error (the input storages are too small for the type/production quantity).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #155 on: December 12, 2014, 06:38:35 AM »
Shipments larger than the input storage arrive causing an overflow (which becomes lost demand). The result is the steel mill working sub optimally due to an under supply of coal. In other words the steel mill is applying a penalty for bad delivery service (the huge goods train delivering to a tiny shop problem).

I still blame this on the consumer ordering too much, although I do see how complicated it is "making the consumer smart enough" to avoid this completely (in a transportation graph that can be almost infinitely complex).

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #156 on: December 12, 2014, 02:45:27 PM »
Quote
I still blame this on the consumer ordering too much, although I do see how complicated it is "making the consumer smart enough" to avoid this completely (in a transportation graph that can be almost infinitely complex).
The most correct solution involving average travel time and the ability to regulate how much is unloaded from a stop would be to apply an artificial bottleneck on the last step loading. If you have a massive 1,000 unit transport loading into a 250 unit storage then it would allow only at most 250 units to be loaded in that transport. Based on average travel time it could then approximate how much can be loaded at the last stop so that when it arrives at the destination it will unlikely overflow. Transfer restrictions could do the rest. This is converging on what Experimental aims to do (although that is slightly buggy at times) where it uses the maximum in-transit value summed with current storage as a demand buffer without the ability to overflow storages.

However as you can see, that would be excessively complicated to implement.

JIT2 was not meant to be perfect, it was only intended to be a dramatic improvement over JIT1. In JIT2 in a properly functioning network it is impossible to get your coal power station buried in coal and then run dry because shipments fail to arrive in time before the storage depletes. JIT2 also implements dynamics that you need an appropriately sized convoy for deliveries, a concept that was not particularly emphasised before. The main issue is that some input storages might be too small since they were never really that important and balanced for JIT2 (the pak64+food marketplace is a good example where its tinned food storage is less than the minimum 2050 transporter available).

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: Suggestion for JIT mechanics revision.
« Reply #157 on: December 13, 2014, 07:56:14 AM »
JIT2 was not meant to be perfect, it was only intended to be a dramatic improvement over JIT1. In JIT2 in a properly functioning network it is impossible to get your coal power station buried in coal and then run dry because shipments fail to arrive in time before the storage depletes. JIT2 also implements dynamics that you need an appropriately sized convoy for deliveries, a concept that was not particularly emphasised before. The main issue is that some input storages might be too small since they were never really that important and balanced for JIT2 (the pak64+food marketplace is a good example where its tinned food storage is less than the minimum 2050 transporter available).
Could free station storage at the station the payload is delivered to counted towards input storage? Or would this remove the need to have appropriately sized convoys as a game element?

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #158 on: December 13, 2014, 08:48:00 AM »
Could free station storage at the station the payload is delivered to counted towards input storage? Or would this remove the need to have appropriately sized convoys as a game element?

The biggest issue with this is that it is a new concept in the simulation. The way I understand it, stations are passive, they don't do anything, so industries would have to start polling stations for goods, rather than having it dumped into storage by the vehicles. Then there is the issue if stations are able to hold cargo not destined for another station, and adapting the GUI to show such things without confusing players.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #159 on: December 13, 2014, 04:45:39 PM »
Quote
Could free station storage at the station the payload is delivered to counted towards input storage? Or would this remove the need to have appropriately sized convoys as a game element?
That is the concept of a warehouse and has been discussed before. Although I agree it would be useful, especially for unstable lines in the end it should make no difference. If a pakset is properly balanced so that input storage is suitable for available transport options then everything should be arriving just in time and work.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #160 on: December 13, 2014, 05:24:19 PM »
If a pakset is properly balanced so that input storage is suitable for available transport options then everything should be arriving just in time and work.

It is rather silly that input storage is less than a single vehicle. I guess the thing here is that what can be put in a single vehicle in 2000, might be too much to have in storage in 1900. Especially for goods that are consumed at a slow rate, but go bad faster without refridgeration or similar. So it's another issue cause by lack of in-place industrial evolution in Simutrans.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #161 on: December 14, 2014, 12:04:32 AM »
Quote
It is rather silly that input storage is less than a single vehicle. I guess the thing here is that what can be put in a single vehicle in 2000, might be too much to have in storage in 1900. Especially for goods that are consumed at a slow rate, but go bad faster without refridgeration or similar. So it's another issue cause by lack of in-place industrial evolution in Simutrans.
It is perfectly fine that in the old years you can expect factories to have considerably larger storages compared with the shipment unit. In the old days some large industries had enough material stored to operate for several months without shipments. It is only a very recent trend with the rise of computers that a bare minimum is kept in storage on site. The most notable example would be a car factory in the 1950s would have storage for many months yet a car factory in 2014 stores only enough for a few days of operation.

The main issue is that the storage sizes of some places are unrealistically small. The best example is the pak64 + food marketplace which stores only 25 canned food at times. The smallest you can ship boxed goods in 2050 is 40 units odd. Yes the building is old but it consumes a fair amount monthly. Raising it to 80 units storage is a lot more acceptable since it gives a reasonable buffer time for trucks. Yes the building is old but its rate of consumption is not and if anything such a high consuming old building should easily be able to accept the unloading of a single truck at least.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #162 on: December 14, 2014, 09:54:17 AM »
The main issue is that the storage sizes of some places are unrealistically small. The best example is the pak64 + food marketplace which stores only 25 canned food at times. The smallest you can ship boxed goods in 2050 is 40 units odd. Yes the building is old but it consumes a fair amount monthly. Raising it to 80 units storage is a lot more acceptable since it gives a reasonable buffer time for trucks. Yes the building is old but its rate of consumption is not and if anything such a high consuming old building should easily be able to accept the unloading of a single truck at least.

Since it's canned food in particular, it's a bit odd, given how it won't rot overnight, or even for months. Had it been fresh meat, then having a storage capacity much less than monthly consumption would make sense before about 1950.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #163 on: December 14, 2014, 01:41:04 PM »
Quote
Since it's canned food in particular, it's a bit odd, given how it won't rot overnight, or even for months. Had it been fresh meat, then having a storage capacity much less than monthly consumption would make sense before about 1950.
The reasoning was probably because it was consumed slower. The result was the following definition...
Code: [Select]
InputGood[0]=fish
InputCapacity[0]=50
InputSupplier[0]=0
InputFactor[0]=50
InputGood[1]=flour
InputCapacity[1]=50
InputSupplier[1]=0
InputFactor[1]=50
InputGood[2]=beer
InputCapacity[2]=200
InputSupplier[2]=0
InputFactor[2]=100
InputGood[3]=canned_food
InputCapacity[3]=25
InputSupplier[3]=0
InputFactor[3]=25

In the case of JIT2 these values would be more appropriate for the building.
Code: [Select]
InputGood[0]=fish
InputCapacity[0]=120
InputSupplier[0]=0
InputFactor[0]=50
InputGood[1]=flour
InputCapacity[1]=120
InputSupplier[1]=0
InputFactor[1]=50
InputGood[2]=beer
InputCapacity[2]=160
InputSupplier[2]=0
InputFactor[2]=100
InputGood[3]=canned_food
InputCapacity[3]=80
InputSupplier[3]=0
InputFactor[3]=25
(this is an example, not a change suggestion)

Note that this was done with eye only. Better results might be achieved by careful planning and possibly even a formula. The idea is for the input capacity to have at least enough to receive 1 "appropriately" sized shipment and use that as the starting point. For the market place this a truck of food. For something like a steel mill a 4-6+ tile long bulk train would be appropriate. You then multiply it by some amount to add robustness to the supply flow (to cope with variances of signals/traffic etc). Goods that are consumed slowly (canned food in marketplace) can be multiplied less since each unit represents more variance in time. Goods that are consumed very quickly (beer in marketplace) need to be multiplied by more as each unit of storage represents less resilience time.

The amount of resilience time desired depends on how "difficult" you want supplying an industry to be. Something like a coal or oil fired power station could be given a large resilience to be realistic (since they are designed to never stop working, possibly even running months without shipments). On the other hand the above marketplace could be given very little resilience to represent spoilage (especially of frozen goods!) so it requires a very efficient and precise network to deliver.

Currently many industries in pak64 have quite small input storages so may struggle to operate 100% of the time under JIT2 mechanics (the marketplace being the example which is impossible). On the other hand industries in pak128 have massive input storages so are very difficult to not supply them properly (a cement factory holds 8,000 tons of coal, enough for several standard months of operation so can accept multiple of any shipment size even in unpredictable transport times).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #164 on: December 14, 2014, 02:29:03 PM »
Let's say that a marketplace sells 1 barrel of fresh fish per day irrespective of the year (constant number of customers with constant taste for fish). That means that it must have storage for 1 barrel of fresh fish in 1900. At that time, one horse-drawn carrige, carrying on barrell of fish arrives from the fishery each day. But by 1950, refridgerated storage is available, so fresh fish can be kept in storage longer. So you get trucks carrying 10 barrels of fish, and the horse drawn carriges become obsolete, not just because of lesser capacity, but also because of their below average speed causing traffic jams.

The only ways to integrate the new trucks with the old marketplace, is either to give the marketplace an unrealistically high storage capacity in the past, or let the input storage overflow in the present (and technically also in the past, but the low capacity of the vehicles then makes this difficult to achive). The former is impossible if the newer vehicles come from an add-on.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #165 on: December 14, 2014, 02:42:54 PM »
Pak64 should not really be played re 1930 odd and trucks should always be present.

The issue you describe is one of the industries not scaling over time. The Marketplace in 2050 (end game time) should be considerably different from that found in 1900 with different demand/storage amounts.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #166 on: December 14, 2014, 02:58:21 PM »
The issue you describe is one of the industries not scaling over time. The Marketplace in 2050 (end game time) should be considerably different from that found in 1900 with different demand/storage amounts.

That's what I wrote several posts ago.

Pak64 should not really be played re 1930 odd and trucks should always be present.

I like starting out in the second half of the 19th century, or there is hardly any evolution in vehicles at all. It peaks at about 1950, and by late 1970 it's pretty much over. (Which seems true to life with regards to capacity and speed.) Road transport before 1930 is awful, but then I find road vehicles a necessary evil later on as well. (Too much to transport, too small vehicles and too small capacity at stops.)

Offline Václav

  • Devotee
  • *
  • Posts: 3325
  • formerly VaclavMacurek
  • Languages: CZ, EN
Re: Suggestion for JIT mechanics revision.
« Reply #167 on: December 14, 2014, 05:52:15 PM »
I found that with JIT2 powerplants do not produce power on the same level at all times - even if they have sufficient amount input good to work. Their production alterates between 100 and 99.

And trains' max. speed alterates too (again) - between moment max. speed and moment max. speed +1.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #168 on: December 14, 2014, 06:35:55 PM »
Quote
Their production alterates between 100 and 99.
That is because of rounding. Their power output is scaled based on their work done so unfortunately rounding applies. Some ticks they consume slightly more than others.

Quote
And trains' max. speed alterates too (again) - between moment max. speed and moment max. speed +1.
Nothing to do with JIT2. Only factory code was changed with this.

Someone else altered those calculations recently so it is probably an error related to that.

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: Suggestion for JIT mechanics revision.
« Reply #169 on: December 15, 2014, 03:05:13 AM »
[...] The idea is for the input capacity to have at least enough to receive 1 "appropriately" sized shipment and use that as the starting point. For the market place this a truck of food.
It might be interesting to re-visit the old idea of having a very number of small end consumers. Art tested a few concepts, i think with pak britain. A few years ago. With large lorries and small consumers one would have to have a warehouse and send convoys to more than one consumer.

Quote
[...] For something like a steel mill a 4-6+ tile long bulk train would be appropriate. [...]
That seems to be quite low, while i don't know pak64 very well, in pak128 I usually start with 6 to 8 tile bulk trains in 1930, and run 12 tile trains as soon as Diesel-electics become available. Especially when it is for a long distance transport over 2000 tiles.

Quote
[...]
You then multiply it by some amount to add robustness to the supply flow (to cope with variances of signals/traffic etc). Goods that are consumed slowly (canned food in marketplace) can be multiplied less since each unit represents more variance in time. Goods that are consumed very quickly (beer in marketplace) need to be multiplied by more as each unit of storage represents less resilience time.

The amount of resilience time desired depends on how "difficult" you want supplying an industry to be. Something like a coal or oil fired power station could be given a large resilience to be realistic (since they are designed to never stop working, possibly even running months without shipments). On the other hand the above marketplace could be given very little resilience to represent spoilage (especially of frozen goods!) so it requires a very efficient and precise network to deliver.
This nicely summarizes the requirements on a pakset to be used with JIT2.

Quote
Currently many industries in pak64 have quite small input storages so may struggle to operate 100% of the time under JIT2 mechanics (the marketplace being the example which is impossible). On the other hand industries in pak128 have massive input storages so are very difficult to not supply them properly (a cement factory holds 8,000 tons of coal, enough for several standard months of operation so can accept multiple of any shipment size even in unpredictable transport times).
The cement mill i knew had very large coal storage it did not use more than 10% of. I supppose in the past they stored much more, buying when prices were low, or supply was easy. It is hard to guess how much could have been piled there, but i expect it would have been at least the equivalent of a dozen trains. Storage was very cheap, only a large level surface and some walls were needed. There was hardly any storage for limestone though. It was just delivered the 2 km from the quarry.

I think the last aspect raises an old question, that became acute with JIT 2. Some industries are always in the vicinity of the required resources. This limits the access to other resources though. (eg since cement mills are near to limestone, they are always far away from coal). With JiT2 more realistic industry placement algorithm becomes desirable. (yet not necessarily feasible).

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #170 on: December 15, 2014, 04:06:56 AM »
Quote
That seems to be quite low, while i don't know pak64 very well, in pak128 I usually start with 6 to 8 tile bulk trains in 1930, and run 12 tile trains as soon as Diesel-electics become available. Especially when it is for a long distance transport over 2000 tiles.
Pak128 is balanced slightly differently. In 1930-1960 my calculations were that it was most economical to ship in multiples of 3. In 2050 you need 15+ tile long trains due to the low density of bulk cars (the post 2000 one is physically larger) and the massive power of engines (anything less is a waste). You can also ship at pretty high speeds using the more powerful engines. That said the break even point is usually 1-2 cars/trucks of bulk so the rest is revenue to offset the high maintenance of pak128.

Pak64 is balanced slightly differently. Unlike pak128 where convoy running cost is very low and the maintenance high, pak64 has low maintenance and high running costs. To put it in perspective you will spend >50% of the income shipping some goods with some goods not being viable for shipment via some means at all (you cannot ship paper at a reasonable speed by road without huge losses post 2000). As such throwing power to move goods fast is often not that profitable (or was, its changed recently since you no longer have that final massive wave of speed bonus penalty). To do this there is a neat little 60km/h engine that is by far the most economical way to move goods like bulk. That engine generally works out convoys in lengths of multiple of 3 size. As such for supplying some industries it might be appropriate to have a convoy length in the form of a multiple of 3 with 12 only being for very high demand industries. It is also worth noting that most trains max out at 12 tiles (2 cars/trucks/engines per tile) with the only exception being car transporters and the one diesel engine which is bigger than 1/2 tiles. In pak128 many goods could produce convoys longer than 12 station tiles at the end with the biggest being ~20 tiles so it is not a good metric for balance.

Where as something like steel mill coal could arrive in train length 6 (since steel mills use less coal), iron ore could be expected to arrive in 12 length convoys (since a steel mill can consumes several thousand units of iron ore a standard month).

Quote
I think the last aspect raises an old question, that became acute with JIT 2. Some industries are always in the vicinity of the required resources. This limits the access to other resources though. (eg since cement mills are near to limestone, they are always far away from coal). With JiT2 more realistic industry placement algorithm becomes desirable. (yet not necessarily feasible).
That would have to be part of a general economic revision. Something like a cement mill might be placed nearby a town (people need to work but not get the pollution) near one of its inputs (distance from the other is irrelevant and not considered). Certain cities could be given types such as industrial or commercial where industrial cities get processing industries (food processor, concrete works, builders yards etc) and commercial cities more consumers (department store, supermarket, etc).

However before such a thing is considered I would recommend revising the entire city growth mechanic based on what I mentioned elsewhere. Founding more cities should not make more total growth and more total industries. Industries should come at a "levelling up" rate based on global population. Total population growth should be based on total transport metrics and starting city number and spread across all towns based on their transport metric weight compared with the total. Industries need a cost weight for generation so that a tiny green energy facility uses "less population up" than a concrete chain.

I have had games turn into industry deserts as all that ever spawned were solar farms due to a lack of initial power placement. Something that really needs addressing...

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5695
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #171 on: December 15, 2014, 06:40:11 AM »
That seems to be quite low, while i don't know pak64 very well, in pak128 I usually start with 6 to 8 tile bulk trains in 1930, and run 12 tile trains as soon as Diesel-electics become available. Especially when it is for a long distance transport over 2000 tiles.

In pak64, I find trains longer than 6-8 tiles overly long compared to the world. (Although very short compared to the locomotive, at least for freight trains.) Power, weight and capacity seems balanced for this as well, but I don't know if that's because the past and present creators also see it that way, or if the thing with 6 tile long trains is just copied from Transport Tycoon. (The maker of Transport Tycoon might himself have found that 6 tiles fits the scale of the world best.)

Offline Vladki

  • Devotee
  • *
  • Posts: 3726
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Suggestion for JIT mechanics revision.
« Reply #172 on: December 15, 2014, 07:40:06 AM »
Supplying more small markets with one truck is a challenge that is much easier with jit2 than before. But you may find out that the truck runs mostly half empty thus never making profit.
Without jit2 it will mostly load goods for one of the markets, run empty along the others. When one market is buried for several months, then another market is chosen. Some markets may never get anything. But with jit2 every market will get its goods on board.

Sent using recycled electrons.


Offline Václav

  • Devotee
  • *
  • Posts: 3325
  • formerly VaclavMacurek
  • Languages: CZ, EN
Re: Suggestion for JIT mechanics revision.
« Reply #173 on: December 16, 2014, 07:50:38 AM »
I found following:

Some factories don't show accepted goods.

I have lines that bring coal to powerplants - there it is right. Coal power plants show how much coal lefts to storage would be empty.

Also I have line that brings electronics to supermarket. Factory stops production because supermarket has full storage (because train brings more electronics than is needed - for long time), but supermarket does not show how much electronics lefts. So I cannot see how much time will pass until next ride of train.


I found that for short time that supermarket had a full storage - but there was only such amount of goods that storage can contain - but where is the rest? (it means if train brings 759 - and storage of supermarket may contain 15 - where is 745 units?) And train earnt as money as it should (currently about 840 thousand). It is very strange.
« Last Edit: December 16, 2014, 09:22:57 AM by Václav »

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Suggestion for JIT mechanics revision.
« Reply #174 on: December 16, 2014, 04:31:35 PM »
Quote
So I cannot see how much time will pass until next ride of train.
I need a screenshot as it should be there. The form used is the following...

current amount/max amount : in-transit(+/-demand buffer)

current amount is always less than or equal to max amount and never less than 0.
in-transit has no reasonable limit and is always natural.
when demand buffer is greater than or equal to 0 goods will be ordered and in under supplied situations it will max out at ~max amount.

Quote
I found that for short time that supermarket had a full storage - but there was only such amount of goods that storage can contain - but where is the rest? (it means if train brings 759 - and storage of supermarket may contain 15 - where is 745 units?) And train earnt as money as it should (currently about 840 thousand). It is very strange.
Overflowing storages is not allowed in JIT2. A tiny shop just cannot hold more than 15 units at a time as their property is not big enough. One has to imagine that the rest of the 759 units is thrown away or sold elsewhere and to represent that the shop gets a demand penalty equal to the overflow. This mechanic was necessary so that a demand penalty could be created based on the amount overflowed. If you want something to work at 100% you have to respect the fact that you cannot use a 12 tile long train to deliver to a tiny corner shop.

That said many industries were balanced around JIT1 so do not have appropriate max amounts. This is something for pakset authors to consider once JIT2 gains popularity (if it does). Every input should at least be able to receive 1 full load from a end-game convoy. There should also be some buffer amount based on rate of consumption to allow for variances in delivery time.