Minecraftforge: More Flexible IGuiHandler

[SonarSonic]

Hey,

Just wondering if it would be possible to get a more flexible IGuiHandler which would allow more arguments apart from just the GUI ID. In some cases such as with MCMultipart you need to know the parts UUID as well as the GUI ID.

Thank you,
Ollie

[williewillus]

The xyz arguments basically give you an extra 96 bits to use. Those don't necessarily have to be coords.

(still doesn't solve the uuid problem though which needs 128 bits)

[raoulvdberge]

I agree with what @SonarSonic says. To give an example, I have an item which opens a GUI. Said container needs to know in which hand the item is, so I pass an ID in with the x argument. While this works, it's not neccesarly clean / ideal.

[SonarSonic]

@williewillus good point, i'll hack it slightly. I already have the UUID synced anyway so I can use the hashcode to get that. Although this works for me, I still think we need more than one arg. I tried writing one myself, everything worked apart from the mouse didn't appear when the gui opened, which was really strange.

[mcenderdragon]

@SonarSonic I guess you opened the Gui from the Netty Thread? It must be the main thread, duno why.
And why dont we use an Integer array ? they can have many args, but are also easy to sync over netty.

[williewillus]

Legacy, guihandler was written ages ago :p

[LexManos]

THere really isnt any more reason to have more data in this packet, you have enough to identify as much information as you want.
Ive yet to see a instance where you cant get the information you need to fit into 128 bits. {x/y/z/id}
The problem with switching to some arbitrary thing, such as a raw buffer or a NBT is that it just asks for the packet to explode and it breaks the backwards compatibility of the network protocol that more then just forge uses.

[mcenderdragon]

This means if we patch more data in it, we will break other stuff. It whould be also bad if we implement some kind of new system with custom args, right?

[SonarSonic]

@mcenderdragon Thank You!!! Got my custom GUI handler working now :)
@LexManos Okay that's fair enough, I guess I hadn't thought of using the x,y,z to begin with, it is a pretty rare case thing, hopefully MCMultipart adds support for this itself.

[amadornes]

Yeah, @SonarSonic, I'm already working on something :)
Which reminds me... @LexManos I have to talk to you about FMP when you have time. I've been waiting for you to review some code for over a month and a half which I have a feeling didn't even make it to you... and I'm scared to remind you because you don't like people asking the same thing over and over :P

[AEnterprise]

i have a usecase for this: if you have multiparts (like descripbed above) with parts that go on cables, you can have multiple of the same part on that cable, they thus share the same xyz and the same guiID

[SonarSonic]

@AEnterprise Yeah that was my situation, i've got my workaround working now, but it's not pretty.

[mcenderdragon]

@AEnterprise but theoraticaly its another gui, isnt it?

[AEnterprise]

@mcenderdragon another GUI yes, but how can that be determined? when opening the GUI you'd have to somehow determine that there are 2 in the blockspace and give both an unique ID, both on the client and server

[mcenderdragon]

you have 32bit so you could use 12bit for the Block ID an aditional 4bit for the metadata. the server has also the mutliblock, so it could check wich block is meant. (I now, this is not a very good solution)

[HenryLoenwind]

BTW/FYI: Don't forget that a BlockPos serializes into 64 bits with its toLong() method. That means you still have 32 bits in the x,y,z tuple after encoding a BlockPos.

[Actuarius]

@mezz added labels [Feature]

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time, and will be closed if no further activity occurs. If this issue was overlooked, forgotten, or should remain open for any other reason, please reply here to call attention to it and remove the stale status. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.