Time Nick Message 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 19:25 hecks Are tile layers used for something other than cracko? 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 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? 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 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 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:54 oil_boi Was very nervous clicking that link but I'm glad I did that's crazy