Time  Nick      Message
10:07 Krock     will merge #9228 in ~10 minutes
10:07 ShadowBot https://github.com/minetest/minetest/issues/9228 -- lua_api.txt: Improve privs_to_string and string_to_privs documentation by ClobberXD
10:16 Krock     mergign
10:53 ANAND     Are getLeftClicked and getLeftState equivalent to wasKeyDown and isKeyDown for normal keys?
10:54 ANAND     That seems to be right, going by what I understand from the code, but I just wanted to confirm this.
11:03 ANAND     #7924 seems to be a very popular feature, going by the emojis. Let's not leave it forsaken.
11:04 ShadowBot https://github.com/minetest/minetest/issues/7924 -- [NO SQUASH] Allow binding dig, place actions to keys; remove LMB/RMB hardcoding by ClobberXD
11:21 Krock     presumably it's the equivalent, yes.
11:27 ANAND     Ok, thanks!
11:35 Krock     ANAND: btw: #8468 can be shortened to https://krock-works.uk.to/u/patches/set_rotation_autorot.diff
11:35 ShadowBot https://github.com/minetest/minetest/issues/8468 -- Make automatic_rotate relative, allow setting rotation by ClobberXD
12:01 p_gimeno  Krock: the point of that comparison is to set a threshold below which to stop rotating
12:02 Krock     it's an on/off rotation switch
12:03 Krock     there's no need to do an additional rotation calculation of there's no automatic rotation
12:08 p_gimeno  um wait, I got lost
12:08 p_gimeno  do you mean the whole PR can be reduced to that?
12:10 Krock     The purpose of the PR seems to have changed from "automatic rotation with attachments" to "set_rotation in combination with automatic rotation"
12:10 Krock     so yes
12:13 p_gimeno  where does the "relative" part come into play then?
12:15 ANAND     Whoa
12:16 ANAND     The intended objective can be achieved with just that 5-line diff?
12:17 p_gimeno  that's the part that allows setting the rotation, I believe
12:17 p_gimeno  but it does not make it relative
12:18 p_gimeno  the original PR did that: https://notabug.org/pgimeno/minetest/commit/db6029d48a75f20c9aecfcffe56e8618e034418e
12:20 ANAND     That's what I was wondering
12:20 ANAND     8468 is currently the exact same as the original commit, except for maybe a couple of code-style changes.
12:20 ANAND     https://github.com/minetest/minetest/pull/8468/files?utf8=%E2%9C%93&diff=split&w=1
12:21 Krock     p_gimeno: it does the same, but rather than  node->getRotation(); it takes the rotation from m_rotation and increases that
12:21 p_gimeno  Krock: that won't work for relative rotation
12:23 Krock     and also: no, the PR is not the same + code style changes. the entire rotation calculation is still guarded by getParent() which isn't the case in p_gimeno's patch
12:23 ANAND     Ah yes
12:23 Krock     uh well.. (getParent() ? 0.f : m_prop.automatic_rotate)  is about the same due to multiplication by 0
12:24 p_gimeno  yes, I thought that avoiding the branch could compensate the additional multiplication
12:24 p_gimeno  I'm OK with it being written as a branch
12:25 ANAND     Let me make sure I get this right: Relative rotation is taking the object's rotation, and rotating it's Y component by automatic_rotate, right?
12:25 p_gimeno  yes
12:26 ANAND     And currently, automatic_rotate doesn't take the object's rotation into consideration?
12:26 Krock     after all I would like to know why "m_rotation" and node->getRotation() then go out of sync
12:26 Krock     both should be the same
12:27 Krock     ANAND: it does. > m_rotation.Y += dtime * ...
12:28 Krock     but the automatic_rotate angle is currently not kept as soon set_rotation is called
12:29 p_gimeno  gosh, I have a bad cold and some fever, and I can't think straight with this now
12:29 p_gimeno  Krock: does the test mod look the same with your patch and with the PR patch?
12:30 Krock     p_gimeno: I hope you'll get well soon. Just to be sure, I'll retest the two versions now
12:30 p_gimeno  I believe the problem is that changing the Y component of the object causes an absolute rotation, not a relative one
12:30 p_gimeno  that's why it uses the Y component of the *child* node
12:33 p_gimeno  so, if you have e.g. a fan blade and set its X rotation to 90°, then rotating over Y will not make the blade rotate naturally, but over a weird axis
12:33 p_gimeno  that was the whole point of the PR
12:34 p_gimeno  and thanks btw
12:34 Krock     right. it's exactly that.
12:34 Krock     the "simple" change from me overwrites the progress of the automatic rotation. this does not happen with the PR
12:35 p_gimeno  yeah, additionally the PR makes them independent
12:37 p_gimeno  mind you, this is a breaking change, but I doubt there's much code relying on the current behaviour
12:37 Krock     I think the risk is low enough
12:38 p_gimeno  the whole discussion is in #8456
12:38 ShadowBot https://github.com/minetest/minetest/issues/8456 -- Support configuring rotation axis for `automatic_rotate`
12:41 Krock     ANAND: (m_prop.automatic_face_movement_dir) does not depend on automatic_rotate
12:41 Krock     it only depends on !getParent()
12:45 p_gimeno  I *think* it could have been made relative without using the child's rotation, if it rotated over the Z axis instead of Y, but that of course does break a lot of stuff
12:46 p_gimeno  then you would only need to apply set_rotation incrementally if automatic_rotate was in effect
15:03 ANAND     > it does. but the automatic_rotate angle is currently not kept as soon set_rotation is called
15:03 ANAND     Gotcha
15:07 ANAND     I won't be available for the next four days, and I won't be able to attend to PRs until I return. Sorry for the inconvenience.
16:40 Wuzzy     what's the highest permitted collisionbox of a node?
16:42 sfan5     I don't think there's a limit
16:43 sfan5     but everything above 2.0 is not guaranteed to work and worse, we will make no effort to fix it
16:44 Wuzzy     from experiment i noticed that exactly 2.0 does not work
16:44 Wuzzy     but slightly below 2.0 works
16:44 Wuzzy     like the limit of leveled nodeboxes
16:44 Wuzzy     if collisionbox is exactly from -0.5 to +1.5, then i cant jump from it
16:45 Wuzzy     Are nodeboxes of 2.0 supposed to work?
16:50 Krock     maximal extend is defined somewhere in collision.cpp
16:59 Wuzzy     the maximum safe max Y i have found from testing so far is 1.484375 (=95/64 =max leveled nodebox height)
20:06 Wuzzy     How do the tiles and special tiles work for liquids/flowing liquids?
20:09 Krock     I bet it's undocumented
20:10 Wuzzy     of course it is. otherwise i wouldnt have asked ?
20:11 Wuzzy     I have the suspicion that a LOT of games are definining liquids completely wrong
20:11 Wuzzy     because they just copy code
20:12 nepugia   Heh, i just defined Ice and no liquids, didn't find it either :p
20:24 Wuzzy     interesting. it seems liquid source nodes support all 6 faces
20:25 nepugia   Well, you can have glass next to em, so makes sense to me :3
20:28 Wuzzy     no i mean you can set all 6 textures on each side
20:30 nepugia   i ment that too, it makes sense to me, no need to special case that here :g
20:34 Wuzzy     its interesting because glasslike only supports 1 texture, not 6
20:54 nepugia   Wuzzy, huh, didn't know that
20:54 nepugia   is glasslike required for translucency?
20:54 Wuzzy     many drawtypes "support" translucency
20:55 Wuzzy     however, depth sorting is broken since years
20:55 Krock     *since forever
20:57 p_gimeno  is there *any* depth sorting at all?