Time |
Nick |
Message |
00:24 |
|
Fixer_ joined #minetest-dev |
00:26 |
|
v-rob joined #minetest-dev |
00:33 |
v-rob |
What's up with set_rotation? Is roll supposed to act like pitch when yaw points along the X axis of the world? |
00:34 |
v-rob |
Roll only rolls when yaw points along the Z axis of the world |
00:38 |
|
Fixer joined #minetest-dev |
00:47 |
v-rob |
Is there a trivial way for mods to do this, or would another API function be helpful, say set_relative_rotation? |
01:43 |
|
fluxflux_ joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
05:36 |
|
metalune joined #minetest-dev |
05:41 |
|
metalune left #minetest-dev |
05:41 |
|
metalune joined #minetest-dev |
05:49 |
|
metalune left #minetest-dev |
05:49 |
|
metalune joined #minetest-dev |
05:53 |
|
metalune left #minetest-dev |
05:53 |
|
metalune joined #minetest-dev |
05:58 |
|
metalune left #minetest-dev |
05:58 |
|
metalune joined #minetest-dev |
06:12 |
|
metalune left #minetest-dev |
06:12 |
|
metalune joined #minetest-dev |
06:16 |
|
metalune left #minetest-dev |
06:16 |
|
metalune joined #minetest-dev |
06:24 |
|
metalune left #minetest-dev |
06:24 |
|
metalune joined #minetest-dev |
06:44 |
|
metalune left #minetest-dev |
06:44 |
|
metalune joined #minetest-dev |
06:58 |
|
metalune left #minetest-dev |
07:00 |
|
metalune joined #minetest-dev |
07:08 |
|
metalune left #minetest-dev |
07:58 |
|
vesper11 joined #minetest-dev |
08:00 |
|
ShadowNinja joined #minetest-dev |
08:07 |
|
metalune joined #minetest-dev |
08:21 |
|
metalune left #minetest-dev |
08:21 |
|
metalune joined #minetest-dev |
08:40 |
|
YuGiOhJCJ joined #minetest-dev |
08:54 |
|
metalune left #minetest-dev |
08:54 |
|
metalune joined #minetest-dev |
09:23 |
|
metalune left #minetest-dev |
09:23 |
|
metalune joined #minetest-dev |
09:39 |
|
metalune left #minetest-dev |
09:44 |
|
metalune joined #minetest-dev |
09:49 |
|
metalune left #minetest-dev |
10:29 |
|
metalune joined #minetest-dev |
10:39 |
|
amk joined #minetest-dev |
10:43 |
|
proller joined #minetest-dev |
11:00 |
pgimeno |
does anyone know what v-rob was talking about? |
11:12 |
|
calcul0n_ joined #minetest-dev |
11:20 |
|
Beton joined #minetest-dev |
11:23 |
|
Fixer joined #minetest-dev |
11:28 |
|
twoelk joined #minetest-dev |
11:34 |
|
metalune left #minetest-dev |
11:34 |
|
metalune joined #minetest-dev |
12:01 |
|
oleastre joined #minetest-dev |
12:07 |
|
metalune left #minetest-dev |
12:15 |
|
metalune joined #minetest-dev |
12:29 |
|
metalune left #minetest-dev |
12:29 |
|
metalune joined #minetest-dev |
12:56 |
|
Fixer_ joined #minetest-dev |
13:06 |
MTDiscord |
<exe_virus> I wish I did, in normal 3d graphics the order of operations for applying rotations is pitch, yaw, and then roll. |
13:06 |
MTDiscord |
<exe_virus> Who knows what order we are applying them |
13:06 |
|
mizux joined #minetest-dev |
13:06 |
MTDiscord |
<exe_virus> Actually yeah this is exactly the problem v-rob is running into |
13:09 |
|
Icedream joined #minetest-dev |
13:24 |
MTDiscord |
<appguru> ZXY |
13:40 |
|
proller joined #minetest-dev |
13:41 |
|
metalune left #minetest-dev |
13:42 |
|
metalune joined #minetest-dev |
14:30 |
|
metalune left #minetest-dev |
14:30 |
|
metalune joined #minetest-dev |
14:43 |
|
metalune left #minetest-dev |
14:43 |
|
metalune joined #minetest-dev |
15:13 |
|
olliy joined #minetest-dev |
15:15 |
|
Wuzzy joined #minetest-dev |
15:15 |
Wuzzy |
bugfix PR: #10742 |
15:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/10742 -- Fix world-aligned node rendering at bottom by Wuzzy2 |
15:26 |
|
twoelk left #minetest-dev |
16:27 |
|
metalune left #minetest-dev |
16:27 |
|
metalune joined #minetest-dev |
16:31 |
pgimeno |
yes, Minetest needs a somewhat esoteric order because of its somewhat esoteric choice of axes |
16:33 |
pgimeno |
the docs mention which is which: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L6299 |
16:35 |
pgimeno |
ahh now I understand him, he's complaining that the angles are extrinsic, not intrinsic |
16:36 |
pgimeno |
yes the idea was to add function object:rotate({x=pitch, y=yaw, z=roll}) |
16:36 |
|
olliy_ joined #minetest-dev |
16:36 |
pgimeno |
https://github.com/minetest/minetest/pull/7395#issuecomment-394093984 |
16:38 |
pgimeno |
I think I offered to do that at some point, but there didn't seem to be much interest |
16:41 |
pgimeno |
I can't find it in the longs, maybe I didn't |
16:41 |
pgimeno |
logs* |
16:50 |
pgimeno |
anyway it's relatively simple. Use setPitchYawRollRad (from src/util/numeric.cpp) to calculate the matrix from the axes, and apply (post-multiply) that matrix to the scene node's matrix. Or maybe pre-multiply; not sure if Irrlicht needed the opposite convention. |
16:51 |
MTDiscord |
<exe_virus> Right, just flip the order they are applied. What would you call the lua function? |
16:52 |
pgimeno |
object:rotate |
16:52 |
MTDiscord |
<exe_virus> But we need to have access to both... |
16:52 |
pgimeno |
alternatively, have separate object:applyPitch(), object:applyYaw(), object:applyRoll() |
16:52 |
MTDiscord |
<exe_virus> Unless we are adding an optional boolean to the end of the rotate function, that could work |
16:53 |
pgimeno |
oh, the current one is called object:set_rotation, which is absolute (as the name 'set' suggests) |
16:53 |
pgimeno |
object:rotate() does not exist yet |
16:53 |
MTDiscord |
<exe_virus> Gotcha, then yeah having the option to do either in a single command with intrinsic/extrinsic as the default would be nice |
16:55 |
pgimeno |
I think separate functions is better for intrinsic rotations, as the modder will have better control over the order of rotations without surprises, and no extra work will be wasted when they only need to rotate around a single intrinsic axis |
16:57 |
pgimeno |
hm, I might be wrong about how simple it is. I think the rotation is stored server-side as three Euler angles, not as a matrix. |
16:57 |
pgimeno |
That means it needs to be converted to matrix form first, then converted back to Euler form later. |
16:58 |
MTDiscord |
<exe_virus> nods sounds like what irrlicht would do |
16:59 |
pgimeno |
!tell v-rob See https://irc.minetest.net/minetest-dev/2021-02-05#i_5781728 on the local rotation issue |
16:59 |
ShadowBot |
pgimeno: O.K. |
17:07 |
|
metalune left #minetest-dev |
17:07 |
|
metalune joined #minetest-dev |
17:16 |
|
metalune left #minetest-dev |
17:16 |
|
metalune joined #minetest-dev |
17:18 |
pgimeno |
I made this proof of concept using just Lua: http://www.formauri.es/personal/pgimeno/pastes/relrot.lua |
17:20 |
|
fluxflux_ joined #minetest-dev |
17:27 |
pgimeno |
I've noticed inconsistent usage of commas to separate privs between /privs, /grant and /revoke |
17:28 |
pgimeno |
/privs reports the privs with commas, /grant and /revoke don't |
17:35 |
Krock |
https://krock-works.uk.to/u/patches/0001-Server-properly-delete-ServerMap-on-interrupted-star.patch |
17:35 |
Krock |
fix for #10917. will push in 20 minutes if there are no objections/change requests |
17:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/10917 -- Minetest aborts after consequence of Lua error |
17:38 |
Krock |
pgimeno: yes, I also observed that. both formats should be accepted |
17:40 |
pgimeno |
Krock: it affects the output only, it's quite difficult to read without the commas IMO. Trivial fix, see https://github.com/minetest/minetest/blob/master/builtin/game/chat.lua#L228 |
17:40 |
pgimeno |
https://github.com/minetest/minetest/blob/master/builtin/game/chat.lua#L299 too |
17:41 |
pgimeno |
https://github.com/minetest/minetest/blob/master/builtin/game/chat.lua#L157 is how /privs does it (with comma) |
17:41 |
Krock |
hmm. that would again delay the builtin translations - if those ever get through |
17:42 |
Krock |
L297 too |
17:43 |
pgimeno |
well spotted |
17:43 |
pgimeno |
and L222 |
17:43 |
pgimeno |
err, L226 |
17:44 |
Krock |
basically all `, ' ')` occurrences in the file |
17:48 |
pgimeno |
Wuzzy: I suggest you indicate tiled:tiled in the repro instructions of #10742, I had a bit of a headache trying to reproduce it |
17:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/10742 -- Fix world-aligned node rendering at bottom by Wuzzy2 |
17:50 |
pgimeno |
but yeah, it's easily reproducible by adding nodes in the X direction, they keep changing numbers |
17:55 |
Krock |
pushing patch... |
17:57 |
Wuzzy |
pgimeno: i havent found a reliable pattern yet, but its generall "keep adding or remove nodes and hope for the best" ? |
17:58 |
Wuzzy |
pgimeno: also: 9275 |
17:58 |
Wuzzy |
#9275 |
17:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/9275 -- Bottom side of world-aligned node textures misbehaves while placing nodes along X axis |
18:00 |
pgimeno |
very easy for me... start devtest, give yourself tiled:tiled, make a 3 nodes high tower, then keep adding nodes east or west and observe how the other nodes change numbers as you add tiles. I think they stop changing at mapblock boundaries. |
18:06 |
pgimeno |
http://www.formauri.es/personal/pgimeno/temp/bug-9275.gif |
18:09 |
MTDiscord |
<Flamore> the 8/2 block gets replaced by the 8/1 probably |
18:11 |
pgimeno |
I believe it has to do with textures, not blocks |
18:11 |
pgimeno |
(UVs) |
18:12 |
pgimeno |
Wuzzy: I mentioned it because the repro recipe in 9275 does not work because experimental:tiled does not exist |
18:13 |
Wuzzy |
its tiled:tiled now |
18:13 |
pgimeno |
hence why I suggested you to indicate it, to make it easier for reviewers/testers |
18:16 |
|
numzero joined #minetest-dev |
18:20 |
|
Fleckenstein joined #minetest-dev |
19:17 |
|
metalune left #minetest-dev |
19:17 |
|
metalune joined #minetest-dev |
19:23 |
|
metalune left #minetest-dev |
19:23 |
|
metalune joined #minetest-dev |
19:24 |
|
metalune left #minetest-dev |
19:24 |
|
metalune joined #minetest-dev |
19:26 |
|
metalune left #minetest-dev |
19:26 |
|
metalune joined #minetest-dev |
19:28 |
|
metalune left #minetest-dev |
19:28 |
|
metalune joined #minetest-dev |
19:29 |
|
metalune left #minetest-dev |
19:29 |
|
metalune joined #minetest-dev |
20:39 |
|
lhofhansl joined #minetest-dev |
20:46 |
|
numzero joined #minetest-dev |
20:57 |
|
metalune left #minetest-dev |
20:57 |
|
metalune joined #minetest-dev |
20:58 |
|
metalune left #minetest-dev |
20:58 |
|
metalune joined #minetest-dev |
21:02 |
|
metalune left #minetest-dev |
21:02 |
|
metalune joined #minetest-dev |
21:09 |
|
kilbith joined #minetest-dev |
21:10 |
kilbith |
`table.indexof` is broken |
21:10 |
kilbith |
https://github.com/minetest/minetest/blob/master/builtin/common/misc_helpers.lua#L197 |
21:10 |
kilbith |
should be changed to `pairs` |
21:10 |
kilbith |
because otherwise: |
21:10 |
kilbith |
local t = {"foo", "bar", "baz", [5] = "banana"}; print(table.indexof(t, "banana")) |
21:10 |
kilbith |
> returns -1 |
21:10 |
|
metalune left #minetest-dev |
21:36 |
rubenwardy |
indexof is for integer tables, not for keyed tables |
21:38 |
kilbith |
[5] ain't an integer maybe? |
21:39 |
kilbith |
changing it `pairs` would make it returns any kind of indexes, there are only bonuses without losses |
21:39 |
|
Fixer joined #minetest-dev |
21:39 |
kilbith |
* it to |
21:43 |
rubenwardy |
sorry, I meant array-based tables |
21:43 |
rubenwardy |
tables have array parts and hash parts. Array parts must be contiguous from 1 |
21:46 |
pgimeno |
using the array parts is faster |
21:46 |
kilbith |
thanks for teaching me something about Lua tables /s |
21:46 |
pgimeno |
so it's not right that there are no loses |
21:46 |
kilbith |
oh come on |
21:47 |
kilbith |
we are talking about 1e-10 ms. in most common cases |
21:48 |
kilbith |
the benefits outright the superfluous performance loss |
21:49 |
kilbith |
I mean supplant not outright - english gets rusty |
21:49 |
pgimeno |
no, we're talking about breaking a trace. pairs() is NYI. |
21:50 |
kilbith |
? |
21:50 |
pgimeno |
http://wiki.luajit.org/NYI#libraries_base-library |
21:51 |
pgimeno |
to be fair, # can return (and therefore is able to check) more elements than ipairs() which always stops at the first nil |
21:51 |
pgimeno |
so maybe it should be rewritten to use # |
21:56 |
pgimeno |
OTOH, ipairs is consistent, while # may not be |
22:02 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/test-table-indexof-with-hash.lua - yes, maybe not consistent enough |
22:03 |
rubenwardy |
I agree with using # |
22:04 |
kilbith |
Lua PUC needs to go anyway |
22:06 |
pgimeno |
yeah but LuaJIT returns the element or not, depending on the size allocated for the hash - that's not consistent |
22:07 |
pgimeno |
or for the array |
22:11 |
|
v-rob joined #minetest-dev |
22:12 |
v-rob |
On the rotation issue: it seems I was working with an older version of Minetest with different behaviour, but there's still no easy way to rotate relative to the current rotation with the new behaviour either. |
22:13 |
v-rob |
I was asking because I want to make a set_look_roll/set_look_rotation, but that might be over my head... |
22:16 |
kilbith |
is this in a relation with the model part of the formspec rewrite? |
22:17 |
kilbith |
-a |
22:17 |
v-rob |
No, for the player's camera, i.e. as the third axis to go with set_look_horizontal/vertical |
22:18 |
v-rob |
It'd be useful for e.g. space games or |
22:18 |
v-rob |
games that don't have a concept of an up or down axis |
22:18 |
kilbith |
I thought you were busy with the formspec rewrite |
22:19 |
v-rob |
I am, but I thought that a change of pace with a small detour would be nice, but apparently I was wrong in assuming that it would be easy. |
22:20 |
v-rob |
Figuring out Freetype's units for properly calculating underline position (which is inaccurate right now) is kind of boring... |
22:21 |
|
GreenXenith joined #minetest-dev |
22:21 |
kilbith |
underline's in the font itself, no? |
22:22 |
kilbith |
ah no, we don't have an underlined font |
22:23 |
v-rob |
Fonts do store underline info via Freetype's API, but they use multiple different units. The current underline code from hypertext doesn't use optimal calculations (e.g. all underlines have odd numbers of pixels) |
22:27 |
rubenwardy |
#10921 |
22:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/10921 -- Reduce ore noise_parms error to deprecation warning by rubenwardy |
22:40 |
|
kilbith joined #minetest-dev |
23:01 |
|
kilbith joined #minetest-dev |
23:27 |
|
kilbith joined #minetest-dev |
23:35 |
Wuzzy |
hey, recently became a member of Minetest on github, but i dont really know what it means to me now. care to explain? |
23:36 |
v-rob |
I believe that's for issue triaging; I know we were considering you for that |
23:37 |
v-rob |
The idea is that people who aren't core devs can take care of issues, like labeling, closing old ones, and suchlike. |
23:38 |
v-rob |
So more people can take manage issues and pull requests without the full responsibilities of a core dev. |
23:38 |
rubenwardy |
https://dev.minetest.net/Git_Guidelines#Issue_and_Pull-Request_Management |
23:39 |
Wuzzy |
"If a pull request or an issue does not get a response from its author within one month when requiring more details, it is closed." |
23:39 |
Wuzzy |
oh, really? doesnt look like that. we literally have many issues that date back to 2016 |
23:40 |
v-rob |
We have one that dates to 2011, #36 |
23:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/36 -- Add ability to update node/craft/tool/entity properties during runtime |
23:40 |
Wuzzy |
2017*. but still |
23:40 |
Wuzzy |
i think that one should be rejected, actually |
23:41 |
v-rob |
It's got a "Supported by core dev", but I don't know why paramat put that on. He doesn't seem to support it from what I can see. |
23:42 |
v-rob |
Well, you do have the power to close issues (and pull requests) like that now |
23:43 |
Wuzzy |
thing is, just closing old issues won't solve anything if they describe real world problems, no matter how old. ;) they are just removed from view |
23:44 |
v-rob |
Well, 36 really isn't applicable unless we have SSCSM because metadata isn't a viable solution |
23:44 |
Wuzzy |
i feel like the label was added by accident tho |
23:44 |
v-rob |
Probably |
23:45 |
Wuzzy |
unfortunately, i wont be adding labels until MS fixes their broken website (i.e. likely never) |
23:45 |
v-rob |
Oh, no JavaScript? |
23:45 |
Wuzzy |
at least i'll be able to close issues. thats more than nothing. heh |
23:46 |
Wuzzy |
but still. i think "lack of labels" is not really our biggest problems anyway |
23:46 |
Wuzzy |
the real problem is more like "tiny code review pipeline bottleneck" |
23:47 |
Wuzzy |
I feel like we can basically throw away *easily* at least half of the PRs that are open right now because of old age and massive incompability problems. sad but true. |
23:48 |
v-rob |
And no one wants to close them because they *could* be useful, if anyone did anything about them |
23:50 |
Wuzzy |
We have a serious problem with the review process. we don't lack programmers (>100 open PRs constantly FFS). we lack reviewers. |
23:50 |
Wuzzy |
not sure how i could help with that tho |
23:51 |
Wuzzy |
I find reviewing PRs to be extremely inconvenient. I usually just wait until its merged before I actually start testing new features. ? |
23:53 |
LoneWolfHT |
Comprehensive review instructions would help a little bit in some cases |
23:53 |
v-rob |
I'm fine with reviewing code; it's the testing that's annoying |
23:54 |
LoneWolfHT |
I can't review code as I know C, not C++. Testing is what I'm best at |
23:54 |
Wuzzy |
there should be a goal of keeping the open PR count low. if there are >100 open PRs open at all the time, its hard for your code to stand out. usually, only the newest PR have a chance of succeeding, while the old PRs usually fade into obscurity |
23:55 |
Wuzzy |
but i also find it hard to find PRs that are *truly* closeworthy ? the original contibutors are still somewhat active in it |
23:55 |
v-rob |
The only way to get old PRs noticed is to bug the core devs on IRC, which a lot of people don't do because they don't know about IRC or are just too polite |
23:56 |
Wuzzy |
not even that helps anymore, lol |
23:56 |
Wuzzy |
after the 25th ping i almost gave up |
23:57 |
Wuzzy |
as i said, we have way to few *official* reviewers. thats where the delays are coming from |
23:57 |
MTDiscord |
<Jonathon> ^ |
23:58 |
Wuzzy |
lets talk about good reasons to kill a PR. i think Minetest is WAY to polite in keeping PRs open forever |
23:58 |
MTDiscord |
<Jonathon> thats going to get you a lot of hate |
23:59 |
Wuzzy |
not neccessarily |
23:59 |
Wuzzy |
it really depends on what it is and how you do it |
23:59 |
v-rob |
Depends on which PRs are being closed |
23:59 |
Wuzzy |
the first rule should be that if you kill a PR you should say why. that should be obvious |