Cuberite Forum

I think we've hit the spot when patching up the cWindow and the jewelry around it is no longer feasible. It's time for refactoring this part of the code. Currently (rev 850-ish), chests aren't working and some windows are near impossible to implement (doublechest).

I propose a change like this:
A window is made up of several "areas". These areas each correspond to slots with a similar purpose. For example, the inventory area, or the crafting grid area, or chest storage area. Each area knows its items, the number of slots and whether it's per-player (inventory), global (chest) or temporary (crafting grid). A common ancestor for the area classes knows how to handle clicks within that area.

A window, then, is a collection of these areas, with slot numbers assigned ascending for each area. The window object is then just a simple container class that redirects click events to the individual areas and receives update commands from areas (furnace smelting etc.) A Window can be bound to a block (chest) or to an entity (player, storage minecart). A single window object can be shared among multiple players.

As for shift-clicks, they are moving stuff between areas automagically, so we need a way for an area to call out to other areas and ask them, "Do you want this stack? And how much of it?" This should be easy to route through the parent window. If not for any reason, then the parent window could be subclassed for the wanted functionality.

Comments, ideas?

I support this change.
So, doublechest would be like two single-chest-like areas, right?

I would also like to have two simple functions in the lua API: "TakeItemsFrom" and "GiveItemsTo" - appliable to chests, furnaces, inventories. "TakeFrom" should take items, return false if there wasn't any items of specified ammount and integer value for taken ammount otherwise (for example, we take 30 apples, but there are just 2 of them in the chest, so function will return 2).
Is it possible to make them work this way? (I don't remember cInventory class capabilities)

Or am I missing something, and window is not equivalent to generic "item container"? (Because it basically is the same thing)

Sounds good

(09-10-2012, 06:40 AM)Taugeshtu Wrote: [ -> ]I would also like to have two simple functions in the lua API: "TakeItemsFrom" and "GiveItemsTo"

This doesn't concern the windows at all. The windows are all about UI on the clients, while you're after something modifying the underlying data. The two functions you'd like to have would make more sense to be implemented directly in the cChestEntity class (and possibly, in cInventory).

So, to recap: cChestEntity stores the items, cUIChestArea handles the clicks (manipulates the cChestEntity's storage)

---

Double chest could be represented either by two singlechest areas, or it could be a single chest area with double the height and two underlying cChestEntity objects. Not sure yet which one would be better.

Quote:Not sure yet which one would be better.

the one that would make it easier to get drops when one part of the chest is broken

Quote:The two functions you'd like to have would make more sense to be implemented directly in the cChestEntity class

Got it!

Question: do we need two separate clases for inventory, cSurvivalInventory and cCreativeInventory? The client treats the inventory as one, so there's really no point to distinguish class-wise. We could have just two cIntentory instances for each inventory contents, if we want to keep them separate. And we could even make the inventory shared between creative and survival (that's what vanilla does)

i know this is windowing refactoring but do you think you can also make the enderchest work?

later, when the windows are working again. It will be much easier to implement once I get this refactoring done.

ok do you have any idea how long it will take for the refactoring?

Sorry, no. Could be two days, could be two weeks. I haven't looked much into possible problems in detail, so it's possible I'll run into something unexpected.