-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Status widget for machines and covers #1303
base: master
Are you sure you want to change the base?
Implement Status widget for machines and covers #1303
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your hard work on this PR. But I think you are trying to mix two things together here which in this case does not blend together that well.
I would like you to split this one to two different PRs. One which will handle multi tank formation to which I added one comment. And second handling loss of capabilities. For which I have this:
If machine does not provide compatibility on some side we have to respect that and it should cover even loss of given compatibility. Let's take for example Brewery and Logistic Pipes. As Brewery does not have output slot it does not have ITEM_HANDLER_CAPABILITY
on its output side. Which we respect by not allowing placing Conveyor Cover on it and others should too. By clicking it with screwdriver we will allow input which means ITEM_HANDLER_CAPABILITY
will be available which will in end allow placing of Conveyor cover on it.
So to handle this correctly we need to do 2 things:
- Correctly handle
defaultvalue
being null in allgetCapability
for covers which means proper checks before constructing these delegates and throwing argument null exception if someone constructs them with null. - Inform Cover GUI that cover is missing "required" capability which prevents him from working so player can have some clue for why it does not work - this one may be quite tricky
src/main/java/gregtech/api/metatileentity/SimpleMachineMetaTileEntity.java
Outdated
Show resolved
Hide resolved
src/main/java/gregtech/common/metatileentities/storage/MetaTileEntityTank.java
Outdated
Show resolved
Hide resolved
c6a4fe7
to
bf1286d
Compare
This comment has been minimized.
This comment has been minimized.
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:
Situations we want to report: 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. |
I struggled a lot with the registry setup so could really use some tips here. |
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 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. |
Also please update name and description of this issue |
8850a5f
to
0a54039
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to say great job on this PR and keeping with my request. There is another bunch of them.
protected TextureArea area; | ||
private boolean isVisible = true; | ||
|
||
public SituationWidget(int xPosition, int yPosition, int width, int height, IntSupplier getSituationId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also there is still lingering my previous comment regarding use IntSuplier
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i couldn't find any other way to sync the widget properly while its open without using it here.
setting it to int will only display the changes when the GUI is reopened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For synchronization you will still need that int id but you can get it from Situation it self
9719ca1
to
af0b2ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am looking that you are doing some good progress on this. I have added some comments you should take look at.
if (this.currentRecipe != null && setupAndConsumeRecipeInputs(this.currentRecipe)) { | ||
setupRecipe(this.currentRecipe); | ||
} else { | ||
metaTileEntity.setSituation(OUTPUT_INVENTORY_FULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a note, the trySearchNewRecipe
method is overridden in MetaTileEntityMultiFurnace
, so it would not benefit from this output full situation being set here. The situation being set should also be added to MetaTileEntityMultiFurnace
.
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. |
01bffe1
to
3ab1317
Compare
Single blocks to do:
Electric:
Multiblocks to do :
|
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. |
we try to push from from the output side every 5 ticks, so some caching of the state is needed to avoid flickering, due to the rest of the logic running every tick
add capability related situation logic to covers
fix pump "tank exported to is full" logic
syncing still is done by rebuild the situation from the registry by its id
cleanup unused variables in the cyclebuttonwidget (hoovering tooltip moved to widget class)
handle null cases
widget updates really slowly due to the ticking logic
avoid iterating the input slots again.
3d8e3ef
to
8e7c421
Compare
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