Time  Nick      Message
13:21 sfan5     merging #17004, #16871 soon
13:21 ShadowBot https://github.com/luanti-org/luanti/issues/17004 -- Work around glObjectLabel problem with GLES by sfan5
13:21 ShadowBot https://github.com/luanti-org/luanti/issues/16871 -- Fix network code safety issues and add tests by nerzhul
13:22 sfan5     also #16816
13:22 ShadowBot https://github.com/luanti-org/luanti/issues/16816 -- Add support for LUANTI_GAME_PATH and LUANTI_WORLD_PATH by apteryks
18:01 Krock     Zughy: I think I might've misunderstood the issue that you reported, thus unable to reproduce it. I hope my suggestion fits better.
18:02 Krock     by "overwritten by a ghost item" I thought the item would visually disappear, or corrupt, which is not what you meant.
19:50 sfan5     man can we please write better documentation
19:50 sfan5     what exactly is "stack" in on_metadata_inventory_take?
19:52 Krock     ItemStack ?
19:52 sfan5     not the type, the meaning
19:54 Krock     ah. So that would be "The ItemStack that the player took from listname + index." sure. Improving that would be nice.
20:00 sfan5     there's actually a logical contradiction here: the documentation is written as if on_drop is allowed to return any arbitrary itemstack.
20:00 sfan5     the issue then is, if on_drop causes main:wood 12 to be replaced by main:sticks 5, what has been "taken"? what if main:wood 5 gets replaced by main:sticks 12?
20:01 Krock     the "taken" callback runs on whatever the player did. the on_drop code may do whatever it pleases
20:02 sfan5     the engine has to deal with the result of on_drop can call the taken callback
20:02 sfan5     s/can/and/
20:02 Krock     main:wood 12 are taken and what ends up in the inventory is then main:sticks 5
20:03 Krock     err. * ends up dropped
20:03 sfan5     if main:wood 12 is replaced by main:wood 11, what is the taken stack? does the item metadata matter?
20:04 sfan5     going the "if the item is different than before then everything was taken" is logically consistent but weird if you observe the usual behavior
20:04 Krock     the taken stack always indicates which action the player did. Taking on_drop or similar callbacks into consideration here seems very impractical and overly complex to deal with
20:05 sfan5     I don't get to redesign this API ;)
20:05 Krock     huh.. so is on_drop called before the on_*_take callback?
20:06 sfan5     AllowTake -> OnDrop -> OnTake
20:06 Krock     yes that's wrong
20:06 Krock     should be changed. question is how many mods that would break
20:07 Krock     AllowTake -> OnTake -> OnDrop is IMO what should happen. Like in real life. you first have to take an item before you can put it anywhere
20:09 Krock     that's very similar to the allow_take/allow_put/on_take/on_put execution order fix that I did a while ago
20:10 sfan5     then the whole workflow becomes AllowTake -> OnTake -> OnDrop (-> AllowPut -> OnPut)
20:10 Krock     s/fix/change of behaviour and documenting it for the first time/
20:10 sfan5     with no clear idea what to do if AllowPut rejects the leftover item
20:10 sfan5     you can't undo everything at that point
20:11 Krock     there is no AllowPut for the drop action, thus it would end at (
20:11 Krock     or put in general
20:12 sfan5     so you'd skip the inventory callbacks for the returned item?
20:12 Krock     OnDrop is the equivalent of OnPut
20:12 sfan5     my point is OnDrop may not consume everything
20:13 Krock     it should get treated exactly the same as OnPut. The returned ItemStack is finally written to the current slot
20:14 Krock     does that make sense?
20:15 [MatrxMT] <Zughy> and it sounds like I should change my code/game somehow, because this is not going where I hoped
20:15 sfan5     OnPut can't return anything
20:16 [MatrxMT] <Zughy> kinda frustrating after hours of debugging, not gonna lie
20:16 Krock     I meant the return value of OnDrop that finally becomes the wielded item
20:17 Krock     (or whatever slot that was dropped from, since this is also possible within the inventory)
20:18 Krock     trying to get the current order (AllowTake -> OnDrop -> OnTake) to work is IMO equivalent of trying to fix potholes in a swamp
20:19 sfan5     that is true
20:21 Krock     https://github.com/luanti-org/luanti/blob/master/doc/lua_api.md?plain=1#L3886-L3897   <-- "on put" becomes "on put" or "on_drop".    It's sort of undefined behaviour in my understanding
20:23 Krock     where "It's" == the execution order of on_drop and the on_*_take callbacks
20:29 sfan5     the interaction of take=-1 and the return value of on_drop is also unclear
20:29 sfan5     the docs say "A value of -1 for take will make the source stack infinite." or "value -1: Allow and don't modify item count in inventory."
20:31 sfan5     if take=-1, the item was main:wood 1 and on_drop returns main:stick 2, what should be put back into the inventory?
20:32 sfan5     the first quote makes it sounds like main:stick 2 would be an okay result. the second implies it should be main:stick 1.
20:33 sfan5     what is really was in practice so far is neither of those, it's "don't replace the source stack"
20:34 Krock     if only the count (not the itemname) changed, then the answer would be trivial --> unmodified source stack
20:34 Krock     (since it's infinite)
20:35 Krock     changing the itemname is perhaps something we should disallow
20:35 sfan5     unless you also want to disallow changing wear or item meta that doesn't fix anything
20:37 Krock     disallow everything but the count. For compatibility reasons I suppose we'd overwrite the source stack if it's not infinite, and leave it untouched if finite
20:37 sfan5     that's the current state, but I don't like it
20:38 Krock     *if infinite
21:18 [MatrxMT] <Zughy> sfan5: does your PR stop on_drop from being called if allow_etc returns 0 with take ?
21:18 sfan5     yes
21:18 sfan5     that's inevitable, sorry
21:19 [MatrxMT] <Zughy> I get it. Maybe I'd be super explicit in on_drop, saying that is not called if allow_etc returns 0
21:19 [MatrxMT] <Zughy> *that it's
21:21 [MatrxMT] <Zughy> or "Called when the player SUCCESSFULLY drops [..]"
21:23 sfan5     that would be a backwards because on_drop *does* the dropping
21:24 sfan5     a bit*