Time Nick Message 05:39 Pexin welp bisect for bouncy gave me #9343 , big surprise 05:39 ShadowBot https://github.com/minetest/minetest/issues/9343 -- Collision various fixes by TheTermos 05:42 Pexin >3ad5388c6d3894e2f4aa7158cc2b62b626f0f967 is the first bad commit 10:55 sfan5 yeah that's what I guessed 12:33 kilbith sfan5 is basically alone maintaining MT; what are the other core-devs doing? 12:33 celeron55 cheering him up 12:49 MTDiscord If I can speed up any part of the boring parts for him, I'm willing to spend some time doing that each week. I just need to be asked. 12:54 kilbith you only need to focus better on stuff that matter, because nobody cares of GCC 5 or i386 but sinister nerds 12:55 kilbith HEAD~10 ain't making my dick hard 12:55 MTDiscord kilbith: That's BS 12:55 MTDiscord Breaking GCC 5 compat was absolutely unnecessary; it took only a couple small changes to restore it 12:56 sfan5 nobody noticed of however many months, so clearly it wasn't that important 12:57 kilbith ^ 12:57 MTDiscord Well, it only was the dev version, right? 12:57 MTDiscord Do you think the systems running ancient GCC versions are running dev versions? 12:57 sfan5 I think nobody runs ancient GCC versions 12:58 sfan5 gcc 4.8 or 4.9 is effectively broken even on 5.4 12:58 MTDiscord My point simply is that upgrading to newer GCC isn't worth it just for initializer curly braces. If you want to use more features, sure, do it. But not for minor things. 13:00 celeron55 the unspoken rule we have is: there is no need to support anything older than what debian stable has, altough i think centos or whatwasit was dragging us down lately 13:00 kilbith you'll understand what is stuff that matter when you make it to mass-market, Luatic 13:00 celeron55 unspoken and unwritten :D 13:00 MTDiscord Stuff that matters includes extensive testing before PRs are merged, not after the fact as you suggest with your "aggressive" merging strategy 13:00 sfan5 by virtue of the development process the simple stuff usually gets approved first 13:01 sfan5 there's a few PRs that would bring changes that matter for a 5.5 release but they're still just there, waiting 13:01 MTDiscord #11427 is still waiting to be merged 13:01 ShadowBot https://github.com/minetest/minetest/issues/11427 -- Redo serialize.lua by appgurueu 13:02 MTDiscord It's been idling for half a year now despite (1) being Lua (2) fixing a bug (3) being rather small (4) being maintenance 13:02 sfan5 though looking at the commit history one might think other coredevs have forgot how to operate the merge button 13:02 kilbith "if it's not broken, don't fix it" 13:03 MTDiscord kilbith: unfortunately serialize.lua IS BROKEN 13:03 sfan5 @luatic a refactor is not "just maintenance" 13:04 MTDiscord I should file a bug for nan and inf handling of the current serialization as well I guess 13:19 MTDiscord #11899 13:19 ShadowBot https://github.com/minetest/minetest/issues/11899 -- minetest.deserialize fails for serialized data containing NaN or infinities 13:41 MTDiscord I have no kind of official education or development experience in C++, kilbith. If you'd like me to work on something engine-wise I'm certainly willing to get started, but I was avoiding it for the core dev's sake. 14:01 MTDiscord As my life gets more free time in the next year I plan to be more active as a maker of PR's and reviewer, as I agree sfan5 needs more help 14:14 MTDiscord Honestly should consider allowing prs being approved once only with conditions. Else look no further than what happened to mtg 14:17 celeron55 maybe we need something to offset the annoying bit of responsibility resulting from the pressing of the merge button 14:17 celeron55 i have no idea what that would be 14:20 MTDiscord is it really annoying? 14:20 MTDiscord i think the problem is the most core devs are just busy with smth else 14:22 celeron55 i'm not saying it's the primary reason for anything 14:22 celeron55 but it might have an effect 14:24 celeron55 we generally don't have a culture of blaming people for merging stuff, altough sometimes individuals make some exception to that (which is not a good idea) 14:25 celeron55 many times whoever is merging is just following the process and all the decisions have already been made or agreed to by others 14:26 MTDiscord New rule, all merge button presses automatically fill in celeron55 as the merger 14:27 MTDiscord if it's really a problem, you can fill me as a merger, i don't mind :D 14:28 MTDiscord but i think people don't blame core devs, except few toxic individuals 14:29 MTDiscord actually everyone can review a pr, so everyone is to blame :) 14:29 MTDiscord Well, blame for what? Slow merges? Or slow improvements? It seems like we move at a reasonable pace for open source 14:32 MTDiscord for merging broken code ig 15:32 kilbith__ ffmpeg support reconsideration; game makers need proper cutscenes 15:33 kilbith__ hecks agrees with that 15:33 MTDiscord is ffmpeg really necessary for that though? 15:33 kilbith__ * needs reconsideration 15:38 celeron55 realtime CGI would seem much more minetesty for a cutscene 15:39 MTDiscord I was never really excited about that ffmpeg thing, but if we ended up pulling in Opus and AVIF as a side effect that might actually be pretty interesting :-) 15:41 celeron55 but for a realtime rendered cutscene, some apis need to be made, most obviously camera controls 15:41 celeron55 you can kind of do it now too though, maybe it needs a bit of a review 15:42 kilbith ffmpeg supports media reading from URLs, idk about other libs 15:42 celeron55 the engine isn't very far off from some kind of a cutscene creation mod toolset to be possible 15:43 celeron55 (depending on what exactly you want from it) 15:43 sfan5 a camera API is sorely needed, this is again obvious when testing some of the game jam submissions 15:43 MTDiscord yes 15:43 celeron55 (if you want to block out the actual current world the player is in, for example to whitelist entities for rendering as they can be in the way, that's something that i can see being needed) 15:44 celeron55 (could be part of a camera api) 15:45 MTDiscord I am vaguely planning to work on an aerial combat game, but for that I'd need 1. camera roll 2. better (possibly scriptable) client prediction 3. massive performance improvements for emerging and generating the map, as fighter airplanes go fast 15:50 MTDiscord Mapgen could run in RAM, that was my solution 15:50 MTDiscord As for camera stuff, yeah that is absolutely needed. 15:50 MTDiscord And client side physics is already near and dear to my heart ;) 16:06 MTDiscord One simple improvement I feel like we could actually use is just player:add_pos(), i.e. the ability to teleport the player, but without "resetting" any movement that may have happened on the client-side since the teleportation vector was calculated. 16:07 MTDiscord This would work well for e.g. when you want to seamlessly teleport a player from one area to another with similar collision geometry, or when you want to, say, "bump" a player out of a solid block but don't want to reset movement on axes perpendicular to the direction of movement. 16:17 MTDiscord set_pos() should be made to not half-do that too 16:22 sfan5 it's a miracle the new biome selection in the world tab even works 16:22 sfan5 the settings aren't actually written to map_meta.txt, they merely hang around globally and if you start the world right after creating it they will happen to work 16:22 MTDiscord I think there are times when you will absolutely want to set the player's pos to a specific location, like a teleport that's supposed to "feel like" a teleport, and others where you'll want a relative teleport, like when you're trying to hide the transition, or where you just want to correct player location along a specific axis, like nudge them up out of a floor. 16:53 sfan5 @Warr1024 would you have some time to review recent PRs that are sitting in the backlog 16:57 MTDiscord I can try to take a sweep at them. Anything specific you had in mind? 16:58 sfan5 preferably bugfix/maintenance PRs or ones that are in https://github.com/minetest/minetest/milestone/18 17:03 MTDiscord RE FFMPEG support: It seems to me that if someone wants to get their PR merged, they shouldn't rage quit, flip everyone off, and delete the branch, but I digress. I don't think that adding such a big dependency is worth it just to support the worst kind of cutscene when in-world cutscenes that leave the player in control (Valve style) are almost universally considered the better alternative, and are feasible. 17:06 MTDiscord tbh cutscenes are sort of the last thing I'd want to do with it. It could be used for much better texture animation compression (where lossy is acceptable but you want smoother motion at lower media cost) and some of the codecs you'd drag in with it are things I'd want supported for other uses anyway. 17:43 kilbith Benrob: at least I do have code to contribute, unlike some people that waste their time on Discord… but I digress 17:44 kilbith I am not fine with just having a camera API for cutscenes. Can you imagine Diablo games without video cutscenes ? 17:45 MTDiscord @Benbob0329 in-world cutscenes aren't feasible with the current API we have for doing in-world stuff, and that isn't limited to the camera API 17:45 MTDiscord and even if in-world cutscenes would be feasible, they would still be inferior to video cutscenes which could be prerendered on more powerful devices 17:46 kilbith For once we do agree, Luatic 17:46 MTDiscord I think it's sad that the FFMPEG PR died. 17:48 sfan5 I think some of the formspec/hud/camera mess needs to be sorted out first before it's a good moment to add such features 18:21 Krock will push trivial segfault fix in 20 minutes: https://krock-works.uk.to/u/patches/0001-Fix-segfault-in-drawItems-due-to-missing-inventory-l.patch 18:21 Krock discovered while testing the TowerDefense Game Jam game 18:30 MTDiscord Yeah, formspec mess cleanup is a great target. 18:40 Krock how would you clean that up? 18:40 Krock it's a giant pile of features mixed with legacy code 18:41 Krock pushing patch 18:42 Krock done 18:48 sfan5 Krock: I stumbled upon that too, but I wondered whether drawItems() just shouldn't return entirely 18:49 Krock I thought so too, but then you wouldn't see a frame at all 18:49 Krock and I thought having a frame drawn, but no items is better than discarding the entire HUD element 18:50 Krock after all, the same would happen if the inventory list were empty 18:50 sfan5 IMO discarding the entire element when the inventory does not actually exist is okay but not so important 18:50 Krock well yes. it does not matter. in terms of safety it might be better to return right away ... *shrug* 18:51 Krock by the way. did you test #11903 with MSVC, or crosscompiled through wine? 18:51 ShadowBot https://github.com/minetest/minetest/issues/11903 -- Socket-related cleanups by sfan5 18:52 Krock *cross-compiled and then tested with Wine 18:52 sfan5 msvc and tested in a vm 18:52 Krock great 18:56 sfan5 maybe the windows CI could run unittests with wine, wonder if that works 18:58 Krock considering how many games run in Wine, it would be very surprising if it didn't 19:06 celeron55 some of --run-unittests seem to fail when ran in wine, using the official portable release 19:08 celeron55 here's which tests if someone is wondering http://paste.dy.fi/mFe/plain 19:10 celeron55 and if someone is wondering, this is wine-6.0 (Staging) 19:18 Krock 6.0 is pretty old already 19:18 Krock wonder what's causing the fails... hmm 19:19 MTDiscord fails for me on official minetest 5.4.1 win64 binaries too, under wine 7.0rc1... and freezes at testGetModNames for some reason? 19:20 MTDiscord the fact something as simple as testLowercase is failing is super weird though 19:21 sfan5 >6.0 is pretty old already does c55 run debian stable? 19:22 Krock even Debian Sid is still on 5.0.3-3 19:28 sfan5 Krock: did you get that game jam submission to run? I gave up on it 19:29 Krock I did manage to join the provided world, but I cannot get anything done in it. 19:29 Krock the spreadsheet also contains notes about what issues I had. same for all other games 19:31 sfan5 provided world? ohhhh 19:31 MTDiscord Are PlayerRefs guaranteed to not be replaced from on_joinplayer to on_leaveplayer? Currently this is the case AFAIK, would be nice if this could be included in the docs as a hard guarantee. 19:31 Krock technically, the server might shut down without calling leaveplayer in singleplayer mode AFAIK 19:32 sfan5 I don't think this is something we want to guarantee 19:45 sfan5 would be convenient if someone could review #11881, it's just code removal 19:45 ShadowBot https://github.com/minetest/minetest/issues/11881 -- Remove unused (de)serializeAttributes() methods by rollerozxa 19:50 MTDiscord @Luatic Rather than giving in to my bad tendency to take on projects I really don't gave time just to try and prove a stupid point, is there any reason in particular you don't think an animated mesh(es) wouldn't work for an in-world cutscene (similar to the Kleiner's Lab scene at the start of HL2)? 19:51 MTDiscord The issues I can think of are mainly related to making positional audio work properly, but you could have sound emitted objects that only have to roughly be in the right place to sound right 19:51 MTDiscord *emitter 19:51 Pexin is minetest a movie making engine? 19:51 Pexin sorry, nevermind me 19:53 MTDiscord minetest is a drama making engine 19:54 Pexin @savilli: and I played right into it...... damn. x_x 19:56 MTDiscord We all do, unfortunately 19:59 MTDiscord kilbith: Sorry, I didn't need to be passive aggressive about that. To be fair to your PR, most Linux distros already have the ffmpeg libs installed so its not like it's a lot of extra download. My main concern is that it'll wind up adding a lot of extra complexity that will only cause problems later, but thats really down to how well the core devs can maintain it. 20:00 celeron55 21:20:31 <+sfan5> >6.0 is pretty old already does c55 run debian stable? 20:00 celeron55 yeah this can of worms is getting a bit old, should open the new one already 20:11 kilbith yes, ffmpeg is a helluva complex lib, but then it can be feed with virtually anything (including GIF and URL) 20:12 kilbith life tends to grow in complexity, get used to that 20:12 kilbith it's not like it's a suckless ideological project 20:12 MTDiscord It's probably better to use one big complex lib than to try to duct tape together a hundred little ones to get the same effect 20:12 kilbith +1 20:13 MTDiscord If ffmpeg handles the duct tape part of this for us, and makes is so we don't have to maintain all that crap ourselves, that sounds nice. 20:13 kilbith that's why I disagree with you on faking a cutscene with animated spritesheet, it's much heavier and time wasting 20:17 kilbith so yeah, I'll happen to re-open my PR once hecks is back 20:18 MTDiscord Nothing to do with suckless-level ideology, its a practical concern that too much added complexity might cause the whole project pain sometime down the road. 20:19 kilbith hey, ffmpeg is pretty solid software 20:20 celeron55 does the PR have working builds for windows and android? 20:20 MTDiscord I do often find myself wondering if our attitude about external dependencies is really healthy for the project though. Avoiding them is nice in that they can be a pain, but losing the functionality can also be pretty painful. 20:20 kilbith celeron55: no, I did develop it under linux 20:21 rubenwardy ffmpeg is solid, my concerns would be more with media loading 20:22 rubenwardy using minetest's built-in media transfer would be a terrible idea, as-is, it can't handle large media 20:22 sfan5 well it can, with remote_media ;) 20:22 rubenwardy that's still stored the same way locally though - in the cache and in memory 20:22 celeron55 historically MT has taken in dependencies when there has been a valid use case and compiling has been able to be kept easy 20:23 MTDiscord Can confirm that FFmpeg is fantastic. If the devs are comfortable enough working with it I think that MT can probably work around media issues. 20:23 celeron55 i have a hard time imagining people make video content for MT for any other purpose than maybe education 20:23 rubenwardy we need some better way to handle large media to support music better 20:23 celeron55 education is a valid use case though 20:24 MTDiscord I mean, I have to wonder how difficult it'd be to support a small HTTP server for media transfer automatically, perhaps running on another non privileged port 20:25 celeron55 well it could run on TCP at the same port as the UDP socket is opened for the custom protocol 20:25 celeron55 assuming all platforms support that 20:25 kilbith__ ffmpeg is able to capture the camera also, so let's imagine people taking selfies for their in-game posters 20:26 MTDiscord yeah let's make the camera controlled by the server /s 20:26 MTDiscord what can be wrong 20:26 MTDiscord I'd love lazy loading and custom media handlers via URI scheme but I think that is probably well out of scope for MT. 20:26 celeron55 this is starting to sound like a blocky 3D version of facebook 20:27 rubenwardy don't worry, formspecs are too shit for infinite scrolling 20:27 kilbith__ you people doesn't seem to know what stuff is selling and what is not 20:27 sfan5 blockchain certainly sells 20:27 sfan5 maybe we should add that 20:27 MTDiscord We've already got the blocks 20:28 MTDiscord minetest NFT! 20:28 Pexin rubenwardy: seems to me that brings up the point: there are more important priorities, like formspec reform 20:28 MTDiscord Thats because our wallets aren't tied to MT :P 20:29 MTDiscord Shitty movie sequals and remakes are selling, but that'd be the last thing I'd want to make. 20:30 celeron55 i have an idea: we'll add ffmpeg to one release, and then if nobody makes any proper content using it, we'll remove it from the next release 20:30 celeron55 what's proper? well, obviously content i personally like 20:30 MTDiscord Heh, I feel like I've heard this before 20:31 rubenwardy I get that's probably a joke, but by that point you would have already spent the effort to review it and fix media loading 20:31 celeron55 it's a half joke 20:31 MTDiscord Does media loading need to be fixed right away, or can we see what kinds of things its actually used for first? 20:31 rubenwardy our feature compat policy would be ? by that point 20:32 rubenwardy you'd need to severly limit the length of videos to have any reasonable performance / loading times 20:32 MTDiscord Servers which make use of massive media can always use a mediaserver 20:32 celeron55 it can say to everyone using it and in the api docs that it's experimental 20:33 sfan5 I think the original plan in that PR was to just let the server specify a HTTP/RTMP or whatever url to load and play 20:33 sfan5 and not actually deliver the media via MT 20:33 sfan5 I might be misremembering 20:33 rubenwardy that would work 20:34 MTDiscord Is this just like playing fullscreen video over top of the game we're talking about, or can videos actually be perspective-mapped and occluded on in-game geometry? 20:34 MTDiscord Heh, I can see laggy mirrors being implemented with a stream and client already :P 20:34 rubenwardy the demo had them rendered on nodes 20:34 kilbith__ fullscreen video would take the form of video[] in a formspec 20:34 Pexin security cam ingame video screens? 20:34 MTDiscord I'd still see some value, with the right choice of codec, for using this for things that are not live-streamed, like animated textures. 20:35 sfan5 what kind of animated textures do you have that video codecs make sense 20:35 celeron55 you need to remember for example hecks' project is an mmorpg, it's not an issue to set up media or even streaming servers for something like that 20:35 kilbith__ and yes, I did render a video on the map 20:35 MTDiscord Something where I want smoother interpolated motion, like liquids, would make the most sense for video-animated textures. 20:36 MTDiscord This still feels like a can of worms, but that can does seem useful. 20:36 sfan5 wat 20:36 celeron55 that sounds mind bogglingly resource hungry and completely out of any world you can imagine 20:36 sfan5 I think you're grossly underestimating the overhead of using real video codecs just for that 20:36 celeron55 i'd like to see it just to have a laugh 20:37 MTDiscord real video codecs for which thing? 20:37 sfan5 liquid textures like you just said 20:37 celeron55 i mean, just imagine walking past walls of nodes each showing some sort of video type media 20:38 celeron55 you don't expect it 20:38 celeron55 you don't even think it's possible 20:38 MTDiscord For simple looping animations I don't see why the overhead would be an issue. The bigger problem would be the memory use once it's been unpacked, but that's always been an issue anyway. 20:38 celeron55 but it would be 100% useless 20:39 MTDiscord Honestly I think that there are bigger hurdles to content creation than this (namely B3D and a better camera API) 20:39 celeron55 ^ 20:39 MTDiscord It'd be a trade off between media compression over the network vs. the decompression time. 20:39 MTDiscord I'd rather see Assimp than FFmpeg as a dependency 20:40 MTDiscord I don't see a reason to hold back ffmpeg just because people can't imagine a case where they personally would want to use it, but there do seem to be plenty of other reasons to keep it shelved for now. 20:40 sfan5 I am also questioning that the encoded version would even be smaller than the PNG "animations" we have now 20:40 sfan5 unless of course you mean video codec = GIF 20:40 kilbith__ sfan5: it is definitely smaller, I compared 20:40 MTDiscord At least it would require the other platforms to handle it before we can really move forward with it. 20:41 kilbith__ video codec are much more efficient are compression n frames than a PNG spritesheet 20:41 kilbith__ *at 20:41 MTDiscord ^ 20:41 sfan5 which codec? resolution? frame count? settings? 20:41 MTDiscord Temporal compression is handy for long or complex texture animations 20:41 kilbith__ sfan5: mp4 20:41 sfan5 mp4 is a container 20:42 MTDiscord There are already cases where we aren't using PNG anyway, e.g. where JPEG outperforms it, like for skyboxes. That would be a pretty spectacular place to see video (though much more daunting to try to actually do efficiently) 20:42 sfan5 you're not wrong but I suspect it doesn't match what Warr meant when he said "liquid textures" 20:42 sfan5 s/it/the example/ 20:42 MTDiscord I smell "giant ass globe video floating in the background" all over again 20:43 MTDiscord If we're assuming people are mostly going to stick with 16px pixel-art-style for everything then we're risking imposing our stylistic preferences onto game devs. 20:43 MTDiscord MOST MT art is very small-scale and compresses better with lossless techniques anyway, but it doesn't all necessarily have to be that way. 20:43 MTDiscord But potential misuse is not reason enough to dismiss a feature, unless that potential is dangerous. 20:44 MTDiscord I mean if gamedevs want to shoot themselves in the foot and build some feature that Works On My Machine but is completely useless for real-world players, it's not like we don't already give them all the tools they need for that :-D 20:45 MTDiscord I'm much more inclined to give them the tools they might need and let them take responsibility for how they use them though. 20:45 MTDiscord sounds line Invector /s 20:45 MTDiscord *like 20:46 MTDiscord Heh, well giving them power and responsibility is on a "for better or worse" basis, not necessarily "for better xor worse" :-) 20:47 celeron55 assimp seems to have a reasonable build system and dependencies 20:48 celeron55 self contained and uses cmake, you can't get much more easy to use and multiplatform than that 20:50 celeron55 but we can of course ask how many formats we really want to support, it's an attack vector after all 20:50 celeron55 supporting one good format makes more sense 20:50 sfan5 (that's gltf) 20:50 MTDiscord Assimp would remove the need for MT to care 20:50 MTDiscord In theory, anyways 20:51 celeron55 well 20:51 celeron55 the server could convert all formats to glTF then, before sending to the client 20:51 MTDiscord New model formats, old model formats, it no longer has to handle them 20:51 celeron55 then the client doesn't have to trust all its model loading code 20:52 sfan5 that's certainly an interesting idea 20:52 sfan5 bad for startup times though 20:52 MTDiscord Assimp converts everything to it's own internal format iirc 20:52 MTDiscord You support that, and it handles everything else 20:52 celeron55 is assimp's own internal format safe to load from an untrusted source? 20:52 celeron55 i would assune no 20:52 celeron55 assume* 20:53 MTDiscord Great question 20:53 MTDiscord Probably one for the Assimp devs 20:53 MTDiscord what about tinygltf? 20:53 celeron55 https://github.com/assimp/assimp/tree/v5.0.1/code/Assbin 20:53 celeron55 i assume it's this one 20:54 MTDiscord https://github.com/syoyo/tinygltf fairly minimal and lightweight gltf loading library. only caveat it is it uses another json library from the one minetest uses 20:54 celeron55 it seems reasonably written 20:55 celeron55 i could trust that 20:55 celeron55 at least after a bit of fuzz testing 20:55 MTDiscord Hopefully gltf doesn't go out of style, but then we've limped along with B3D for this long 20:56 MTDiscord We'll still need to hold onto the old B3D code though 20:56 sfan5 it's cool that it tries to be dependency-free but it vendors image loading code 20:57 MTDiscord *if we use a gltf library specifically 20:57 celeron55 assimp uses rapidjson 20:57 sfan5 honestly we should just roll our own gltf support 20:57 celeron55 tinygltf uses a json library crammed inside a single .hpp file 20:58 MTDiscord sfan5: is that really worth it though? 20:58 celeron55 it seems to be a concatenated version of https://github.com/nlohmann/json 20:58 sfan5 not including unnecessary features (baggage) is worth it to me 20:58 MTDiscord NIH syndrome and all but MT doesn't have a good history with this sort of thing 20:59 sfan5 what do you mean? 20:59 celeron55 gltf has to be loaded into MT's (irrlicht's) custom data structures anyway 20:59 celeron55 neither assimp nor tinygltf will do that 20:59 celeron55 that's the reason for rolling our own 21:00 MTDiscord MT has a history of slow progress, with POCs getting lost to time and poor implementations. 21:00 MTDiscord But hey, I won't say you shouldn't, I'm just asking if its worth it. 21:01 celeron55 i would put more focus on camera api though 21:01 celeron55 we have model loading, we don't have a camera api 21:02 MTDiscord Working with B3D remains a pain 21:03 Pexin with scripted camera controls, I'd like the option of making something that plays like zelda64, complete with enemy lock-on feature (need more mappable buttons. would be terrible for keyboard) 21:05 MTDiscord I think the main things are: A) Lua settable mouse sensitivity (probably a multiplier), B) Restricting camera modes, and C) Smooth swiveling of the player camera from Lua 21:06 Pexin "smoothed" mouse camera movement always gives me unbearable motion sickness, if that's what you mean 21:11 MTDiscord No, I mean interpolated 21:12 MTDiscord ie not just setting the yaw/pitch/roll, but also setting how long it takes to move there 21:12 MTDiscord player:add_yaw(rads, seconds) or something 21:47 sfan5 Krock: do you want me to merge #11851 too? 21:47 ShadowBot https://github.com/minetest/minetest/issues/11851 -- Formspec: Unify argument checks by SmallJoker 21:47 sfan5 and v-ro... oh 21:47 sfan5 timeout 21:47 Krock sfan5: totally forgot about that one. feel free to do so 21:48 sfan5 ~tell v-rob both of your PRs are approved, please merge them when you have a moment 21:48 ShadowBot sfan5: OK. 21:49 sfan5 merging irr#86, #6765, #11881, #11903 in 10m 21:49 ShadowBot https://github.com/minetest/minetest/issues/6765 -- Add more neighbors on mesh update by numberZero 21:49 ShadowBot https://github.com/minetest/minetest/issues/11881 -- Remove unused (de)serializeAttributes() methods by rollerozxa 21:49 ShadowBot https://github.com/minetest/minetest/issues/11903 -- Socket-related cleanups by sfan5 21:49 ShadowBot https://github.com/minetest/irrlicht/issues/86 -- Remove unused attribute saving and loading by rollerozxa 21:51 kilbith Krock: when will we finally get the runtime update checker finished? 21:51 kilbith same question for sfan5 about the Lua async PR 21:52 Krock maybe 2022 21:52 kilbith I do not forget these important PRs 21:52 sfan5 maybe 2022 21:52 Pexin 2022 is saturday ._. 21:52 MTDiscord maybe 2022 22:43 sfan5 oh jeez I forgot to merge the PR I promised 22:43 sfan5 merging #11851 in 8m 22:43 ShadowBot https://github.com/minetest/minetest/issues/11851 -- Formspec: Unify argument checks by SmallJoker 23:15 nrz_ Haha 23:15 nrz_ Well done sfan5 23:26 MTDiscord #11907 - are formspecs completely unusable!? 23:26 ShadowBot https://github.com/minetest/minetest/issues/11907 -- Showing a formspec shortly after another one was closed works rarely