Time Nick Message 08:28 sfan5 if you want to merge a breaking change feel free to do it anyway if you get the core team on board 08:29 sfan5 but if (when) someone shows up after 5.9.0 and asks what the fuck were we thinking I will neatly keep myself out of the discussion 08:36 sfan5 I know how annoying it is and I agree it discourages anyone from touching that, but the times where we could just change things is over. At least until Minetest 6.0. 08:37 sfan5 it would be reasonable to argue that what MT needs is a bunch of motivated developers with the license to change anything they see fit (no compatbility) but alas that's not where we are 09:31 [MTMatrix] Do you see 6.0 happening in the next couple years sfan5? 10:02 celeron55 the thing about 6.0 is that from 5.0 we forgot many things that should have been there 10:02 celeron55 there absolutely has to be a list that has to be combed through meticulously 10:03 celeron55 otherwise the first thing someone says after the 6.0 release is "why didn't you include this obvious thing"? 10:03 celeron55 ?"* 10:03 rubenwardy yeah 10:03 MTDiscord Isnt there a list of those? 10:03 rubenwardy we broke object model positioning but didn't fix the 10x thing 10:03 rubenwardy https://github.com/minetest/minetest/blob/master/doc/breakages.md 10:04 MTDiscord There it is 10:04 celeron55 if #13975 isn't merged with a physics flag, then it has to be added on that list 10:04 ShadowBot https://github.com/minetest/minetest/issues/13975 -- Fix glitch that jolts players up edges by jordan4ibanez 10:05 nrz a 6.0 could be interesting, especially for rendering engine, it has been a couple or years since last breakage. It just has to be announced at the good moment 10:53 [MTMatrix] We could count 5.9 -> 6.0 👀 10:54 [MTMatrix] Possibly accompanied by a name change? Ping greenxenith for the internal discussion 11:15 sfan5 @zughy hard to say. to not be overly pessimistic: maybe 11:22 ROllerozxa how would a name change even work with the API since the entire API namespace is tied to the current name 11:23 ROllerozxa would be remedied if people used `core` instead of `minetest`. unsure why that's not recommended, is it too generic and may conflict with other Lua using things? 11:39 rubenwardy some init.lua contains `minetest = core`, can just add a new line for the new name 12:01 ROllerozxa fair 12:06 ROllerozxa I guess it doesn't hurt if the old name were still referenced in technical stuff as long as the new name is used for anything user-facing, to make the transition less painful 12:20 celeron55 if we get to a point where the namespace naming is the biggest problem, that'd be unimaginably far ahead 12:20 celeron55 would get* 18:17 sfan5 idea: speed up 5.9.0 release for just before fosdem 18:24 MTDiscord that way everyone can experience a rushed and buggy version of Minetest :3 18:52 rubenwardy 👀 19:11 celeron55 i'm giving the go ahead. we can entice new contributors by having easy to fix stupid bugs 19:36 MTDiscord Is this suggestion serious? 19:37 MTDiscord (Because there's at least big PR (glTF support) I'd like to see make its way in, but I'm not sure that's realistic in a 2 week timeframe) 19:38 sfan5 it is serious but I didn't look at the milestones before making it 19:38 MTDiscord well we could risk yolo'ing gltf 19:38 MTDiscord i am 95% sure that minetest won't explode if we do 19:40 MTDiscord If tests indicate that the backwards compatibility is intact, then worst case is that gltf is broken until the next minor release. Best case is that is works. 19:40 MTDiscord Not a horrible tradeoff 19:41 MTDiscord The risk of gltf breaking existing stuff if not used is practically zero 19:42 MTDiscord There is a small risk that we introduce vulnerabilities, but with all the vulnerabilities I assume to be lingering in Minetest, I don't think it would make much of a difference. I've also taken great care when writing the code to validate. 19:46 celeron55 does your test cases include a fuzz test? 19:47 MTDiscord not yet 19:47 celeron55 fuzzing will be the first thing any curious attacker will do to any new format 19:48 MTDiscord fuzzing isn't trivial here since this isn't a binary format. we'd need a JSON-grammar-based, ideally even JSON schema based fuzzing to get something useful. or start with a valid JSON and just corrupt it a bit. 19:48 MTDiscord still, you'll want nontrivial corruptions. I'm pretty confident that my schema validation is decently tight; it was in large autogenerated by a Lua script from the JSON schemata (and then edited by me). 19:49 celeron55 well, JSON is a good start in preventing a fuzz attack to begin with, really, so i wouldn't be expecting anything 19:50 MTDiscord Do we support any big-endian platforms? 19:50 MTDiscord (I've got a path for them in my code, but it hasn't been tested yet since I'm on a little-endian platform like most) 19:51 celeron55 are there any non-trivial algorithms in place where the JSON data is converted into native structures ready for rendering, or is it all just 1:1 make a similar structure the same size and copy the stuff over? 19:52 MTDiscord There is some complexity, but it's more code complexity resulting from C++'s static typing rather than algorithmic complexity, I'd say 19:53 celeron55 personally i'd like it if MT had theoretical support for big endian, but i would assume there is no actual need for support and spending any time doing it is a waste 19:55 celeron55 is there any iffy casting going on? 19:56 celeron55 i guess i should just browse through the code 19:58 MTDiscord I'd appreciate any feedback. I'm currently also waiting for Josiah to have an eye on it. 20:05 sfan5 can I merge this? #13321 20:05 ShadowBot https://github.com/minetest/minetest/issues/13321 -- Support OpenGL 3 by numberZero 20:09 Desour I also saw this today and wondered why I didn't approve it yet. you can merge :+1: 20:09 sfan5 done 20:23 Desour luatic: are you planning to also add binary gltf support btw? or some sort of compressed gltf? sending huge json files via media is not super efficient 20:26 MTDiscord Desour: glb support is planned as it's not too much work, but gltf is also good enough for a first shot: The base64 encoded binary data is "only" 33% larger than if it were binary. Note that the JSON doesn't get that large since the bulk of the "raw data" is in these base64 encoded binary buffers. 20:33 Desour I see. and zlib compression or similar? does gltf support that directly? 20:34 MTDiscord As far as I know it doesn't. We could bolt that on on the Minetest side of things, though. 20:43 Desour just looked in blender right now. it has some "compression" option (under "data"). apparently it uses google draco, which seems to be an extension to gltf. anyway this can come later I guess 21:25 MTDiscord Yeah, draco is a gltf extension 22:05 nrz Why not having média server in http return, embedded in minetest? Libmicrohttpd is tiny, Or there is one in CPP very efficient too 22:08 Desour you mean send media always over http? if there's a serious benefit, why not 22:10 MTDiscord merging #14123 in 10m 22:10 ShadowBot https://github.com/minetest/minetest/issues/14123 -- Add API for restoring Pseudorandom and PcgRandom state by sfence 22:11 MTDiscord while I'm at it, let's add #13477 22:11 ShadowBot https://github.com/minetest/minetest/issues/13477 -- Reduce `minetest.after` time complexity and provide ordering guarantee by appgurueu 22:12 MTDiscord Brother, if minetest hasn't exploded yet I doubt that's going to cause it