Posts: 4
Threads: 1
Joined: Mar 2016
Thanks: 2
Given 0 thank(s) in 0 post(s)
03-02-2016, 10:28 AM
(This post was last modified: 03-02-2016, 04:46 PM by Fighter19.
Edit Reason: Removed not important information.
)
Currently I'm trying to create a class to create the trade window, especially for use with Plugins.
The Problem I'm facing is, I've made the functions available towards the LUA interpreter and I'm now wondering if that's ok,
because my Class is just like the other classes (AnvilWindow, etc.) which are not exposed to LUA (ofc, with the exception of cLuaWindow).
Also I'm wondering whether it's ok to introduce a new class called "cTrade" inside the same files used for the Window.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
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.
Posts: 4
Threads: 1
Joined: Mar 2016
Thanks: 2
Given 0 thank(s) in 0 post(s)
03-08-2017, 05:58 AM
(This post was last modified: 03-10-2017, 12:18 AM by Fighter19.)
I meant that cItems might be enough to serve for the purpose of storing the trading template.
However deriving an extra class out of it could add more readability to the code.
(e.g having a functions like "AddSellItems AddResultItem" makes it easier to read understand and also would provide a better interface to use for the LUA interpreter).
By cTrade I was referring to the class that is meant to store the template.
EDIT: I think this is necessary because it's possible for multiple trades to be selected in one Window. So cTrade would be a container of multiple cItems which represent the trades.
Maybe it should be named cTradeList, then.
My current plan goes as follows:
Derive cSlotArea to cSlotAreaTrade, add functionality.
However for this to work, cSlotAreaTrade needs to be provided an instance of cTrade.
Normally I'd think I should retrieve this from the parent window.
This would however mean that the parent window is a container of the trade object.
So I'd add a pointer to a cTrade instance into cLuaWindows as a member. I'd move it over to cWindow as soon as it can be retrieved from a villager.
(Or optionally a own class could be made for TradingWindows regardless of if LUA or normal).
Also functionality like SetTradeList would be added to cLuaWindows and SendTradeList to the protocol interface as well as the implementations.
Then when there is an interaction with the slots, cSlotAreaTrade would try to cast it to a LuaWindow, if it worked and it has wtNPCTrade then it will use the Trading List from there, to see if the items provided are the correct ones. If they are, the item will be set into the result slot, and can be dragged.
EDIT2:
I just started implementing it and I ran into following problem:
cLuaWindow allows any size to be accepted.
But a simple trade window actually doesn't hold any items itself (Unlike chests or furnaces for example).
So creating the window with size will shift the inventory on the client but not on the server (and thus cause the inventory states to differ).
It might be easier to just use a seperate class for Lua Trade Windows.
Also none of the other similar window (e.g Anvil) provide functionality when used with LUA.
EDIT3:
I think there should be at least two LUA classes, one that provides functionality and one that leaves everything up to the scripter (as it's currently the case).