Synchronize temporary Inventory for Trade GUI

[Xaser]

I'm experimenting with player-player trade interactions. I have created an item that, when one player uses it on another player, is supposed to open a trading GUI for both players. Each player is seeing his own inventory, an inventory that is temporarily created for the trade where he can put the items he wants to offer and an inventory that he cannot interact with, which shows the items that the other player is offering.

 

I'm pretty much done with the GUI, using dummy inventories, however no I'm not sure how I should tackle the inventory creation for the "offer"-inventories. Both these "offer"-inventories have to be created on the fly and synchronized to both players.

 

I'm wondering if I can make use of existing structures or if I have to do all the syncing manually using custom network pakets. I have looked at how the inventory for container blocks are created, but they rely on being created together with their TileEntities (which don't exist for my temporary GUI). Possibly I could create a temporary custom entity? would that automatically get synced to all players?

[Animefan8888]

I would use packets or somehow set the server side container for both players to the same one.

[Xaser]

Thanks for the reply. Good to know that they get synced automatically. Still trying to figure out the correct approach here.

 

So obviously the Container will be created once on the server and client respectively in the getServerGuiElement and getClientGuiElement functions of my GuiHandler. (In fact getClientGuiElement will create the Gui which in turn creates the Container).

 

So here's my current idea: When player1 uses the special tade-initiation item, this will call TradeHandler.requestTrade, which will handle all the permissive stuff and so on and create an instance of the Trade class, which is stored in both players using capabilities or something equivalent (i need to store the instance of the Trade in the player so I can access it via the player later in the GuiHandler).

 

Finally, the TradeHandler will call openGui for both players and the respective trade containers will be created in the getServerGuiElement and getClientGuiElement functions respectively... which will also mean that the server has two containers, one for each player..

 

I hope this makes some sense.

 

 

Ignore this (editor bug): be create

[Xaser]

I'm implementing this now. Another quick question that came up was: usually capabilities are attached in the onAttachCapabilitesEvent, which is called at some point during entity creation i presume. However I'd like the capability to only exist if the player is currently in a trade, is there a possibility to attach and remove the capability at any desired time?

[Xaser]

oh right.. now the provider class makes much more sense to me. The hasCapability and getCapability functions are exactly what I need already.. I just didn't see it.. thanks!

[Xaser]

Sorry, I'm stuck again, maybe I just don't get the capability system after all.

 

So I register the CapabilityProvider. However I can only access its getCapability and setCapability functions via the EntityPlayer directly. I have no way of calling another function that the provider might have to set the "trading" state of the player. So I have no real way to externally control when the instance field for the actual Capability in the CapabilityProvider is set. So I cannot make the Provider assign a value to the instance when the trading start and set it to null again, when the interaction is done. Correct? What might be a possible solution?

[Xaser]

Well i'm just trying to find a way to signal to the in-code user of the capability whether or not the player is currently in a trade interaction or not, i.e. hascapability would only return true if the player is in a trade and getCapability would then return an object containing references to both participating players.

If however the player wasn't in a trade, hasCapability would return false and getCapability null.

 

However there doesn't seem to be a way to achieve this directly, so I need another layer, i.e. instead of a Trade capability, I am now trying a "trader" capability.

[Xaser]

ok, almost there.. it was a bit tricky but  it's definitely taking shape.

 

Last question (hopefully): this feature / capability is entirely non-persistent so has no need for a Storage implementation. I cannot pass null however, as this causes an exception. is there a dummy implementation that I can pass? also for IStorage, do writeNBt and readNBT have to return a non-null value?

 

Edit: also, can the default implementation be skipped during registration? I have multiple capabilities that require arguments to be passed to the injector and cannot have a default constructor since they do not function without the proper injection of the owning Entity.

Edited February 26, 2017 by Xaser