Minetest logo

IRC log for #minetest-dev, 2020-01-19

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
01:12 GreenDimond joined #minetest-dev
01:30 realz joined #minetest-dev
04:12 Miner_48er joined #minetest-dev
05:33 indiana joined #minetest-dev
08:03 YuGiOhJCJ joined #minetest-dev
08:38 ShadowNinja joined #minetest-dev
09:21 fluxflux_ joined #minetest-dev
10:06 Krock joined #minetest-dev
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:04 proller joined #minetest-dev
11:14 df458 joined #minetest-dev
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 Fixer joined #minetest-dev
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:43 mizux joined #minetest-dev
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
13:01 Beton joined #minetest-dev
13:32 pmp-p joined #minetest-dev
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:00 absurb joined #minetest-dev
16:37 Wuzzy joined #minetest-dev
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)
17:08 T^4im joined #minetest-dev
18:58 Fixer joined #minetest-dev
19:00 Fixer joined #minetest-dev
19:05 nepugia joined #minetest-dev
19:50 proller joined #minetest-dev
19:51 erlehmann joined #minetest-dev
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:43 nepugia joined #minetest-dev
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?
21:03 fluxflux_ joined #minetest-dev
22:06 erlehmann_ joined #minetest-dev
23:28 machinehum joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext