Implement Status widget for machines and covers

[PrototypeTrousers]

What: Proposed system to visually help the user solve issues that may arise while using machines and covers, with a widget that may hint as to the root cause of the problem.

How solved: A 'situation' is set every time the logic passes, or fails.

The widget will then show the player when the GUI is open, where the problem, if any is.

Outcome: May hint the player to common issues, like why the machine is not working or the cover may stop working due to rare capability issues.

Additional info:

Possible compatibility issue: on machines the widget uses the space where previously was the low energy one

[PrototypeTrousers]

Currently we have three indicators, we can add more and make even more verbose or show only when the cover wont work. I know i can do better on the indicators but have to know if they are needed in the first place. widget is synced from the server, so shows current status dynamically.

[LAGIdiot]

Honestly I was not expecting you to implement it right away as I did not even finished requirements for it. This will be part of public API so we can't rush it out because reworking it later would be pain. Also I want this to be usable on all GUIs that GTCE (and addons) have so it needs to be quite versatile and easy to use. With as little boiler plaiting on use side as possible. So let me get some analysis on this matter. Suggesting are welcome and this may even change to discussion for quite while.

State types we want to report: Every state should have it's own icon which should be distinct and recognizable on first sight.

• Working (everything is going as expected - recipe is being work on, pump is pumping, ...)
• Idle (could work if there was something to work on - no recipe selected, nothing to pump, ...)
• Warning (situation is happening which may lead to problem or is preventing work - recipe is using more energy then machine is getting, recipe can't be processed because outputs are full, ...)
• Problem (something is not working as expected - recipe stopping and progress being reset because of missing energy, steam can't exhaust, missing capability, ...) Maybe warning could even be split to two soft and hard

Situations we want to report: This has to be most forgiving so GTCE or addons can add new ones when need arise or remove them without breaking anything. We should use GTControlledRegistry for this and have publicly available list of know types, so addons could use them and even add it's own. List to be build when needed.

Regarding use side there should be just one function which will return widget on specified position, and one that will take Situation and feed it to widget, no situation state caching - all this needs to be in widget itself.

[PrototypeTrousers]

I struggled a lot with the registry setup so could really use some tips here. Basically functions the same as before, but the widget gets from the registry the additional info.

[LAGIdiot]

First of all good work! You are really putting up good fight with my requests.

Regarding registry setup. I would do it in same way as we have StoneTypes. Two classes one which contains our Situations registrations and one which is Situation. Situation should handle creation and whole registration process if possible in one go. Constructor should get id, name (just short name not full one which you will need for lang files), and state type as enum value (which will be in widget translated to textures). There is no need for holding counter it will be up to registrant not to register with same ID.

Also passing only id to widget seems bit un-intuitive (for synchronization purposes it is required). Regarding used icons and current texts I would like @pyure to say something as he is more UX person them me. There are also some formatting errors but I believe that you will fix them before posting it for verification.

[LAGIdiot]

Also please update name and description of this issue

[LAGIdiot]

This looks good most of things I mentioned seems to be resolved. We may need to extend coverage of this to cases like one mentioned by @ALongStringOfNumbers.

I would like to see this in next minor version update. But for that we need extensive testing given it's size and integration. Which may be little problematic given my broken dev environment. But I will get to it.

Anyway thank you for you hard work.

[PrototypeTrousers]

Single blocks to do: Steam:

• [ ] Boilers
• [ ] Forge Hammer texture overlapping
• [ ] Turbines

Electric:

• [ ] Pump
• [ ] Item collector
• [ ] Diesel generator
• [ ] Gas turbines

Multiblocks to do :

• [ ] Everything
• [ ] Query multiblock parts situation along with controller situation
• [ ] Fit situation type and descriptions to multiblock screen

[LAGIdiot]

I was finally able to take a look at this. Let's start with thank you for not abandoning this in my "absence".

I quickly looked through code and it looks solid, for now I will not do review on it as it needs more work. I think that there was some bad merging done as there are issues with lang file. As some PR touching it which are in master are reverted here (for example numeric formatting and TOP integrations).

I see that you created list of machines which are missing this mechanism which is nice. We may also implement this for Battery buffer, Rock breaker and maybe some other on top of your list.

From quick testing I have stumble onto bug with fisher using missing lang entry when water check fails.