Power logic fix patch

[DrSuperGood]

Many people may have noticed some strange satisfaction oscillation problems in distribution transformers when consumption amounts change. This is especially the case with JIT2 running due to the highly dynamic nature of power consumption (changes all the time). Although hardly a critical bug (the game will still work) it looks bad, is unintuitive and does cause issues when trying to max out factory production.

There are 2 issues...

• Incorrect power demand refund logic. Refunding is based on current demand and not the demand that was solved resulting in equivalently a FIR filter and hence oscillations in boost. I caused this during implementation of JIT2 due to the documentation for power being poor.
  
• Incorrect transformer power consumption display at distribution transformers. It shows the last load factor with the demand to solve rather than with the last demand. The problem is noticed in that load factor change is always 1 tick after demand change. This issue has existed for a long time but was never noticed due to power demands changing infrequently.
  

The attached patch solves both issues. I also tried to re-structure and document the changed areas so that future maintenance will be easier and hopefully no one will make a similar mistake.

This does not fix the 1MW power fluctuation issue some factories suffer from. That is with the JIT2 power computation logic and will be looked at later. That is also a very minor issue as generally the fluctuations can be considered a very small noise that becomes increasingly insignificant in large power networks.

[DrSuperGood]

Many people may have noticed ~1MW noise with JIT2 industry power consumption and generation. Others may also have noticed that re-routed factory goods due to overfull stops was not refunding industry demand buffers with JIT2 factories.

This patch aims to solve both issues as well as provide some minor code polish. This patch does not include the above power network fixes, both patches should still be applied.

The noise issue was the result of slightly incorrect power calculation logic. This error could cause power consumption to vary by a few MW during factory operation. This has now been corrected to produce more stable and accurate power results. A well operating power network should vary only a few percentage once everything has stabilized. Tested with a small sized power network of 1 power station and about 10 factories.

The goods redirection loss was the result of missing JIT2 logic (an oversight). Goods which were re-directed at a full factory stop to a different destination did not refund the demand buffer for the original destination. It should  now refund the original destination's demand buffer. This prevents an unintended loss of goods at busy stops. This fix appears to work when tested in simple conditions.

[TurfIt]

Should the refund JIT2 demand buffers for rerouted goods not be in fabrik_t::update_transit() rather than ::verteile_waren()  ?
i.e. keep the demand buffers updated no matter the reason for the goods changing.

[DrSuperGood]

fabrik_t::update_transit() is called a lot of times by convoy and stop code if I recall. It is used to generate the in-transit amount on load. Where as in-transit can be recalculated by counting every instance of a good after loading, this is not helpful for demand counters since they are modified by the creation of goods and do not care how many goods they have caused to enter the transport system. The method is called when one does not want to modify demand counters.

Further more not all goods destruction should refund demand counters. Specifically if a player destroys a stop or convoy carrying goods it should not refund the demand counter to prevent possible exploitation. If it did refund the demand counter the player could "ship to nowhere", destroy the stop to reset the demand counters and rebuild the stop to ship to nowhere again. A better solution in such a case might be if all the destroyed goods get "teleported" to the factory, possibly at the players expense.

[DrSuperGood]

Ops...

I noticed I broke the JIT2 factory with the above fix as I deleted an early escape clause (by mistake...) allowing consumption logic to run on factories with empty inputs. I also forgot to scale consumption correctly after deferring the work scaling divisor to reduce noise.

The fix that was applied by another developer was not completely correct.

Attached is a patch fixing the problem from the current revision. I am sorry for the inconvenience.

[Dwachs]

Is this patch the proper fix to the bug that I tried to cure with r7677?

[DrSuperGood]

Is this patch the proper fix to the bug that I tried to cure with r7677?

Yes this should be the proper fix.

The bug is not present in release as it does have the escape test. I accidently deleted the escape test in one of the above patches (stupidity, maybe I was thinking of revising the code but forgot, honestly I do not know why anymore).

Inputs are never meant to drop below 0 when using JIT2 since that makes no sense (they used something that does not exist). To make sure of this I added extra logic although in theory it should be unnecessary but it also should not hurt.

[Dwachs]

Inputs are never meant to drop below 0 when using JIT2 since that makes no sense (they used something that does not exist). To make sure of this I added extra logic although in theory it should be unnecessary but it also should not hurt.

I got the impression that sometimes the input value is slightly under zero, just a tiny fraction of one unit of the freight type. But maybe this was a symptome of the same bug as well.

[DrSuperGood]

Factories with more than 1 product were consuming more than 1 times as much of their input than intended. As such the metering logic to prevent inputs falling below 0 did not work.

For example a chemical plant producing Printer Ink and Chemicals would correctly dish out the last 3 units of oil but instead would remove 6 units instead of the 3 it correctly metered out, hence going negative.

[Dwachs]

this is in 7681 now. thank you!