Justenoughitems: Suggestion for 1.10.2

[Speiger]

I noticed that Recipe Buttons are bound to gui classes.
I just made a gui system that shares 1 Gui Container Class for almost every machine/block and that means i can not register a button area without having to Reflection call myself into JEI to inject a custom class into it...

It would be nice if you could make a Interface that allows you to validate the button for the gui itself.
(isValidForGui(T guiInstance)) or something like that.

[AEnterprise]

why do you only have 1 class for multiple machines? doesn't that make things more complex then they need to be?

[Speiger]

@AEnterprise well its better to have 1 class where i inject the texture and do not have repeating code. The difference between the machines is just the recipe list. Their Code is 100% Equal on Gui Stuff so instead of having 10 Differend classes with the same code i have 1 class with the Texture Requested from the TileEntity...

Note: I am refering to the "Macerator, Extractor, Compressor, Recycler, Electric Furnace and their AdvVersions"
Instead of making 5 TileEntity Classes, 5 Gui Classes, 5 Container class which are basicly 100% Equal except the Texture i am making 5 TileEntity Classes, 1 Container, 1 Gui. (5 Tiles to prevent networking bugs and some other variant things) and save a lot of Extra Time to programm something and i get only benefits from that.

[AEnterprise]

you can just have that 1 gui class with subclasses extending the main one then, that way all the common code is in the main gui but you have different classes for jei to use

[Speiger]

So you want me to readd for every machine a extra gui class that has no code in it "No use" wasting ram and space and making the code more dirty just to make a feature work?
You know that NEI allowed to add buttons yourself based of the Gui Data. And @mezz could add that without performance issues.
Also what if you machine has multipurpose like an EnderIO Alloy furnace?

Also that kind of feature is supported by the "GuiSize" so why not with the recipe button?

[AEnterprise]

i don't work on JEI myself so mezz could have a different opinion

but as your concern is adding overhead your sugestion would make matters worse, yes you need to add classes, if your subclass has no added fields the ram usage would be identical, these subclasses don't need anything more then just a default constructor calling the super one but that would just replace the constructor calss with those params you are currently using. the only difference that would occur would be a few bytes in memory usage that you wouldn't even notice (due to class names).

while adding this would require JEI to call that check every time a gui opens. granted in most cases it will just instantly return true but it's a check to be done. the added code to all the gui's that integrate with recipe buttons into JEI would also need to implement this, thus adding a few bytes to all of them as well

TL;DR: it wouldn't make a difference to RAM usage, would add slight (but not realy noticable) overhead and would be more work to add then just making a few "empty" subclasses

[Speiger]

@AEnterprise if you want to make that do it i do it the way i think its ok.
Also JEI Loads the buttons to the gui always when the gui loads the only thing is: the iterator just gets a isAllowed check. Thats it.

[AEnterprise]

i know it wouldn't be a massive check, i'm just saying that from a performance point of view the difference would not be noticable but it would more code and an additional check

this would just move the 'dirty' (as you call it) to JEI code while i don't agree that adding a subclass with no constructor agruments calling the super with arguments is dirty code, nor does it have a performance impact (as i mentioned above)

ultimatly it's up to @mezz to decide, just thought i'd share my insights to the performance aspect you mentioned that i think is incorrect

[BionicFelps]

He's right, this is a prime example where inheritance should be used, a base class containing the gui code, and sub classes containing the recipe list for the individual machine, it separates the common code from the uncommon code, it doesn't really add any extra code.

[Speiger]

@BionicFelps well that differend classes for Differend recipe lists exists thats ok but i dont do that a double. Basicly Thats why i have subTileEntity classes to make that happen... Why should i do gui classes on top of that which have basicly a constructor and just make just bigger for no needed reason.

[AEnterprise]

there is a reason to do it: to allow JEI and any other mod that reacts to the inventories of other mod gui's to see the difference between them.

as you say: it's basicly a class that only extends and has a constructor, not much work to implement, just a few lines of code each and then replacing the constructor calls to the new ones

and please stop trying to use performace arguments (saving ram, no bigger classes, ...) as they are completely invalid in this scenario. while the performance impact of both is small and the end user won't ever notice it there is a difference: adding this functionality to JEI would mean and extra check to perform on ALL the recipe gui's, this would be a useless check (always returning true) on all the mods except for your mod.
this means extra work for nothing in all the other mods and your mod will be doing checks in that function.

while if you just make those classes there is no extra work to be done for things to work, the detection will heapen in the already existing checks, and no extra code/checks taking up that memory you are so concerned about for some reason

[Speiger]

First you dont use a gui class to see the difference in a gui. Secondly how many mods actually do it?
And again its making work cleaner while supporting a feature for multipages which you really cant do with the current system. I have for example a gui that has 6 pages on 1 gui and should i make now 6 new classes because it has 6 differend pages? Just to allow the buttons to be in 6 differend positions and not colide with each other?

[AEnterprise]

@Speiger now you are just contradicting yourself, please open play with your guis in a test world and look at your code, then give us the full picutre about what's going and what the problem is

first you say this is about multiple blocks/machines sharing the same class (where we provided an alternative for) and now suddenly it's a single machine gui with 6 tabs?

your 'solution' would not work in this case eighter, if they all need seperete recipe buttons some JEI hook would indeed be needed but not the one you are proposing. the isValid() woudl only run when your gui opens and JEI hooks into it, you would have to use the api (if its possible already or else a hook might be needed) to tell JEI that the gui has changed and it needs to pretend that a new one has opened

i don't know the gui but is it also realy needed to have 1 gui make 6 different types of recipes? it sounds like a machine that would seriously confuse the mod users

[Speiger]

Basicly: Supporting a SingleGuiClass for multible machines should be supported.
@AEnterprise i doubt you have reasons against that kind of system.
And i am running into issues because you just imply to me "I have to use the current system no matter what" and i try to be nice and deliever you something that you can agree with but you cant it seems and i am running out of things to give you so you shut yourself up. So let @mezz decide instead of telling me my stuff is bad... Because i got a lot of improvements out my stuff...

[AEnterprise]

i never said i was against a system that supports a single class for multiple machines, i just said i don't see the need for it and pointed to an alternative

i also never said "you have to use the current system no matter what", all i did was point to how you COULD do it with the current system

nor did i ever say your stuff was "bad" (nor did i had the intention to imply that if you think that our of my comments) so please don't try to put any words in my mounth i never said

thanks for trying to find something everyone can agree on (thoug in the end it's @mezz who has the final say indeed), i just thought the point of this issue was to get JEI working fully with YOUR mod guis, not some abstract system you would like it to support (that again can be done already, just fire the right gui events)

also i'm happy you are trying to optimize your mod's footprint, more modders should do that. however in this case none of your performance related arguments where valid, if anything i beleive this would be worse for performance then adding a few classes and/or firing some events yourself

[AEnterprise]

in any case i'll 'shut myself up' as you put it so 'kindly' as this discussion is getting pointless, arguments have been made and it seems this has gone from supporting a specific usecase to a general gui system (that is used to much i can't even think of another mod that does the same thing), that's something only @mezz can decide on what to do with

in any case my apologies letting this go on to this point to @mezz and any others, seems that i made this from a issue about support for something into a pointless discussion

[mezz]

adding this functionality to JEI would mean and extra check to perform on ALL the recipe gui's, this would be a useless check (always returning true) on all the mods except for your mod.
this means extra work for nothing in all the other mods and your mod will be doing checks in that function.

This is the crux of the issue for me. I do not want to make changes to the API or add complexity for the benefit of a very unusual case that can be worked around. Sorry Speiger.

[mcenderdragon]

Does jei has methods to add these Buttons after the GUi is opened ? If this methods (and also clearing methods) would exists then the api change whould be only adding some static functions and also the problem with the gui tabs would be fixed.

[mezz]

There is an alternative method to adding buttons to open recipe categories using the API:
IRecipesGui#showCategories(List<String> recipeCategoryUids)
This will require you to detect that JEI is present, and add your own button, but it will should work cleanly for you.

[Speiger]

adding this functionality to JEI would mean and extra check to perform on ALL the recipe gui's, this would be a useless check (always returning true) on all the mods except for your mod..

Nope it does not have to effect all mods that already use that system. I mean you managed to change JEI Item injection System to the recipes without even causing modissues using the old system.
What i ask for is a optional function which can add a validator for the button beeing added.
And when the buttons are loaded then you have this special if inside it:
@Nullable public RecipeClickableArea getRecipeClickableArea(GuiContainer gui, int mouseX, int mouseY) { ImmutableCollection<RecipeClickableArea> recipeClickableAreas = recipeClickableAreasMap.get(gui.getClass()); for (RecipeClickableArea recipeClickableArea : recipeClickableAreas) { IRecipeButtonValidator valid = recipeClickableArea.validator; if ((valid == null || valid.isGuiValid(gui)) && recipeClickableArea.checkHover(mouseX, mouseY)) { return recipeClickableArea; } } return null; }
That has no change inside of your API its compatible to other mods even if they wont use it and it supports single guis systems

[mezz]

@Speiger please see my reply for an alternative method you can use without changing your gui system at all.

There is an alternative method to adding buttons to open recipe categories using the API:
IRecipesGui#showCategories(List recipeCategoryUids)
This will require you to detect that JEI is present, and add your own button, but it will should work cleanly for you.

[Speiger]

Doesnt work. Independent mod is the first rule of what i am doing. Tha would add a dependency.
I would have to write it inside of my gui code... Optional can do only so much but not everything since all plugins are optional and you can shut them down. with this dependency it is not possible.
(And yes even the JEI Plugin that you load goes over my plugin validator before it actually loads stuff)

[mcenderdragon]

use reflection

[mezz]

Sorry Speiger but I'm done discussing this.
You have options that you choose not to use.
Plugins are only disabled if they are crashing. You can safely depend on JEI with Optional for this case.
This is not an issue for me to solve.

[Speiger]

Totally fine. if you dont want to support that thats not a problem.
That only means people will have to use jei to get to the recipe area.

[AEnterprise]

you don't want a dependency? put the call to the JEI api in a static function in a helper class, only call the helper class after you checked JEI is loaded, then nothing can crash is JEI isn't present yet it does it's job when JEI is installed

[Speiger]

@AEnterprise That doesnt work for Optional since i would asm the Class out. Because i have a secondary option. And a static function to a class which is then redicted through 2 other classes with a HashMapCall + a != null check + 2 instance call is not really helping it. Its not worth it... The code is bigger then it needs to be.

[way2muchnoise]

If a class never gets loaded in you don't need to make it optional. Just have some class managing with mods are loaded. And an other that has the JEI calls. If you never actually call the JEI class it won't be loaded in thus not causing Missing class errors.

[Speiger]

Facepalm.... thanks for the area. @mezz could you lock this conversation i think we talkt enough.