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).
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).