opened
Zajozor
username_0
fixes #5367 

I added a configuration category called storage, which is loaded both on client and server.
Created default values for the storage, for most of the machines, that were in the switch in `getUsage()` function.
Notably added an option for `TELEPORTER` and `CHARGEPAD`, which had hard-wired values in `getUsage()`. Using the previous method of determining storage as default.

As suggested by @username_1 , the code does:  `baseEnergy = Math.max(usage, storage);` 
This is not perfect though, if you put some speed upgrades into the machine, you can still get it into a state when it requires more energy, than can hold, or when the energy use increases due to some settings (eg. using silk touch in digital miner).

I see no straightforward way how to fix these machine issues (which can anyway happen only with very unusual config values). If you would like it to work somehow, feel free to suggest me something.
I did test the changes and they seem to work as expected, other than what was mentioned.
Add support for configurable machines storage.
issue
created
Zajozor
username_0
Hey, sorry for the huge changes, the renaming got a little wild, but most files are changed really just cosmetically.
Also sorry for the force-push history, I had a little trouble getting `ItemBlockMachine.java` right, as it has  CRLF endings, which were auto deleted, leading to a heavy diff.
The branch should be rebased above 1.12 now though.

Changes:
- add the storage config with default values
- remove `Usage` and `Storage` from config field names, and renamed their respective usages
- previously, as the storage was calculated as `400*usage`, on every config sync, `BlockStateMachine.MachineType.updateAllUsages();` was called, to update `MachineType.something.baseEnergy` values. When the storage is in the config though, this is unnecessary, because the machines can get their storage directly from there. So I removed the `baseEnergy` field, added a `getStorage()` one (simillar to the existing `getUsage()`), and made the code use that, where applicable.
- Machines extending from `TileEntityMachine` and similar were accessing the `MekanismConfig` directly, and using the old `baseEnergy` field to get their usage/storage. Now, they get them through `MachineType.something.getUsage/Storage()` (hence a lot of diff). This allows to use `max(usage,storage)==actualStorage` (on a direct config access we could not alter it).
- I did allow myself to rename some method arguments from `maxEnergy` to `baseMaxEnergy`, as that is what they are really used for, and it also conforms with the existing `baseEnergyUsage` argument naming. If this is a problem, I shall revert it.

- Regarding factories, they should now work as intended -> previously `200*processes*baseUsage`, now `0.5*processes*baseStorage`, which gives same defaults. Will follow up with some screenshots, demonstrating this.
- Also added storage config option for the chargePad and Teleporter (which do not have a usage config option)
comment
created
Zajozor
username_0
Example screenshots:

When we set enriching factory to have only 10kJ = 2kRF storage, the basic factory will have 1.5x times that much.
![image](https://user-images.githubusercontent.com/1835434/56461072-f48e4500-63ac-11e9-8d4b-f8bf11d9503e.png)
And the elite one will have 3.5x that much:
![image](https://user-images.githubusercontent.com/1835434/56461081-0a036f00-63ad-11e9-938a-e99299e0ec4b.png)

When you set some storage to too low (eg. EnergizedSmelterUsage = 0 here), then storage gets capped to usage (20):
![image](https://user-images.githubusercontent.com/1835434/56461085-23a4b680-63ad-11e9-8a37-b440121b5a5d.png)
And the basic factory will have 1.5x times (30 storage), meaning it can only power one operation at a time:
![image](https://user-images.githubusercontent.com/1835434/56461299-8e0b2600-63b0-11e9-9982-1815cb67b624.png)
And an advanced factory with an energy upgrade will have 50+16.67 capacity, being able to smelt 4 items at a time 15rf/t each:
![image](https://user-images.githubusercontent.com/1835434/56461303-b98e1080-63b0-11e9-8397-c945c8e7b857.png)

Custom chargepad storage:
![image](https://user-images.githubusercontent.com/1835434/56461312-c6aaff80-63b0-11e9-8fbd-138c34782c03.png)
Custom teleporter storage:
![image](https://user-images.githubusercontent.com/1835434/56461314-cf033a80-63b0-11e9-9273-aedf38c12094.png)

As mentioned above, sometimes I get an issue, where the client ignores the custom config value, then it looks like this -> The teleporter is set to have 690kRF as maximumStorage (and won't charge any further, the server limits it correctly), but the client still displays the maximum as 2MRF. I am unable to determine when this happens, if you have any suggestions I would be glad. (Maybe just a random workspace issue)
![image](https://user-images.githubusercontent.com/1835434/56461047-9e210680-63ac-11e9-9f9f-c7db3745884a.png)
comment
created
thiakil
username_1
I think the cap here should allow all processes to be used in a factory at a minimum

Your explanations are fantastic by the way, I appreciate the effort you've put into this :)
comment
created
Zajozor
username_0
Sure, will do soon. (sorry easter got on me in the last couple of days :) )
Other than that, is there anything else i should tweak or some special cases that I should test?
comment
created
Zajozor
username_0
Now the storage should behave as you suggested. So now:

When you set some storage to too low (eg. EnergizedSmelterUsage = 0 here), then storage gets capped to usage (20*tier.process), here is a basic factory:
![image](https://user-images.githubusercontent.com/1835434/56716565-f48a9e00-673a-11e9-9fb5-20181bf2b7d0.png)

An advanced factory with a energy upgrade:
![image](https://user-images.githubusercontent.com/1835434/56716611-13893000-673b-11e9-8e28-6a363d99bd9a.png)

It is still possible though, to get into a situation, when the factory cannot do all of the processes, when you apply speed upgrades and the storage is too low. Here is an elite factory with two speed upgrades:
![image](https://user-images.githubusercontent.com/1835434/56716908-be99e980-673b-11e9-9c22-853471401950.png)
It correctly consumes 
`126.5 = 2 processes * 20 baseUsage * (10 maxUpgradeMultiplier ^ (2 * 2/8 upgrades))`.

Other functionality remains unaffected.
comment
created
thiakil
username_1
Sounds good (it's always been possible to get into speed/energy upgrade mismatch problems)

I'll have a proper code review this weekend
comment
created
Zajozor
username_0
Indeed, this fixed all desync problems I can observe, thank you :)
comment