| Time |
Nick |
Message |
| 00:23 |
|
Qiangong2[m] joined #minetest-dev |
| 00:25 |
|
pipo joined #minetest-dev |
| 02:33 |
|
Kimapr joined #minetest-dev |
| 03:46 |
|
DI3HARD139 joined #minetest-dev |
| 04:01 |
|
Taoki joined #minetest-dev |
| 06:50 |
|
calcul0n joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:04 |
|
appguru joined #minetest-dev |
| 08:09 |
|
NetherEran joined #minetest-dev |
| 09:04 |
|
erlehmann joined #minetest-dev |
| 09:47 |
|
Flitzpiepe joined #minetest-dev |
| 10:25 |
|
Taoki joined #minetest-dev |
| 10:44 |
|
absurb joined #minetest-dev |
| 11:17 |
|
erlehmann joined #minetest-dev |
| 11:17 |
|
Fixer joined #minetest-dev |
| 11:21 |
|
Zughy joined #minetest-dev |
| 11:34 |
celeron55 |
by quickly searching through the 5.2->5.3 diff it doesn't seem like there are any changes related to marking more blocks for sending |
| 11:34 |
celeron55 |
but if hecks is right, there has to be something |
| 11:48 |
|
Wuzzy joined #minetest-dev |
| 12:23 |
|
oiaohm joined #minetest-dev |
| 12:33 |
|
Kimapr joined #minetest-dev |
| 13:13 |
|
Kimapr joined #minetest-dev |
| 14:28 |
|
oil_boi joined #minetest-dev |
| 14:40 |
|
Kimapr joined #minetest-dev |
| 15:20 |
|
appguru joined #minetest-dev |
| 16:04 |
|
fluxflux joined #minetest-dev |
| 16:06 |
|
erlehmann joined #minetest-dev |
| 16:13 |
|
search_social joined #minetest-dev |
| 17:26 |
|
NetherEran joined #minetest-dev |
| 18:27 |
|
appguru joined #minetest-dev |
| 18:51 |
|
Fixer joined #minetest-dev |
| 19:10 |
|
hecks joined #minetest-dev |
| 19:25 |
hecks |
Are tile layers used for something other than cracko? |
| 19:34 |
|
calcul0n joined #minetest-dev |
| 19:38 |
oil_boi |
So we were having a major discussion with frustrations of infrequencies of releasing/patching/the dev cycle |
| 19:38 |
oil_boi |
I had a pretty substantial thought as I got caught in a mirror maze of thoughts on this, why is the dev cycle 6 months this, 6 months that, rebasing with that methodology becomes an absolute nightmare |
| 19:39 |
oil_boi |
Also, someone's life could change completely in the span of 6 months, that's a very, very long time |
| 19:39 |
oil_boi |
The idea I had was: 1 week bugs, 1 week features, repeat |
| 19:40 |
oil_boi |
Utilize the version number's third digit more often, 5.3.1, 5.3.2, etc even counting up past where that is 5.1.10 if needed |
| 19:40 |
oil_boi |
This would result in less frustration and better development freshness |
| 19:40 |
rubenwardy |
the third number is patch, which means bug fixes |
| 19:41 |
sfan5 |
the version scheme reserves the last digit for bugfixes releases |
| 19:41 |
sfan5 |
ninja'd |
| 19:41 |
oil_boi |
Exactly, and if a major bug is fixed during a week of bug fixing you can bump the release from 5.3.X to 5.3.Y at the end of the week |
| 19:41 |
rubenwardy |
I think that weekly is too much, but monthly is more feasible. The problem is time to test, and difficulty in releasing |
| 19:42 |
rubenwardy |
heh |
| 19:43 |
oil_boi |
This keeps developers and _potential_ developers fresh and on their feet, eager to make additions/bug fixes because the mindset will be, oh man this is gonna be so cool I want to try to add this in as a pr so it can possibly get merged next week!! vs oh man, 6 months until this is gonna even get potentially merged, I'm not even bothering |
| 19:43 |
rubenwardy |
releasing more doesn't mean that PRs will get merged faster |
| 19:43 |
sfan5 |
the minimum theoretical duration until merge is only ever 2-3 weeks |
| 19:43 |
oil_boi |
That's why there was the other idea, trusted non core devs |
| 19:44 |
sfan5 |
unless you mean the point when features appear in a release |
| 19:44 |
oil_boi |
Users allowed to test things that are potential additions and fixes to the engine that improve everything |
| 19:44 |
oil_boi |
They can just say Tested: Approved or Tested: rejected |
| 19:45 |
rubenwardy |
talking about releasing, can we release 5.3 soon? |
| 19:46 |
sfan5 |
if someone finally merged #10145, sure |
| 19:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/10145 -- Fix player controls only being applied for the first move by sfan5 |
| 19:47 |
oil_boi |
Ok, I'll give er a test |
| 19:48 |
rubenwardy |
the code lgtm, |
| 19:48 |
sfan5 |
according to what TheTermos said if you have 100+ fps this doesn't change anything for you |
| 19:48 |
rubenwardy |
I'm not familiar with the code |
| 19:48 |
rubenwardy |
<oil_boi> They can just say Tested: Approved or Tested: rejected |
| 19:48 |
rubenwardy |
so, how would this actually change things? Just a label? |
| 19:49 |
sfan5 |
saves time for coredevs because they have people they can rely on |
| 19:49 |
rubenwardy |
I have been encouraging non-core devs to review and test like that. I did it before becoming on |
| 20:04 |
oil_boi |
An fps difference decides whether or not that code works |
| 20:08 |
oil_boi |
Tested: Rejected https://youtu.be/7e7AW8kY4G0 |
| 20:08 |
oil_boi |
See that method is easy! |
| 20:09 |
rubenwardy |
thanks |
| 20:10 |
sfan5 |
it fixes the bug for 60fps though |
| 20:11 |
sfan5 |
100+ fps should have worked before |
| 20:12 |
oil_boi |
A question: Shouldn't jumping only be viable once the user is committed to standing on the node they are on? |
| 20:12 |
oil_boi |
30fps, ah man I can't believe I'm saying this, feels better |
| 20:13 |
sfan5 |
could be made an option if you want that behaviour for crafter |
| 20:13 |
oil_boi |
But I tried to make that an option :< |
| 20:13 |
sfan5 |
the PR is still open isn't it? |
| 20:14 |
oil_boi |
OH the pr was checking if it was possible, such an old bug in the engine I forgot people liked it, then PR approved yay |
| 20:15 |
oil_boi |
Indeed it is |
| 20:17 |
oil_boi |
Can we get any core to test/approve it so it can finally be merged? |
| 20:18 |
rubenwardy |
oh, so not tested: rejected? |
| 20:19 |
sfan5 |
https://0x0.st/iyvT.mp4 works for me with 30fps btw |
| 20:19 |
rubenwardy |
well, lgtm if it's tested |
| 20:19 |
oil_boi |
Nah, I didn't realize that it was meant to implement the bug, I misread that it was to prevent it |
| 20:19 |
hecks |
actually, a high framerate makes the stair glide work without the fix too |
| 20:20 |
hecks |
talking something like 300+ FPS |
| 20:20 |
hecks |
it becomes possible again |
| 20:20 |
sfan5 |
oil_boi: didn't you find that the bug does not happen with 30fps? |
| 20:20 |
oil_boi |
Hm, could the vs windows 10 compiler be doing some strange stuff to the executable? |
| 20:21 |
sfan5 |
I hope fast math isn't enabled in the msvc options |
| 20:21 |
oil_boi |
It doesn't, I thought that was intended behaviour I have no idea if we're trying to put it in, take it out, or mix it |
| 20:21 |
sfan5 |
but then collision would be entirely broken |
| 20:21 |
hecks |
can someone give me a second opinion on this: client/mesh.cpp, scene::IMeshBuffer* cloneMeshBuffer, does this leak memory or what? |
| 20:21 |
sfan5 |
the objective of the PR is to put the "bug" back in |
| 20:21 |
oil_boi |
Oh then yeah, I have to go back again, and this is why I'll never be core :P |
| 20:22 |
sfan5 |
hecks: it intentionally returns an allocated mesh buffer that the caller is supposed to free (later), sound correct? |
| 20:23 |
hecks |
I'm talking about the use of mesh_buffer->getVertices() inside the function |
| 20:23 |
hecks |
who frees *that*? |
| 20:23 |
sfan5 |
that's a pointer to stuff that's already there |
| 20:23 |
hecks |
hm okay so that's not a copy, and dropping the original mesh will free that |
| 20:23 |
sfan5 |
yea |
| 20:29 |
sfan5 |
rubenwardy: do you think it can be merged then? |
| 20:40 |
|
oiaohm joined #minetest-dev |
| 20:47 |
|
_Zaizen_ joined #minetest-dev |
| 20:51 |
|
Unarelith joined #minetest-dev |
| 20:52 |
|
appguru1 joined #minetest-dev |
| 21:12 |
rubenwardy |
When structuring the CSM sandbox, should we care about things that can crash the client? |
| 21:12 |
rubenwardy |
I guess not |
| 21:16 |
oil_boi |
Yes |
| 21:18 |
rubenwardy |
A `error()` will crash the game gracefully |
| 21:18 |
rubenwardy |
I guess the problem is if it crashes ungracefully |
| 21:19 |
sfan5 |
my personal roadmap includes making all errors graceful so that the client continues working and just disables CSM when it breaks |
| 21:19 |
sfan5 |
no idea if others would agree |
| 21:19 |
rubenwardy |
hmm |
| 21:20 |
rubenwardy |
Could it reload CSM, and pretend it's loading from scratch? |
| 21:20 |
rubenwardy |
heh |
| 21:20 |
sfan5 |
would confuse the server if they communicate |
| 21:20 |
rubenwardy |
true |
| 21:20 |
rubenwardy |
It should close any mod channels, which would allow the server to detect it |
| 21:20 |
oil_boi |
Why would it confuse the server? |
| 21:21 |
rubenwardy |
also, #10162 |
| 21:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/10162 -- Refine CSM sandbox by rubenwardy |
| 21:21 |
hecks |
how about designing it to actually catch lua errors in events, dump an error, and run the next step anyway |
| 21:21 |
rubenwardy |
you can end up in an undefined state |
| 21:21 |
rubenwardy |
actually, that doesn't matter for a client as there's much less risk of corruption |
| 21:21 |
hecks |
this is a VM though, undefined state is not anywhere as scary as it sounds |
| 21:22 |
sfan5 |
still a bad design decision |
| 21:22 |
hecks |
it would have some value as a developer option |
| 21:23 |
hecks |
just dumping someone to desktop/menu for an error makes development somewhat slower, soft errors and hot reloading of code would make this smoother |
| 21:23 |
hecks |
though I admit those things become less valuable the more complex a project gets |
| 21:23 |
oil_boi |
Can we just disable os library for csm since there is minetest.get_us_time and the only class usage for that was os.clock? |
| 21:24 |
rubenwardy |
already is disabled |
| 21:24 |
rubenwardy |
wait no, os.clock, os.date, os.difftime, and os.time exist |
| 21:24 |
rubenwardy |
os.date may crash in some version of Lua |
| 21:24 |
rubenwardy |
which is why I asked the question about crashing |
| 21:24 |
rubenwardy |
if we care about ungraceful crashes due to mods, then os.date would need to be removed/replaced |
| 21:25 |
oil_boi |
Just disable the entire library from being lua accessed with a passthrough function being available in it's place |
| 21:25 |
hecks |
what use is there for os.date in client code? |
| 21:25 |
sfan5 |
to display the local time of when an event happened? |
| 21:25 |
hecks |
hm, okay, local timestamps |
| 21:26 |
oil_boi |
minetest.get_date minetest.get_realtime |
| 21:26 |
hecks |
might as well |
| 21:26 |
oil_boi |
There's already minetest.get_us_time might as well complete the cycle client and server |
| 21:27 |
hecks |
reminder that us_time is broken and someone needs to fix it |
| 21:27 |
sfan5 |
on Windows which nobody uses ;) |
| 21:27 |
hecks |
;] |
| 21:27 |
oil_boi |
Might as well keep it set to US time since that's in there already even though us_time doesn't say which time zone :P |
| 21:27 |
oil_boi |
Hm it seems to work for me |
| 21:28 |
sfan5 |
I think by broken hecks means that it wraps around too fast / at all |
| 21:28 |
hecks |
it overflows after something like two hours |
| 21:28 |
oil_boi |
is it a 32 bit int limit for it? |
| 21:29 |
hecks |
the windows perf counter is supposedly 64 bit but something might be truncating it to 32 |
| 21:30 |
hecks |
in any case it's as easy as checking if the time got reset and accounting for it with an offset |
| 21:30 |
oil_boi |
It must be translating from the os.clock in c++ or whatever it's called into a s32 and then overflowing due to the 32 bit integer limit assigned to it as it's translated into lua |
| 21:31 |
hecks |
on Windows it's using the perf timer |
| 21:31 |
hecks |
oh wait |
| 21:31 |
hecks |
WAIT |
| 21:31 |
hecks |
it's not windows only |
| 21:32 |
oil_boi |
*waiting* |
| 21:32 |
oil_boi |
:O |
| 21:32 |
hecks |
my server is slackware |
| 21:32 |
hecks |
it happened there too |
| 21:32 |
hecks |
in fact, it might be happening *more* often on linux |
| 21:32 |
oil_boi |
This might be why my server randomly crashes when no one is on it even after a full restart with nothing loaded overnight |
| 21:33 |
hecks |
well it's not a crash for me, but animators all suddenly freeze because I never ever use time accumulators in my code |
| 21:33 |
hecks |
and instead check time against time+offset, which always fails after the overflow |
| 21:34 |
hecks |
now if you also naively calculate delta time from us_time, and apply it to anything... |
| 21:35 |
oil_boi |
The us must be responsible for this |
| 21:35 |
hecks |
capitalist pigs |
| 21:41 |
hecks |
updated #10105 please change the tag |
| 21:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/10105 -- minetest.get_us_time overflow |
| 22:24 |
hecks |
still a little messy but damn https://a.cockfile.com/4CBx2F_batch.jpg |
| 22:34 |
hecks |
https://a.cockfile.com/u4sLrr_saved.jpg check out the 'batches saved' count |
| 23:22 |
hecks |
ah, yes |
| 23:23 |
hecks |
nothing like solving the camera offset problem by just cutting it out :] |
| 23:32 |
pgimeno |
o.O what does that mean? |
| 23:34 |
hecks |
at the moment, minetest applies the camera offset to every map mesh in existence, statically |
| 23:35 |
hecks |
literally iterating over blocks, then over their verts and adding the camera offset there |
| 23:36 |
hecks |
so I've changed it to just set a transform matrix when drawing like anyone sane would |
| 23:36 |
oil_boi |
Hahaha, that's why only 500 fps |
| 23:36 |
hecks |
now this only happens when the offset changes |
| 23:37 |
hecks |
but it probably results in a visible spike |
| 23:37 |
hecks |
also, repeatedly shifting all world geometry might not be healthy for precision |
| 23:38 |
oil_boi |
Does the geometry get rebuilt even when the user has no camera/positional vector change? |
| 23:38 |
hecks |
well, in this case no, the camera offset is tied to your position and changed every 200m but |
| 23:38 |
hecks |
I've got an unrelated thing going on where minetest is sending me block changes for no apparent reason, even when I'm stationary |
| 23:39 |
|
xerox123_ joined #minetest-dev |
| 23:39 |
oil_boi |
Abm calculations causing a nil block update? |
| 23:39 |
hecks |
no, this is a very very barebones devtest setup meant to isolate this |
| 23:39 |
hecks |
time frozen, no abms, no nothing |
| 23:40 |
hecks |
by the way if you're getting 500 fps *now* I should let you try my branch soon |
| 23:40 |
oil_boi |
ABMs might still be running even though they're assigned not to, I would give er a check in case the server is running that code, I dunno man grasping for straws at a haystack here |
| 23:40 |
hecks |
this is even better than those blocksize 64 tests |
| 23:40 |
hecks |
well the one thing I noticed |
| 23:41 |
hecks |
whenever those block changes are sent, the geo *is* updated somehow |
| 23:41 |
hecks |
by like one quad |
| 23:41 |
* oil_boi |
looks at server env source |
| 23:41 |
hecks |
I've combed through that already |
| 23:41 |
hecks |
but you're welcome to try, let me look something up |
| 23:42 |
oil_boi |
Do you have any liquids around you? |
| 23:42 |
hecks |
this was definitely the "block update due to packet" path |
| 23:42 |
hecks |
it happened even on a map without liquids |
| 23:43 |
hecks |
just mgflat with zero features |
| 23:43 |
pgimeno |
<hecks> also, repeatedly shifting all world geometry might not be healthy for precision <-- I've been trembling about that since I saw it, so nice job moving it to a matrix, let's hope it doesn't affect precision too. Try near the 30K border. |
| 23:43 |
oil_boi |
Could it be auto unloader doing an instant unload-reload |
| 23:44 |
oil_boi |
https://github.com/minetest/minetest/blob/master/src/server.cpp#L585 |
| 23:44 |
hecks |
maybe it's the client "forgetting" a block when it shouldn't |
| 23:44 |
oil_boi |
That would certainly do that actually |
| 23:44 |
hecks |
but right, I wonder, I should disable data unloading entirely |
| 23:45 |
hecks |
but first let me fix the... map edge precision problems |
| 23:45 |
hecks |
the other thing mapblockmesh does is translate the whole block geo to its world position |
| 23:46 |
hecks |
so effectively if you teleport to the edge of the map, you will translate it back from that position..... statically |
| 23:46 |
hecks |
well okay, it will be cancelled out when the block is meshed |
| 23:46 |
hecks |
but I'll just like, use a matrix, man |
| 23:47 |
hecks |
oh right, my batcher doesn't cull or forget anything yet https://a.cockfile.com/0jzlvK_18kdrawcalls.jpg |
| 23:52 |
|
fluxflux joined #minetest-dev |
| 23:54 |
oil_boi |
Was very nervous clicking that link but I'm glad I did that's crazy |
