Confusion with CapabilityItemHandler and sidedness

[pkmnfrk]

I have a block that acts as a storage provider based on an ephemeral inventory; it doesn't use ItemStackHandler or anything because the inventory is virtual. So, I'm implementing IItemHandlerModifiable manually. However, I'm getting a crash on the client side because the data that I use to calculate the ephemeral storage is on the server, not the client*.

 

I'm not looking for help diagnosing the specific issue, but for help in understanding where it is expected that these capabilities should run properly. Should I be wrapping getSlots(), etc in

if(!world.isRemote)

? Or is it expected that this should all work correctly on the client side too?

 

Or (and this is the most likely scenario) am I completely misunderstanding how this all works?

 

My code, if it helps, is here: https://github.com/pkmnfrk/equivalentintegrations. If it helps, the crash happens here, because the cachedKnowledge List isn't populated, because the client never gets to load the data it would need to do this.

 

 

* - Unimportant background: I'm extending ProjectE and hooking into transmutation data. Technically this is in fact synced to the client, but I'm adding the possibility to use other player's data, which obviously would not be synced. So, I'm try to assume that this is server-side only.

[Animefan8888]

3 minutes ago, pkmnfrk said:

Or is it expected that this should all work correctly on the client side too?

This is true.

 

3 minutes ago, pkmnfrk said:

List isn't populated, because the client never gets to load the data it would need to do this.

Use packets to sync your data to the client.

[pkmnfrk]

Hm... I guess I'm struggling to see why that would be necessary.

 

I guess I didn't mention explicitly, but there's no way for the player to directly interact with this inventory; it's strictly meant for automation purposes. So, there should be no circumstance when the client is trying to view it...

 

*tries things*

 

Oh, actually it turns out that I'm just an idiot, the crash was happening on the server side because I forgot to create the hash map. It has nothing to do anything. ?

[Animefan8888]

4 minutes ago, pkmnfrk said:

Oh, actually it turns out that I'm just an idiot, the crash was happening on the server side because I forgot to create the hash map. It has nothing to do anything. ?

I've been there.

5 minutes ago, pkmnfrk said:

I guess I didn't mention explicitly, but there's no way for the player to directly interact with this inventory; it's strictly meant for automation purposes. So, there should be no circumstance when the client is trying to view it... 

Then you don't need to do anything on/for the client.

[desht]

By the way, you mentioned that you don't use ItemStackHandler because your inventory is "virtual" - there's still nothing to stop you using it, and if you just need a simple inventory to hold a collection of items, it's by far the best option; you get some robust and well-tested code for free.  If you need any custom handling (e.g. only allow certain items in certain slots), there's also nothing stopping you from subclassing it.

 

(Of course, there may be good reasons to have a custom IItemHandlerModifiable implementation, but ask yourself if it's absolutely necessary).

Edited July 13, 2018 by desht

[pkmnfrk]

I understand what you're saying, but in this case, it would be far more effort to synchronize the non-virtual inventory of the ItemStackHandler with the actually virtual data that I'm presenting. Some background:

 

I'm creating an addon for ProjectE that exposes a player's transmutation data as an inventory for automation purposes. If you're not familiar with ProjectE, it allows you to convert items to/from a currency called EMC. Eg, a piece of cobble is worth 1 EMC, while a furnace is worth 8 (because it's crafted from 8 cobble). You can sell the furnace to get 8 cobble back, or another furnace, or any other 8 EMC worth of items.

 

So, what I'm doing is taking the player's knowledge (which is a list of every Item they've put into this system), and their current EMC, and exposing how many of each you can make at the moment. So, if you have 64 EMC and knowledge of Cobble and Furnaces, then I expose 64 Cobble and 8 Furnaces. If one of these items is withdrawn, I deduct the EMC, and update the book keeping internally. Similarly, if you insert an item, I basically void the item stack and credit you the EMC.

 

Therefore, there's two tricky parts that ItemStackHandler wouldn't really help with:

 

1. These virtual slots change quantity based on how much EMC you have, not based on how many items you have.

2. The idea of slots is very nebulous. You can't move items arbitrarily, and the size of the container depends on how many items you know about, since this list is coming straight from an external data source (ProjectE's api)

 

I agree that it would be possible to overcome this, but I suspect that I'd have to override every single method with implementations that look very similar to what I have, plus some extra code to sync with ItemStackHandler's idea of inventory. The only part I wouldn't have to touch is the NBT serialization, and that's because I don't need to save this inventory at all (because it doesn't really exist)

 

TL;DR: I did think about it

 

Edit: My implementation is complete, and is part of the repo I mentioned in the OP. The one thing I did poorly that I'll probably refactor today is that I implemented it as part of the TileEntity, and I should probably have made it it's own class. I just need to think about how to do that properly, but that's a different matter

Edited July 13, 2018 by pkmnfrk

[Draco18s]

Just make this a subclass of the existing ItemStackHandler class that overrides the extraction and insertion code to do that synchronization. When an item is inserted, convert it to a stack of cobble, and insert that into the super implementation.

 

When non-cobble is extracted, give the player the stack without reducing how many of that stack is available for extraction (unless their EMC falls too low) and modify the EMC available based on its cost.

[pkmnfrk]

I can't stress this enough; I looked at ItemStackHandler, and I need literally 0% of that code. I promise. I have no interest in actually storing any items, they turn directly into EMC at the threshold.