| 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 |
