03-14-2016, 10:55 PM
I think you should approach this from a different perspective.
All UI Windows in Cuberite are basically containers of cItem objects, organized into cSlotArea instances that provide the behavior. So I think the trade window needs a special new cSlotArea descendant that will handle the actual trade. The trade template itself should be stored in an array within the cVillager object for the villager who is offering the trade; the player should have a link to the villager with whom they are interacting, together with an index into the trade array. The trade template should be a simple container of three items and possibly some flags, as needed for the protocol currently: http://wiki.vg/Plugin_channel#MC.7CTrList
As for the actual data being sent to the client, this is protocol-specific and should be handled in the protocol handlers, I would personally edit cProtocol180::SendWholeWindow() - if the window being sent is a trade window, send the Tr|List plugin message as well (call a new virtual function cProtocol180::SendTradeList()).
It would be great to actually abstract the trading away from the cVillager class and instead create a cMerchant abstract class that declares the interface for "trading" - stores trade templates and actually processes the trade ("you give me X and Y, I give you Z and like you more and possibly have another trade for you"), each as a virtual function that is implemented by descendants.
All UI Windows in Cuberite are basically containers of cItem objects, organized into cSlotArea instances that provide the behavior. So I think the trade window needs a special new cSlotArea descendant that will handle the actual trade. The trade template itself should be stored in an array within the cVillager object for the villager who is offering the trade; the player should have a link to the villager with whom they are interacting, together with an index into the trade array. The trade template should be a simple container of three items and possibly some flags, as needed for the protocol currently: http://wiki.vg/Plugin_channel#MC.7CTrList
As for the actual data being sent to the client, this is protocol-specific and should be handled in the protocol handlers, I would personally edit cProtocol180::SendWholeWindow() - if the window being sent is a trade window, send the Tr|List plugin message as well (call a new virtual function cProtocol180::SendTradeList()).
It would be great to actually abstract the trading away from the cVillager class and instead create a cMerchant abstract class that declares the interface for "trading" - stores trade templates and actually processes the trade ("you give me X and Y, I give you Z and like you more and possibly have another trade for you"), each as a virtual function that is implemented by descendants.