| Time |
Nick |
Message |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:23 |
|
MTDiscord joined #minetest-dev |
| 05:53 |
|
calcul0n joined #minetest-dev |
| 06:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 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 |
| 08:42 |
|
vampirefrog joined #minetest-dev |
| 09:02 |
|
tarsovbak1 joined #minetest-dev |
| 09:18 |
|
tarsovbak1 left #minetest-dev |
| 09:31 |
[MTMatrix] |
<Zughy> 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 |
<greenxenith> 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 |
<greenxenith> 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] |
<Zughy> We could count 5.9 -> 6.0 👀 |
| 10:54 |
[MTMatrix] |
<Zughy> 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:03 |
|
appguru joined #minetest-dev |
| 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* |
| 13:11 |
|
Lupercus joined #minetest-dev |
| 14:57 |
|
Guest61 joined #minetest-dev |
| 18:17 |
sfan5 |
idea: speed up 5.9.0 release for just before fosdem |
| 18:24 |
MTDiscord |
<lemente> that way everyone can experience a rushed and buggy version of Minetest :3 |
| 18:37 |
|
v-rob joined #minetest-dev |
| 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:35 |
|
Desour joined #minetest-dev |
| 19:36 |
MTDiscord |
<luatic> Is this suggestion serious? |
| 19:37 |
MTDiscord |
<luatic> (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 |
<luatic> well we could risk yolo'ing gltf |
| 19:38 |
MTDiscord |
<luatic> i am 95% sure that minetest won't explode if we do |
| 19:40 |
MTDiscord |
<mistere_123> 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 |
<mistere_123> Not a horrible tradeoff |
| 19:41 |
MTDiscord |
<luatic> The risk of gltf breaking existing stuff if not used is practically zero |
| 19:42 |
MTDiscord |
<luatic> 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 |
<luatic> not yet |
| 19:47 |
celeron55 |
fuzzing will be the first thing any curious attacker will do to any new format |
| 19:48 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> Do we support any big-endian platforms? |
| 19:50 |
MTDiscord |
<luatic> (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 |
<luatic> 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:54 |
|
v-rob joined #minetest-dev |
| 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 |
<luatic> 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:11 |
|
appguru joined #minetest-dev |
| 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 |
<luatic> 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 |
<luatic> 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:08 |
|
grorp joined #minetest-dev |
| 21:18 |
|
vampirefrog joined #minetest-dev |
| 21:25 |
MTDiscord |
<luatic> Yeah, draco is a gltf extension |
| 21:42 |
|
v-rob joined #minetest-dev |
| 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 |
<luatic> 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 |
<luatic> 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 |
<jordan4ibanez> Brother, if minetest hasn't exploded yet I doubt that's going to cause it |
| 22:41 |
|
Desour joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:39 |
|
v-rob joined #minetest-dev |
