Skip to content
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

Rework Multiblock Abilities #2420

Open
wants to merge 112 commits into
base: master
Choose a base branch
from

Conversation

ghzdude
Copy link
Contributor

@ghzdude ghzdude commented Mar 19, 2024

What

Reworks IMultiblockAbilityPart to allow for multiple abilities from one part.
MultiblockRecipeLogic checks if an item handler could also be a fluid handler (only for distinct mode atm)
Implements a ghost circuit slot for single-tank fluid input hatches.

Implementation Details

add a class to MultiblockAbility's constructor so that class types can be checked
add a new class to store instances of a MultilbockAbility. types are checked and an exception is thrown when the wrong type is added.
a new class, DualHandler, is added to implement item and fluid handling capabilities. (not used for anything atm)
Should multitank fluid hatches (quad/nonuple) have ghost circuits as well?

Outcome

fluid hatches are more spooky

@ghzdude ghzdude added the type: refactor Suggestion to refactor a section of code label Mar 19, 2024
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 0c22cbd to 6b8c11a Compare March 19, 2024 20:09
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch 2 times, most recently from b58ef1c to f6b840f Compare April 6, 2024 06:48
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 6bdc2d7 to 6d0fcf2 Compare April 14, 2024 16:52
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 6d0fcf2 to dff15e9 Compare July 4, 2024 20:01
@ghzdude ghzdude marked this pull request as ready for review July 4, 2024 23:03
@ghzdude ghzdude requested a review from a team as a code owner July 4, 2024 23:03
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 829ea5f to 04ad422 Compare July 6, 2024 02:51
Comment on lines 352 to 370
for (IMultiblockPart multiblockPart : parts) {
if (multiblockPart instanceof IMultiblockAbilityPart) {
@SuppressWarnings("unchecked")
IMultiblockAbilityPart<Object> abilityPart = (IMultiblockAbilityPart<Object>) multiblockPart;
List<Object> abilityInstancesList = abilities.computeIfAbsent(abilityPart.getAbility(),
k -> new ArrayList<>());
abilityPart.registerAbilities(abilityInstancesList);
for (IMultiblockPart part : parts) {
if (part instanceof IMultiblockAbilityPart abilityPart) {
List<MultiblockAbility> abilityList = abilityPart.getAbilities();
for (MultiblockAbility ability : abilityList) {
List abilityInstancesList = abilities.computeIfAbsent(ability,
k -> new ArrayList<>());
abilityInstancesList.addAll(abilityPart.registerAbilities(ability));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens here if a single multiblock part has IMPORT_ITEMS and IMPORT_FLUIDS, but the multiblock only allows one of these in the structure at that position. Should the part be allowed or rejected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a method that skips adding abilities at certain positions, but should i just invalidate the multiblock instead?

@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 3700d34 to bfd2e2f Compare July 11, 2024 23:26
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from fd8136b to 4ac4934 Compare July 27, 2024 00:00
return isExportHatch ? MultiblockAbility.EXPORT_FLUIDS : MultiblockAbility.IMPORT_FLUIDS;
public @NotNull List<MultiblockAbility<?>> getAbilities() {
return isExportHatch ?
Collections.singletonList(MultiblockAbility.EXPORT_FLUIDS) :
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the slots for filling fluid containers technically not count for abilities here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think it makes sense to include the IO slots when searching for a recipe

@ALongStringOfNumbers
Copy link
Contributor

Should the reservoir hatch also get a circuit slot?

@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 7f5f0be to 7e2e27a Compare February 3, 2025 22:02
Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will take a look at the Fluid Hatch GUI stuff next time

if (items instanceof IMultipleTankHandler tankHandler) {
tanks.addAll(tankHandler.getFluidTanks());
}
return new FluidTankList(getInputTank().allowSameFluidFill(), tanks);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this takes allowSameFluidFill from the normal input tanks, but does not take into account if any of the dual handlers discovered set this value to true. Do we want to check if any of the discovered tanks have this set to true, and if so pass that to the FluidTankList? Or what happens when a dual handler allows same fill, but normal hatches on the multiblock do not?

* Entry of multi fluid tanks. Retains reference to original {@link IMultipleTankHandler} for accessing
* information such as {@link IMultipleTankHandler#allowSameFluidFill()}.
*/
private static final class MultiFluidTankEntry implements ITankEntry {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sort of confused why we need this class in the first place. The incoming fluid data is wrapped into this MultiFluidTankEntry, but then immediately unwrapped into an ITankEntry.

}
}

return new FluidTankList(allowSameFluidFillForOutputs(), tanks);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question about if the DualHandler allows same fill, but the normal hatches on the structure do not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the tanks are already wrapped, then they should respect the setting of their parent fluid tank list

Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got this error in the log when I was playing around with the reservoir hatch,

[22:41:51] [Client thread/ERROR] [modularui]: Tried to open a panel, but a panel handler that opens the same panel already exists. Using existing panel handler!

Repeat by shift clicking the circuit slot, set a circuit number with shift click, and then shift click the circuit slot again and set a new number with shift click.

super.initializeInventory();
if (this.hasGhostCircuitInventory()) {
this.circuitInventory = new GhostCircuitItemStackHandler(this);
this.circuitInventory.addNotifiableMetaTileEntity(this);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to add the fluid hatch to the notified list? Since the hatch can never perform any recipes. We get the multiblock in the add to structure override, but I don't think there is any need for the hatch itself to be notified, is there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk, every other usage of GhostCircuitItemStackHandler does this as well, but it doesn't seem to be needed?

@ghzdude
Copy link
Contributor Author

ghzdude commented Feb 24, 2025

Got this error in the log when I was playing around with the reservoir hatch,

[22:41:51] [Client thread/ERROR] [modularui]: Tried to open a panel, but a panel handler that opens the same panel already exists. Using existing panel handler!

Repeat by shift clicking the circuit slot, set a circuit number with shift click, and then shift click the circuit slot again and set a new number with shift click.

this is because the ghost circuit slot calls IPanelHandler.simple() on each mouse click. it isn't really the ideal way to handle the popup, but that should be changed in the rc4 pr imo.

ghzdude added 28 commits March 3, 2025 22:48
…nstead of sealed class

casually rework DualEntry to not be an item handler
fix distinct fluids
spotless
clarify existing check at set
use simple name instead of class string
remove unused methods
simplify AbilityInstances a bit
remove exception throwing
remove getAbilitiesModifiable()
add contains check
rename delegate methods
add annotations
add javadoc
remove unused method
add toString to instances
@ghzdude ghzdude force-pushed the gh-mutli-abilities branch from 0b42db8 to 83a4325 Compare March 4, 2025 05:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: refactor Suggestion to refactor a section of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants