Wuzzy wrote:I don't really understand your callback approach, to be honest. But if you say that every chest-like node now must supply its own callback functions, this is clearly the wrong way. There are many many nodes in Minetest mods which are basically just chest variants which behave like the Minetest Game chest. And the callback code would essentially be the same for all chests.
function blah.make_chest_callback(listname)
return function(pos, itemstack, source_pos)
-- Put the stack in the specified item list
end
end
blah.generic_chest_callback = blah.make_chest_callback("main")
minetest.register_node("blah:chest", {
-- Other fields
hopper_callback = blah.generic_chest_callback,
})
minetest.register_node("blah:furnace", {
-- Other stuff
groups = {
container = 1,
furnace = 1,
},
})
minetest.register_node("blah:chest", {
-- Other stuff
groups = {
container = 1,
chest = 1,
},
})
texmex wrote:Not relating to the immediate discussion in this thread, but I will try the sorter node out later because the new feature sounds great. A dream situation would be for it to work in conjunction with the freshly released drawers mod, don't you think?
FaceDeer wrote:texmex wrote:Not relating to the immediate discussion in this thread, but I will try the sorter node out later because the new feature sounds great. A dream situation would be for it to work in conjunction with the freshly released drawers mod, don't you think?
Just had a look through drawer's code and compatibility will require a bit of work. A drawers node doesn't actually have an inventory, when you "put something into it" it records the item's name and quantity as metadata values. So none of the standard inventory add/remove callbacks exist, I'll have to add them to the mod and submit a pull request.
I'm liking the concept of drawers, it's very elegant from a player's perspective. Would have loved to have something like this back when I was playing instead of modding. :)
Byakuren wrote:Maybe you can allow the user to optionally specify a function instead of an inventory list name when defining a container? If you want to both take and put items, you would need to take two functions, though.
FaceDeer wrote:My version of hoppers keeps track of the player who placed the hopper in question and passes that in the parameters for the inventory callbacks, this allows them to make appropriate use of locked chests and other protected inventories.
Sure, the new callbacks could be used by things other than hoppers. But it's better to avoid the proliferation of new APIs and interfaces when there are existing ones covering this use case that are documented in the main lua_api.txt and that every modder knows already.
Byakuren wrote:What do you mean keeps track of the player? Keeps the player object around (by saving it in an upvalue or table field or somewhere)? You will have issues if the player logs out or their object is otherwise invalidated. You could limit use to when the player is online, but wouldn't that be too limiting?
Byakuren wrote:I really wish inventories had callbacks that were called for both player and non-player interactions.
FaceDeer wrote:Byakuren wrote:I really wish inventories had callbacks that were called for both player and non-player interactions.
Some standards are good, so more must be better I guess. :)
I've worked with Pipeworks compatibility in the past and it wasn't too bad, I'll see if I can have hoppers take advantage of existing Pipeworks interfaces when they already exist. That'll simplify things for implementers somewhat. Maybe I can even have hoppers automatically register pipeworks-enabled nodes. And I can provide "template" functions for implementers to make use of that should easily cover a lot of the basic cases - the owner check for locked chests just requires comparing the placer's name to the owner's name, for example, a simple string comparison between two metadata values.
This is doable. It's just annoying that it needs to be done (and that the documentation misled me into thinking it didn't). The existing API was so close to handling it.
Byakuren wrote:I wish people would stop posting this xkcd comic when it barely applies. A better API in the engine would prevent proliferation of similar APIs.
FaceDeer wrote:Byakuren wrote:I wish people would stop posting this xkcd comic when it barely applies. A better API in the engine would prevent proliferation of similar APIs.
But we don't have that better engine API, so proliferation ahoy it seems. I think that makes the comic applicable here. I don't want to add custom stuff, and will strive to avoid it if at all possible, but it now looks impossible in this situation.
I'll spend my evening on this project and see what I can manage.
Users browsing this forum: No registered users and 5 guests