| 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 |
