Minetest logo

IRC log for #minetest-dev, 2021-12-29

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:07 Alias2 joined #minetest-dev
01:06 v-rob joined #minetest-dev
03:55 v-rob joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
05:11 olliy1or joined #minetest-dev
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
09:35 calcul0n_ joined #minetest-dev
10:33 Fixer joined #minetest-dev
10:55 sfan5 yeah that's what I guessed
11:10 olliy joined #minetest-dev
11:17 appguru joined #minetest-dev
12:29 calcul0n__ joined #minetest-dev
12:31 kilbith joined #minetest-dev
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 <josiah_wi> 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 <luatic> kilbith: That's BS
12:55 MTDiscord <luatic> 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 <luatic> Well, it only was the dev version, right?
12:57 MTDiscord <luatic> 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 <luatic> 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 <luatic> 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 <luatic> #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 <luatic> 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 <luatic> kilbith: unfortunately serialize.lua IS BROKEN
13:03 sfan5 @luatic a refactor is not "just maintenance"
13:04 MTDiscord <luatic> I should file a bug for nan and inf handling of the current serialization as well I guess
13:17 kilbith_ joined #minetest-dev
13:19 MTDiscord <luatic> #11899
13:19 ShadowBot https://github.com/minetest/minetest/issues/11899 -- minetest.deserialize fails for serialized data containing NaN or infinities
13:33 kilbith__ joined #minetest-dev
13:41 MTDiscord <josiah_wi> 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 <exe_virus> 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 <Jonathon> 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 <savilli> is it really annoying?
14:20 MTDiscord <savilli> 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 <exe_virus> New rule, all merge button presses automatically fill in celeron55 as the merger
14:27 MTDiscord <savilli> if it's really a problem, you can fill me as a merger, i don't mind :D
14:28 MTDiscord <savilli> but i think people don't blame core devs, except few toxic individuals
14:29 MTDiscord <savilli> actually everyone can review a pr, so everyone is to blame :)
14:29 MTDiscord <exe_virus> Well, blame for what? Slow merges? Or slow improvements? It seems like we move at a reasonable pace for open source
14:32 MTDiscord <savilli> for merging broken code ig
15:03 kilbith__ joined #minetest-dev
15:18 Fixer joined #minetest-dev
15:32 kilbith__ ffmpeg support reconsideration; game makers need proper cutscenes
15:33 kilbith__ hecks agrees with that
15:33 MTDiscord <Sublayer plank> 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 <Warr1024> 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 kilbith joined #minetest-dev
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 <luatic> 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 <luatic> 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 <exe_virus> Mapgen could run in RAM, that was my solution
15:50 MTDiscord <exe_virus> As for camera stuff, yeah that is absolutely needed.
15:50 MTDiscord <exe_virus> And client side physics is already near and dear to my heart ;)
16:06 MTDiscord <Warr1024> 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 <Warr1024> 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:11 Extex joined #minetest-dev
16:17 MTDiscord <LandarVargan> 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 <Warr1024> 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:45 olliy joined #minetest-dev
16:53 sfan5 @Warr1024 would you have some time to review recent PRs that are sitting in the backlog
16:57 MTDiscord <Warr1024> 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 <Benrob0329> 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 <Warr1024> 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:09 asdflkj_sh joined #minetest-dev
17:24 Taoki joined #minetest-dev
17:43 kilbith joined #minetest-dev
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 <luatic> @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 <luatic> 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 <luatic> 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:05 Fixer joined #minetest-dev
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 <exe_virus> 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:04 kilbith__ joined #minetest-dev
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 appguru joined #minetest-dev
19:19 MTDiscord <Sublayer plank> 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 <Sublayer plank> 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:26 v-rob joined #minetest-dev
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 <luatic> 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 <Benrob0329> @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 <Benrob0329> 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 <Benrob0329> *emitter
19:51 Pexin is minetest a movie making engine?
19:51 Pexin sorry, nevermind me
19:53 MTDiscord <savilli> minetest is a drama making engine
19:54 Pexin @savilli: and I played right into it...... damn.  x_x
19:56 MTDiscord <Benrob0329> We all do, unfortunately
19:59 MTDiscord <Benrob0329> 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:05 kilbith joined #minetest-dev
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 <Warr1024> 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 <Warr1024> 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:14 GreenXenith joined #minetest-dev
20:17 kilbith so yeah, I'll happen to re-open my PR once hecks is back
20:18 MTDiscord <Benrob0329> 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 <Warr1024> 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 <Benrob0329> 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:23 kilbith_ joined #minetest-dev
20:24 kilbith__ joined #minetest-dev
20:24 MTDiscord <Benrob0329> 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 <savilli> yeah let's make the camera controlled by the server /s
20:26 MTDiscord <savilli> what can be wrong
20:26 MTDiscord <Benrob0329> 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 <Warr1024> We've already got the blocks
20:28 MTDiscord <savilli> 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 <Benrob0329> Thats because our wallets aren't tied to MT :P
20:29 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Warr1024> 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 <Benrob0329> 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 <Warr1024> 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 <Warr1024> Something where I want smoother interpolated motion, like liquids, would make the most sense for video-animated textures.
20:36 MTDiscord <Benrob0329> 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 <Warr1024> 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 v-rob joined #minetest-dev
20:38 celeron55 you don't expect it
20:38 celeron55 you don't even think it's possible
20:38 MTDiscord <Warr1024> 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 <Benrob0329> 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 <Warr1024> It'd be a trade off between media compression over the network vs. the decompression time.
20:39 MTDiscord <Benrob0329> I'd rather see Assimp than FFmpeg as a dependency
20:40 MTDiscord <Warr1024> 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 <Warr1024> 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 <Benrob0329> ^
20:41 sfan5 which codec? resolution? frame count? settings?
20:41 MTDiscord <Benrob0329> 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 <Warr1024> 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 <Benrob0329> I smell "giant ass globe video floating in the background" all over again
20:43 MTDiscord <Warr1024> 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 <Warr1024> 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 <Benrob0329> But potential misuse is not reason enough to dismiss a feature, unless that potential is dangerous.
20:44 MTDiscord <Warr1024> 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 <Warr1024> 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 <Benrob0329> sounds line Invector /s
20:45 MTDiscord <Benrob0329> *like
20:46 MTDiscord <Warr1024> 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 <Benrob0329> Assimp would remove the need for MT to care
20:50 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> Assimp converts everything to it's own internal format iirc
20:52 MTDiscord <Benrob0329> 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 <Benrob0329> Great question
20:53 MTDiscord <Benrob0329> Probably one for the Assimp devs
20:53 MTDiscord <Sublayer plank> 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 <Sublayer plank> 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 <Benrob0329> Hopefully gltf doesn't go out of style, but then we've limped along with B3D for this long
20:56 MTDiscord <Benrob0329> 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 <Benrob0329> *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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> MT has a history of slow progress, with POCs getting lost to time and poor implementations.
21:00 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> No, I mean interpolated
21:12 MTDiscord <Benrob0329> ie not just setting the yaw/pitch/roll, but also setting how long it takes to move there
21:12 MTDiscord <Benrob0329> player:add_yaw(rads, seconds) or something
21:41 kilbith_ joined #minetest-dev
21:44 kilbith_ joined #minetest-dev
21:44 appguru joined #minetest-dev
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 <Sublayer plank> maybe 2022
22:13 benrob0329 joined #minetest-dev
22:16 kilbith_ joined #minetest-dev
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:12 Extex joined #minetest-dev
23:15 nrz_ Haha
23:15 nrz_ Well done sfan5
23:26 MTDiscord <luatic> #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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext