| Time |
Nick |
Message |
| 01:04 |
|
alek13_ joined #luanti-dev |
| 02:39 |
|
alek13 joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:11 |
|
AliasStillTaken joined #luanti-dev |
| 04:54 |
|
SFENCE joined #luanti-dev |
| 05:50 |
|
SFENCE joined #luanti-dev |
| 07:17 |
|
SFENCE joined #luanti-dev |
| 08:18 |
|
SFENCE joined #luanti-dev |
| 09:10 |
|
SFENCE joined #luanti-dev |
| 10:12 |
|
SFENCE joined #luanti-dev |
| 11:00 |
|
SFENCE joined #luanti-dev |
| 11:31 |
|
SFENCE joined #luanti-dev |
| 11:54 |
|
SFENCE joined #luanti-dev |
| 12:17 |
|
SFENCE joined #luanti-dev |
| 12:35 |
|
SFENCE joined #luanti-dev |
| 12:47 |
|
SFENCE joined #luanti-dev |
| 13:21 |
|
SFENCE joined #luanti-dev |
| 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 |
| 14:02 |
|
SFENCE joined #luanti-dev |
| 14:18 |
|
alek13 joined #luanti-dev |
| 14:22 |
|
alek13_ joined #luanti-dev |
| 14:38 |
|
SFENCE joined #luanti-dev |
| 16:21 |
|
Desour joined #luanti-dev |
| 17:40 |
|
calculon joined #luanti-dev |
| 17:53 |
|
SFENCE joined #luanti-dev |
| 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* |
