| Time |
Nick |
Message |
| 00:58 |
rubenwardy |
Thanks |
| 00:58 |
rubenwardy |
And good night |
| 01:02 |
|
paramat joined #minetest-dev |
| 02:21 |
|
nephele joined #minetest-dev |
| 06:49 |
|
Edgy1 joined #minetest-dev |
| 07:37 |
|
pmp-p joined #minetest-dev |
| 08:38 |
|
ShadowNinja joined #minetest-dev |
| 11:33 |
|
Krock joined #minetest-dev |
| 11:41 |
|
Fixer joined #minetest-dev |
| 11:41 |
|
Fixer joined #minetest-dev |
| 12:05 |
|
rustik joined #minetest-dev |
| 12:08 |
|
Kimapr joined #minetest-dev |
| 12:12 |
|
rustik joined #minetest-dev |
| 12:41 |
|
rustik joined #minetest-dev |
| 13:05 |
|
kollaps[m] joined #minetest-dev |
| 13:05 |
|
texmex joined #minetest-dev |
| 13:05 |
|
MayeulC_backup joined #minetest-dev |
| 13:05 |
|
Qiangong2[m] joined #minetest-dev |
| 13:11 |
Krock |
>.< |
| 13:47 |
Krock |
What to do if Lua's garbage collector is not fast enough? GC makes it RAII compliant but deletion is delayed way too much |
| 13:56 |
Krock |
will merge #9150 in 15 minutes |
| 13:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/9150 -- Attachments: Fix interpolation from (0,0,0) after detach by SmallJoker |
| 13:59 |
Krock |
branch squashed & function renamed |
| 14:11 |
Krock |
merging |
| 14:14 |
Krock |
#8910 close as Can't Fix upstream issue? |
| 14:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/8910 -- Add PNG file name in PNG profile warnings |
| 14:17 |
p_gimeno |
Krock: run collectgarbage manually? |
| 14:18 |
Krock |
well that's among a :close() function a possibility |
| 14:18 |
Krock |
but that's not instant RAII |
| 14:22 |
ANAND |
Whoa, #9150 fixes all the camera offset bugs? |
| 14:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/9150 -- Attachments: Fix interpolation from (0,0,0) after detach by SmallJoker |
| 14:28 |
Krock |
not sure |
| 14:32 |
ANAND |
Seems to fix most of them, going by the closed issues :) |
| 14:32 |
ANAND |
Awesome work, thanks! |
| 14:32 |
Krock |
np |
| 14:33 |
Krock |
however, objects attached to LocalPlayer's CAO still don't update instantly (for some reason not handled by Irrlicht) |
| 15:29 |
|
hecks joined #minetest-dev |
| 15:30 |
hecks |
How do I get the magical, consecrated libstdc DLL that the latest win64 build requires |
| 15:30 |
hecks |
stealing it from sfan no longer works |
| 15:30 |
sfan5 |
"latest win64 build" from where? |
| 15:31 |
hecks |
from the buildbot, from git itself |
| 15:31 |
hecks |
it doesn't pack three DLLs, libstdc, pthread and uh something |
| 15:31 |
sfan5 |
git is a version control program |
| 15:31 |
sfan5 |
do you mean gitlab? |
| 15:31 |
hecks |
from the git REPO |
| 15:31 |
hecks |
I usually steal the missing DLLs from your builds |
| 15:31 |
sfan5 |
oh you've built it yourself |
| 15:32 |
|
fluxflux joined #minetest-dev |
| 15:32 |
sfan5 |
the DLLs you need come with the mingw toolchain installed on your system |
| 15:32 |
hecks |
yeah, to test joker's merge from like an hour ago |
| 15:33 |
sfan5 |
in /usr/x86_64-w64-mingw32/lib or similar |
| 15:33 |
hecks |
oh they're there |
| 15:33 |
hecks |
why thank you |
| 16:08 |
Krock |
> Then maybe disable client-side predictions for drops altogether? |
| 16:08 |
Krock |
ANAND: results in double-dropped items on laggy servers |
| 16:08 |
Krock |
players expect that the item is dropped instantly |
| 16:09 |
Krock |
same with nodes. you don't wait until the server confirms that it's really dug |
| 16:09 |
Krock |
you'd end up waiting for the server confirmation that might arrive a second late |
| 16:16 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 16:59 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 17:03 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 17:22 |
|
ensonic joined #minetest-dev |
| 17:44 |
|
Ruslan1 joined #minetest-dev |
| 18:11 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 18:15 |
|
ensonic joined #minetest-dev |
| 18:48 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 19:14 |
Krock |
Well so... anyone here? |
| 19:17 |
p_gimeno |
do I count? |
| 19:17 |
Krock |
yeah, although I also hoped for some core developers |
| 19:17 |
sfan5 |
hi |
| 19:17 |
Krock |
tbh I wonder why something like #8665 is still open |
| 19:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/8665 -- Formspec: change the appearance of the cursor on fields and co. by DS-Minetest |
| 19:17 |
Krock |
o/ sfan5 |
| 19:18 |
Krock |
the meeting points on the wiki could be way longer but adding more wouldn't help much at all |
| 19:18 |
Krock |
concept discussions would probably fit best, rather than reviewing which happened in 0.4.x times |
| 19:21 |
Krock |
nore, sofar: would you possibly have some free time to spend on a short dev meeting? |
| 19:25 |
Krock |
back in 2014 there were Zeno, RBA, BlockMen and hmmmm helping to process the PRs and issues. in exchange there are now two new members, including me. Question is whether it would help to actively look for potential devs |
| 19:27 |
Krock |
I actually also talked with rubenwardy and nore about the situation but we couldn't really recall someone who'd be interested in joining the team |
| 19:28 |
Krock |
numberZero was a candidate, but he didn't seem to be interested or just disappeared |
| 19:30 |
Krock |
p_gimeno: too bad you no longer have a GitHub account :/ |
| 19:30 |
p_gimeno |
easy fix, just migrate to GitLab ;) |
| 19:31 |
p_gimeno |
couldn't resist, sorry |
| 19:34 |
Krock |
fair enough. they didn't kill the golden goose yet, though. |
| 19:35 |
p_gimeno |
I always follow this chat, and look at some issues from time to time and comment when I think it's appropriate |
| 19:37 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 19:38 |
Krock |
that's also a great way of contributing, even though the messages are lost if it's not a larger discussion |
| 19:43 |
p_gimeno |
I'm out of the loop for the most part these days though, so it isn't very frequent. Last I remember is noting that the Irrlicht particles PR would bring back #8363. I could get motivated again though, but contributing this way is somewhat limiting. |
| 19:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/8363 -- Attached particle spawners no longer rotate with object |
| 19:44 |
p_gimeno |
I tried for a long time playing with the Irrlicht particles PR to see if I could make attached particles work, which would automatically fix this, but I was unable. |
| 19:45 |
Krock |
yet another camera shift issue? |
| 19:53 |
p_gimeno |
I thought so, but then I tried at 0,0,0 and couldn't make it work there either |
| 20:02 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 20:04 |
rubenwardy |
p_gimeno: I've migrated to gitlab |
| 20:06 |
p_gimeno |
rubenwardy: migrated what? can we now handle issues and PRs there? |
| 20:06 |
Krock |
just him personally |
| 20:06 |
p_gimeno |
ah |
| 20:08 |
p_gimeno |
so, like the personal repos I guess |
| 20:10 |
p_gimeno |
is that camera offset thing really necessary? can't a different approach work better than that? I don't think any other 3D project handles it that way |
| 20:10 |
|
Icedream joined #minetest-dev |
| 20:10 |
sfan5 |
the offset approach is quite prone to bugs too |
| 20:10 |
sfan5 |
as seen multiple ... times ... recently |
| 20:11 |
p_gimeno |
gtg for a while sorry, will read the backlog later |
| 20:11 |
Krock |
p_gimeno: you can try to disable it in client/camera.cpp (or set the offset values to > 33k) |
| 20:11 |
Krock |
the issue is that the fastRaceRows vertices will have gaps in between |
| 20:12 |
Krock |
it gets more noticeable the further you go from spawn |
| 20:12 |
Krock |
*makeFastFace rows |
| 20:13 |
Krock |
that's mainly because f32 are used to calculate the vertex positions |
| 20:14 |
sfan5 |
hmm if it's so easy to disable maybe we could ask the issue reports to test with offsets disabled |
| 20:14 |
sfan5 |
(regarding recent issues with entities, camera and attachments) |
| 20:15 |
sfan5 |
would narrow the problem down by a lot |
| 20:15 |
Krock |
well, if it doesn't work within 200m from (0,0,0) it's surely broken anyway |
| 20:15 |
|
Cornelia joined #minetest-dev |
| 20:15 |
Krock |
camera offset only matters when going further than 200m into one direction |
| 20:19 |
|
ensonic joined #minetest-dev |
| 20:30 |
|
HDMI_STECKDOSE joined #minetest-dev |
| 20:30 |
Krock |
> ./util/travis/script.sh: line 68: 12233 Segmentation fault (core dumped) ${CMD} |
| 20:31 |
|
paramat joined #minetest-dev |
| 20:35 |
paramat |
i had to go out but am here from now on |
| 20:37 |
Krock |
welcome. there's a long monologue in the logs. |
| 20:38 |
Krock |
for now it might be best to check who could be added to the team |
| 20:43 |
p_gimeno |
back, yeah I know that it's a precision issue, I just think there must be a better way to handle it |
| 20:44 |
Krock |
offset each node? |
| 20:44 |
Krock |
it would be more consistent but have the same bugs as 200m so after all it wouldn't matter at all |
| 20:46 |
p_gimeno |
I'm not sure exactly how, but the general idea is that at render time, you subtract the camera position from every object somehow... maybe Irrlicht is not prepared to do that, I just know how I'd do it |
| 20:46 |
p_gimeno |
think of it as a continuous offset, rather than discrete |
| 20:47 |
p_gimeno |
if I want to translate that idea into code, I need to look into a lot of things |
| 20:48 |
Krock |
offset = floor(pos) |
| 20:48 |
Krock |
pos -= offset |
| 20:49 |
p_gimeno |
why not offset = pos; pos = 0 ? |
| 20:50 |
p_gimeno |
but I never know when to apply camera offset |
| 20:50 |
Krock |
so to say - all SceneNodes would be relative to you |
| 20:50 |
p_gimeno |
yes |
| 20:51 |
Krock |
you need to apply the camera offset when dealing with Irrlicht SceneNodes. Only there. |
| 20:51 |
p_gimeno |
I see |
| 20:51 |
Krock |
the camera sets the origin (kinda) |
| 20:51 |
Krock |
and all other SceneNodes are placed around it using the offset from the camera |
| 20:52 |
p_gimeno |
it makes some sense, in that it's the AbsolutePosition calculation that screws the precision |
| 20:53 |
paramat |
yes, i read logs |
| 20:53 |
p_gimeno |
addition of big floats plus small floats destroys the precision of the small floats |
| 20:54 |
Krock |
after all it's still needed to have the absolute position of entities for speed calculations - at least server-side |
| 20:54 |
Krock |
and for client-side prediction as well |
| 21:01 |
p_gimeno |
in the interval from 16K to 32K, a single has a precision of 1/512, i.e. you can go from 20000.0 to 20000.001953125 but not anywhere in between, that's ~2 mm but the accumulated error in the matrix computations will make things much worse |
| 21:02 |
p_gimeno |
can the camera go far away from the player in any circumstances? |
| 21:03 |
* Krock |
grammar-corrects the team discussion post |
| 21:04 |
Krock |
p_gimeno: yes. attachments. |
| 21:04 |
p_gimeno |
if it can't, player-relative coordinates could work, but for guaranteed results, camera-relative coordinates will always work |
| 21:04 |
Krock |
when the player is attached to an entity, the model is in another location than the eyes |
| 21:04 |
p_gimeno |
I see |
| 21:04 |
Krock |
this is somewhat weird but the mods might depend on this |
| 21:04 |
p_gimeno |
I don't think there are models >200 nodes big though :) |
| 21:05 |
Krock |
see also: game.cpp ->getEyeOffset |
| 21:05 |
p_gimeno |
or, well, things probably aren't expected to work flawlessly in such cases |
| 21:05 |
Krock |
no. 200m is a safe distance for likely all use-cases in Minetest |
| 21:13 |
p_gimeno |
so what happens when a 200m barrier is crossed? are all scene nodes moved? |
| 21:14 |
Krock |
AFAIK detached and re-attached to the scene |
| 21:14 |
Krock |
content_cao.cpp GenericCAO::step() when the visuals expired |
| 21:15 |
p_gimeno |
would doing that every frame be too much? |
| 21:15 |
p_gimeno |
I'll look, thanks |
| 21:15 |
Krock |
"AFAIK" because I'm not 100% sure whether that's exactly executed when passing the barrier |
| 21:15 |
Krock |
I didn't measure the time but I'd expect more imprecisions due to position movements |
| 21:17 |
Krock |
if you detach the SceneNode, the position in the map remains the same but is no longer relative to its parent |
| 21:17 |
Krock |
rather - relative to the origin (0,0,0) |
| 21:18 |
Krock |
moving the origin could btw mess up the entire mapblock mesh placement. just so that I mentioned it |
| 21:19 |
p_gimeno |
I think that the authoritative source for the object position is what's used to re-add the object to the scene, i.e. there's no accumulated error. Otherwise it could be a chaos. |
| 21:20 |
p_gimeno |
or, well, I *hope* it's done that way |
| 21:21 |
Krock |
*shrug* |
| 21:29 |
paramat |
#1119 |
| 21:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/1119 -- Fix rendering glitches when far from the center of the map by Ekdohibs |
| 21:29 |
paramat |
'every frame' sounds scary |
| 21:44 |
rubenwardy |
I'm around now |
| 21:55 |
|
Cornelia joined #minetest-dev |
| 21:58 |
p_gimeno |
https://github.com/minetest/minetest/pull/1119/commits/da63e5863b83e9b8bf18faa6bb6479b69838d382#diff-c2f90db5de8c33a259c27113939c63c5R1417 |
| 21:58 |
p_gimeno |
I guess that's costly to do it once per frame |
| 22:02 |
p_gimeno |
also, it's incremental, i.e. subject to accumulated error |
| 22:33 |
|
erlehmann joined #minetest-dev |
| 22:38 |
|
paramat joined #minetest-dev |
| 22:38 |
sfan5 |
merging #8813 in 5 minutes |
| 22:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/8813 -- Clean up craft replacements docs by pauloue |
| 22:39 |
sfan5 |
also #9173 |
| 22:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/9173 -- Run luacheck in travis by rubenwardy |
| 22:50 |
sfan5 |
... |
| 22:50 |
sfan5 |
merged |
| 23:03 |
|
Cornelia joined #minetest-dev |
| 23:20 |
|
reductum joined #minetest-dev |
| 23:51 |
|
Cornelia joined #minetest-dev |
