03-02-2016, 06:45 PM
Hello, welcome to the forum.
The basic idea behind the cWindow class hierarchy was, that the cWindow and its descendants, such as cCraftingWindow, cAnvilWindow etc. were to be created internally by Cuberite whn the player interacted with the "owners" of the windows - crafting table, anvil... A Lua plugin couldn't create a new instance of such a class. On the other hand, once the window was created by Cuberite, plugins should be allowed to interact with the window. Still, all the operations needed for the interaction are implemented directly in the base class, cWindow. The derived classes mostly only specify what kinds of "Slot areas" the windows contain and how shift-clicking distributes items between the areas.
The cLuaWindow class acts as an "any type" window that can be created directly by Lua, regardless of what the player is doing - so that plugins can open a "chest" window for a player even if there's no chest around. It doesn't provide any kind of extra processing based on the window type, other than adding the armor SlotArea for the Inventory and Workbench window types.
I think you should add the trade-related functions directly into cWindow, that way even Lua plugins can use them both in the built-in windows and the Lua-created ones. It is kind hackish, but it's the easiest thing to do right now.
I believe the cTrade class will need some more interaction than just the windows - it will need storage in the world files, and will be most likely managed by the villagers themselves, so I'd say make it a standalone source file.
The basic idea behind the cWindow class hierarchy was, that the cWindow and its descendants, such as cCraftingWindow, cAnvilWindow etc. were to be created internally by Cuberite whn the player interacted with the "owners" of the windows - crafting table, anvil... A Lua plugin couldn't create a new instance of such a class. On the other hand, once the window was created by Cuberite, plugins should be allowed to interact with the window. Still, all the operations needed for the interaction are implemented directly in the base class, cWindow. The derived classes mostly only specify what kinds of "Slot areas" the windows contain and how shift-clicking distributes items between the areas.
The cLuaWindow class acts as an "any type" window that can be created directly by Lua, regardless of what the player is doing - so that plugins can open a "chest" window for a player even if there's no chest around. It doesn't provide any kind of extra processing based on the window type, other than adding the armor SlotArea for the Inventory and Workbench window types.
I think you should add the trade-related functions directly into cWindow, that way even Lua plugins can use them both in the built-in windows and the Lua-created ones. It is kind hackish, but it's the easiest thing to do right now.
I believe the cTrade class will need some more interaction than just the windows - it will need storage in the world files, and will be most likely managed by the villagers themselves, so I'd say make it a standalone source file.