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

0 Members and 1 Guest are viewing this topic.

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #35 on: August 11, 2014, 08:57:38 PM »
Hi DrSuperGood,

finally I've got time to read this thread carefully and try out you patches. (Compiling on Linux now). I'm really glad you did the coding. I have a few suggestions. Your system is really very close to mine - i think we should join forces and take the best of them. I' try to describe an improved demand counter algorithm:

1. I suggest separate demand counters (and switch), for each input good.
2. decision when to increment the buffer:
- if the factory is producing and input is not over limit - increment by amount consumed
- if the factory is producing and input is over limit - increment by 50% of consumed amount (+1 I really like this - thats big improvement comapared to my original proposal)
- if the factory is not producing and input is empty - increment by possibly consumed amount (with or without power/pax/mail boost)
- if the factory is not producing and input is not empty - do not increment (this means that factory cannot produce because its consumers are overcrowded, or that it does not have all needed input goods available)

3. further improvements could be made in the algorithm when produced goods get their destination. The current behavior is that the goods go to the factory that has the least cargo waiting on the station. I recoomend sending it to the one with highest demand buffer.

4. Demand buffer should be initalized at its max value, equal to max input storage. I think it is sensible for real world factory to begin by ordering full storage...

Compilation is done - I got this warning, if you are interested:

===> CXX simfab.cc
g++ -O3 -minline-all-stringops -DNDEBUG -DREVISION="7287M" -Wall -W -Wcast-qual -Wpointer-arith -Wcast-align  -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DCOLOUR_DEPTH=16 -c -MMD -o build/default/simfab.o simfab.cc
simfab.cc: In function 'sint64 convert_goods(sint64)':
simfab.cc:65:95: warning: suggest parentheses around '-' inside '<<' [-Wparentheses]
simfab.cc: In member function 'void fabrik_t::step(uint32)':
simfab.cc:1393:77: warning: suggest parentheses around '-' in operand of '&' [-Wparentheses]


Now I'm going to open my game and see the improvements.




Leartin: your approach of establishing the link with exact capacity is fine as long as you have dedicated links between factories, especially trucks. But it completely fails if you deliver goods for multiple factories in one train. Then you need more capacity but cannot choose which goods you are loading. This system could help in such cases.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8823
  • Total likes: 323
  • Helpful: 229
  • Languages: De,EN,JP
Re: Suggestion for JIT mechanics revision.
« Reply #36 on: August 11, 2014, 09:13:38 PM »
Quote
2. decision when to increment the buffer:
- if the factory is producing and input is not over limit - increment by amount consumed
- if the factory is producing and input is over limit - increment by 50% of consumed amount (+1 I really like this - thats big improvement comapared to my original proposal)
- if the factory is not producing and input is empty - increment by possibly consumed amount (with or without power/pax/mail boost)
- if the factory is not producing and input is not empty - do not increment (this means that factory cannot produce because its consumers are overcrowded, or that it does not have all needed input goods available)

Essentially this would increase the demand at all times. The case of a factory far away which suddenly becames overvrowded (which why the in transit limitation was introduced) will reoccur when there is demand with an empty factory.

And I would like to try your patches. Where are they. The Simutrans JIT2.zip I cannot download, my provider tells me this is malware ... Please is there a zip with only the patch?

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #37 on: August 11, 2014, 11:19:01 PM »
Essentially this would increase the demand at all times. The case of a factory far away which suddenly becames overvrowded (which why the in transit limitation was introduced) will reoccur when there is demand with an empty factory.
If you really want you can ovecrowd a factory. In-transit limit won't stop you either. But this system is IMHO much more helpful.

Quote
And I would like to try your patches. Where are they. The Simutrans JIT2.zip I cannot download, my provider tells me this is malware ... Please is there a zip with only the patch?
My testing is OK with simple chains, let's see tomoorow on a more complex game. Sources attached.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #38 on: August 12, 2014, 02:51:31 AM »
Quote
1. I suggest separate demand counters (and switch), for each input good.
That is what I did? Each input and output has a demand counter and each input uses their demand counter separately. The reason outputs also have one that is never used or visible is because of poor design decisions (inputs and outputs should extend a production parent type, instead they share members for both of which some are never used).

Quote
- if the factory is producing and input is not over limit - increment by amount consumed
A special case is needed on the tick that consumes the last of the product in storage. This was not modelled as the current factory tick system is rather poorly structured.

Quote
- if the factory is producing and input is over limit - increment by 50% of consumed amount (+1 I really like this - thats big improvement comapared to my original proposal)
Percentage is adjustable. The only problem is no mater what you do it will still run at at-least 50% efficiency. It would be nice if people really messed up that it could reach lower percentages maybe (a hard mode?). However for such a loose definition as Simutrans industry this is the best one can do.

Quote
- if the factory is not producing and input is empty - increment by possibly consumed amount (with or without power/pax/mail boost)
The one I made goes through extensive effort to make sure to order the correct amount. This is especially problematic with power as if the factory has a transformer and is not actually producing anything you have to assume that it has sufficient power and order as if it did.

Quote
- if the factory is not producing and input is not empty - do not increment (this means that factory cannot produce because its consumers are overcrowded, or that it does not have all needed input goods available)
Not as easy as it may sound. Factories will keep producing even without a supplier at a diminishing rate until their output storage is full. Also you still need to order all goods that are consumed in equal ratios unless an overflow is applied. I also implemented this to some extent with the first rule, ordering as consumed, and a special refund case where if the order amount is too large it will scale back the other (under supplied situation).

Quote
3. further improvements could be made in the algorithm when produced goods get their destination. The current behavior is that the goods go to the factory that has the least cargo waiting on the station. I recoomend sending it to the one with highest demand buffer.
It currently chooses them in a round robin fashion out of all the destinations accepting orders. Orders are accepted for the entire duration of a tick to assure fairness (all suppliers given a chance to fulfil order) There is a bias towards some factories as a result of internal order and just how the numbers play out however it should make little difference except under extreme circumstances (there exists a good destination allocation pattern such that all consumers have their orders fulfilled yet this algorithm does not find it).

Quote
4. Demand buffer should be initalized at its max value, equal to max input storage. I think it is sensible for real world factory to begin by ordering full storage...
Initialization does need improvement. I just choose 0 as it is a clean value to test with. The buffer also needs to be saved and loaded.

Quote
===> CXX simfab.cc
g++ -O3 -minline-all-stringops -DNDEBUG -DREVISION="7287M" -Wall -W -Wcast-qual -Wpointer-arith -Wcast-align  -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DCOLOUR_DEPTH=16 -c -MMD -o build/default/simfab.o simfab.cc
simfab.cc: In function 'sint64 convert_goods(sint64)':
simfab.cc:65:95: warning: suggest parentheses around '-' inside '<<' [-Wparentheses]
simfab.cc: In member function 'void fabrik_t::step(uint32)':
simfab.cc:1393:77: warning: suggest parentheses around '-' in operand of '&' [-Wparentheses]
G++ pedantic errors. The code is valid and takes full advantage of the operator precedence of C++ (as defined by the standard) however G++ thinks it needs bracers as it could be I am an idiot and did not read operator precedence so is not executing in the intended order. Visual C++ compiler I used to write the code did not throw this warning which is why I never fixed it. I did not build with G++ so was not aware of it.

Quote
And I would like to try your patches. Where are they. The Simutrans JIT2.zip I cannot download, my provider tells me this is malware ... Please is there a zip with only the patch?
I have no idea how to generate a patch with the git system. I kind of downloaded the source code and hacked away on 2 files which I included in the zip. Unless dropbox somehow infected the zip it should not contain malware (your ISP probably is thinking that the 2 windows executables included are malware which is sad). Anyway I have no idea why I did not think to attach the code files directly here in the first place (it was only these two code files, which appear to be located in the root folder of the project).

In my opinion the entire industry tick function needs to be rewritten. There are too much hacky calculations applied everywhere that it is hard to get a proper industry production and consumption model working.

Of specific note is with factories that produce many output products the amount of raw material consumed is based on the most produced output and not the actual amount produced (especially case if one output is full). Also the outputs are all tied synchronously to the most produced output and do not scale production down in parallel as storage fills up (having a oil refinery using 100% gasoline and barely touching printer ink will result in the printer ink being restored at full production rate despite the output storage never getting near empty). In any case the result is that more product is consumed than is produced which usually means free money (more raw product to ship at a profit).

Same example, Oil Refinery with Gasoline used 100% and Printer Ink used 0-1% (hardly at all).
What is happening now is that it will be consuming oil at its full declared production rate. This is the same amount as if it was producing only Gasoline at 100% and if it was also producing Printer Ink at 100%.
What should happen is that it consumes oil at a reduced rate. This is because only part of the output is working at full power (lost production) so it consumes less.

There are many ways this could be implemented. Simplest is averaging production across all outputs (above example this would give 50% production) however some pak balancers may want different ratios (Printer Ink may use 2 times as much oil to produce as Gasoline so affects consumption rate more).

This is also the case with power where an industry will either use all or nothing. Power used should be based on the amount of work a factory does. This would make power grids a lot more stable as everything will settle to a largely stable base load which more accurately reflect a power fraction (out of maximum power demand).

There needs to be certain quantities defined.
Maximum Production: The absolute maximum amount of effort the factory can output. This is based on things like base production, pax, mail and power fulfilment.
Desired production: The amount of productive effort that is desired based on maximum production. This factors in production scaling down for each output with appropriate weightings and determines the amount to order (base order rate is always at the desired production rate scaled for the various inputs).
Actual production: The amount of production effort actually produced as a fraction of desired production. This is used with scaling and maximum production to determine the amount of product produced.

Maximum production factors in how much of the power demand was fulfilled. Actual production is used to scale power order for the next tick (so it uses only as much power as production done to get full power boost). Power plants need to work differently where their desired production is scaled based on the amount of power consumed (???? not possible ATM) and actual production is overwritten when storage runs empty to represent the amount of power produced from the remaining resources otherwise it is always 1. This would change game dynamics a lot (for the better?) as you can no longer simply supply power stations and expect them to generate electricity for nobody. Although they always appear to generate maximum power when working they will only consume based on what is used so they will reach 100% use when overloaded. Such a change as this fits quite well with the entire flow mechanics idea and JIT systems and even turns power into an industry chain (you need power consumers for power to work).

There should also be different industry flags for pakset authors to change how industries behave.
Synchronous Consumer: This is basically the current factory model, all inputs are consumed synchronously with all stopping if any storage runs empty.
Asynchronous Consumer: This is basically the current end consumers, all inputs are consumed asynchronously in parallel with overall production being lowered if at least one is empty (but not stopped).
Synchronous Producer: Like with the consumer, it is forced to produce synchronously. Factories kind of do this already but there would be stricter limits with a bottleneck occurring if output storage of 1 product is full.
Asynchronous Producer: Basically it fills the output storages as required with maximum production obtained when all outputs are empty all the time.
Power station: Produces power as described above. As long as it is working it will output maximum power but consumption is limited to how much power was used.

So what would these lose flags allow?
Something silly like a hamburger joint might have separate inputs for buns and patties yet require they are ordered synchronously as they cannot server a burger without both. This is currently not possible as the outlet would work at 50% production if 1 of the goods was lacking completely.
Something like a nuclear powerstation could be made to be a Synchronous Producer and Power Plant, meaning that you have to remove the atomic waste from it before it can generate more power.

The overall idea is to generalise behaviour away from hard coded implementations into mix and match flags/attributes you can assign an industry. You could even define other kinds of flags such as...
Shared Demand: All inputs share a common demand (scaled appropriately).
Interchangeable Input: Each input alone can now run the factory at full production if sufficiently supplied (intended with shared demand for a factory which can use 1 of many raw materials to make a product). If not shared demand present then it would order based on least demand.
etc...

Such flags would be a great extension but not directly needed for a production revision.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8823
  • Total likes: 323
  • Helpful: 229
  • Languages: De,EN,JP
Re: Suggestion for JIT mechanics revision.
« Reply #39 on: August 12, 2014, 09:25:50 AM »
The power depends on the production done. You can consumer more or less power. It requires setting on the dat files to use this, otherwise it will just use the default settings for backward compatibility.

Power plants not consuming anything without a consumer would force people to built powerlines. That is somehow against the spirit of simutrans; o.e. you are not forced to do stuff. You can happily do only freight transport, or only passengers, and you can use to ignore power plants.

Obviously one could introduce a setting to force power plants to consumer at reduced rates (10% or so) if no power is demanded.

The suggestion to make the consumption dependent on how much is produced is certainly good. Consuming base on actual total produce instead to a fixed number sound good. However, I am not sure how much it would change in the end. Very few producer produce more than two.

The reason is that Simutrans industry model is "broken" rather in the sense it does not really guess very well what industries are needed next. Producer with too many output are very hard to balance so all outputs can be used.

There have been quite few attempts to work a that out over the years. But in the end the whole options (crossconnect all/decidated connections/production increases by power/very complex factories in pak128) make this almost impossible to improve beyond what is there now. (Which is not far from what was done in the very beginning.)

I do not think the synchronous end consumer will happen that much that you have to worry about it. Simutrans is already conplex, and there can be too much complexity for too little gain.

Imho most gain would be a patch to base the consumption on the actual output if there is more than one good (implementation like by consuming per each good separately).

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #40 on: August 12, 2014, 06:40:28 PM »
Quote
Power plants not consuming anything without a consumer would force people to built powerlines. That is somehow against the spirit of simutrans; o.e. you are not forced to do stuff. You can happily do only freight transport, or only passengers, and you can use to ignore power plants.
Not entirely true. It would turn power stations from being an end consumer (they will take whatever you can ship to them) to a factory (with production that requires consumption). This would mean that power becomes another part of the industry chain.

I personally think this would add to the game as currently power stations like coal and oil are the first industries people supply as they are simple no step source to destination routes. With the new dynamic they would need to first run other industries moderately well before there is enough power demand for the power stations to become profitable. Basically power becomes part of the chain kind of like you need enough people connected for a lot of passengers or you need to offer commuter services for consumers like bookshops for them to have decent demand. Basically all other chains have similar "forces" so why not power? Only difference is that suddenly people actually use power infrastructure outside of a few specific purposes.

Obviously power system generally would need improvement. This includes pay being based on distance (so transferring power across the map to that remote factory is not profitable by itself) and the ability to share power networks (with some fairness in pay). Until then power stations can just be consumers like they are currently now with desired production always being 100%.

Quote
Obviously one could introduce a setting to force power plants to consumer at reduced rates (10% or so) if no power is demanded.
Having something like that would be good to keep them ticking over. The key thing is that they should only produce at full if they are nearly fully used so that people are encouraged to actually use power. Currently power is so easy to max efficiency and in pak64 a single oil power station can earn you several million a year with a simple 2 station train line where as something like books requires you to grow the shop's city, offer it good commuter services, set up all kinds of factories so finally you get a good throughput of products to it. Power is just too easy in my opinion which is why in every online game you will find such power stations are always built up unless it happens to be very fresh (no one noticed it yet) or bugged (it cannot be supplied, like that pak128 oil-fired power station on Fifty's server due to max in-transit computation error).

Quote
The suggestion to make the consumption dependent on how much is produced is certainly good. Consuming base on actual total produce instead to a fixed number sound good. However, I am not sure how much it would change in the end. Very few producer produce more than two.
The order in which the factory production is computed could be changed to accommodate it. Looping through all outputs to first work out the desired production (which factors this in) before looping through the inputs to work out exactly how much can be produced with it then finally looping through all outputs to actually produce the product. This is kind of the inverse of what happens at the moment.

Quote
The reason is that Simutrans industry model is "broken" rather in the sense it does not really guess very well what industries are needed next. Producer with too many output are very hard to balance so all outputs can be used.

There have been quite few attempts to work a that out over the years. But in the end the whole options (crossconnect all/decidated connections/production increases by power/very complex factories in pak128) make this almost impossible to improve beyond what is there now. (Which is not far from what was done in the very beginning.)
This all comes down to economic models. I would say the best approach for this is to view each factory/source/destination as their maximum production (all bonuses applied) and then work with some rules. All end consumers should always have sufficient supply (more production of their consumed goods than needed). Middle factories operate slightly less efficiently with insufficient demand for their total production. Raw materials have a lot of extra production capabilities. This forms a pyramid with the top being the bottleneck on productions and the base being very wide and capable of support holes (you may not need that extra steel mill, or may not need to connect that iron ore mine at all with the end consumers still working all the time). Fine tuning could be done with individual factories raising or lowering base production (which appears to be in the code but not use?) However this is more a discussion for an economic model revision and not a factory mechanics revision.

Quote
I do not think the synchronous end consumer will happen that much that you have to worry about it. Simutrans is already conplex, and there can be too much complexity for too little gain.
The idea is that it adds no complexity to the code as you run it past that step anyway as you need that mechanics for factories. Currently all the mechanics are separated (with end consumers treated by a different branch of the code) which results in a lot of procedural coupling in the end.

Quote
Imho most gain would be a patch to base the consumption on the actual output if there is more than one good (implementation like by consuming per each good separately).
Except that starts to add the problem of [inputs * outputs] worth of operations which scales very badly (some strange pakset might have a factory with 20 inputs and 20 outputs, the time would start to become significant if many such factories existed).
I think running extra passes through all inputs/outputs would scale better.

Basically a pipeline like follows.
1. For all outputs, compute the desired production (scaled for their current storage level so that only as much work is done as required).
2. For all inputs, compute the amount of production that can occur based on input. This is a fraction of work done.
3. For all outputs, apply the production scaled based on intended amount for that output scaled by the fraction from 2.
4. Consume all inputs based on the fraction from 2.

I mentioned 2 and 4 separately as they would need separate passes unless you take advantage of negative storage amounts (allow them but stop when negative). This would still keep average production as precise but instead simplifies the logic since a factory production is boolean (on/off) and not (on but at some fraction due to insufficient inputs at this tick). Maybe simplicity is the best thing in this case.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #41 on: August 12, 2014, 08:33:30 PM »
It would turn power stations from being an end consumer (they will take whatever you can ship to them) to a factory (with production that requires consumption). This would mean that power becomes another part of the industry chain.

It would be a different kind of link in the chain then, because all other links are mandatory, whereas power distribution is just extra fluff for those that are into it.

Offline hreintke

Re: Suggestion for JIT mechanics revision.
« Reply #42 on: August 12, 2014, 09:00:31 PM »
Quote
It would be a different kind of link in the chain then, because all other links are mandatory, whereas power distribution is just extra fluff for those that are into it.

You could generalize this and to "optional inputgoods" and/or "outputgoods recipies" and get very flexible chain definitions.

Discussed a little in this thread : http://forum.simutrans.com/index.php?topic=11865

Herman

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #43 on: August 12, 2014, 09:37:12 PM »
That is what I did? Each input and output has a demand counter and each input uses their demand counter separately.
Ah, fine. I did not read the code yet, only the forum posts, which made me think there is only one counter per factory.

Quote
Initialization does need improvement. I just choose 0 as it is a clean value to test with. The buffer also needs to be saved and loaded.
I gave that another thought and 0 seems to be a good value. Well supplied factories will have demand near zero, while demand of  undersupplied factories will grow to the maximum. For many cases saving/loading is not very important. Notable exception would be a factory link where convoys have higher capacity than stations - typical for ships.

The rest is getting a bit out of topic, but I want to say something to it.

Factories with multiple outputs: if we take oil refinery as an example, you cannot separate the outputs. Oil refinery splits the oil to fractions, so it can make only X liters of gasoline from Y liters of crude oil. It does not matter if it uses other fractions to make ink, plastics, chemicals, or not. So you can think that it is just throwing away the extra production that nobody wants. Similar situation is with sawmill (pak128.britain), you cannot produce planks without producing woodchips. But you can just throw them away.

Of course there are other situations where it should be the other way round. Orchard can produce apples and cider, but you should get either a box of apples, or barrel of cider, not both. However this could be solved at pak level - let orchard produce only apples, and have another factory that turns apples into cider. And you could choose to deliver apples to the cider factory or directly to the market.

Similar thing applies for input goods. I'd like to have e.g. a cannery that can accept either meat or fish or fruit or vegetables (for foodstuffs), and either steel or glass (for package). Currently I would have to supply all of that, but I would like it to produce if at least one foodstuff and one packaging material is suplied. Yes again this could be done by having 4 (or 8) different canneries...

Well instead of sync/ansync groups or models it could be generalised by having a logical formula for inputs and outputs. Something like this: cannery input = ( meat || fish || fruit || vegetables ) && ( steel || glass ); sawmill output = ( planks && chips ), orchard output = ( fruit XOR cider ). Current behavior is && everywhere, except for end cunsumers which use ||

Furhter idea could be that some goods are only a booster (fertilizer for farms, grain for feeding livestock, coal instead of electricity for glass, cement and other factories)

Power plants - thermal power plants (coal, oil, nuclear) cannot easily adjust their output power. They operate best at full power. They cannot slow down and use less fuel if there is lower power consumption. The extra power is just "thrown out of the window". (Its more complex but my english is not that good to explain it). So I'm against binding power plants fuel consumption to electricity consumption. And I really like the fact that there are these simple chains, especially at the beginning of the game, so that you can get some steady income to fund building the infrastructure for more complex chains. If this is ever implemented it shoud be made optional, and the power plant should start full production when something gets connected.

The other suggestion that power boost (consumption) should not be on/off but proportional to production is fine. I would base it on  fullness of input storage - if it is near empty, boost a little. if it is almost full, boost almost 100%. If there are more inputs use the minimum.

A note for Leartin: please join the testing. You have opposed JIT2 on the ground that you are comfortable with the current JIT and do not want it broken. Please try JIT2, and see yourself if it breaks yor way of playing. I think it requires the same attention from player in regard to choosing the right amount and capacity of convoys. It just makes the flow of them more smooth and regular.  I have seen it during my test. I have a link where 2 trucks are not enough, and 3 trucks are a bit too much. With old JIT the consumer was slowly overcrowded, and then all 3 trucks piled up at the producer, blocking the road, and traffic around. Not for long but still enough to delay other deliveries. This does not happen with JIT2, as the trucks are loaded gradually and come in regular intervals.

Offline Leartin

  • Devotee
  • *
  • Posts: 848
  • Total likes: 301
  • Helpful: 44
  • !!!!!This user was banned for double posting!!!!!
  • Languages: DE, EN
Re: Suggestion for JIT mechanics revision.
« Reply #44 on: August 12, 2014, 11:07:48 PM »
A note for Leartin: please join the testing. You have opposed JIT2 on the ground that you are comfortable with the current JIT and do not want it broken. Please try JIT2, and see yourself if it breaks yor way of playing. I think it requires the same attention from player in regard to choosing the right amount and capacity of convoys. It just makes the flow of them more smooth and regular.  I have seen it during my test. I have a link where 2 trucks are not enough, and 3 trucks are a bit too much. With old JIT the consumer was slowly overcrowded, and then all 3 trucks piled up at the producer, blocking the road, and traffic around. Not for long but still enough to delay other deliveries. This does not happen with JIT2, as the trucks are loaded gradually and come in regular intervals.

I don't want to test it since I'm sure it does not break my way of playing, only my expierience. The time you are happy to save is pretty much the time I lose in gameplay value with no gain from it, since the intended gain is what I don't like about it. As long as I have the option to play the current JIT, I'll play that. Once I can't anymore, it does not matter if I like it or not, I'd need to adapt anyway. What I want and what JIT2 does are just two completely different things, so I'd much prefer you go on and make JIT2 the best it can be without interference of an opposer.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #45 on: August 13, 2014, 04:25:20 AM »
Quote
Power plants - thermal power plants (coal, oil, nuclear) cannot easily adjust their output power. They operate best at full power. They cannot slow down and use less fuel if there is lower power consumption. The extra power is just "thrown out of the window". (Its more complex but my english is not that good to explain it).
Not entirely correct. Power stations are seldom 1 reactor, often with several. Power output can be adjusted by varying the number of reactors online at a given time. In the case of a coal powerstation this would mean shutting off many of the fires/boilers resulting in less steam being generated.

If you are talking reality, a power station not connected to a load cannot even generate electricity as it would blow the generators apart. Economically without generating electricity there is no reason to even have the power station consuming anything at all. Thus my suggesting making sense.  That said, there could be production tiers with power stations (20%, 40%, etc) so that 100% utilization is not required, only enough to reach the 100% tier.

Quote
And I really like the fact that there are these simple chains, especially at the beginning of the game, so that you can get some steady income to fund building the infrastructure for more complex chains. If this is ever implemented it shoud be made optional, and the power plant should start full production when something gets connected.
That is the problem... They are so simple and profitable you really do not want anything but power. Instead of "hay a new bookstore has opened" you say "awww it is not an oil-fired power station". There should not be such easy money to be made. Power is almost always the first industry to be supplied and I often see 3 players fighting over power stations and even complaining and being rude if they cannot get one all to themselves.

Quote
The other suggestion that power boost (consumption) should not be on/off but proportional to production is fine. I would base it on  fullness of input storage - if it is near empty, boost a little. if it is almost full, boost almost 100%. If there are more inputs use the minimum.
Storage has nothing to do with how efficiently something can run. It is there to act as a buffer between shipments, not some strange production process. The amount of power consumed should be based on the amount of work done as in the end a factory not producing anything is not going to take much power. This would in turn be based on the fullness of output storage since output storages define the production rate. Currently there appears to be logic for some kind of cut-off where output is above 75% it stops using power but until then it consumes at full power rate. Since a flow based system depends on the storages being high for continuous production, this could be a problem so by making it based on the amount produced you will find that your entire power network reaches an equilibrium and remains approximately stable around it, which would be a huge improvement over now where in large networks I have had them fluctuate by ~60% from having tons of spare power to being heavily overloaded.

Quote
Factories with multiple outputs: if we take oil refinery as an example, you cannot separate the outputs. Oil refinery splits the oil to fractions, so it can make only X liters of gasoline from Y liters of crude oil. It does not matter if it uses other fractions to make ink, plastics, chemicals, or not. So you can think that it is just throwing away the extra production that nobody wants. Similar situation is with sawmill (pak128.britain), you cannot produce planks without producing woodchips. But you can just throw them away.
Except this is not what happens in real life. Oil refineries try and use naturally occurring compounds to make a substance but if there is not enough they can synthesise from other factions through various processes. This obviously is not viable for petrol or diesel but for more specialist chemicals it probably is. Also in the case of a sawmill, the woodchips can be converted into kinds of artificial planks (which are commonly used everywhere in this day and age).

Anyway, subtract all the "desired features" that people are coming up with now and see what I produced. Personally it appeared a viable way to play with no glaring faults when I tested it. Bottlenecks are a problem but since you now have flows you can enable routing restrictions to deal with those.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #46 on: August 13, 2014, 05:29:47 AM »
If you are talking reality, a power station not connected to a load cannot even generate electricity as it would blow the generators apart. Economically without generating electricity there is no reason to even have the power station consuming anything at all. Thus my suggesting making sense.

Power stations in Simutrans are always supplying something: all the houses and shops. Since Simutrans isn't Sim City, this isn't simulated, it is just assumed to be there.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8823
  • Total likes: 323
  • Helpful: 229
  • Languages: De,EN,JP
Re: Suggestion for JIT mechanics revision.
« Reply #47 on: August 17, 2014, 10:44:29 PM »
Quote
Quote
The reason is that Simutrans industry model is "broken" rather in the sense it does not really guess very well what industries are needed next. Producer with too many output are very hard to balance so all outputs can be used.

There have been quite few attempts to work a that out over the years. But in the end the whole options (crossconnect all/decidated connections/production increases by power/very complex factories in pak128) make this almost impossible to improve beyond what is there now. (Which is not far from what was done in the very beginning.)
This all comes down to economic models. I would say the best approach for this is to view each factory/source/destination as their maximum production (all bonuses applied) and then work with some rules. All end consumers should always have sufficient supply (more production of their consumed goods than needed). Middle factories operate slightly less efficiently with insufficient demand for their total production. Raw materials have a lot of extra production capabilities. This forms a pyramid with the top being the bottleneck on productions and the base being very wide and capable of support holes (you may not need that extra steel mill, or may not need to connect that iron ore mine at all with the end consumers still working all the time). Fine tuning could be done with individual factories raising or lowering base production (which appears to be in the code but not use?) However this is more a discussion for an economic model revision and not a factory mechanics revision.

Since you want some choice, it means that more than one producer is producing for more than one consumer. How to balance this out is non-trivial. Furthermore there are certain goods designed to be in short supply, like coal in pak64. So it is a strategic decision either power the steel mill or the coal power plant. That is very though to get right.

Offline TurfIt

Re: Suggestion for JIT mechanics revision.
« Reply #48 on: August 24, 2014, 11:25:06 PM »
Some threads you may have missed as these subjects were brought up here again:
  Limit on storing incoming goods in factories
  enable factory_max_input_capacity to be set from config files
  Electrical issues


As for the proposed JITv2, I keep flip flopping if it's good or not... Having all the suppliers dump their entire output stores into their attached stations (and the transport network) when a consumer starts up doesn't really make much sense. So throttling this to the rate of consumption is good.

However, one of the stated goals of JITv2 is to 'solve' the too far distance between supplier and consumer causing production stoppages at the consumer. I fail to see how this algorithm does so. The critical distance is simply doubled instead.

e.g. Take a factory that consumes 1000 units/month with a 1000 unit input storage located exactly 1 month travel away from its supplier who has infinite production.
Under the existing JIT system, once the input becomes full, the supplier stops sending. convois already enroute continue their deliveries resulting in possibly a quite large overstock. Consumption eventually results in the storage failing below full, and the supplier resuming shipments. The first convoi departs and arrives just as the storage empties. All's good.
Now move the consumer to be 6 weeks away from its supplier, and the storage sits empty for 2 weeks until the first convoi shows up. Enter JITv2 and the supplier continues to send at a 50% rate once the storage is full. Hence some convois continue arriving, and the consumer never runs out fully.
However, now lets move the consumer to be 2 months away. At the point the consumers storage falls below full resuming the 100% shipment rate, the entire transport system is full of convois delivering at the 50% rate. It will take two months before the first 100% convoi arrives, there's one month stock in storage, and one month stock in the 50% convois. Hence the first 100% convoi arrives just as the storage empties. Back to the All's good.
Move the consumer even farther, and there will be times the consumer runs out. Exactly the same as JITv1 (excepting the consumer produces at 50% rather than 0% during this time).


Ordering based on full electric boost but current pax/mail boost make no sense to me. Why the distinction? IMO just order based on the current consumption rate.

For intermediate factories, why link the input stores together with the 'lost order' mechanic? IMO the inputs should be independent. The linking is done naturally by the consumption ratios when the factory produces.
With the linked orders, it's possible to starve a factory on one input even when it's well inside the JITv1 critical distance. As a test, I setup a steel mill, and started supplying it with coal. Once the iron demand hit max, coal orders ceased which didn't make much sense. I then oversupplied it with iron. Once the iron became overfull, both iron and coal stopped ordering. After the convois in the pipeline emptied out, there was 100/150 coal, and 900/500 iron in the factory. Once steel started flowing and production resumed, the coal stock was exhausted before the first convoi could arrive. If instead the coal had continued ordering until it was also full, then the full stock of 150 would have prevented the shortage. This cycle continued as the steel consumption rate cycled. Sometime the steelmill would be left with only 20/150 coal, sometimes it would also be overful. Really depended on the exact timing of the convois. In the 20/150 case, the shortage also caused a steel shortage downstream. In this case, JITv2 caused production stoppages that would not have occurred with JITv1.

Having .accepting apply for an entire step cycle is good. Every supplier then has a chance to supply instead of just the first ones stepped. This should be back applied to JITv1, and the max_intransit limit so certain factories aren't preferred.

Speaking of max_intransit, JITv2 is completely ignoring this. The whole purpose of it (IMHO) is to prevent players just dumping goods into a station outside the factory and bypassing the JIT setting. So, IMO JITv2 should respect this too. Of course the opposite occurs too with malicious players maxing out intransit and shutting down factory chains, but then multiplayer games do require active moderation to have any hope of smooth working anyways...

And, WTF happened with max_instransit - it was based a percentage of the input storage which make sense. Now it's based on the sum of a percentage of the outputs of the suppliers? huh?

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #49 on: August 25, 2014, 01:01:59 AM »
Quote
However, one of the stated goals of JITv2 is to 'solve' the too far distance between supplier and consumer causing production stoppages at the consumer. I fail to see how this algorithm does so. The critical distance is simply doubled instead.
It works because goods turn into flows. If you have a chain of trucks from a coal mine to power station 100 units away or 1,000 units away or even 100,000 units away there is no difference in power station operation since as fast as it consumes the coal more coal is being ordered. Instead of waiting for storage to become less than maximum storage then ordering everything it can, it instead orders a constant trickle from all suppliers which in turn results in a constant trickle into its storage.

That said the algorithm is not perfect...
1. Transfer bottlenecks without any transfer restrictions can grow potentially infinitely. Having 2,000,000 units of oil into an oil transfer is completely possible (however unlikely if the company manager knows the slightest what he is doing).
2. If an in-transit bottleneck was to occur which results in a storage overflow it is possible that the same problem with burst production consumption can occur. However it is limited at worst case to the overfull order fraction (50% in my demo) no mater how big the distances involved are.

Quote
Move the consumer even farther, and there will be times the consumer runs out. Exactly the same as JITv1 (excepting the consumer produces at 50% rather than 0% during this time).
Yes except that is kind of the point. It will only run at 50% use as a penalty for you overflowing its storage (this also serves to "burn off" backlog in case of changes of in-transit amounts). However if you deliver in appropriate shipment sizes it will never overflow the storage since it orders exactly as much as it consumes. Since it keeps ordering at 100% even when empty a buffer in the storage will build up to compensate for shipment difficulties.

There are problems with existing pakset balance such as marketplace in pak64 with food addon. The max storage of the consumer can be so small that it is not possible to supply it end game without causing it to overflow (there are no non-obsolete convoys capable of shipping that little). However this becomes a pakset issue and is easily resolved by raising it to 100-200 units max in storage. You still cannot supply it with 12 long trains without it overflowing however you can have 1-2 trucks arriving close together to account for transport dynamics.

Quote
Ordering based on full electric boost but current pax/mail boost make no sense to me. Why the distinction? IMO just order based on the current consumption rate.
Because when not consuming anything the power boost disappears (bad design of power boost). As such it would be ordering at the mail/pax boost rate and not the power boost rate despite it being capable of consuming at the power boost rate because the consumer is sufficiently supplied with power (just not currently reflected on the production rate due to it not producing anything). Since it is not using any power and you cannot get the attached power net (no relationship in that direction) we cannot determine actually what power boost it is going to receive so we have to assume 100%. When it is producing then we simply use the current production rate since now power is being applied.

What power should do is treat each factory as a load and vary the power used depending on work done. Under this definition an idle factory connected to power will get 100% power boost so we can directly order the amount. However the current definition is binary and the power boost vanishes completely when idle so we would order too little if there was no compensation.  In theory it would eventually correct itself without this compensation but it could take in the order of years to reach 100% production so it is far better to just make the assumption (if connected to any transformer and not producing we are running at 100% power boost) and over order if necessary (which can be fixed by under ordering later) than to sit idle trying to slowly build up the order.

Quote
For intermediate factories, why link the input stores together with the 'lost order' mechanic? IMO the inputs should be independent. The linking is done naturally by the consumption ratios when the factory produces.
Because in the case of a supply bottleneck you would end up overflowing the other inputs with no real limit. Yes if the bottleneck is fixed it will eventually stabilize thanks to the overflow order fraction (50% in demonstration) however until then and under bottleneck conditions nothing would stop the order storages reach the hard-coded maximum of 15,000 units and still keep ordering. For this reason if the order buffer overflows causing orders to be lost then it also loses orders for other goods so that the supply bottleneck is transferred to the orders of the other inputs.

Quote
Once the iron became overfull, both iron and coal stopped ordering. After the convois in the pipeline emptied out, there was 100/150 coal, and 900/500 iron in the factory. Once steel started flowing and production resumed, the coal stock was exhausted before the first convoi could arrive. If instead the coal had continued ordering until it was also full, then the full stock of 150 would have prevented the shortage. This cycle continued as the steel consumption rate cycled. Sometime the steelmill would be left with only 20/150 coal, sometimes it would also be overful. Really depended on the exact timing of the convois. In the 20/150 case, the shortage also caused a steel shortage downstream. In this case, JITv2 caused production stoppages that would not have occurred with JITv1.
Middle industries are particularly difficult since their actual rate of consumption is based on their linked consumers. For this reason additional stalls are required. The rate of ordering is based on the rate of production. Since the output storage is getting full the rate of production falls resulting in less being ordered. Eventually ordering stops as output storage approaches full (it might not physically stop but the units are so small it might as well be considered stopped). However once the steel mill gets going eventually orders out reach an equilibrium where the production rate of the steel mill sufficiently supplies the linked consumers. Under this circumstance it is now possible to know how much has to be ordered so the correct amount will start to follow into the steel mill.

You are correct that distance will cause some temporary issues. The steel mill may run out of input and so start ordering at 100% (more than is required). This may eventually cause an overflow (if the mill is not used 100%) which may under order for a while. However due to constant orders it should eventually reach an equilibrium. When the steel mill works at 100% this is not an issue.
Quote
Having .accepting apply for an entire step cycle is good. Every supplier then has a chance to supply instead of just the first ones stepped. This should be back applied to JITv1, and the max_intransit limit so certain factories aren't preferred.
JIT1 does not suffer supply preference. All factories will try and supply the consumer with a load if it is accepting and less than maximum in-transit. In the case of 2 accepting factories it uses a round-robin selector to be fair. Since maximum in-transit is so large it is virtually impossible for it to be filled only in 1 tick, the amount of bias left would be only for the final tick where it may stop before visiting all factories however this deviation is minimal and under loaded conditions the bottleneck will be the rate of production for suppliers anyway.

Quote
Speaking of max_intransit, JITv2 is completely ignoring this. The whole purpose of it (IMHO) is to prevent players just dumping goods into a station outside the factory and bypassing the JIT setting. So, IMO JITv2 should respect this too. Of course the opposite occurs too with malicious players maxing out intransit and shutting down factory chains, but then multiplayer games do require active moderation to have any hope of smooth working anyways...
That is not within the scope of JIT2 and instead is part of the game's transfer mechanics. However since JIT2 makes flows of goods you can now much more easily use transfer restrictions like no routing if overcrowded or drop at overcrowded. The reason for this is that the amount of goods at any stop in your network will now be pretty constant so with some storage planning it is easy to get transfers not to overcrowd. If you look at in-transit graphs of well established games for industries without a transfer bottleneck you will see how instead of huge spikes it flat lines at a very low level (the optimum in-transit, virtually nothing waiting and mostly actually in-transit on convoys). This is perfect for use with transfer restrictions that are otherwise discouraged as no one can handle a burst of >50k tons of coal to a power station in a huge coal network.

Also with the recent rise of max in-transit from being a multiple of storage to a multiple of output for every supplier this has become a major problem even with max in-transit restrictions. I mean on fifty's nightly I obtained a massive 200,000 units of oil in a transfer (as oil refineries had max in-transit of well over 150,000 units). Upon deep analysis I decided that maximum in-transit is kind of a useless mechanic. All it does is soft apply a maximum map size and eventually stop people shipping more once their transfer has over 150,000 units in it (or more for big maps). At this stage we might as well let them keep shipping as the fact is they will not be maximizing profits and if they ever collapse it (fix the bottleneck) they will suffer a 50% production penalty for several years. Obviously they could use the cargo bounce exploit and things to make infinite money from the cargo but that is kind of cheating anyway and they can even do it with still shipping to the end destination without a bottleneck.

A solution? Well anything would need to modify the cargo router to detect a bottleneck or upon arrival to a transfer feed back to consumer of a bottleneck. What to do with that information I am not sure. However all this is kind of pointless when there are already transfer restrictions which are perfectly suited for JIT2. In the end you should not be able to transfer more into a stop than it can hold, that is another problem unrelated to the industry model.

Quote
And, WTF happened with max_instransit - it was based a percentage of the input storage which make sense. Now it's based on the sum of a percentage of the outputs of the suppliers? huh?
That was not me (some other developer made this change). I think it was to address the soft map size issue that max in-transit applies where with enough suppliers far enough away you could get it that 100% of the maximum in-transit amount was in actively moving convoys which end up insufficiently supplying the consumer. In the end maximum in-transit makes little sense and is purely a work around for poor production and transfer mechanics which JIT2 when applied to transfer restrictions such as no route over overcrowded solves.

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #50 on: August 25, 2014, 03:23:33 PM »
Hi,

just a few comments from testing. I had not so much time to play, but anyway. I have a map (San francisco bay) with long distances between factories and low capacities, so I am using mostly trucks. I have a china shop whose input capacity i less than the truck's, so I have to run at 80% load to keep the shop running near 100%. It is really JIT, as the truck usually arrives just at the moment when last stock is being sold. Thus a traffic congestion can interrupt the production, but otherwise it is OK. The trucks supplying clay to pottery run nicely spread over the whole distance, clay pit is supplying the right amount of clay, always only one truck waiting for the load.  :thumbsup:

However I struggle with fishery. I have 12 boats supplying fishing port, and 4 trucks from fishing port to fishmonger. Input capacity at both is only sligtly larger than the capacity of boat (truck), so it is easy to overfill them. It seems to take forever to find the equilibrium, so I had to help it a little - stopping the truck just before unloading and waiting for the shop to consume enough fish to prevent overload. Anyway it is still much better than old JIT, which would easily leave the fishing port or shop out of supply for months. Maybe the 50% penalty for overcrowded input is too harsh in this case.

TurfIT: max_in_transit is IMHO really bad solution to JIT problems. You need different in_transit percentage for different distance between factories. Experimental tries to solve it by scaling max_intransit by measuring the delivery time, however JIT2 does not need it at all. Thats why it is ignored.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #51 on: August 25, 2014, 11:15:51 PM »
Quote
Maybe the 50% penalty for overcrowded input is too harsh in this case.
It is needed to "burn off excess" as otherwise the storage will never decrease unless suppliers become overloaded or shipments stop (eg if a supplying company bankrupts).

I agree it is not optimal however what are the alternatives? I could "discard" excess incurring you a financial penalty based on distance from source however that could possible be abused. Alternatively discarding could occur with bonus income if shipments fall under the storage amount (shipping combos, with a maximum income multiplyer after enough is shipped correctly and resetting if discarding occurs).

However I still think the current idea of 50% order penalty is by far the most intuitive and is also very easy to implement. A smaller amount could be used but then there is no incentive to not overfill the buildings. It is obvious that some pak sets will need some balancing. I would advise raising storage for such industries as you described to accommodate for the new system. Anything in the 100-200 range would be suitable for trucks for most industry types but not for trains or trains of longer lengths.

Starting next week I will look into a second attempt at this, hopefully one that will be more publish friendly.

A possible optimization and simplification is to get rid of partial consumption (retro-active with the current JIT as well). Currently if input is insufficient it will only produce and consume what it can. This requires a lot of logic to handle for something which makes no difference in the end. Instead the number of "empty" inputs could be cached in a variable (that can even be computed at load time! so not extra data saved). For factories if this is above 0 then production halts. For consumers if it is above 0 then it is known as consuming less. What this does mean is that you could get negative storage (-0.xxx of an input as an example) however this makes no difference in the big picture as still the same amount gets produced on average and the amount produced from overshoot is as good as nothing (1 tick of full production at most, which gets deducted from the next shipment anyway). For the UI values below 0 could show 0. This at least would take advantage of the fact signed integers are used for storage amount. It could also allow for some considerable optimizations to industry ticks since a factory with empty cache being greater than 0 can return almost immediately and no extra loop through inputs is required to determine the minimum production possible as it would be all or nothing.

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #52 on: August 26, 2014, 06:36:06 AM »
I must say that jit2 is IMHO really good as is. I just didnt have much time to test thoroughly.

I have one idea about input storage, but I am afraid it will interfere badly with jit2. It is so that factories will never accept more cargo than their input, leaving the excess stuff on the station. Thus you could increase the input store by adding extensions to stations. But this will just shift the overcrowding from factory to station and will need no-route-via-overcrowded station.

Hmmm. Or an option to build storage extensions directly to factories so that player can extend the storage as needed.

Sent using recycled electrons.


Offline scamps

Re: Suggestion for JIT mechanics revision.
« Reply #53 on: August 26, 2014, 09:42:40 AM »
Any chance for a lazy player to get a windows executable?

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #54 on: August 26, 2014, 10:12:20 AM »
I can offer linux executable...

Sent using recycled electrons.


Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #55 on: August 26, 2014, 02:24:11 PM »
Quote
Any chance for a lazy player to get a windows executable?
I attached one in my post. If it works for you is another question (some people said it did not work). I do apologize if this is the case but I have little idea how to build perfectly portable windows executable and am using compilers and libraries that are about 4-5 years old. It works on my computer as that is how I did the testing.

You will need the visual C compatible pthread dll, this was something I forgot to bundle with (normal simutrans is built with G++ so uses the GCC compatible pthread dll).

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #56 on: September 09, 2014, 07:30:13 PM »
I have played with JIT2 for a while now, and I am very satisfied with it. It helps a lot specially in cases where there is more goods in supply than demanded.

I would only suggest two improvements:

- display the demand counter in factory info
- make it a config file option, so that player can choose: JIT, JIT2, freeplay

I recommend accepting JIT2 into simutrans, as it solves frequent beginners question:

- overcrowded stations at source - if there is an oversupply, a player may try to buy more and more convoys and build more infrastructure to haul all the available cargo, just to find out that after a while, the destination is overloaded and not accepting any more, and all his expensive vehicles sit idle until the overstock is used. However when playing with JIT2, source stations are overcrowded only if the destination is willing to accept that without getting overloaded. (Or at least not overloaded for too long).

It also helps in other situations - recently discussed problem with supplying a coal plant and steel mill with one train carrying both coal and ore. With jit2, all cargo is loaded in proportion to demand of consumer, so that they are supplied more evenly. Without JIT2, you could often get one consumer overloaded and the other one starving.

This is even more visible if the consumers are not at the same station, and the train has to drop off part of the cargo on one station, then continue (half-loaded) to second station, and then return for full load. Without JIT2, you often end up supplying only the closest factory until it is overloaded, while the second is idle. Thus you usually end up having dedicated lines for both industries, but that needs more investment in vehicles and infrastructure. And you can't afford that in the beginning of the game.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #57 on: September 09, 2014, 10:51:47 PM »
Quote
- display the demand counter in factory info
It actually does this! It replaces the maximum in-transit counter with the demand counters (since maximum in-transit is not used in JIT2). However this is only on by default for Pak64 with Pak128 using the traditional display.

Quote
- make it a config file option, so that player can choose: JIT, JIT2, freeplay
More difficult as this involves touching other files. However that is the next step.

I am going to try a second attempt at this quite soon and hopefully tag it with some other improvements (even possible optimizations).

For example processing industries could terminate early if last cycle ran into insufficient goods and no shipments arrived.
Another example is that instead of computing maximum production based on input always, it could assume maximum production and consumption and if consumption fails (storage less than 0) then apply a correction to production and consumption (production stop events are rare, most industry ticks will not have a stop event).

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #58 on: September 11, 2014, 07:13:18 PM »
It actually does this! It replaces the maximum in-transit counter with the demand counters (since maximum in-transit is not used in JIT2). However this is only on by default for Pak64 with Pak128 using the traditional display.
How can I enable it for other paks? (especially pak128.Britain)

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #59 on: September 11, 2014, 09:57:27 PM »
Quote
How can I enable it for other paks? (especially pak128.Britain)
It is a new feature to RC120 and later. To be honest I do not know but I would imagine it is some game configuration. The text is generated by a conditional statement.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8823
  • Total likes: 323
  • Helpful: 229
  • Languages: De,EN,JP
Re: Suggestion for JIT mechanics revision.
« Reply #60 on: September 11, 2014, 10:14:47 PM »
A configurable JIT model would indeed be very nice, as JIT2 has gotten some varied feedback.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #61 on: September 12, 2014, 05:06:11 AM »
I'm a bit puzzled by why JIT2 behaves differently between pak sets. Or more correctly: how. The game doesn't really know what pak set is running. It just does things the way the pak set dictates, and it seems strange that pak sets already contain configuration parameters for JIT2.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #62 on: September 12, 2014, 05:32:11 AM »
Quote
I'm a bit puzzled by why JIT2 behaves differently between pak sets. Or more correctly: how. The game doesn't really know what pak set is running. It just does things the way the pak set dictates, and it seems strange that pak sets already contain configuration parameters for JIT2.
It does not behave differently at all.

Between 112.3 and RC120 some configuration option was added to show extended factor storage information. The only difference is that the storage string also includes maximum in-transit amount in brackets next to the current in-transit amount. By default newer versions of Pak64 have this turned on. Pak128 on the other hand does not and still uses the classic non-extended display.

Since there are no maximum in-transit numbers in JIT2 (well there are but they are never used in the rough implementation I made, better implementation should not contain them as JIT2 does not need them) I replaced the string printer for extended display mode to include the demand buffer information.

In pak64 it will produce something that looks like this...

10/1987-20/140
the format is...
current storage/in-transit + demand/maximum storage

In-transit is kept because it still is useful. In fact it is now more useful than ever since in an efficient network this will indicate the capacity of your network when shipping that good. The demand buffer should mostly be negative for properly linked and supplied industries as positive demand means there is a lack of supply. It only makes sense that demand is shown next to in transit as it represents the amount that it wants to add to the in-transit volume.

That said the display is rather rubbish. There really ought to be a table for this information rather than some cryptic string generated from a formatted string printer.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #63 on: September 12, 2014, 02:38:58 PM »
Sounds like it's the translation, rather than the pak set that controls it.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #64 on: September 12, 2014, 03:10:52 PM »
Actually it appears it is based on "in-transit percentage".

Code: [Select]
if(  welt->get_settings().get_factory_maximum_intransit_percentage()  ) {

So any game which has a maximum in-transit percentage should display it in extended form. I do admit that was not very smart of me seeing how it does not even use maximum in transit...

Offline Vladki

Re: Suggestion for JIT mechanics revision.
« Reply #65 on: September 14, 2014, 03:44:16 PM »
Ah that's it. I played with max_in_trasnit = 0. After changing it to non-zero I got it displayed.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #66 on: September 15, 2014, 03:41:08 PM »
I am having a second attempt at this, trying to make it an applicable patch.

So far I am changing the Just In Time flag to be a number.
0 -> Classic - I believe this results in no limit on good production.
1 -> JIT Classic - Does what JIT does currently with very few (minor, you will probably not even notice) mechanical variations.
2 -> JIT2 - Flow based industry model with demand buffers. Also includes improved industry logic.

Now this is not easy for the following reasons.
1. Many new fields. Forces incrementing the game version number (sorry).
2. Improving the industry logic while keeping the old logic practically intact requires a lot of care.
3. The entire tick function for factories has to be rewritten. The old one just was not structured well enough.
4. Migrating to edge events instead of polling requires changes in logic in other places in the code.

That said it will add the following features to JIT2.
1. Power consumption based on actual production. An industry working at 15% will only use 15% of the power it does at 100%. In JIT Classic it uses 100% power unless production falls below 25% in which case power bonus vanishes completely and no power is used.
2. Consumption is based on actual production. If a factory only produces 1 good at 50% and another at 25% then it will work at 37.5%. In JIT Classic consumption was based on the largest production rate output (50% in the example).
3. Improved production precision. The extra precision field has been improved from 10 bits to 16 bits just because the other bits were being discarded for no apparent reason. This will affect both industry models.

I am still a long way away from having it working sadly.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #67 on: September 15, 2014, 04:49:16 PM »
2. Consumption is based on actual production. If a factory only produces 1 good at 50% and another at 25% then it will work at 37.5%. In JIT Classic consumption was based on the largest production rate output (50% in the example).

Whether this is right or wrong depends on the actual industry. Oil refineries are typical examples of an industry where the current behaviour is the right one. For one unit of crude oil, you get some amount of petrol and some amout of diesel. If you reduce the production of diesel, but keep petrol production the same, you will still need the same amount of crude oil. There will just be more waste. On the other hand, a factory producing hammers and crow bars will reduce iron consumption if production of either one is scaled back. Pak64 might arguably have the mutual-byproduct type factories. I don't know about the others.

Offline DrSuperGood

Re: Suggestion for JIT mechanics revision.
« Reply #68 on: September 15, 2014, 05:13:48 PM »
Quote
Whether this is right or wrong depends on the actual industry. Oil refineries are typical examples of an industry where the current behaviour is the right one. For one unit of crude oil, you get some amount of petrol and some amout of diesel. If you reduce the production of diesel, but keep petrol production the same, you will still need the same amount of crude oil. There will just be more waste. On the other hand, a factory producing hammers and crow bars will reduce iron consumption if production of either one is scaled back. Pak64 might arguably have the mutual-byproduct type factories. I don't know about the others.
Not entirely true. Cracking is used to break longer/heavier hydrocarbons down into smaller more useful ones. Without this most oil would be useless heavy fractions. Thanks to cracking they can efficiently convert these less useful heavy fractions into more useful lighter fractions such as jet fuel and diesel.

It also economically makes more sense than them throwing away large amounts of their consumption.

From a game balance point of view it will help ease the oil demands of pak64 oil refineries which have been notoriously hard to supply under high demand due to them consuming 9-16 thousand units of oil a month, the most of any industry. Since supplying them is not a problem with flow model it is needed to trim profits a bit. It also might not be the most realistic but from a gaming perspective it probably will make more sense to people.

"So I am pulling more out of the refinery and it is using more oil? Yeh that makes sense"

Ultimately a later revision should allow adjustable weights and other features. An example could be that printer ink only uses like 20% of the input oil while the rest is used for chemicals.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4870
  • Total likes: 202
  • Helpful: 108
  • Languages: EN, NO
Re: Suggestion for JIT mechanics revision.
« Reply #69 on: September 15, 2014, 05:46:03 PM »
I just picked oil refineries because it seemed simple and pak64 has one. As for cracking and similar, it usually only works one way. I also think people are familiar with the concept that you can't produce more of something just because there is less demand for a byproduct. The chemicals/ink thing in pak64 is indeed strange, but I don't think it's something that need a global solution. It also feels like dumbing down Simutrans, where the game adapts to the player, rather than challenging the player. Not that Simutrans is perfect, with uneven goods flow you were originally trying to solve as one of the greatest culprits. (Capacity issues due to scale being the other great problem I face. One simply can not get enough horse-drawn coaches on the road the meet the demand.)