LuaWindow class

[xoft]

This is getting too exciting, I'm gonna do this

---

Trouble. There are conceptually two different kinds of windows: private and shared. Private means that each player gets their own contents, for example the crafting table. Shared means that all players share the same contents, for example a chest.
If we allow the same cLuaWindow object to be used by two different players, do they get a Private, or Shared type?

Another point of view on this is where to store the actual window contents. If it's in the cLuaWindow object itself, then the only viable option is the Shared type. If we wanted to do Private type, we'd need to store the contents in the cPlayer object for each player. However, that would mean that whenever a cLuaWindow is created, it would need to be bound to a specific player from the beginning, because it would need to create that contents object for that player. Also, we couldn't have multiple window objects "prepared in the background" for the same player at the same time, because their contents could be incompatible in size. Not to mention that currently the cItemGrid class used for remembering the contents doesn't support resizing once it's created. It's technically possible, but feels bulky.

So I'm inclined to implement the Shared type, and if the plugins want something like the Private type, they'll need to create a new cLuaWindow object for each player.

---

A new neato idea for a plugin - we could make a plugin that would allow users to "link" to each other's inventory - each would receive a chest-like window where the top part is shared between them, so one can put items there and the other can take them, or vice versa.

[xoft]

It seems that it will be a bit more involved than just exporting a few API functions. The window object needs to live until the player closes it, which means we will have to tell Lua somehow not to garbage-collect it until then. No idea how to do it yet, but I'll find out.

[xoft]

I have some code, now Lua plugins are capable of opening a window and querying its contents, but there are object ownership issues - either we're leaking memory or objects get deleted twice, nothing in between
Also, for some reason setting items into the window slots doesn't seem to work.

Still, at least a screenshot, this is actually MC-Server opening a Hopper window

[FakeTruth]

Can't you keep a reference to the window in Lua? Then it shouldn't get destroyed.

[xoft]

Yes, but the problem is, Lua created the object, so it will, at one point or another, try to garbage-collect it; but the window object is already destroyed by the code that closes windows for individual players.
I have already fixed that, but now the problem is the opposite - I need a place to destroy the reference once the window is gone; for that, I need the Lua context of the plugin that created the window, etc... Lots of house-keeping for something this simple

[FakeTruth]

That's why I mentioned keeping a reference. Lua will not garbage collect objects that are referenced.

So what I imagine is that the plugin manages the lifecycle of a window. Do not destroy the window in C++ at some point, but let it be garbage collected automatically.

[xoft]

It seems I have managed to wiggle through all the hoops, now the window seems working, only it doesn't have all the callbacks, so I'm adding that.

Not sure yet if OnSlotChange callback is viable for all slots, I'm afraid it's gonna be difficult and I may need to implement it so that it gets called only for the Lua-handled slots (not in the player armor, inventory nor hotbar), at least for the time being.

---

Pure evil! The OnClosing callback can refuse to close the window The player can't do anything then, other than quit MC altogether.

[NiLSPACE]

I can't wait to try this I have an idea for my Login plugin where you can also use a chest with the right pattern to login. ;D I was planning on rewritting it anyway

---

Pure evil! The OnClosing callback can refuse to close the window The player can't do anything then, other than quit MC altogether.

Usefull for my Login plugin

[xoft]

I think you can already try with rev 1534, it should have all that you need. Only the OnSlotChanged() callback is missing, but you don't need it - just check the contents in the OnClosing() callback

Have a look at the Debuggers plugin, as usual, I keep my testing stuff there so it might come in handy as a reference.

[xoft]

I have added the OnSlotChanged() callback, it is called only for non-inventory slots, and it doesn't have the Player parameter. That's because some changes are not caused by a player and it would be difficult for the window object to keep track of what is and what is not caused by a player.

I think the interface is now good enough, so I'll stop here for now.

I know, it's not what has been promised at the beginning, especially the "paid teleport" feature will be quite a bit more involved to implement (don't forget you're not allowed to stash a cPlayer object), but hey, no-one said it would be all that easy