Time Nick Message 12:43 ROllerozxa is renaming minetest still on the table? haven't heard much discussion about it in a while 12:50 [MTMatrix] There is an internal discussion, yes 12:54 ROllerozxa alright, that's understandable 17:12 erle getroffene hunde bellen https://github.com/minetest/minetest/issues/13795#issuecomment-1716093139 17:15 ROllerozxa yikes 17:15 sfan5 wenn du denkst hier weitere kommentare abzulassen helfe deiner position dann nur zu 17:16 sfan5 du hast aber recht, ich habe vergessen dich wieder in die ignorelist aufzunehmen 17:16 erle i am not your enemy and i was not making fun of you in particular. i do think you didn't think it through, but closing and locking a proposal that is clearly performance-relevant because you are offended is not exactly helpful 17:31 [MTMatrix] check dayoftime on global step is normal? Or minetest have alternative way? 17:31 erle localhost depends on what you want to achieve and this is probably a topic for #minetest 17:37 [MTMatrix] just set sky in skybox by time on every connected and joined players. sorry for offtopic 17:37 sfan5 should I mark #13800 as blocker given #13550 is likely to be merged soon? 17:37 ShadowBot https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled 17:37 ShadowBot https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa 17:41 rubenwardy It's not a blocked as the latter doesn't remove MTG 17:42 sfan5 ah, true 17:42 sfan5 do we plan to actually do that this release? 17:42 rubenwardy that depends on when the release is 17:42 rubenwardy I'd say 17:44 sfan5 hmm 18:07 [MTMatrix] it's supposed to be in September, but frankly if we can delay it to remove MTG, I'm all for it 18:08 rubenwardy we may need to release 5.7.1 very soon to avoid copyright issues 18:11 erle rubenwardy what's copyrighted? 18:12 ROllerozxa I assume it's about the MTG water texture 18:15 sfan5 well if anyone can work on #13800 or #13799 then we can remove mtg asa 18:15 ShadowBot https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled 18:15 ShadowBot https://github.com/minetest/minetest/issues/13799 -- Allow games to enforce lock-step upgrades with versions 18:15 sfan5 p 18:26 rubenwardy the second one is one my to-do list 18:28 rubenwardy ContentDB allows you to do `min_minetest_version = 5.8` in game.conf to do version limits, would be nice to reuse that. The use of the version name rather than protocol may be an issue, probably should have made it an engine feature before putting it in CDB but alas 18:29 rubenwardy so for Minetest Game you'd do `min_minetest_version = 5.8` and `max_minetest_version = 5.9-dev` I guess? The -dev there is a bit messy 18:30 rubenwardy Perhaps you'd only set `min_minetest_version = 5.8` and you'd have support for update detection without entering CDB 18:31 rubenwardy (I've been working on faster APIs that make it possible to quickly check for updates without loading the full package information) 18:36 rubenwardy ah #10336 18:36 ShadowBot https://github.com/minetest/minetest/issues/10336 -- Warnings when loading a mod incompatible with this version of minetest 18:39 rubenwardy I went with MT version rather than protocol version as 1) it's more understandable 2) not all MT minor versions have distinct protocol versions. Note that CDB ignores the minor number 18:39 rubenwardy *patch number 18:41 rubenwardy So to support forks, we could have a concept of API version which happens to be the same as the Minetest version. So a fork could have version 1.1.1 or whatever but api version 5.8 18:45 [MTMatrix] whoa! 5.9 soon? 18:47 rubenwardy let's get 5.8 first 18:54 erle rubenwardy i think feature detection is better than version detection. why not make the mods list features they need? 18:54 erle rubenwardy is that too much? 18:54 rubenwardy that would be very complicated 18:55 erle i just thought that there is a feature table, so maybe … 18:55 rubenwardy also the only way that would work is if we gave each mod its own Lua environment and only exposed features if the mod asks for it 18:55 erle it does not make sense to use those things if the version does cover that though 18:55 erle i see 18:55 ROllerozxa btw #13550 should be ready for merge now 18:55 ShadowBot https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa 20:01 [MTMatrix] about game#3061: can't you just use Soothing 32 as default? 20:01 ShadowBot https://github.com/minetest/minetest_game/issues/3061 -- MTG textures overhaul? 20:03 [MTMatrix] or Mineclone 2 ones 20:05 sfan5 making mtg looks like mcl2 wouldn't be good imo 20:05 sfan5 rubenwardy: ideally only mtg ever uses this feature so I wouldn't worry too much about fork compat 20:06 [MTMatrix] there's also RPG 16, which contrary to Soothing 32, supports all the MTG mods 20:07 sfan5 AFAIK the only reason MTG does this anyway is because it does one or two things that aren't guaranteed to be portable across engine versions 20:07 MTDiscord Soothing 32 is a really nice looking pack, but it makes a very bold aesthetic statement that a lot of existing content wouldn't be able to match. 20:10 [MTMatrix] warr1024: I think that is better to have a sane default people can try to emulate, than a bad one teaching bad art 20:10 sfan5 but MTG isn't supposed to be any kind of "default" ;) 20:54 erle why was ”won't add” added to this if it was not discussed on its technical merits at all? https://github.com/minetest/minetest/issues/13795 20:54 erle i mean, would it still have been ”won't add” if i had been less of a little sarcastic bitch? 20:57 [MTMatrix] next time you can avoid acting as a sarcastic bitch so you will know 20:57 MTDiscord Adding semi-intelligent compression in various places independent of the type of media could actually be pretty nice. LZO or Zstd compression of network payloads, possibly compressing stuff that goes into the media file cache, etc. 20:57 [MTMatrix] *little sarcastic bitch 20:57 erle well, i want to tell everyone that i have been told that it is quite rude to point out when people say things that usually indicate they have not put thought into something, even if that assessment is correct (and obviously if it is not). i will try to avoid toing that. 20:58 erle doing 20:58 erle zughy i hope next time people can avoid dismissing solutions on a hunch though. 20:58 erle Warr1024 i agree for obj files actually 20:59 MTDiscord I haven't tested B3D but they might benefit too 20:59 erle Warr1024 why don't you open a ticket about it, you are less obnoxious than me 20:59 MTDiscord and .tr locale files a bit too 20:59 ROllerozxa B3D and X could benefit from compression over the network too, yeah 20:59 ROllerozxa (especially text format X models... *shudder*) 20:59 erle the thing is, with TGA there are files that do not benefit from compression. is that the case with other formats as well? 20:59 MTDiscord I was hoping for compression at a lower protocol layer too, though, e.g. to compress things like those "object properties" packets and such as well. 21:00 erle because if that is the case you need introspection to see if the compression is a good idea or not. 21:00 erle which is something the minetest engine, as far as i can tell, generally does not offer for file formats. 21:00 ROllerozxa (zipping up mobs_mc_dragon.b3d, which is 670KiB, for testing shrinks it down into 50KiB) 21:01 MTDiscord Generally the "smart" way to handle compression, assuming the CPU trade-off works out in general, is just to try to compress everything, and if it ends up larger (or you get any early indication it's not going to go well), you just send things uncompressed, and you have a "compressed" flag in the header so you can do that with as little overhead as possible. 21:01 MTDiscord Compressing media files might be a separate layer to network compression, though, granted. 21:01 erle for images, the classic gamedev example is a dirt texture that is bigger as a compressed PNG than a TGA because it has too much entropy 21:02 erle ROllerozxa i have noticed several such models, usually they can be optimized in other ways too. i strongly suggest to open some files in mm3d and see if it can optimize the surfaces. 21:02 MTDiscord Honestly, just allowing *.z or *.gz and transparently decompressing might be a big boon for media. IIRC there's a way to save PNG files uncompressed, and if you apply compression outside the PNG header, sometimes you can get some benefits even for a format that's supposed to handle compression internally. 21:03 erle Warr1024 i must disappoint you, having a deflate stream with just literal blocks is one of the worst “uncompressed” formats. 21:03 erle (that is what “uncompressed PNG” refers to i think) 21:04 MTDiscord I've seen gzip squeeze a couple of bytes out of an already-compressed PNG anyway. When I'm doing web serving and can pre-compress things, I just throw everything through the compressor and see what comes out before deciding, rather than trying to rely on heuristics. If MT supported transparent decompression of all media, that could become an option for everything MT too. 21:05 erle well, i already suggested just supporting .z, so i agree. i think heuristics are actually much harder to get right in the engine than in mods. 21:05 MTDiscord The nice thing about "worst uncompressed formats" is that shoving them through a compressor can still yield surprisingly good results. 21:06 MTDiscord Yeah, I think we don't even need to worry about heuristics if we just let mod creators decide on whether to compress or not by just providing either compressed or not files. 21:06 erle yes, but i can not figure out any scenario in which a png.z would would be better than a tga.z (worse in terms of filesize, encoding & decoding speed) 21:06 MTDiscord Tbh I think your requests to make TGA transfer more efficient would go a lot more smoothly if you just didn't mention TGA 😉 21:06 erle > I think we don't even need to worry about heuristics if we just let mod creators decide 21:06 erle finally someone agrees with me 21:07 erle Warr1024 so you making an issue for general handling of .z files? 21:08 MTDiscord Given that .obj, .b3d, .x, and .tr already can benefit from compression, that might already be enough justification anyway without having to drag the more dramatically unpopular formats into the ring. 21:09 erle i mean if you could just use minetest.compress() on some assets, i'm sure mods would be creative. (i strongly suggest to punch everyone in the face who suggests zstd support here though) 21:09 [MTMatrix] xz super compress, but too hard 21:09 erle oh no 21:09 MTDiscord xz is not a great format for this application 21:10 MTDiscord it's very heavy and takes too long to warm up 21:10 erle Warr1024 good luck dealing with the comments like “we should use something else than DEFLATE” 21:10 erle bz2! :P 21:10 [MTMatrix] oops 21:10 MTDiscord gz, z, lzo, snappy, or zstd are all possible candidates. gz, z, and sztd are also already used in the engine and already available to us. 21:11 [MTMatrix] what if uncompressed? Is too much large? :D 21:11 erle i want to point out *again* that zstd lacks the dictionary support necessary for small payloads here 21:11 MTDiscord bz2 is kind of a cool tech in its own way, too bad it's not so hot with files that aren't at least like in the 100kb range. 21:11 erle in the minetest API 21:11 [MTMatrix] terabytes blocks :P 21:11 [MTMatrix] terabytes of blocks :P 21:12 erle and that it's an easy footgun, but i disgress 21:12 erle Warr1024, good luck anyway! 21:12 MTDiscord Yeah, I dunno about how MT uses zstd, but I assume it must be offering at least some advantage over deflate for payloads in the mapblock-size range, else it'dn't've been used. 21:13 erle as appguru explained: he saw the benchmarks for mapblocks and thought they applied to smaller stuff 21:13 MTDiscord I think your feature request may have been too confusing if people were talking about adding compression. It sounds like both you and I are interpreting this feature as offering only decompression in the engine, and game/mod creators would be responsible for doing the compression themselves. 21:13 erle yes 21:13 erle and everyone immediately latches on “the engine should do this automatically instead” 21:14 erle which is a *much* larger task and *much* harder to get right (and not very useful for my use case) 21:14 MTDiscord Decompression only makes this a lot simpler and easier to implement than compression would, and the costs are negligible, since it wouldn't even change the behavior of existing stuff. 21:14 MTDiscord erle: wdym by "smaller stuff", schematics are often bigger than mapblocks (> 16³) 21:14 erle luatic go benchmark it! 21:14 MTDiscord schematics aren't sent as media, so wouldn't apply to this feature anyway 21:15 erle Warr1024, the only thing you have to make sure is that a .z resource is sent raw to older clients. 21:15 erle but that's easy obv 21:15 MTDiscord Ideally, if we've already got the libraries in MT to support .gz, .z, and .zstd, we might as well just support them based on file extension and let creators pick whatever's appropriate on a file-by-file basis. Then we don't need to have the argument about what format is best. 21:16 [MTMatrix] schematics be like: I can save area -500,0,-500; 500,0,500 in WE, but I can't restore it - too large 21:16 [MTMatrix] schematics be like: I can save area -500,0,-500; 500,0,500 in WE for 10 secs, but I can't restore it - too large 21:16 erle Warr1024, well, zstd *is* generally better, but minetest.compress() does not have dictionary support, which means you can't really outperform zlib meaningfully (except on encoding and decoding speed ig, you get 2 to 3 times) 21:17 erle at least for small stuff 21:17 erle and all the stuff we talk here is small 21:17 erle like <100kb 21:17 erle right? 21:18 erle the encoding and decoding speed can probably be enough of an argument though 21:18 MTDiscord Well, for dynamic stuff we might be limited to just zlib, but for creators pre-compressing stuff at build time e.g. to optimize mod download or server join times, they can just try each format and see. I already run basically all the media for all of my mods and games though a battery of stuff including zopfli compression of the deflate parts in all the PNG files, so now I'd be able to do that sort of thing with my OBJ files and such 21:18 MTDiscord too... 21:18 erle i agree 21:19 erle Warr1024 ha, zopflipng! 21:19 erle Warr1024 how large are your texture dimensions generally? 21:19 [MTMatrix] and imagine security issue as... blocks as zip bomb in dumped world 👀 21:19 erle localhost what do you mean 21:20 erle there are already items that contain zipped info 21:20 erle xmaps handheld items and displayed item entities for example contain a zipped TGA in their meta (for easy bookkeeping, garbage collection and so they work in map downloads) 21:20 [MTMatrix] nothing, i just make strange thinks 21:21 erle and i am pretty sure if shulkers would use compression they could contain more stuff hehe 21:21 erle bigger recursive shulkers pls 21:21 MTDiscord I generally do 16px base textures in all my stuff. If people want higher res, that's what TPs are for. I would prefer the baseline to be as conservative as possible a burden on users, and those with capacity for more fancy can add that on as desired later. 21:22 MTDiscord As for what I actually use to compress my pngs, I run them through optipng, then advpng (which uses zopfli) and then ECT (which has its own brute-force search that's apparently even more thorough). 21:22 [MTMatrix] also how I can ask the engine no generate empty space blocks? Except mg limit 21:23 erle localhost what do you mean 21:23 erle Warr1024 funny how you end up at better optimizers and i end up at “wait this is so small, i can zip up the pixels and call it a day” 21:23 MTDiscord Mapgen limit is the only way you can ask the engine not to generate mapblocks, as far as I know. 21:23 [MTMatrix] Just a... no save air blocks in map.sqlite 21:23 erle what 21:24 MTDiscord Sounds like a #minetest question more than a #minetest-dev one. 21:24 MTDiscord localhost: what 21:24 MTDiscord air blocks will be very compact in map.sqlite due to run-length encoding 21:24 erle localhost, do you actually know how to join another channel? 21:25 erle you keep asking questions here 21:25 erle maybe you need help 21:25 erle do you? 21:26 [MTMatrix] Okay. Sorry for wrong select channel 21:27 erle localhost have you joined the correct one or do you need help with that? 21:27 erle ah you have 21:27 erle good 21:46 MTDiscord sfan5, or others who know minetest's mapgen implementation: If every server step, if forceload a block, then the next server step un-forceload it, and forceload it again (or, rarely, forceload a different block), is this going to cause lag/ put undue strain on the engine? If I'm just changing a table that the engine checks at its lesiure by doing that, it shouldnt be laggy, I would think. But if calling forceload_block actually 21:46 MTDiscord actively does something, then it could cause lag 21:47 MTDiscord /s/if forceload/I forceload 21:52 MTDiscord The reason is that I want to let an entity manage itself by preventing itself from ever being deleted while it lives. 21:52 MTDiscord /s/deleted/unloaded 21:55 MTDiscord Interesting ... I've had similar needs, but I avoided the "what if I un-force-load and re-force-load again" problem by just having my own layer of forceload management where I only pass changes down to the engine. It turned out to be necessary as I wanted to have my own limit budget, and I wanted a fair distribution of the available resource in cases where demand exceeded budget. 22:02 sfan5 @mistere_123 un-forceloading a block should cause it to be unloaded eventually, how fast I would have to check 22:02 sfan5 I think a better design would be to only un-forceload the block if you know that the entity is really not there anymore 22:03 MTDiscord ok. This entity will be moving around, so the block could change 22:04 MTDiscord you might have to forceload the new block, then wait for it to actually become loaded, and then move into that block, and then remove the old forceload. 22:05 MTDiscord If you want to be able to move into the new block using normal physics movement, you might have to make sure it's pre-loaded by "leading" in front of the entity's movement based on its velocity. That's still no guarantee though as it can take arbitrarily long to emerge an unloaded block. 22:17 MTDiscord I figured it out, I think. Details in discord dev so as not to clog irc with code 23:11 [MTMatrix] What to do with #10166? It's the oldest PR and OP has no activities on Github in the last two years 23:11 ShadowBot https://github.com/minetest/minetest/issues/10166 -- Unittest/collision by scrain777 23:13 MTDiscord rip 23:13 MTDiscord could rerequest a review from sfan5 23:14 MTDiscord or put it in the next meeting notes if those are going to be a thing 23:48 [MTMatrix] sfan5 already has to deal with dual weilding, definitely doesn't need this one too 23:48 MTDiscord mainly saying it because they already reviewed it