[Mod] Hoppers

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Fri Mar 31, 2017 07:09

I've made an update to the minetest-mods hopper version, adding a new type of block: a "sorter" node. This is essentially a chute node with an alternate output that you can use to shunt particular items to a different destination.

There is a set of inventory slots labeled "Filter" at the top of this block's inventory display, if you place an item into one of these slots the sorter will record the item's type (without actually taking it from you). Then when items come through the sorter's inventory that match one of the items in the filter list it will first attempt to send it in the direction marked with an arrow on the sorter's sides. If the item doesn't match the filter list, or the secondary output is unable to take the item for whatever reason, the sorter will try to send the item out the other output instead.

Credit goes to Burli for prompting me to do this with his Hopper with hopper sorter fork. I wound up rewriting the sorter entirely when I implemented it here (Burli forked off of the original hopper, which my fork has diverged too far from at this point for easy merging) so my version behaves a bit differently.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Fri Mar 31, 2017 10:39

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.

Currently you set the group for all "chest-like" containers to 2. You could instead have a pre-made function that you reuse as a callback in every chest-like container, and expose this function so other mods can use it for their chest-like containers as well. You could even give it custom parameters like item list name.

Example:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
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,
})

It wouldn't make it any more difficult than it is now, except that you move the chest-insertion code into a callback. If you wanted to keep the search capability, though, you could have groups in addition to the callback. There's no reason you can't have both.

For groups I would just use a separate group for each kind of container, in addition to the generic group for all containers. Every container would be both in the generic group, but also in the specialized group. This lets a mod look for both containers in general and specific subsets of containers, depending on what it wants to do. It also prevents collisions between different container type group numbers that might happen in Mineclone 2 if a mod adds a novel kind of container.

Example:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
minetest.register_node("blah:furnace", {
  -- Other stuff
  groups = {
    container = 1,
    furnace = 1,
  },
})

minetest.register_node("blah:chest", {
  -- Other stuff
  groups = {
    container = 1,
    chest = 1,
  },
})
Every time a mod API is left undocumented, a koala dies.
 

User avatar
texmex
Member
 
Posts: 226
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex

Re: [Mod] Hoppers

by texmex » Fri Mar 31, 2017 14:20

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?
I spend all my days going down to the mines. Under the ground where the sun never shines. Breaking my back I put heat in your house. I’ve got the roar of a digtron, the breath of a mouse.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Fri Mar 31, 2017 17:08

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
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Fri Mar 31, 2017 18:27

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

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.
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Fri Mar 31, 2017 19:34

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.


If I can update drawers to make use of the standard inventory put/take API then that will allow it to more easily interact with any mod that deals in those concepts, not just hoppers. I'd much prefer going that route if I can, even if it's a bit more work up front.

I'll have some time after work today to see what I can do. I've got some ideas just from browsing the code.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Fri Mar 31, 2017 21:09

The "standard inventory put/take API" expects a valid player for one of its arguments, so it's not really a solution for automated insertion/taking. And anyway, there's no reason the callbacks I described would have to be limited to hopper use, it could be used for any insertion/extraction of items.
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Fri Mar 31, 2017 22:14

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
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sat Apr 01, 2017 07:55

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.

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?
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Sat Apr 01, 2017 16:29

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?


Well, this is an unhappy revelation. I was recording the player's name and using get_player_by_name to retrieve the player object when needed, but you sparked sufficient suspicion here that I just did some additional testing and it appears that get_player_by_name only returns an object if the player's logged in. That's not documented in lua_api.txt, you'd think that would be kind of an important detail.

I may have to do some special-case coding for this after all. Or perhaps cache the results of the permission check for when the player is offline, or add a new API call as suggested. How annoying, everything would have worked so elegantly were it not for that omission. At least I wrote the code to fail gracefully on an unexpected nil.

In the meantime, I added a feature to the sorter this morning; a button to disable the filter and turn it into an "overflow" handler instead. When a sorter's filter is disabled it will always first attempt to shunt an item into the filter path (indicated by the big arrow) and if that fails (for example due to the target inventory being full) it will fall back to sending it down the other path. Should be handy when filling an array of chests with a huge amount of material, or when filling selective things like furnaces or drawers.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sat Apr 01, 2017 23:12

I really wish inventories had callbacks that were called for both player and non-player interactions. Maybe something like that could be integrated into the current API in the engine as something alongside the player-specific ones (which might be deprecated).

If hoppers implements its own API then we will have two inventory-moving callback APIs, since pipeworks already has one. Maybe hoppers can use the pipeworks API? Mods don't have to depend on pipeworks to set pipeworks callbacks.

EDIT: Actually, I think inventories shouldn't even need to be the current kind of inventories. Just something with the inventory methods. If callbacks could intercept insertions though, this would basically be fulfilled. Detached inventories can use upvalues to maintain state, and nodes can use node metadata.
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Sat Apr 01, 2017 23:50

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
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sun Apr 02, 2017 01:00

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.

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.
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Sun Apr 02, 2017 01:07

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.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sun Apr 02, 2017 03:16

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.

I was speculating on adding a better engine API in the post you responded with XKCD to.
Every time a mod API is left undocumented, a koala dies.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sun Apr 02, 2017 03:18

What's the "difference in how they're placed" mentioned in the OP? That you get unexpected results if you have multiple things next to a hopper?

Is that why the chests aren't next to each other in the screenshot?

EDIT: Actually looking at the code, the answer is no.
Every time a mod API is left undocumented, a koala dies.
 

FaceDeer
Member
 
Posts: 152
Joined: Sat Aug 29, 2015 19:01

Re: [Mod] Hoppers

by FaceDeer » Sun Apr 02, 2017 03:58

Good news, I was picking through Pipeworks to see if I could borrow its API and I think my original approach might be salvageable after all. Pipeworks does a neat trick where it creates "fake" player objects to pass into the allow_metadata_inventory_take etc. methods. here's where it does the deed. I'm going to try implementing that.

Edit: Seems to be working! The current version of hopper now has fake players implemented for players who are offline.
 

Byakuren
Member
 
Posts: 441
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri

Re: [Mod] Hoppers

by Byakuren » Sun Apr 02, 2017 09:09

I know about that trick and think it's a big hack, but I guess that's fine for working temporarily. It also doesn't account for things like drawers that don't have a real inventory.
Every time a mod API is left undocumented, a koala dies.
 

Previous

Return to Mod Releases

Who is online

Users browsing this forum: Bing [Bot] and 10 guests

cron