| Time |
Nick |
Message |
| 00:07 |
|
calcul0n_ joined #minetest-dev |
| 01:49 |
|
Pexin joined #minetest-dev |
| 02:29 |
|
queria^clone joined #minetest-dev |
| 02:33 |
|
queria^clone joined #minetest-dev |
| 03:30 |
|
adfeno joined #minetest-dev |
| 03:58 |
erlehmann |
ok i tested it |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:03 |
erlehmann |
to recape: i have tested it and PR #10570 https://github.com/minetest/minetest/pull/10570 should be REJECTED in its current state. minetest on that branch has NOTICEABLE LAG in hotbar inventory item rendering on my already slow computer, where it did not have that with 5.5-dev. the PR description claims it would speedup item rendering – if it does not do that on a slow computer, the whole thing is wrong. |
| 04:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/10570 -- Item render-to-texture: Texture modifier, speedup by appgurueu |
| 04:05 |
MTDiscord |
<Warr1024> Oh, oof, it uses RTT. I seem to remember that being a very hit/miss tech. We used to rely on it for rendering inventory images, before they were rendered in 3D, and it was a big headache on certain platforms. |
| 04:08 |
MTDiscord |
<Warr1024> IIRC Android was one of the platforms where RTT was particularly painful. This is the kind of thing that probably needs to be tested across a lot of different machines to be confident it does what it's supposed to, and it's good you were able to catch a problem early. |
| 04:11 |
erlehmann |
well the point is, it was apparently not tested at all |
| 04:11 |
MTDiscord |
<Warr1024> erlehmann, I think it would be a good idea to note your observations and concerns directly in the comments thread for the PR to make sure it's seen by anyone involved with it. |
| 04:11 |
erlehmann |
Warr1024 i do not have a private github account anymore i can use, no idea if i can reactivate mine. they one hellbanned me for making too many commits or something. could you do it for now? |
| 04:12 |
erlehmann |
and add your own observations? |
| 04:12 |
erlehmann |
the thing is, the PR has *definitely* not been tested on a slow machine |
| 04:12 |
MTDiscord |
<Warr1024> Eh, I'm sure it was tested on appgurueu's own machine, which I'm guessing is probably NOT one of the ones in which the perf issue was apparent |
| 04:12 |
erlehmann |
bc inventory item rendering is now pretty much instant |
| 04:12 |
erlehmann |
but with the PR it is not |
| 04:13 |
erlehmann |
so to me it looks like some kind of “let me optimize this” by someone who never even cares about performance, just some weird theoretical purity |
| 04:13 |
MTDiscord |
<Warr1024> I'm not sure how slow a machine needs to be to be "slow". I'm inclined to just post your comments for now though because my machines that can compile and test are a bit tied up for a while.. |
| 04:13 |
erlehmann |
thx |
| 04:13 |
erlehmann |
my machine is a thinkpad T60 |
| 04:13 |
MTDiscord |
<Warr1024> I'm sure there was performance in this in theory, the problem is that RTT behavior varies dramatically in practice and empirical testing on a narrow set of machines is not necessarily a large enough sample size to reveal that. |
| 04:14 |
erlehmann |
it runs mineclonia (the mcl* games are biggest most performance killers) with around 25 to 27 fps with opengl, 5 to 7 fps with opengl ES, 1 fps with software rendering |
| 04:14 |
MTDiscord |
<Warr1024> Heh, okay, you got me beat, mine's a T430s |
| 04:14 |
erlehmann |
the thing is *theory* |
| 04:15 |
erlehmann |
you can recognize ppl who claim to talk about performance and don't test, test, test pretty easily |
| 04:15 |
MTDiscord |
<Warr1024> slow machines are great for a game dev who wants to make sure their games run efficiently; nothing forces you to do it right more than feeling the pain directly when you don't |
| 04:15 |
erlehmann |
yes that is one reason why i do it, besides the 4:3 matte screen and that it is remarkably serviceable |
| 04:15 |
erlehmann |
fleckenstein & co have gaming machines and use discord |
| 04:16 |
erlehmann |
it is funny, because the discord signup page is the only web page that i found that makes my whole computer lag |
| 04:16 |
MTDiscord |
<Warr1024> Test, test, test is just hard when people usually don't have access to a ton of machines themselves. Submitting something as a PR is probably one of the first really practical steps you can take to get something enough exposure to get it actually tested. In this case, it seems to have worked ... though possibly only just barely... |
| 04:16 |
MTDiscord |
<Warr1024> Ah, 4:3, heh, I miss tallscreen :-) |
| 04:16 |
erlehmann |
well from my POV there must either be something seriously wrong on the appgurueu machine that makes inv rendering slower than on some >10 year old thing |
| 04:16 |
erlehmann |
OR |
| 04:17 |
erlehmann |
more likely in my opinion, it is just someone thinking this works and not really caring |
| 04:17 |
erlehmann |
which happens all the time |
| 04:17 |
erlehmann |
for example in mineclone2, they chose to drop each item separately |
| 04:17 |
erlehmann |
instead of an itemstack |
| 04:18 |
erlehmann |
because that's EXACTLY LIKE MINECRAFT |
| 04:18 |
MTDiscord |
<Warr1024> Oh, if you mean "appguru probably didn't observe an actual performance problem to solve" then that's plausible. It's also possible that their use-case is unique, like using texture mods on very high resolution skybox textures, where using more GPU features on newer machines actually DOES outperform CPU pixel manipulation in software. |
| 04:18 |
erlehmann |
needless to say, this kills the performance if there are a ton of entities bc someone dropped 99 cobble or something |
| 04:19 |
erlehmann |
yes, i'd bet money on "appguru probably didn't observe an actual performance problem to solve" |
| 04:19 |
MTDiscord |
<Warr1024> It does smell a bit like a "make faster machines faster at the unexpected expense of slower machines" kind of thing |
| 04:19 |
erlehmann |
yeah |
| 04:19 |
erlehmann |
i see that all the time |
| 04:19 |
erlehmann |
if it is a unique usecase it should be gated |
| 04:19 |
MTDiscord |
<Warr1024> I ain't betting money on shit, myself :-) |
| 04:19 |
erlehmann |
like only use it for high performance machines |
| 04:19 |
erlehmann |
or only for huge skybox |
| 04:20 |
MTDiscord |
<Warr1024> A heuristic to automatically choose an intelligent implementation based on the scale of the problem and the available capabilities would be nice, but more likely that's too much to maintain ourselves, and it might just make more sense to focus on things like smarter intermediate caching instead of trying to fancy-up the rendering, unless we're gonna pull in a library that has it figured out for us. |
| 04:21 |
MTDiscord |
<Warr1024> I wouldn't want to hand-roll the heuristic for picking RTT vs software either. |
| 04:21 |
erlehmann |
Warr1024 it reminds me of the item thing, you probably also did not notice the 9-tile-problem |
| 04:22 |
erlehmann |
and you probably did not realize that the algorithm also scales the *background*, i.e. lagging the entire menu |
| 04:22 |
erlehmann |
but you had a legit goal |
| 04:22 |
erlehmann |
so it was not pointless |
| 04:22 |
erlehmann |
just did not test it enough |
| 04:22 |
erlehmann |
i shall probably build some more “performance improvements” |
| 04:23 |
erlehmann |
because i can totally see “make it faster on faster machines and cut out the code path for slower machines bc LEGACY” being a thing |
| 04:23 |
MTDiscord |
<Warr1024> I noticed the lag, but it wasn't that bad on my machine, which I at the time assumed was not really high-end ... and it felt tolerable enough to me that it COULD be a valid choice for a player to accept that traded off for the anti-aliasing effect |
| 04:23 |
MTDiscord |
<Warr1024> like, at least I personally play with the setting on all the time |
| 04:24 |
MTDiscord |
<Warr1024> and at the time it fixed a lot of annoyances for me, which were also reported by a number of other players, even if it may not have necessarily been the only or even best solution possible. |
| 04:24 |
MTDiscord |
<Warr1024> 3D inventory rendering has made at least one use-case for it obsolete, but it still has some value elsewhere at least. |
| 04:25 |
MTDiscord |
<Warr1024> So to clarify, is the lag your only major concern now? Were the crashes and players' heads on backwards things unrelated or resolved or something? |
| 04:25 |
MTDiscord |
<Warr1024> I want to make sure I'm getting a concise and to the point summary in GH |
| 04:25 |
erlehmann |
Warr1024 you could easily make it just apply the scaling for graphics that are smaller or egal to 128x128 |
| 04:25 |
erlehmann |
equal |
| 04:26 |
MTDiscord |
<Warr1024> I could make a threshold for it, but that'd be yet another tunable that needs to be tuned :-D |
| 04:26 |
erlehmann |
i just mean its solvable if you want the icon thing to work |
| 04:27 |
erlehmann |
and contentdb can easily spit out what the biggest icons in use are |
| 04:27 |
MTDiscord |
<Warr1024> Yeah, it just doesn't feel a high prio anymore as it did at the time :-) |
| 04:27 |
erlehmann |
bc it works for you. good that it is not default though. |
| 04:27 |
MTDiscord |
<Warr1024> The "meat" of your recap seems to be this: minetest on that branch has NOTICEABLE LAG in hotbar inventory item rendering on my already slow computer, where it did not have that with 5.5-dev. the PR description claims it would speedup item rendering – if it does not do that on a slow computer, the whole thing is wrong. |
| 04:28 |
erlehmann |
yes. you could add that the lag means there is nothing shown in the hotbar for some amount of time (prob slightly under a second) |
| 04:28 |
erlehmann |
after picking up an item |
| 04:28 |
MTDiscord |
<Warr1024> Yeah, it's annoying that I submitted a feature and nobody really ran with it and carried it farther, but it's good that it's at least available and presumably I'm not literally the only person to ever use it (some people actually do dig in fine-tuning settings or hear about stuff from old PRs and such and try them) |
| 04:28 |
erlehmann |
the crash is weird though and merits investigation |
| 04:30 |
erlehmann |
like there are very likely no crashes in mineclonia that can do that except for … two stronghold portals generating in a way that they overlap, but each portal is already filled with eyes of ender. |
| 04:30 |
erlehmann |
which is really unlikely |
| 04:30 |
erlehmann |
basically, only a serious stack overflow in a lua mod can get remotely to that result (i.e. segfault without error message) |
| 04:31 |
MTDiscord |
<Warr1024> oh, heh, I forgot that stack overflows can cause very hard to trap errors :-) |
| 04:31 |
erlehmann |
Warr1024 please mention the segfault if you don't think it is too much. it needs investigation and i am not sure i can do it without help. |
| 04:31 |
MTDiscord |
<Warr1024> Hmm, this PR does actually already have the "Possible close" tag on it |
| 04:32 |
erlehmann |
thank you |
| 04:32 |
MTDiscord |
<Warr1024> so it's actually already under threat :-) |
| 04:32 |
erlehmann |
thank you Warr1024 |
| 04:33 |
MTDiscord |
<Warr1024> yw |
| 04:36 |
|
Extex joined #minetest-dev |
| 05:13 |
erlehmann |
oh LOL did you ACTUALLY break mineclone2 https://github.com/minetest/irrlicht/pull/48 ? |
| 05:13 |
erlehmann |
i have to test this |
| 05:14 |
erlehmann |
so much for „mineclonia can keep working“ |
| 05:15 |
erlehmann |
i hate it when ppl insist that something is not relevant, then you show that you use it, then they disregard that |
| 05:16 |
erlehmann |
if someone claims my testing of the item rendering „speedup“ which makes it slower does not matter, i'll probably think that person just does not care about performance, but pretends to |
| 05:18 |
erlehmann |
sfan5, you should know that the removal of the tga thing will break *all* existing maps in mineclone2 and mineclone5 on engine upgrade. |
| 05:18 |
erlehmann |
this is kinda a big deal |
| 05:18 |
erlehmann |
it's not like no one plays it |
| 05:19 |
erlehmann |
but switching out the implementation to generate bmp images will not help here. |
| 05:19 |
erlehmann |
because if i undertstand it correctly, the image is generated just once. |
| 05:19 |
erlehmann |
and those things are on contentdb right now as far as i know |
| 05:20 |
erlehmann |
lots of people will *probably* be unhappy with it |
| 05:30 |
erlehmann |
what happened to backwards compatibility? |
| 05:30 |
erlehmann |
:( |
| 06:18 |
erlehmann |
ok so i tested this |
| 06:19 |
erlehmann |
and maps in mineclone5 do not work any more! how can you do that to players? |
| 06:19 |
erlehmann |
a friend of mine built a whole map wall on kay27 mineclone5 server and all that will not be visible! |
| 06:20 |
erlehmann |
i think it is deeply unethical if minetest 5.5 ruins player worlds because someone thinks a file format is not used but it actually is |
| 06:20 |
erlehmann |
the TGA removal is really bad |
| 06:20 |
erlehmann |
:( |
| 06:26 |
erlehmann |
please do not do such backwards-incompatible changes |
| 06:26 |
erlehmann |
it breaks things |
| 06:26 |
erlehmann |
people have been making maps for months |
| 06:26 |
erlehmann |
there is like young kids who are very proud of their things and you developers just want to ruin it? :( |
| 06:28 |
erlehmann |
sfan5, celeron55 what can i do to get the tga thing back? it is not that i particularly like mineclone2 or mineclone5 but i think this is REALLY bad. |
| 06:28 |
erlehmann |
and i bet there are other things being ruined by these removals right now |
| 06:42 |
MTDiscord |
<Sublayer plank> hecks made a lua png writer api which seems to end up doing the same thing as what people use the undocumented tga format support for |
| 06:43 |
MTDiscord |
<luatic> The axing PR hasn't been merged yet IIRC |
| 06:43 |
MTDiscord |
<Sublayer plank> it has |
| 06:43 |
MTDiscord |
<luatic> phenom: But that is not supported on older servers |
| 06:43 |
MTDiscord |
<luatic> oh no |
| 06:43 |
MTDiscord |
<luatic> That is unacceptable, it literally breaks compatibility. |
| 06:44 |
MTDiscord |
<luatic> If the engine says we support formats, we may not remove them in the blink of an eye because we see them used rarely. |
| 06:45 |
erlehmann |
they are not even used rarely |
| 06:46 |
erlehmann |
you are probably annoying every player that has used mineclone2 and mineclone5 in the last few months |
| 06:46 |
erlehmann |
like half a year or so |
| 06:46 |
erlehmann |
singleplayer, server |
| 06:47 |
erlehmann |
without wanting to be mean, i think hecktest is not being honest at all. it is the same person that claimed that computers without openGL 2 can not run minetest well and then wants to remove support. |
| 06:47 |
erlehmann |
and then claims that tga is not used (despite mods on contentdb using it) and removes it |
| 06:48 |
erlehmann |
seriously, i have seen this a bunch of times, most often employed by people from the systemd ecosystem |
| 06:48 |
erlehmann |
the playbook also contains the assertion that a) you listen to complaints but b) the ones who DO complain are in fact, edge cases and should GET WITH THE PROGRAM |
| 06:48 |
MTDiscord |
<luatic> This is compatibility-breaking, plain and simple, and should not have been merged |
| 06:48 |
MTDiscord |
<Sublayer plank> tga has never been officially supported, it has only been working because it's been in irrlicht just like with various other weird image formats |
| 06:48 |
erlehmann |
yeah and a simple check for all mods on contentdb would have shown it |
| 06:49 |
MTDiscord |
<luatic> Axing features we do not use is fine, axing features we do use and claim to support is not. |
| 06:49 |
erlehmann |
Sublayer plank oh i bet all those people who rely on tga support ARE TOTALLY HAPPY to hear it was not ever officially supported for 10 years or so and now their worlds break |
| 06:49 |
erlehmann |
this is dishonest and you all know it |
| 06:50 |
|
ssieb joined #minetest-dev |
| 06:50 |
MTDiscord |
<luatic> It was officially supported, every capable mod dev reads the sources anways to find out what is and isn't supported |
| 06:50 |
erlehmann |
yes |
| 06:50 |
erlehmann |
in fact, fleckenstein told me he did not even read the rubenwardy book |
| 06:50 |
erlehmann |
he read other mods! |
| 06:50 |
erlehmann |
to find out how stuff works |
| 06:50 |
erlehmann |
sfan5 celeron55 bring tga back please |
| 06:51 |
MTDiscord |
<luatic> Well, I think Minetest doesn't properly document which formats it supports AT ALL. |
| 06:52 |
MTDiscord |
<luatic> Try grepping for "b3d" |
| 06:52 |
MTDiscord |
<Sublayer plank> https://wiki.minetest.net/Using_Blender#File_format_support |
| 06:52 |
MTDiscord |
<luatic> Yeah, the dev wiki touches upon it |
| 06:52 |
erlehmann |
look whatever you claim, it is used. it breaks old servers with new clients. |
| 06:52 |
MTDiscord |
<luatic> But the wiki is only semi-official |
| 06:53 |
erlehmann |
it does not matter at all. |
| 06:55 |
erlehmann |
ripping out stuff that has been supported for a while in the name of refucktoring and then telling everyone using a previous version they should fix their stuff now is one of the more evil things minetest can do |
| 06:55 |
erlehmann |
bring tga back! |
| 06:55 |
MTDiscord |
<luatic> Yes, bring TGA and MD2 and all the other axed file formats back. |
| 06:55 |
MTDiscord |
<luatic> https://wiki.minetest.net/index.php?title=Using_Blender&diff=23842&oldid=22754 |
| 06:56 |
MTDiscord |
<luatic> The dev wiki DID mention those file formats at some point. If we are to consider this official docs, removing them in a minor release is unacceptable. |
| 06:56 |
erlehmann |
removing them at all without a seamless upgrade path is absolutely haram |
| 06:59 |
erlehmann |
celeron55, sfan5, i know i can not legally demand it, because it is creative commons. but if engine breakage is allowed to stand – and as i see it, hecktest wants to remove the ability of people to run minetest on older computers entirely, i want to hereby ask you to stop using the minetest icon i designed about 10 years ago in the first release that breaks existing worlds or makes the game unable to run on th |
| 06:59 |
erlehmann |
e computer i am typing from. |
| 07:00 |
MTDiscord |
<luatic> What about starting yet another Minetest fork? |
| 07:01 |
erlehmann |
i could only do that because i did not have a day job or a partner and was generally healthier then. |
| 07:02 |
erlehmann |
i may try to work on waspsaliva and backport everything but the broken stuff, because it has a bunch of convenience things, like optionally not displaying particles (for performance) and stuff like that. but it seems like a lot of work. maybe i can maintain a patchset that makes it possible to play. but i doubt it. |
| 07:02 |
erlehmann |
hecktest seems to be hellbent on destroying the compatibility |
| 07:03 |
MTDiscord |
<luatic> The PR would have been fine if it did what it said in the title. |
| 07:03 |
erlehmann |
yes the PR is a lie |
| 07:03 |
erlehmann |
if it was unused, i would not be upset so much |
| 07:03 |
MTDiscord |
<luatic> But these file formats were used, and I really want to start using MD2. |
| 07:03 |
erlehmann |
rubenwardy, is there an easy way to scan contentdb for filetypes? |
| 07:04 |
MTDiscord |
<luatic> hmm, I don't think there is |
| 07:04 |
erlehmann |
when fleckenstein wanted to remove about 100 nodes from mineclone2 because they were not in minecraft 1.12 (and wanted to alias river water to water LOL), i thought that was bad. hecktest is worse though! if you want to make such large changes, you HAVE to make sure they are REALLY accurate. |
| 07:04 |
erlehmann |
it took wuzzy to come out of retirement and write a long post why it was a stupid idea |
| 07:05 |
MTDiscord |
<luatic> you'd have to download all packages and then scan them |
| 07:05 |
MTDiscord |
<luatic> I might get to it tomorrow |
| 07:05 |
erlehmann |
well i bet mineclone2 and mineclone5 are not the only ones that are broken |
| 07:06 |
erlehmann |
is hecktest on irc? if not, tell that person that it is careless and dangerous and will make many people unhappy |
| 07:06 |
erlehmann |
if yes: hecktest, you may be talented, but you apparently have NO idea what hardware people use or what games they play. |
| 07:06 |
MTDiscord |
<Sublayer plank> hecks is usually here, yeah. idk if he's here at the moment |
| 07:07 |
MTDiscord |
<luatic> Not much is gained from removing these file formats anyways; the relevant readers are rather small and simple. |
| 07:07 |
erlehmann |
yes |
| 07:07 |
erlehmann |
if this is like the fleckenstein situation, i expect the following: hecktest or someone else will offer a solution that does not actually solve the problem (but look like it at first glance), then declare the issue to be closed. |
| 07:08 |
erlehmann |
which is about as clever as aliasing river water to water (it makes river mapgen flood the map) |
| 07:08 |
MTDiscord |
<luatic> Well, I can see why you would "deprecate" baking TGAs instead of PNGs |
| 07:08 |
MTDiscord |
<luatic> PNGs are indeed preferrable, but backwards compatibility must be kept |
| 07:08 |
erlehmann |
i can not see it, the implementation is small and battle tested. |
| 07:08 |
erlehmann |
there is no bloat to find here |
| 07:08 |
MTDiscord |
<luatic> indeed |
| 07:08 |
erlehmann |
also the issue is that map art is generated once. it can not be regenerated, because it is the map at the point when it was generated. |
| 07:09 |
erlehmann |
it also reminds me of the chromium disaster. chromium recently tried to disable the first javascript function many people learn: alert() |
| 07:09 |
erlehmann |
and other stuff |
| 07:09 |
erlehmann |
it broke big websites, so they reverted it, but then said they will remove it anyway and webdevs should get with the times |
| 07:09 |
erlehmann |
yeah i bet all the old websites will TOTALLY get updated (not) |
| 07:10 |
erlehmann |
they will just remove it later as the big websites have now learned to either use the new chrome-internet-explorer APIs or be made unusable |
| 07:10 |
erlehmann |
it is really irritating to me how a project can be so backwards compatible but then just RUIN it |
| 07:11 |
erlehmann |
does no one from the devs actually play mineclone2? |
| 07:11 |
MTDiscord |
<luatic> We should start a petition or something |
| 07:12 |
MTDiscord |
<luatic> Open letter? |
| 07:12 |
erlehmann |
no it does not matter |
| 07:12 |
MTDiscord |
<luatic> Umm, it does matter |
| 07:12 |
MTDiscord |
<luatic> That PR is revertable rather easily |
| 07:12 |
erlehmann |
open letters do not matter |
| 07:12 |
MTDiscord |
<luatic> Well, let's get to the scanning of CDB at the weekend |
| 07:12 |
erlehmann |
there needs to be consensus among the devs if breaking stuff that has been on contentdb for a while i acceptable. i would prefer a BIG NO. |
| 07:13 |
erlehmann |
or if having new clients connect to old servers is acceptable |
| 07:13 |
erlehmann |
i mean if it is acceptable it should not break worlds! |
| 07:15 |
|
specing_ joined #minetest-dev |
| 07:15 |
erlehmann |
if there will be no developer consensus, hecktest or whoever else does that will continue to remove features insisting that they are legacy and not used. |
| 07:16 |
erlehmann |
you need to call people out on their lies if they do that. and by “lies” i mean: i haven't contributed code to minetest in a long time and it was easy for me to find counter examples. |
| 07:17 |
erlehmann |
and it is a LIE if someone just makes stuff up |
| 07:17 |
erlehmann |
luatic i am willing to collaborate on a blog pot |
| 07:17 |
erlehmann |
post |
| 07:18 |
erlehmann |
luatic or just show your open letter |
| 07:18 |
erlehmann |
i can contact all the other devs (of cheat clients or mineclone) so you see this affects many people using the engine |
| 07:28 |
MTDiscord |
<Sublayer plank> you could also go through commit df9d667 in the PR, add back the relevant TGA code, and open that as a PR and push it to be merged |
| 07:29 |
MTDiscord |
<luatic> Why only TGA though? |
| 07:29 |
MTDiscord |
<luatic> We should first see what formats are actually in use, which is what I'm up to right now. |
| 07:31 |
erlehmann |
yes |
| 07:32 |
erlehmann |
the commit should be unconditionally reversed because it was made in bad faith |
| 07:32 |
erlehmann |
just declaring something unused does not make it unused |
| 07:33 |
erlehmann |
> File formats have been triaged rather aggressively - I've left only PNG, JPEG, X, B3D, OBJ. |
| 07:33 |
erlehmann |
> BMP is also enabled because the null video driver would not compile without it. |
| 07:34 |
erlehmann |
so i checked this adn i have about the same amount of TGA files (118) as JPEG files (155) in my cache folder. |
| 07:35 |
erlehmann |
also i have 581 files for which libmagic does not know what they are, >3000 ogg files, ~48700 PNG files, exactly 1 BMP file, 1664 text/plain |
| 07:35 |
erlehmann |
i also want to add that this kind of thing would have not been easily possible if the “put the cache in sqlite” PR would have gone through. i hope it dies a fiery death. |
| 07:41 |
celeron55 |
i'd say adding back tga is a possibility |
| 07:42 |
erlehmann |
celeron55, why not a certainty? |
| 07:42 |
MTDiscord |
<Sublayer plank> what's so bad about the "put the cache in sqlite" PR? |
| 07:43 |
erlehmann |
to be clear, i have about as many map arts here as skybox textures |
| 07:43 |
celeron55 |
removing format support overall is wise, because each and every one of them is a security risk and also a potential maintenance burden in the process of transitioning away from irrlicht |
| 07:44 |
erlehmann |
it is not wise if it breaks several public servers that have relied on it for a time |
| 07:44 |
erlehmann |
or any number of private servers |
| 07:44 |
erlehmann |
*everyone* who crafted a map item in mineclone2 post 0.71 or mineclone5 (both downloaded from contentdb) will be affected |
| 07:46 |
erlehmann |
regarding security risks … i do security as a day job. i can offer to audit the TGA code and try to break it. that does not prove it is secure, though. |
| 07:47 |
celeron55 |
md2 is mentioned by appguru in the thread also, is it used by something? |
| 07:48 |
erlehmann |
no idea, i have so far only found b3d files in my cache. give me a minute or two. |
| 07:48 |
celeron55 |
i could be wrong, but i think these formats weren't officially supported, which is the reason we thought the code could be removed. the official wiki is quite rogue in this matter though as it does mention many of them |
| 07:49 |
erlehmann |
from my point of view the reason you thought they could be removed is because hecktest just made that assertion up |
| 07:49 |
erlehmann |
that they are not used |
| 07:50 |
erlehmann |
and the when someone complained that was ignored! |
| 07:50 |
erlehmann |
it is right there in the PR, mineclone2 devs complaining |
| 07:50 |
celeron55 |
i haven't been following the PR after it was merged |
| 07:51 |
erlehmann |
they were given the suggestion to use a different format by sfan5, but no solution for *every* map being broken in mineclone2 and mineclone5 |
| 07:51 |
erlehmann |
liker, if you want to ruin hundreds of players hard work for in-game experience (making map art is really difficult, you need to place a lot of blocks), go ahead, make a release with that. |
| 07:52 |
erlehmann |
liker → like |
| 07:52 |
celeron55 |
anyway we need the patch that adds in tga, for reviewing it |
| 07:52 |
erlehmann |
how about you revert the patch that removed tga? |
| 07:52 |
erlehmann |
it does not look sane anyway |
| 07:52 |
celeron55 |
it removed 216514 lines of code |
| 07:52 |
celeron55 |
most of it is truely useless |
| 07:52 |
erlehmann |
yes that is extremely stupid, and i mean that in a professional way |
| 07:52 |
MTDiscord |
<Sublayer plank> I feel tga is the only image format removed that has actually seen some use. like, I don't see anyone asking for psd, pvr or rgb to be added back. adding back tga support would be like 500 lines of code at most |
| 07:53 |
erlehmann |
celeron55, making such a big commit breaks most git toolings |
| 07:53 |
nrz |
it's not an issue i think to re-add tga |
| 07:53 |
erlehmann |
sometimes in subtle ways, sometimes in more obvious |
| 07:53 |
celeron55 |
i think that commit is fine, it just removed tga, which was in use, and appguru's comment about md2 there has a point |
| 07:53 |
erlehmann |
gitg will probably be unusable for the irrlichtMT repo |
| 07:53 |
nrz |
and we can add depreciation notices instead of being aggressive on format removal ? |
| 07:54 |
erlehmann |
i think the commit should have been a bunch of small things for each format |
| 07:54 |
erlehmann |
so you can revert the stuff that is stupid |
| 07:54 |
erlehmann |
hecktest is not careful! |
| 07:54 |
erlehmann |
if you add it in, will you lose the history of the file? |
| 07:54 |
erlehmann |
for the lines i mean |
| 07:54 |
erlehmann |
<celeron55> it removed 216514 lines of code |
| 07:54 |
erlehmann |
how was that even reviewed |
| 07:55 |
erlehmann |
like come on you can't tell me someone actually checked this manually |
| 07:55 |
celeron55 |
removing code is fine to me, if it breaks something that'll pop up just like it did now |
| 07:55 |
erlehmann |
uhhh, no? |
| 07:55 |
erlehmann |
this was almost not noticed |
| 07:56 |
erlehmann |
because a) the PR was dismissive towards the ppl who said it is a bad idea b) the mineclone2 devs use cheat clients, which lag behind the official one. you can rebase the cheats on an official release. |
| 07:56 |
celeron55 |
it was noticed on 23 jul, just need to be more careful to follow the post merge comments in these PRs |
| 07:56 |
erlehmann |
ok |
| 07:56 |
erlehmann |
fleckenstein is the author of the dragonfire cheat client, he will probably not notice early when stuff breaks |
| 07:57 |
erlehmann |
but at the next merge/rebase-fest |
| 07:57 |
celeron55 |
well i can say we don't support cheat client developers |
| 07:57 |
celeron55 |
so you can go away with that argument |
| 07:57 |
erlehmann |
uh i think you do misunderstand me |
| 07:57 |
erlehmann |
those ppl test their mod with the up to date version of the cheat client, which means the last major version of minetest usually |
| 07:58 |
erlehmann |
it's not about the cheats |
| 07:58 |
erlehmann |
it's that they have a legit reason to use an older featureset |
| 07:58 |
celeron55 |
if you develop games for minetest, you should check the in-development version in case of bugs especially when a release is coming up. of course not everyone will have the time to do that, but we need that and wish enough game developers will do it |
| 07:59 |
erlehmann |
celeron55 can i do something to prevent such breakage in the future? i will try to read more that hecktest did to find more breakage. |
| 07:59 |
erlehmann |
yeah but if high-profile games break and neither the engine devs nor the game devs notice it MAYBE you should handle stuff like this like the texture alpha thing |
| 08:00 |
erlehmann |
where a lot of warnings are output for a long time |
| 08:00 |
erlehmann |
that was ok, people fixed their stuff, nothing broke |
| 08:00 |
erlehmann |
but just removing stuff that is actually used, horrible |
| 08:00 |
erlehmann |
especially with claiming it is not used, which is the argument for removing it. if that was true, it would be good! |
| 08:01 |
celeron55 |
also we didn't have much experience in doing stuff with our irrlicht fork at the time and many weren't following it as it was so new, so that also explains the inattention |
| 08:01 |
erlehmann |
but i will from now on believe that every such claim is a lie unless backed up by data |
| 08:01 |
MTDiscord |
<Sublayer plank> the largest chunk of tga format code is contained in their CImage{Loader,Writer} source files, only thing apart from that would be minor build code-related things you can find with a ctrl+f |
| 08:01 |
celeron55 |
i.e. this is easy to learn from |
| 08:01 |
erlehmann |
Sublayer plank can you add it back in? i can test |
| 08:01 |
erlehmann |
i think btw hecktest and whoever approved it should fix it |
| 08:01 |
erlehmann |
or have their stuff reverted |
| 08:02 |
erlehmann |
they broke it! |
| 08:02 |
celeron55 |
also no data was lost or anything, simply adding the code back will make everything work again. it's not really a bad situation |
| 08:02 |
erlehmann |
celeron55, i am so agitated so that it does not become a bad situation. |
| 08:02 |
erlehmann |
it is not yet bad, but it could have been. |
| 08:02 |
erlehmann |
obviously earlier warnings were ignored. |
| 08:02 |
celeron55 |
well, it's nice you noticed it, that prevented a worse situation |
| 08:03 |
erlehmann |
good. btw, the “speedup item rendering” thing that actually slows down item rendering is the same. |
| 08:03 |
MTDiscord |
<Sublayer plank> yeah I was thinking of adding it in and creating a PR if nobody else would step up to do that |
| 08:03 |
erlehmann |
someone just claimed stuff and it was wrong! |
| 08:04 |
erlehmann |
this one https://github.com/minetest/minetest/issues/10570 – where Warr1024 even knew it was “hit/miss tech” and “a big headache” |
| 08:04 |
erlehmann |
btw “if any unit test breaks I would just delete it” LOL |
| 08:06 |
erlehmann |
celeron55 “also no data was lost or anything, simply adding the code back will make everything work again” yes ok in that way the mineclone2 situation was worse – it would have ruined those worlds forever. |
| 08:07 |
celeron55 |
well, only as long as the code wasn't added back in |
| 08:09 |
erlehmann |
no, because fleckenstein wanted to do stuff like alias river water to water |
| 08:09 |
erlehmann |
i.e. all river water would have flooded the map and never be turned back |
| 08:09 |
erlehmann |
once you load the world with the new version |
| 08:10 |
erlehmann |
let's say fleckenstein wanted everything to be EXACTLY LIKE MINECRAFT 1.12 |
| 08:10 |
erlehmann |
regardless of if that affects performance badly or player experience |
| 08:10 |
celeron55 |
ah yeah that sounds kind of bad |
| 08:10 |
erlehmann |
at some point wuzzy came and told fleck among other things that the reason why minecraft 1.12 did not have these blocks is bc of technical limitations |
| 08:11 |
erlehmann |
their block id space was too little, so minecraft changed to a namespaced system like minetest in 1.13 |
| 08:11 |
erlehmann |
too small i mean |
| 08:12 |
erlehmann |
celeron55, don't worry, i'm sure with the rate of breaking changes i have encountered in the past week sooner or later i will find one that is not easily reversible! |
| 08:12 |
celeron55 |
anyway, if someone wants to make me actually angry, you have to cause data corruption. anything else just makes me say "guys come on" |
| 08:13 |
erlehmann |
well i am also upset because how it was handled. for 4 things in a row now i found that they were not really supported by evidence how they affect performance, the submitters of the PR were just making stuff up. |
| 08:15 |
erlehmann |
like “sqlite is a faster key-value store than the filesystem” (not the case), “the number of machines that can actually run minetest but have opengl <2 is the empty set” (we talked about that), “this PR speeds up inventory item rendering” (actually slowed it down) and now “these file formats are not used” (but they are) |
| 08:16 |
erlehmann |
if someone at work would submit PRs like this, i'd probably talk to their boss about them making stuff up to get their pet features included. |
| 08:17 |
erlehmann |
celeron55 obviously i am eager to help. what do you think i can do to minimize breakage? |
| 08:17 |
sfan5 |
why are there five mentions of my nick when I look in here for the first time today |
| 08:18 |
erlehmann |
oh this is fun as well https://github.com/minetest/minetest/pull/10570#issuecomment-915797012 |
| 08:18 |
erlehmann |
> I don't quite see why this would cause the mentioned lag |
| 08:18 |
erlehmann |
yeah, but i measured it. it's laggier than before. |
| 08:18 |
nrz |
sfan5, because you are famous ? |
| 08:18 |
erlehmann |
it does not matter if the person who wrote the code does not understand it |
| 08:21 |
erlehmann |
sfan5, TGA support was removed here https://github.com/minetest/irrlicht/pull/48, breaking map art in mineclone2 and mineclone5 which are both on contentdb. you approved these changes even though hecktest just made probably anything about unused file formats up on the spot. |
| 08:22 |
erlehmann |
sfan5 you also suggested a … well … non-solution to the problem of breaking *existing* map art, i.e. replacing the TGA encoder with a BMP encoder, so maybe you did not understand that making map art is a time consuming process (basically 1 pixel is 1 voxel, so you need to place a lot of nodes for a thing). |
| 08:22 |
erlehmann |
and that it would break existing stuff from about the last half year |
| 08:23 |
erlehmann |
i have written BMPs in bourne shell, replacing the encoder is easy, you are right! |
| 08:24 |
erlehmann |
but the TGAs contain the state of the map at the point the image was made. so mineclone2 and mineclone5 would have to have code to a) adjust all items that refer to tga textures b) read the TGA files to encode them anew on the fly as BMP. |
| 08:24 |
MTDiscord |
<Sublayer plank> https://github.com/rollerozxa/irrlicht/commit/ea419b78c15e5f7a0903338eaa819db6a4375818 |
| 08:24 |
erlehmann |
let's say as someone who has dealt with mineclone2 and mineclone5 development, i think the likelier outcome is just that those two games stay broken for months. |
| 08:24 |
erlehmann |
and then some |
| 08:25 |
MTDiscord |
<Sublayer plank> doesn't work right now, I can't get it to use a TGA image for a node texture as a test |
| 08:25 |
erlehmann |
damn |
| 08:25 |
erlehmann |
if only hecktest had made proper commits removing each feature |
| 08:25 |
erlehmann |
i hate that i can not use gitg for the repo anymore or “git log -p” without having segfaults or lag |
| 08:26 |
erlehmann |
if you think i trash-talk the mineclone2 devs post-wuzzy … mineclone2 0.71 was even uploaded to contentdb with massive lag, and no nether quartz or nether wart generating. |
| 08:26 |
erlehmann |
which basically made potions unobtainable |
| 08:27 |
erlehmann |
also most enchanted items had at least 21kb of metadata, so if you put on enchanted gear, well, LAG |
| 08:27 |
erlehmann |
or if you had it in your inventory |
| 08:27 |
erlehmann |
all of that took *months* to fix |
| 08:28 |
erlehmann |
so that's why i think they will probably not fix anything if the engine breaks it. apart from that, come on, breaking user worlds is the ONE thing that minecraft does all the time and minetest does not. |
| 08:29 |
erlehmann |
i shall be silent and work |
| 08:29 |
sfan5 |
erlehmann: removing supported formats is technically not in line with our backwards-compat but reasonably to make an exception for a once-in-a-lifetime event such as Irrlicht cleanup |
| 08:30 |
sfan5 |
and if the TGA removal was such a big issue one of the MCL* devs should have said so (well you are doing now, but I mean back then) |
| 08:30 |
erlehmann |
they said so |
| 08:30 |
erlehmann |
and come on, checking every mod on contentdb for the case-insensitive string "TGA" is possible |
| 08:30 |
sfan5 |
"but we use TGA" "yeah but you can use BMP" "[crickets]" |
| 08:30 |
erlehmann |
for such a big change |
| 08:31 |
erlehmann |
well, i guess your reply basically told them you do not understand the problem, but i do not know for sure |
| 08:31 |
erlehmann |
while i am pretty rude and willing to bitch about problems until they are fixed |
| 08:32 |
erlehmann |
sfan5, by the way: my problem is not with the removal of stuff that is not used per se, but that a) the submitter just made something up b) you approved it without actually checking if what was claimed (which file formats are not used) was actually true. |
| 08:32 |
erlehmann |
can maybe running file(1) on all contentdb mods be added to the CI? |
| 08:33 |
erlehmann |
or could rubenwardy chime in if it makes sense to have contentdb collect this info? |
| 08:34 |
MTDiscord |
<Sublayer plank> wtf is up with CNullDriver |
| 08:34 |
erlehmann |
btw, i am happy you listened to me |
| 08:35 |
erlehmann |
i mean, in the mineclone2 story i was called terrorist for my “stop breaking the game for everyone who has it installed” nagging |
| 08:35 |
sfan5 |
if they make no (real) attempt to explain the problems they are facing because of TGA being removed then we can't accomodate for that |
| 08:36 |
erlehmann |
they are a difficult crowd to work with |
| 08:37 |
erlehmann |
and some of the ppl around mineclone2 or mineclone5 do think the minetest engine devs (particularly including you) are idiots bc their pet feature is not included. i guess they will sooner or later have their own engine fork like crafter guy. |
| 08:37 |
erlehmann |
for the record, i think you are nice |
| 08:37 |
erlehmann |
and i think the mineclone2 dev situation post-wuzzy is dominated by toxic personality conflicts |
| 08:38 |
sfan5 |
anyway I don't think it's too complicated for MCL to convert existing .tga maps to .bmp on startup, you can skip the modifying existing items step because the engine strips the texture extension (I think) |
| 08:38 |
erlehmann |
that leaves the “new client, old server” issue |
| 08:38 |
erlehmann |
has it ever happened before that stuff broke bc you used a newer client? |
| 08:39 |
erlehmann |
some mcl2 servers are still on minetest 5.3, the security nightmare release |
| 08:40 |
celeron55 |
<Sublayer plank> https://github.com/rollerozxa/irrlicht/commit/ea419b78c15e5f7a0903338eaa819db6a4375818 |
| 08:40 |
celeron55 |
did you remember to enable the format in the server and client code also? |
| 08:40 |
celeron55 |
they have file extension whitelists |
| 08:41 |
MTDiscord |
<Sublayer plank> https://github.com/minetest/minetest/blob/1320c51d8e15409544cba970a97b167a37513bae/src/client/client.cpp#L650 |
| 08:41 |
sfan5 |
good point but seeing as Mineclone has a strict policy of only supporting one exact Minetest versions that doesn't seem like a big problem |
| 08:41 |
MTDiscord |
<Sublayer plank> tga was never removed from the client image whitelist |
| 08:41 |
sfan5 |
s/versions/version/ |
| 08:42 |
erlehmann |
mineclone policy means nothing if the engine is not stable |
| 08:42 |
erlehmann |
the problem is breaking worlds on upgrade |
| 08:42 |
MTDiscord |
<Sublayer plank> also it works now, it can load a TGA image but... only when I rename the file to .png? |
| 08:42 |
MTDiscord |
<Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/885445070113898516/unknown.png |
| 08:42 |
erlehmann |
lol |
| 08:42 |
MTDiscord |
<Sublayer plank> it's still in TGA format ofc |
| 08:43 |
erlehmann |
btw in mineclone2 some bugs were never reported because the “obvious” solution to them would have been buggy in a worse way than the bug and the devs never cared about that. i believe it is the same for minetest engine also. in particular, i think some cheat client developers might help with engine debug features that are more for convenience than cheating if they would not expect to be banned or ridiculed. |
| 08:44 |
erlehmann |
i mean, there exist at least 3 different night vision implementations that were probably not considered in the night vision PR |
| 08:44 |
erlehmann |
because they exist in cheat clients … |
| 08:44 |
sfan5 |
you keep mentioning this as a theoretical |
| 08:44 |
sfan5 |
what if they just do it |
| 08:45 |
sfan5 |
they can go to github and contribute |
| 08:45 |
sfan5 |
right now |
| 08:45 |
celeron55 |
we can't help with past bad experiences |
| 08:45 |
MTDiscord |
<Sublayer plank> oh never mind, minetest client/tile.cpp has tga removed already |
| 08:45 |
erlehmann |
yeah but you could maybe accept that cheat clients are not only full of cheats but also have features that are just for less lag and stuff or finding bugs |
| 08:46 |
celeron55 |
minetest is run as an upstream project and it has many downstreams, MT's devs can't be expected to dig through the forks for features to be ported upstream |
| 08:47 |
erlehmann |
no but you could be less hostile. like instead of banning ppl from forums for cheating make a subforum for cheat/debug features. |
| 08:47 |
erlehmann |
specing, you do cheat client stuff too, what is your impression? |
| 08:48 |
sfan5 |
it is not in our interest to condone or promote cheating on the official forum out of all places |
| 08:49 |
erlehmann |
yeah but that is the point, then those ppl go elsewhere. |
| 08:49 |
erlehmann |
and stay away |
| 08:49 |
erlehmann |
which is intended, but that way you don't get engine bugfixes |
| 08:49 |
celeron55 |
i bet many server admins would get pissed off if the forum had a cheating section |
| 08:50 |
celeron55 |
so the choice would be whether to promote cheating and condone server admins, or the other way around like now |
| 08:50 |
celeron55 |
i mean |
| 08:50 |
erlehmann |
yeah i get it |
| 08:50 |
celeron55 |
what's the opposite of condoning |
| 08:50 |
erlehmann |
tolerating |
| 08:51 |
erlehmann |
i don't want to promote cheating btw |
| 08:51 |
erlehmann |
i only use fly to build better and to not get killed by ppl who remove the ground under logged out players |
| 08:51 |
erlehmann |
but i play on clamity mostly and clamity server has cheat clients allowed. i believe your-server.de does it best, they have a test server they use to investigate dupes and other cheats. |
| 08:52 |
erlehmann |
forget about the cheating thing, i just wanted to explain why those ppl are probably not particularly motivated to help |
| 08:53 |
celeron55 |
anyway, MT's official stance must be towards fair play and order, because if MT does not officially do that, nobody else is going to, it'll be all chaos |
| 08:53 |
erlehmann |
that being said, i kinda expect mineclone2 to just stop development, mineclone5 to continue and if mineclonia stops probably depends if minetest will stop running on where it is develped (for example, my pc) |
| 08:53 |
sfan5 |
<erlehmann> can maybe running file(1) on all contentdb mods be added to the CI? <- this wouldn't have helped would it? MCL ships no tga files, it only generates them at runtime |
| 08:54 |
erlehmann |
sfan5 it would have cleared it up for other file formats though |
| 08:55 |
erlehmann |
i think if you believe that hecktest just made up which file formats are important, checking contentdb is a good first step to see if other important stuff was removed, even if it would not catch all cases. |
| 08:55 |
erlehmann |
file(1) will nod catch b3d or md2 files though |
| 08:55 |
erlehmann |
at least on my machine |
| 08:55 |
erlehmann |
nod → not |
| 08:55 |
erlehmann |
sfan5, i would probably not have expected jpeg to be used btw if i was asked to make up which file formats are used, bc i have never interacted with skyboxes much |
| 08:56 |
erlehmann |
compared to PNG everything is unimportant ^^ |
| 08:56 |
erlehmann |
sfan5, if you want to figure out what you have in your cache, you can probably do: ls |xargs -n50| file --mime --brief |sort |uniq -c |
| 08:57 |
erlehmann |
sorry |
| 08:57 |
erlehmann |
sfan5, ls |xargs -n50 file --mime --brief |sort |uniq -c |
| 08:57 |
sfan5 |
the decision which formats to drop was made purely on how obscure they seemed |
| 08:58 |
erlehmann |
which is another way to say “conjured out of thin air and not based on facts” |
| 08:58 |
erlehmann |
and which i think is wrong. it is wrong here, it is wrong with the PR that claims to enhance performace but actually worsens it etc. pp. |
| 08:58 |
celeron55 |
i think the base failure here was that, now that i looked at 5.4.1, we actually didn't have a list of supported formats for anything in lua_api.txt or anywhere else |
| 08:59 |
celeron55 |
so the list of supported formats was informal at best, but actually inexistent |
| 08:59 |
erlehmann |
yes but the thing is, people will find a way in minetest, even if something is not supported |
| 08:59 |
sfan5 |
erlehmann: correct, but most decision work that way |
| 08:59 |
erlehmann |
sfan5, then most decisions are probably at least partially wrong |
| 09:00 |
celeron55 |
well it's this again: one day people ask us to merge code with lighter checking if there's no time for thorough review, and then the next day other people blame us for doing exactly that |
| 09:00 |
erlehmann |
celeron55, for example, compasses in mcl2 are like a bunch of items that are switched out in the inventory all the time. banners are entities that are cobbled together at runtime. every non-trivial mod has hacks upon hacks upon hacks. |
| 09:00 |
erlehmann |
> people ask us to merge code with lighter checking if there's no time for thorough review |
| 09:01 |
erlehmann |
in my experience, those ppl are unreasonable. when we did that in mineclonia and mcl_meshnode, particularly for huge changes, it always broke something. |
| 09:01 |
erlehmann |
mineclone5 also had that problem, mineclone2 did not have reviews at all |
| 09:02 |
celeron55 |
that's what i've found out too, and that's why MT still has the "why do you do that, that's so slow and nothing gets through" 2 coredev requirement for merging |
| 09:02 |
erlehmann |
and mineclone2 had *two* forks because of the abysmal quality lol |
| 09:02 |
erlehmann |
celeron55, https://github.com/minetest/irrlicht/pull/48 was only approved by sfan5 though. that makes one core dev. |
| 09:03 |
sfan5 |
the second coredev is hecks |
| 09:03 |
sfan5 |
himself |
| 09:03 |
celeron55 |
a PR made by a coredev implies one approval |
| 09:03 |
celeron55 |
if you want to benefit from that, apply for a coredev status today! |
| 09:03 |
erlehmann |
ok hi |
| 09:03 |
erlehmann |
where do i need to put in the work |
| 09:03 |
sfan5 |
and also the two approvals requirement never really applied to repos other than minetest and minetest_game |
| 09:03 |
erlehmann |
yeah maybe you should apply it to the irrlicht thing officially |
| 09:04 |
erlehmann |
celeron55, it is the same thing that has worked for mineclonia then |
| 09:04 |
erlehmann |
2 approvals if code comes from outside, 1 if it comes from inside |
| 09:04 |
sfan5 |
I've enjoyed working on minor fixes, cleanup or other things in IrrlichtMt without worrying about approvals |
| 09:05 |
erlehmann |
sfan5 well either your code is uncontroversially good, then convincing *one* other person that it is, is not a big task. or it is not, then you should think again why it is difficult to find an approver, no? |
| 09:05 |
erlehmann |
are you understaffed? |
| 09:05 |
erlehmann |
i can promise to review stuff with as much vitriol as i can spare, but i am not good at C++. i can see security issues though! |
| 09:05 |
MTDiscord |
<Sublayer plank> all volunteer-run projects are always understaffed, to some extent |
| 09:07 |
sfan5 |
convincing another person is a big task when there is no such person for 70% of the week |
| 09:08 |
erlehmann |
well i want to help because so far the majority of the issues were kinda affecting playability |
| 09:08 |
erlehmann |
i am even willing to use github for that |
| 09:09 |
erlehmann |
also engine devs are kinda the adversary from a gamedev point of view, they can break stuff. keep your enemies closer and all that! |
| 09:10 |
celeron55 |
well, technically i think you do have some commits in the engine, albeit insanely old ones, so that requirement does pass for being a core dev |
| 09:11 |
erlehmann |
well due to the hg import i lot of commits are erroneously attributed to me |
| 09:11 |
erlehmann |
sorry |
| 09:12 |
erlehmann |
but i did do some stuff |
| 09:12 |
erlehmann |
like … bookshelves! |
| 09:12 |
celeron55 |
(fun fact: my newest comment is also insanely old) |
| 09:12 |
erlehmann |
also the omsk bird |
| 09:12 |
celeron55 |
eh |
| 09:12 |
erlehmann |
commit? |
| 09:12 |
celeron55 |
commit |
| 09:12 |
erlehmann |
why did you remove oerkki |
| 09:12 |
erlehmann |
i always wanted to ask that |
| 09:12 |
erlehmann |
also my sick block texture was removed ^^ |
| 09:13 |
MTDiscord |
<Sublayer plank> anyways what is up with CNullDriver in irrlicht? there's references to writing and loading various removed image formats in it and I don't know why it doesn't make it fail during compile, other than it being dead code |
| 09:13 |
erlehmann |
i bet hecktest knows, i mean bmp is in it just bc of that? |
| 09:13 |
erlehmann |
or wait, i should not chime in. i know nothing about that part of the code |
| 09:13 |
|
pmp-p joined #minetest-dev |
| 09:14 |
celeron55 |
is CNullDriver it ever built at all? |
| 09:14 |
sfan5 |
bmp is used by some internal things and I would have advocated keeping at least one simple, uncompressed format anyway |
| 09:14 |
MTDiscord |
<Sublayer plank> from what I can tell it seems to be the "null" driver backend that is the base for all other backends like opengl and opengles |
| 09:15 |
erlehmann |
celeron55, so what do i need to do now to get core dev, submit my pgp key? |
| 09:15 |
sfan5 |
it doesn't actually call those https://0x0.st/-w0Z.png (note the subtle graying out) |
| 09:15 |
sfan5 |
so yes dead code |
| 09:16 |
MTDiscord |
<Sublayer plank> oh right, preprocessor instructions |
| 09:20 |
celeron55 |
erlehmann: i must ask the existing core team for opinions, and if nobody disagrees, you should tell me you've read and understood this (and check that it makes sense to begin with, sometimes it gets outdated and nobody notices) https://dev.minetest.net/All_rules_regarding_to_development and if that works out i can add you to the team on github which gives you the permissions on the repo |
| 09:20 |
celeron55 |
and then you would be a core dev |
| 09:21 |
erlehmann |
> If a core developer is doing almost nothing but blocking everything that comes their way, they will be unassigned. |
| 09:21 |
erlehmann |
would this also be the case if i focus on patches that make the game unplayable or ruin stuff? |
| 09:21 |
erlehmann |
bc it is very easy to tell why, but it would be kinda negative |
| 09:22 |
erlehmann |
also i never know before testing if it is a problem |
| 09:22 |
celeron55 |
i guess i'll ask for opinions then: erlehmann would like to be a core dev would be interested in reviewing PRs as they relate to security and compatibility, any opinions from core devs? |
| 09:22 |
celeron55 |
+and |
| 09:23 |
erlehmann |
yeah i probably don't want to add much features, wuzzy already tries so hard and it takes ages before they are reviewed. |
| 09:23 |
celeron55 |
(god damn making making me look like a fool not showing the entire line as i'm editing it) |
| 09:23 |
celeron55 |
+irssi |
| 09:23 |
celeron55 |
:----D |
| 09:23 |
|
calcul0n_ joined #minetest-dev |
| 09:25 |
celeron55 |
erlehmann: well, if it tells anything no unassignments have been made so far, i guess to the disappointment of the people who have sometimes requested them |
| 09:26 |
celeron55 |
(aside from the person themselves asking to be unassigned, but you can leave the team on github on your own so it really doesn't require even asking) |
| 09:27 |
celeron55 |
i think from the core dev toolbox what you would be using most would indeed be the veto power, or at least the fact that people will put more weight on the words of a core dev when one questions a PR |
| 09:27 |
erlehmann |
ah |
| 09:30 |
sfan5 |
do you plan to review feature PRs though? |
| 09:43 |
erlehmann |
maybe, but mostly if it is related to features i care about, because then i have the context. i mostly want to review bc a) the last few things i casually looked at had game-breaking issues b) there seems to be a lack of thorough reviews |
| 09:43 |
erlehmann |
let me look at them |
| 09:45 |
erlehmann |
sfan5, i have an interest in particle spammers, texture modifies, fonts, physics overrides and dupes |
| 09:45 |
erlehmann |
sfan5, i bet i find enough features that touch any of these topics |
| 09:46 |
erlehmann |
in general, i would only look at it if i want to use it. bc one needs to be familiar with the use case. |
| 09:46 |
erlehmann |
otherwise bad things are more likely to happen |
| 09:46 |
erlehmann |
or maybe not *only*, but preferably |
| 09:47 |
erlehmann |
sfan5 i do not want to promise anything |
| 09:48 |
erlehmann |
sfan5, this is probably something i would review in-depth https://github.com/minetest/minetest/pull/11110 |
| 09:49 |
erlehmann |
in fact i am surprised that removing working features is more important than a bugfix, but well, i guess i am interested in different things |
| 09:50 |
erlehmann |
i will also have holidays soon, so don't expect me to do much in the next 3 weeks or so |
| 09:55 |
sfan5 |
¯\_(ツ)_/¯ |
| 09:57 |
sfan5 |
sounds fine but I'm a bit skeptical on the outcomes, we'll see |
| 10:23 |
MTDiscord |
<luatic> Well erlehmann, regarding my proclaimed speedup... It was partially assumed, but also benchmarked (not by me though) |
| 10:37 |
erlehmann |
sfan5, well you can look at my mineclonia work to see how thorough i do stuff |
| 10:37 |
erlehmann |
luatic no hard feelings, i just think it is sloppy work |
| 10:38 |
erlehmann |
luatic i have no idea myself why this is slower on my computer, i just noticed it is |
| 10:38 |
erlehmann |
luatic did you actually have performance problems without it? |
| 10:39 |
erlehmann |
sfan5, in mineclonia i also did stuff like take other people's branches and clean them up (i.e. split commits, merge commits, make sure that no unrelated changes are in it) |
| 10:39 |
erlehmann |
s/merge/squash/ |
| 10:40 |
sfan5 |
I have no doubts about the things you mentioned |
| 10:41 |
erlehmann |
i just said the holiday thing bc i won't be online much and won't have time |
| 10:42 |
erlehmann |
in general my interest is keeping minetest performant |
| 10:54 |
erlehmann |
and also trying to make ppl back up their statements |
| 10:55 |
erlehmann |
sfan5, in my experience almost everyone is pretty annoyed at me asking until i get a good answer, but think about the boundaries for the overlong items – if i had just taken your guess and anon5 had not corrected it, the code would have been wrong. |
| 10:55 |
erlehmann |
only slightly wrong, but in the end it's a constant. |
| 10:57 |
erlehmann |
btw, quoting a friend of mine regarding regressions that make it hard or impossible to run on old hardware (like including removing fixed pipeline): “it's not cool because the way I see it minetest is for people who have computers that can't run minecraft” |
| 10:57 |
erlehmann |
that's not my idea of it, but i do agree it should run |
| 11:21 |
celeron55 |
eh |
| 11:21 |
celeron55 |
that implies minetest is a worse minecraft with the only thing going for it that it runs on old computers |
| 11:22 |
celeron55 |
you can tell your friend he just insulted my project |
| 11:25 |
celeron55 |
and didn't insult minecraft enough |
| 11:33 |
erlehmann |
lol ok |
| 11:34 |
erlehmann |
celeron55, told him ;) |
| 11:34 |
erlehmann |
celeron55, don't worry my friend also made minetest mods |
| 11:35 |
erlehmann |
he knows what is good |
| 11:42 |
|
appguru joined #minetest-dev |
| 11:51 |
|
proller joined #minetest-dev |
| 11:59 |
|
proller joined #minetest-dev |
| 11:59 |
|
calcul0n__ joined #minetest-dev |
| 13:07 |
Calinou |
[18:01] <9c27b0erlehmann> btw i have had a thing where if i fall very fast and disable fall damage the server (5.4.1) and client 5.5-dev desync after impact |
| 13:08 |
Calinou |
my guess for this is that the client only sends position updates when it moves. When you hit the ground, you stop moving |
| 13:08 |
Calinou |
therefore, the interpolator does not try to follow the final position as it doesn't get any new data. Try disabling this optimization on the client side, then test again (it's hardcoded in C++) |
| 13:08 |
Calinou |
it was added in late 2012 or so |
| 13:10 |
Calinou |
The other reason is that your velocity is null when you hit the ground, so the last position is never sent to the server in the first place. This is less likely but not impossible. Try disabling the smooth translator to confirm this |
| 13:12 |
erlehmann |
Calinou can you tell me how to do this exactly? where do i have to disable it? |
| 13:12 |
erlehmann |
which line of code on which revision in which file? |
| 13:13 |
Calinou |
I don't remember where it is in the client code (I'm on mobile right now), but search for SmoothTranslator |
| 13:13 |
Calinou |
that's how the interpolator was called back then |
| 13:13 |
Calinou |
as for the sending optimization, I don't know. You could try looking at all commits made in November and December 2012 |
| 13:14 |
Calinou |
it may point to incorrect locations since the code has likely been refactored since, though |
| 13:14 |
Calinou |
I think Taoki made that optimization, or was it celeron? |
| 13:15 |
Calinou |
for the record, I've seen the bug you're mentioning in action too |
| 13:17 |
erlehmann |
hmm |
| 13:25 |
sfan5 |
the sending optimization is probably in client.cpp since packets get sent in there |
| 13:25 |
sfan5 |
(also the mainloop and other stuff is there) |
| 13:35 |
MTDiscord |
<Warr1024> As far as the whole "backwards compat" debate goes, I think we need to remain compatible but without remaining backwards. That means we SHOULD be able to deprecate features at any time, though there are better ways to do it than just axing things. As long as people are okay with changes given proper notice, then I think we don't have a problem. If someone submits a PR to update documentation to mark something as deprecated |
| 13:35 |
MTDiscord |
(especially if they've got a WIP PR ready for the later removal) I'm inclined to approve. |
| 13:36 |
MTDiscord |
<Warr1024> Suddenly dropping TGA support without warning is probably a bug. However, game/mod makers may have to accept that it could be deprecated, and if the necessary documentation/warnings are added to 5.5, there should be no reason that removing it in 5.6 should be considered a bug. |
| 13:39 |
erlehmann |
i see no reason whatsoever to deprecate stuff that is not a maintenance burden |
| 13:39 |
erlehmann |
i think code is a liability |
| 13:39 |
MTDiscord |
<Warr1024> As for core dev promotions: if the only thing it's for is veto power then it shouldn't be necessary. Objections to changes should be based on the merits of the objections and not on the status of the person making them, so a non-core-dev should have as much weight as a core dev if their objection is adequately valid. That being said, recognizing that game makers especially are MT's core audience and need to be the focus of support |
| 13:39 |
MTDiscord |
is probably of value, and promoting game devs to core devs is a way to accomplish this... |
| 13:39 |
erlehmann |
so deleting what you don't need is not good |
| 13:40 |
MTDiscord |
<Warr1024> code is a liability, and deleting what you don't need is not good ... okay, I think I missed the "liability is good" step there somewhere. |
| 13:40 |
erlehmann |
but deleting something that people rely on and creating a huge overhead for ppl who relied on it and breaking their worlds is not nice |
| 13:40 |
erlehmann |
Warr1024 ok sorry deleting what you don't need is good |
| 13:41 |
erlehmann |
the thing is, tga support is not really something that hurts anyone, ever. removing it makes lots of people unhappy *precisely* because mineclone2 and mineclone5 have such a bad track record with releases. |
| 13:42 |
erlehmann |
and even if they figure something out, they will have to have to carry a full tga decoder in lua forever |
| 13:42 |
erlehmann |
which is a bit of a stretch |
| 13:42 |
sfan5 |
if tga support never hurts anyone why does carrying a tga decoder in lua hurt anyone? |
| 13:42 |
MTDiscord |
<Warr1024> Every feature that continues to exist is a burden, so every feature is always on trial and always needs to continue to justify its existence. I think in the case of TGA, the justification existed but we don't have the infrastructure to easily hear that justification, so sometimes brandishing the axe is how that justification is elicited from the community. |
| 13:43 |
erlehmann |
sfan5 because it needs to be written, tested, run for each world forever. |
| 13:43 |
erlehmann |
basically multiple mods need to do the tga decoding themselves just to do a migration |
| 13:43 |
erlehmann |
the tga decoder in minetest though was there and worked |
| 13:43 |
erlehmann |
i absolutely hate it when ppl rip out support for something that worked for 10 years or so |
| 13:43 |
MTDiscord |
<Warr1024> If nobody is hurt and nobody is helped by TGA then that would mean TGA should get the axe. In this case, TGA DOES help someone so it can stay in for at least a little longer. Whether it should be gone in the long run requires weighing the costs and benefits, which themselves I imagine we could debate a lot. |
| 13:43 |
sfan5 |
that's more than "kept and run for each world forever" (the case of irrmt), reasonable |
| 13:44 |
erlehmann |
again: axing any format in use has the old-servers-new-clients problem |
| 13:44 |
MTDiscord |
<Warr1024> The way I understood it, we were hoping to provide a PNG encoder or something (IIRC one was necessary for other reasons already or something, so might as well make it available to modders) that could provide a sane upgrade path to replace TGA, and would also carry other benefits like reduced media size. |
| 13:45 |
sfan5 |
@Warr1024 BMP was always an alternative to TGA (in fact I have no idea why anyone would choose it over BMP), MCL just has a special problem because it keeps those TGA files around |
| 13:45 |
erlehmann |
more like mcl did not have a problem until someone pulled “tga is not used” out of thin air |
| 13:45 |
erlehmann |
“As long as people are okay with changes given proper notice” is the important thing from Warr1024 |
| 13:46 |
erlehmann |
like everyone fixed their texture alphas |
| 13:46 |
erlehmann |
bc minetest complains A LOT about it |
| 13:46 |
MTDiscord |
<Warr1024> Ah, okay, so it needs to persist the TGA files, it's not rebuilding them from some internal data? Well, that would make migration trickier, though probably still not impossible at least. |
| 13:46 |
sfan5 |
if it generated files at runtime it could switch to BMP right now and we would not be discussing it |
| 13:46 |
erlehmann |
Warr1024 it can not ever rebuild them, it is snapshots of the map from above at some point in time |
| 13:46 |
MTDiscord |
<Warr1024> Probably the better way to proceed would have been to make a PR that JUST adds deprecation notices. We could have had the debate about upgrade path then. |
| 13:47 |
MTDiscord |
<Warr1024> I don't think I've seen anyone do a deprecation-notice-only PR though, so it'd be a thing we would have to learn to do :-) |
| 13:47 |
erlehmann |
you both have not understand how map art works i guess. you click the map, you get a map with something like minetestmapper in small. |
| 13:47 |
erlehmann |
but for *that point in time* |
| 13:47 |
erlehmann |
everything else would be an info leak |
| 13:48 |
erlehmann |
also i believe some server operators may have replaced the tga files with other tga files to have posters, which is an even worse hack |
| 13:48 |
sfan5 |
you have a habit of insinuating that others have not understood what is being discussed |
| 13:48 |
MTDiscord |
<Warr1024> Yeah, so it decodes the existing TGA, draws pixels for the area you're mapping, and then writes back the new TGA. You'd need an upgrade path that involves decoding the old TGA and then writing a PNG or something, and it would have to be done unconditionally even if you're not updating the map. |
| 13:48 |
sfan5 |
speaking for me you have been consistently wrong |
| 13:48 |
erlehmann |
sfan5 probably because i myself do that |
| 13:48 |
erlehmann |
sfan5, ok i will try to be less dismissive, sorry |
| 13:49 |
MTDiscord |
<Warr1024> I mean, I'm familiar with MC maps, and while I don't know the specifics of MCL-family maps, I understand the theory, and using TGA itself as the persistence format makes some sense |
| 13:49 |
erlehmann |
Warr1024 and then you *still* have the problem that every minetest 5.5 client visiting a minetest server after 0.71 that does not have that hypothetical fix, can not see maps or use maps |
| 13:49 |
erlehmann |
i mean after mineclone2 0.71, which includes mineclone5 |
| 13:50 |
sfan5 |
upgrading textures isn't actually that bad but as pointed about above (^) this doesn't work in an "new client, old server" setup |
| 13:50 |
erlehmann |
seriously, there are a lot of hoops you can jump through, but in the end, tga files are as common as jpeg files |
| 13:50 |
erlehmann |
like, rare, but used |
| 13:50 |
sfan5 |
s/about/out/ |
| 13:50 |
MTDiscord |
<Warr1024> and tbh removing TGA support from MT would not require changing that storage format, even, since the reason TGA was chosen I assume is that it does not REQUIRE a fancy decoder and can be done easily in pure lua. It would only require that the TGA be written as PNG somewhere else before being sent to the client for display; TGA could still be used as the internal "database" format, which would also mean that it's still possible to |
| 13:50 |
MTDiscord |
roll back to old versions of MCL without your maps being broken by a one-way upgrade. |
| 13:50 |
MTDiscord |
<Sublayer plank> jpeg is used because it's got lossy compression as compared to png, making it useful for i.e. skyboxes |
| 13:50 |
MTDiscord |
<Warr1024> It would just require that (1) a sane usable PNG encoder is provided by the engine, and (2) MCL and derivatives need to have enough time to actually do the migration. |
| 13:51 |
MTDiscord |
<Sublayer plank> only reason tga was used for maps from what I can tell is because it's easy to write |
| 13:51 |
erlehmann |
i just meant if you deprecate stuff on “is it used” alone, tga and jpeg are equals |
| 13:52 |
erlehmann |
btw i am pretty sure fleckenstein won't do anything |
| 13:52 |
erlehmann |
it will just be broken if tga does not come back |
| 13:52 |
MTDiscord |
<Sublayer plank> he seems to wanna fork the engine anyways |
| 13:52 |
sfan5 |
right now we know but I bet if you asked a coredev a few months ago about TGA they'd say that they've never heard of a mod using it |
| 13:53 |
MTDiscord |
<Warr1024> Yeah, "is it used" by itself is kind of a lousy metric for whether something should be deprecated, since (1) being used is not necessarily the same as getting value from it, and (2) we have been historically overconfident in our ability to measure it, and we don't really have effective means to tell for certain. |
| 13:53 |
MTDiscord |
<Warr1024> We have to assume that anything that's supported might be in use, but not assume that something being supported or being in use is itself overwhelming justification that it shouldn't be deprecated anyway. |
| 13:56 |
erlehmann |
well i counted the filetypes in my cache folder |
| 13:56 |
erlehmann |
if you don't have tga in there you *probably* have never played mineclone2 or mineclone5 this year |
| 13:56 |
erlehmann |
(or played it in singleplayer and never had a map) |
| 13:57 |
erlehmann |
appguru made something to check stuff anyway https://gist.github.com/appgurueu/6b99957fd597d0528080c9c457bdc877 |
| 13:57 |
erlehmann |
doesn't use libmagic, but maybe it gives insights |
| 13:58 |
MTDiscord |
<Warr1024> Even if we didn't deprecate TGA for other reasons, I think there could be at least some value in providing a mod API for writing a PNG file from an array of some kind, and there's a way for mineclone(s) to use that API to make media more efficient and save bandwidth. |
| 14:01 |
celeron55 |
i have 44k cache files and none of them are TGA |
| 14:01 |
sfan5 |
the api for writing a PNG file already exists fyi |
| 14:03 |
erlehmann |
Warr1024 mineclone2 will probably never “save bandwith”, we forked mineclonia from it because of stuff like that |
| 14:03 |
MTDiscord |
<Warr1024> Awesome, given that the PNG API exists, it would probably benefit mineclon{e|ia} to look into using it for the media send and see if it's feasible and improves network efficiency... |
| 14:04 |
erlehmann |
i find all of this deeply concerning |
| 14:04 |
MTDiscord |
<Warr1024> Heh, well, that's sorta their problem then, from your perspective :-) |
| 14:04 |
MTDiscord |
<Warr1024> You can only lead by example after all |
| 14:05 |
erlehmann |
Warr1024 well i *kinda* want ppl to have an upgrade path for mineclone2 to mineclonia so it is very much my problem too sooner or later |
| 14:06 |
MTDiscord |
<Warr1024> If TGA were deprecated it wouldn't mean you can't use TGA files, it would just mean that you wouldn't be able to display them to the client directly. I'm just saying that (1) there's a way to work around that, and (2) that "workaround" actually has more benefit in itself, so it might be worth pursuing even if TGA support in engine is NOT deprecated. |
| 14:07 |
erlehmann |
anyways, i hope “ripping out a non-deprecated thing without warning, in a minor release, without having consulted game devs or server owners or players who rely on it should not have happened” is hopefully a statement most of you agree? |
| 14:07 |
erlehmann |
i mean i don't get why the alpha thing had warnings and all that |
| 14:08 |
sfan5 |
depends on the "thing" |
| 14:08 |
erlehmann |
or maybe there was a policy change |
| 14:08 |
erlehmann |
ok i guess client-sent server mods were never deprecated. but they were also never really announced as a feature. |
| 14:08 |
sfan5 |
funny |
| 14:09 |
rubenwardy |
<erlehmann> yeah i probably don't want to add much features, wuzzy already tries so hard and it takes ages before they are reviewed. |
| 14:09 |
rubenwardy |
as a core dev, you would only need one other reviewer so things get merged quicker |
| 14:09 |
erlehmann |
i am entirely serious |
| 14:09 |
rubenwardy |
I'm generally against people becoming core devs if they haven't already contributed much |
| 14:10 |
rubenwardy |
although contributing to forks should count |
| 14:10 |
erlehmann |
i have contributed stuff, it is just a long time ago |
| 14:10 |
erlehmann |
do git log |
| 14:10 |
erlehmann |
and scroll to the bottom |
| 14:10 |
erlehmann |
i made the 3d clouds, for example |
| 14:10 |
erlehmann |
granted, that's not magic |
| 14:10 |
sfan5 |
erlehmann: if that is so I'm willing to hear a straight, complete explanation of whatever you are referring to by that |
| 14:11 |
rubenwardy |
yeah, improving performance would be good |
| 14:11 |
erlehmann |
i just want performance not regressing |
| 14:13 |
erlehmann |
sfan5 i do *not* have a working exploit if you are asking me that |
| 14:14 |
erlehmann |
so i can not explain, sorry |
| 14:14 |
erlehmann |
i can try to work on one though |
| 14:14 |
erlehmann |
but i think it would be better to have one for 5.5 ready |
| 14:15 |
MTDiscord |
<Warr1024> I've seen some people pushing to "modernize" which would necessarily mean dropping support for older hardware in order to take advantage of newer tech, and frankly I'm pretty torn about it. I don't think it's reasonable to expect MT to never use newer features, and even to degrade its performance on newer tech, just to keep supporting old hardware no matter how old it gets. I would like to be very cautious though about pushing |
| 14:15 |
MTDiscord |
forward, and the fact that I mostly use systems in the 5 to 15 year old range, which many consider very old, colors my perspective :-| |
| 14:15 |
erlehmann |
or whatever version actually enables server-sent client mods (just send a mod back if someone sends me one) |
| 14:16 |
MTDiscord |
<josiah_wi> I think one of the cool aspects of Minetest is that it runs on old hardware. And it effects me because I almost always use secondhand devices some of which are potatoes. |
| 14:16 |
MTDiscord |
<Warr1024> I'm okay with requiring caution, warnings, deprecation periods and procedures, etc. as long as MT can always move forward. Whatever we do needs to at least not kill innovation. |
| 14:17 |
rubenwardy |
the thing is that even 10 year old computers support OpenGL 2+ |
| 14:17 |
erlehmann |
Warr1024 i think the main problem with people who insist that “modernizing” implies “dropping support for older hardware” is that people who are moderately bad at software architecture are rarely able or willing to put in the work that makes both ways work. |
| 14:17 |
MTDiscord |
<Warr1024> re: second-hand hardware: I don't think I buy non-refurbs or non-used hardware anymore. Fancy high-end brand-new just doesn't feel cost effective enough for me anymore. |
| 14:18 |
sfan5 |
erlehmann: that is neither straight, nor complete nor an explanation |
| 14:18 |
rubenwardy |
10 year old hardware was modern hardware when Minetest was created |
| 14:18 |
erlehmann |
yes |
| 14:18 |
erlehmann |
the average programmer will just rip out X and replace it with Y, without putting in a proper abstraction layer |
| 14:18 |
erlehmann |
thus making it impossible to support both old and new |
| 14:19 |
MTDiscord |
<Warr1024> erlehmann, you said it yourself, code is a burden. Supporting arbitrarily old computers requires code to use older OGL versions, and code to tell which version of the supporting code to use, and compat hacks to emulate or gracefully degrade every new feature on older systems. Eventually there comes a point where few enough of those old systems are surviving and in use that it doesn't make sense to keep supporting. |
| 14:19 |
MTDiscord |
<josiah_wi> Warr: I'm talking that old computer your relative thinks is dead so they give it to you and you chuck a Linux CD at it and brrrr |
| 14:19 |
erlehmann |
good ones are like jwz, who has kept really old screensavers running and even did this strange openGL ES port for the iphone |
| 14:20 |
erlehmann |
Warr1024 look i have a system in front of me that hecktest wants to desperately make unable to run minetest. i am willing to put in work. |
| 14:20 |
sfan5 |
are you willing to write a fixed pipeline rendering driver? "just keep the old code" won't cut it |
| 14:20 |
MTDiscord |
<Warr1024> josiah: yeah, I buy refurbs for my "flagship" machines but I still get "dead -> linux CD -> brrrr" machines from family sometimes, and add them to the fleet :-) I don't think I'd run MT clients on most of them, though some can make decent servers... |
| 14:21 |
erlehmann |
sfan5, why will “keep the old code” not cut it? |
| 14:21 |
MTDiscord |
<Sublayer plank> because all that code is being scrapped, I guess |
| 14:21 |
sfan5 |
we have to rewrite things to fix longstanding issus and make new things work |
| 14:21 |
sfan5 |
+e |
| 14:22 |
erlehmann |
lol “you can't keep it because we put it in the trash, without a suitable replacement” |
| 14:22 |
rubenwardy |
Because the old code is irrlicht and that sucks |
| 14:23 |
MTDiscord |
<Warr1024> Modern rendering is all shader-based and whatnot, it all changed since I learned anything about 3D. As I understand it when you use a fixed pipeline, newer hardware is already doing some hacks to emulate that. Eventually it will make a lot of sense to flip that around, and make the modern paradigm our baseline and throw in compat hacks for the older hardware. At that time, the older hardware could be made to technically run but its |
| 14:23 |
MTDiscord |
experience would probably be degraded in some way, either in performance or accuracy or both... I don't think that's avoidable indefinitely though. |
| 14:23 |
erlehmann |
look you have an abstract world model, that should be rendered with different ways. i don't really *get* it why it would not be abstracted away in the way a potato can render it and also a wearable fridge. |
| 14:24 |
erlehmann |
like if you do it shader based, fine, but then abstract the meaning away from it please. like night vision, can be done with shader, can be done differently. |
| 14:24 |
erlehmann |
i get the impression what is planned is that the shader model will be so tightly coupled that it will be impossible to do it otherwise |
| 14:25 |
sfan5 |
your suggestion equates to "keep all the irrlicht using code and irrlicht itself and then add a new render that can be switched on additionally" |
| 14:25 |
sfan5 |
which would essentially result in maintain two minetest clients at once |
| 14:25 |
sfan5 |
maintaining* |
| 14:25 |
MTDiscord |
<Warr1024> Abstraction does come at a cost and it's not actually practical to plan abstractions out ahead of time. I've found it paralyzing, and given limited time and effort, often the only practical way forward is to build things concrete and sloppy at first and then add abstraction later once you find common patterns to abstract out. |
| 14:25 |
MTDiscord |
<josiah_wi> Git exists. As long as networking compat between versions is maintained it's not like people will be forced to upgrade to the newer, maybe slower version right away. |
| 14:26 |
MTDiscord |
<Warr1024> Maintaining 2 minetest clients at once is already possible via a fork. If the time comes, it may be necessary to consider that as the best option. Trying to maintain 2 forks of MT inside a single src tree would be a lot less sane than just letting the split happen. |
| 14:27 |
erlehmann |
it would be a lot more sane in my opinion to have 2 clients in one repo. lots of games have that. |
| 14:27 |
MTDiscord |
<Warr1024> josiah: yeah, same thing, really. The difference between a fork and a branch is irrelevant to the software, we humans are the only ones who attach special meaning to it... |
| 14:27 |
erlehmann |
think of roguelikes who often have a tile version and a terminal one |
| 14:27 |
sfan5 |
yes, that is what about to say next: suppose someone wants to maintain such a fork that uses the old irrlicht forever it's much saner to do so in a fork |
| 14:28 |
MTDiscord |
<luatic> erlehmann: please don't run my script, it apparently kills CDB |
| 14:28 |
|
rubenwardy joined #minetest-dev |
| 14:28 |
sfan5 |
poor rubenwardy |
| 14:28 |
MTDiscord |
<luatic> Just change it to only scan the newest release and it should be fine |
| 14:28 |
erlehmann |
oh lol |
| 14:28 |
erlehmann |
i won't run it anyway, you are already running it right? |
| 14:28 |
MTDiscord |
<Warr1024> It's entirely possible that MT actually ends up as the "maintain old forever" fork and some other fork comes along with the modernization thing, and the community starts to shift over to the modern alternative, and a lot of this is taken out of our hands anyway. Just because no fork in the past has reached that critical mass doesn't mean it could never happen. |
| 14:28 |
|
rubenwardy joined #minetest-dev |
| 14:29 |
MTDiscord |
<luatic> I was, but then it died as CDB died |
| 14:29 |
MTDiscord |
<Warr1024> luatic: if you want to be technically accurate, scan the newest release grouped by max version |
| 14:29 |
MTDiscord |
<luatic> alright, back on track, only scanning the newest release this time |
| 14:30 |
MTDiscord |
<Warr1024> er, min version |
| 14:38 |
|
Fixer joined #minetest-dev |
| 14:39 |
|
twoelk joined #minetest-dev |
| 14:40 |
sfan5 |
merging #11550 in 10m |
| 14:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/11550 -- Dynamic_Add_Media v2 by sfan5 |
| 14:47 |
|
Alias joined #minetest-dev |
| 15:00 |
|
Desour joined #minetest-dev |
| 15:12 |
|
proller joined #minetest-dev |
| 15:22 |
twoelk |
regarding the old supported file formats. The files mentioned in the wiki as accepted by the mt-engine were white-listed in server.ccp and as thus thought to be official though not all documented in the lua_api.txt by name. The pre July 22th wiki page made clear mt accepted only a subset of the file formats irrlicht could support. |
| 15:36 |
erlehmann |
I get it, the plans were on display, in the cellar, in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “beware of the leopard” and that maks it okay! |
| 15:37 |
sfan5 |
a dev version doing something is not the end of the world, you know |
| 15:38 |
erlehmann |
i just looked it up https://wiki.minetest.net/Creating_texture_packs#Creating_Textures |
| 15:39 |
erlehmann |
> The minetest engine does not make use of all formats Irrlicht could use. The server only accepts the following file formats for graphics: .png .jpg .bmp .tga .pcx .ppm .psd .wal .rgb |
| 15:39 |
erlehmann |
i have no idea what .wal and .rgb even are lol |
| 15:40 |
MTDiscord |
<luatic> .rgb is a primitive format like .tga |
| 15:41 |
jonadab |
.tga is probably Targa? Man, there's a graphics format I haven't heard about any time recently. I remember having software that supported it back in the DOS 5 era. |
| 15:41 |
MTDiscord |
<Warr1024> Ironically our sound format support is ... what, like ogg vorbis only? |
| 15:42 |
MTDiscord |
<Noodlemire> That's what I remember hearing (heh) before. |
| 15:42 |
|
olliy joined #minetest-dev |
| 15:42 |
jonadab |
Besides Vorbis, the only other sound format that you'd *want* to support, is flac. |
| 15:42 |
rubenwardy |
mp3 was patent protected until recently |
| 15:42 |
MTDiscord |
<Warr1024> I'd actually want to upgrade to opus |
| 15:42 |
rubenwardy |
don't we support wav? |
| 15:42 |
jonadab |
wav would be easy to support, but wav files are gratuitously large; flac is strictly better. |
| 15:42 |
MTDiscord |
<Warr1024> Not sure if wav support is even worth thinking about :-D |
| 15:43 |
MTDiscord |
<Warr1024> flac is a strictly better alternative to wav, and opus would be the best option on the lossy side |
| 15:43 |
jonadab |
I've not heard of opus as a sound format before. Is it new? |
| 15:43 |
erlehmann |
not particularly |
| 15:44 |
MTDiscord |
<Warr1024> I would really like to add more sound diversity to my game in the future, but the impact of the audio file format's efficiency makes me wary of increasing the media size more. |
| 15:44 |
erlehmann |
https://en.wikipedia.org/wiki/Opus_(audio_format) |
| 15:44 |
erlehmann |
> Initial releaseSeptember 11, 2012 |
| 15:44 |
twoelk |
oops, my statement might be misunderstood. Thought to be official by wiki-editors such as me :-) |
| 15:45 |
erlehmann |
https://en.wikipedia.org/wiki/Opus_(audio_format)#Quality_comparison_and_low-latency_performance |
| 15:45 |
erlehmann |
twoelk what exactly did you want to say though? |
| 15:46 |
MTDiscord |
<Warr1024> If someone uses a media format that's deprecated it shouldn't be too hard to throw a warning for it in the server logs. I know that I actually check those when I test against a new release, so that would be a reasonable way to get the word out. |
| 15:47 |
jonadab |
.bmp should definitely be deprecated, there is no legit reason to use it at this point, even MS Paint has supported PNG for a while. |
| 15:47 |
jonadab |
pcx and ppm are even older. |
| 15:47 |
erlehmann |
oh my |
| 15:48 |
jonadab |
There's an argument for .psd, but then you'd also want .xcf for the same reason, and probably .xcf.gz, .xcf.bz2, and so on. |
| 15:48 |
erlehmann |
even hecktest, slayer of file formats, left bmp in |
| 15:48 |
jonadab |
Honestly, I think .psd and .xcf should be considered _source_ formats, and for actual use, export a .png. |
| 15:48 |
erlehmann |
jonadab are your comments just some opinion or are there mods that use psd textures? |
| 15:48 |
jonadab |
erlehmann: NOt that I'm aware of. |
| 15:49 |
jonadab |
The argument in favor of the format would be, it supports layers and such, which formats like .png do not. |
| 15:49 |
jonadab |
But again, I think I'd consider it a source format, and tell people to export a .png for actual use. |
| 15:49 |
erlehmann |
jonadab i think this round of file format support dance is only slashing as much as possible |
| 15:50 |
jonadab |
Also, deprecating a format is not the same thing as outright removing existing support for it. |
| 15:50 |
erlehmann |
we will know about file formats at some point whe appguru script has run its course |
| 15:50 |
erlehmann |
jonadab i think if it was deprecated i would not have flipped my shit about it |
| 15:51 |
erlehmann |
i would still have thought it was an insane and dangerous idea |
| 15:51 |
jonadab |
The recommendation should be to use .png, IMO |
| 15:51 |
erlehmann |
well, provide an upgrade path for the stuff out there |
| 15:51 |
|
Extex joined #minetest-dev |
| 15:51 |
erlehmann |
spoiler: good luck |
| 15:52 |
jonadab |
Upgrade path? Are there image editors in widespread use that don't support .png at this point? |
| 15:52 |
twoelk |
erlemann, ehm, just wanted to state wiki info was not rouge but researched - not really important anymore just a little annoyed |
| 15:53 |
sfan5 |
jonadab: BMP has a point for dynamically writing textures from mods since it's so simple |
| 15:54 |
sfan5 |
ofc we have a PNG encoder API now but before that BMP was a reasonable choice (yet mineclone chose tga...) |
| 15:54 |
erlehmann |
if only there were mods that wrot textures dynamically, like tga |
| 15:54 |
erlehmann |
look i am not defending mineclone2 choices here |
| 15:54 |
rubenwardy |
lol, Irrlicht supported photoshop files?! |
| 15:54 |
jonadab |
sfan5: Ah, I was not aware that mods could generate textures dynamically; that's a whole different kettle of fish then. |
| 15:54 |
rubenwardy |
there's no way that's still valid |
| 15:54 |
MTDiscord |
<Warr1024> I believe the reason BMP was left in was specifically as an alternative to TGA, i.e. one of the few file formats that supports uncompressed images and has a file format you could write the spec for on the back of a napkin |
| 15:55 |
erlehmann |
i am advocating for the users who do not deserve to have their work undone because some ppl have a grudge against file formats |
| 15:55 |
* twoelk |
thinks bmp just like ascii-text should always be supported as a fallback of sorts |
| 15:55 |
sfan5 |
the reason BMP was left in is because Irrlicht internally uses it |
| 15:55 |
erlehmann |
i believe the reason bmp was left in because some stuff does not work without it |
| 15:55 |
sfan5 |
but I would have advocated for keeping a single simple & uncompressed format anyway |
| 15:55 |
jonadab |
Ok, I can see that. |
| 15:56 |
erlehmann |
twoelk, well the wiki was accurate before hecktest removed a lot of stuff recently |
| 15:56 |
erlehmann |
accurate as in: the code suggested it would work |
| 15:56 |
|
proller joined #minetest-dev |
| 15:56 |
erlehmann |
and mod devs do read the code to figure out what does work |
| 15:57 |
twoelk |
yep, will need to add back in the reference to source info of where to find stuff |
| 15:58 |
twoelk |
hecks did update the blender page in the wiki but missed other plages |
| 15:58 |
twoelk |
-l |
| 15:58 |
erlehmann |
well it doesn't really matter you know |
| 15:58 |
twoelk |
sniff - but but the wiki should matter |
| 15:59 |
erlehmann |
nah, what i mean: if something works for years explicitly coded in then the thing that matters is not if you “support” it (lol) but if it is used or not. |
| 15:59 |
MTDiscord |
<Warr1024> Minetest: the engine that cannot correct the mistakes of the past because somebody is still using them. |
| 16:00 |
MTDiscord |
<Jonathon> the wiki is general is outdated, so easier to not rely on it for anything |
| 16:00 |
MTDiscord |
<Warr1024> The wiki asymptotically approaches reliable. |
| 16:02 |
twoelk |
editor-time just as dev-time so rare these days |
| 16:02 |
erlehmann |
i bet some ppl had more dev time if it was not tolerated to ruin other ppls stuff |
| 16:02 |
erlehmann |
but i guess that ship sailed at some point (when was the backwards compat policy actually changed btw?) |
| 16:03 |
MTDiscord |
<Noodlemire> I feel like if there was any interest (and that interest wasn't smothered by big red labels of DO NOT USE THIS!!!) it wouldn't be that hard to keep the wiki updated with each release. |
| 16:03 |
erlehmann |
Warr1024 the linux kernel does not break userspace and magically still gets release |
| 16:04 |
MTDiscord |
<Jonathon> and cough wuzzy cough active discouraging contributions to certain parts of the wiki |
| 16:04 |
erlehmann |
Warr1024 does it mean it can not “correct the mistaks of th past” ? |
| 16:04 |
erlehmann |
> active discouraging contributions |
| 16:04 |
erlehmann |
what |
| 16:04 |
erlehmann |
explain pls |
| 16:04 |
MTDiscord |
<Jonathon> if your not going to keep it, delete it |
| 16:04 |
MTDiscord |
<Jonathon> else dont keep it in a state of flux |
| 16:05 |
MTDiscord |
<Jonathon> wuzzy discourages contributions to dev wiki |
| 16:05 |
MTDiscord |
<Jonathon> or at least a few months ago |
| 16:06 |
MTDiscord |
<Warr1024> It does seem weird that we have a wiki that's often perceived as stuck in a state of brokenness, neither being fixed, nor fully deprecated. The API info that's on there is like an amalgamation of snapshots in time of subsets of stuff... |
| 16:06 |
twoelk |
do keep in mind though this all was triggered by the frustration that irrlicht was somewhat unmaintained. so it was forked and to make more easy to manage was reduced to the things mt actually uses. |
| 16:06 |
MTDiscord |
<Jonathon> anyways, kinda suprised no one has told us to go to minetest-irc |
| 16:07 |
rubenwardy |
erlehmann: with 5.0, the API should not break without a major release. This includes things documented in the Lua API |
| 16:07 |
MTDiscord |
<Jonathon> well, #minetest for the irc/matrix folk |
| 16:07 |
rubenwardy |
supported formats isn't documented at all, which makes it a grey area |
| 16:07 |
MTDiscord |
<Warr1024> what constitutes "API" has proven to be nebulous though |
| 16:07 |
rubenwardy |
TGA should probably be readded though |
| 16:07 |
rubenwardy |
yeah, "API" isn't well defined |
| 16:07 |
rubenwardy |
as there's lots of room to break mods without breaking the "API" |
| 16:07 |
rubenwardy |
because of undefined behaviour |
| 16:07 |
erlehmann |
“it is not documented, but pretty obviuously mentiond in the forum and the wiki” |
| 16:08 |
MTDiscord |
<Warr1024> by "API" it seems like the general meaning is "functions and their parameters" but it doesn't include things like knowing for certain whether a specific bug workaround is needed. That latter thing, we have plans to at least improve, but it's also a bit in the air atm. |
| 16:08 |
MTDiscord |
<Jonathon> the problem with erlehmanns statement is thats literally impossible to define |
| 16:08 |
erlehmann |
i think breaking mods should be reserved for actually improving behaviour. not “just because”. |
| 16:08 |
rubenwardy |
reducing the size of irrlicht does improve behaviour, it makes it more maintainable and allows removing it completely in the future |
| 16:09 |
erlehmann |
well |
| 16:09 |
erlehmann |
the thing is |
| 16:09 |
rubenwardy |
unfortunately, some used formats fell victim |
| 16:09 |
MTDiscord |
<Jonathon> ^rubens statement |
| 16:09 |
MTDiscord |
<Warr1024> The "behavior" of the project encompasses more than just what the compiled software does at runtime |
| 16:09 |
MTDiscord |
<Jonathon> correct me if im wrong, but isnt mineclone2 maps in the dev version still, not a stable version? |
| 16:10 |
erlehmann |
Jonathon you can go to contentdb and download mineclone5 and make a map. or not, if you have a new enough version, lol. |
| 16:10 |
MTDiscord |
<Warr1024> I'm pretty sure we agreed that removing TGA the way it was done was a mistake already, though? It's just that I disagree with the statement/implication that removing TGA at all is incorrect, or that there aren't other things we can and should remove. |
| 16:10 |
MTDiscord |
<Jonathon> that is not what i asked |
| 16:10 |
MTDiscord |
<Warr1024> the minecloniverse is more than just mineclone2... |
| 16:10 |
MTDiscord |
<Jonathon> i explicitly asked about mineclone2 |
| 16:11 |
erlehmann |
let me look |
| 16:11 |
MTDiscord |
<Jonathon> and so far everyone has given an answer for anything but that |
| 16:11 |
MTDiscord |
<Jonathon> thanks |
| 16:12 |
MTDiscord |
<Warr1024> Look, my workflow works for me, just add spacebar heating back, okay? |
| 16:12 |
MTDiscord |
<luatic> Stop with this stupid example |
| 16:13 |
erlehmann |
yeah the spacebar heating thing is stupid, why would i have to press a key for that even |
| 16:13 |
MTDiscord |
<luatic> First of all, there's an actual reason those file formats are used: Either they are primitive and thus simple to generate, or they have features the other file formats do not |
| 16:13 |
MTDiscord |
<luatic> The first one is the case for TGA; this was just recently made kinda unneeded by the introduction of the PNG writer |
| 16:14 |
MTDiscord |
<luatic> The second one is the case for MD2; I'm not sure anyone uses it, but I'd sure like to try generating some fancy vertex animations |
| 16:15 |
MTDiscord |
<Jonathon> Seems if anything someone should just make a tga reader to input into the png encoder |
| 16:15 |
MTDiscord |
<Warr1024> Pretty sure MCL already has to have a TGA reader because they don't just generate them, they update them |
| 16:15 |
MTDiscord |
<luatic> Removing MD2 means removing an actual feature, not just a "redundant" file format. Hecks themselves noted that. Why? |
| 16:15 |
MTDiscord |
<Sublayer plank> pretty sure they don't have a reader |
| 16:15 |
erlehmann |
Jonathon i can not find a newer release than mineclone2 0.71 on the contentdb, but the “dirty secret” is that mineclone2. 0.71 is so laggy due to a rushed release that people often use mineclone2 git HEAD, mineclonia or mineclone5. |
| 16:15 |
MTDiscord |
<Warr1024> So yeah, with the PNG encoding feature, TGA is already moot, because there's no sane reason to continue to rely on the client supporting it even if it does. |
| 16:16 |
MTDiscord |
<luatic> There is: Older servers don't have said feature. |
| 16:16 |
erlehmann |
there are still 5.3 servers online |
| 16:16 |
MTDiscord |
<Jonathon> Minetest generally requires you to have a new server for new features, while supporting old clients |
| 16:17 |
MTDiscord |
<Jonathon> See the alpha change and all the mods that updated |
| 16:17 |
MTDiscord |
<Jonathon> See entities that use collision on step data |
| 16:17 |
|
lojosls joined #minetest-dev |
| 16:17 |
MTDiscord |
<luatic> Yeah but this way new clients will shit on old servers supplying them with TGA files because they can't properly generate PNGs |
| 16:17 |
erlehmann |
has it ever happened before that a *new* client could not see a texture on an *old* server? |
| 16:17 |
erlehmann |
bc i can't ever remember that |
| 16:18 |
MTDiscord |
<luatic> This is just a mess all around, we'll see the scale of it after I get to analysing file extensions |
| 16:18 |
erlehmann |
but i had a big gap in minetest playing/dev |
| 16:18 |
MTDiscord |
<Jonathon> Tga isnt in the latest release of mineclone2, in the top of cdb, the forks are the issue |
| 16:18 |
MTDiscord |
<Warr1024> "It's never happened before" is a pretty thin argument for "it should never happen" |
| 16:18 |
twoelk |
the player offset is the only client server version conflict I remember |
| 16:18 |
MTDiscord |
<Jonathon> What warr said |
| 16:19 |
erlehmann |
i did not make an argument, i wondered if this happened before |
| 16:19 |
MTDiscord |
<Warr1024> Luatic: a problem with analyzing file extensions might be that you'll have a hard time catching all actual use of TGA since MCL already generates them dynamically... but at least it will give us a good "best case" |
| 16:19 |
erlehmann |
Jonathon i already told you ppl usually do not run the mineclone2 on contentdb. |
| 16:19 |
MTDiscord |
<luatic> Yeah, OFC I can't catch dynamic generation. |
| 16:20 |
MTDiscord |
<Warr1024> I'm pretty sure there are cases where servers have been unable to support both old and new clients smoothly due to breaking changes, especially in those "slip through the cracks" cases like when a bug actually gets fixed, but that breaks the workaround people have been using. |
| 16:20 |
erlehmann |
in my cache, being on 2 mineclone5 servers alone is probably the reason why there are so many map TGAs |
| 16:20 |
erlehmann |
it's a pretty well-liked feature |
| 16:20 |
erlehmann |
i guess very few ppl here play those mods though |
| 16:20 |
erlehmann |
otherwise they would have known about it months ago |
| 16:21 |
erlehmann |
mineclone5 was a branch of mineclone2 btw |
| 16:22 |
MTDiscord |
<luatic> I guess very few people have figured out how to compile MT 5.5-dev :P |
| 16:22 |
erlehmann |
until it got its own release bc it's not EXACTLY LIKE MINECRAFT 1.12 |
| 16:22 |
erlehmann |
luatic that also |
| 16:22 |
erlehmann |
it's a bit weird i mean |
| 16:22 |
erlehmann |
i guess there will be a bunch of more breakage being reported in the future |
| 16:22 |
erlehmann |
once there is a proper release with stuff removed |
| 16:22 |
erlehmann |
no idea what it would be though |
| 16:23 |
erlehmann |
i mean i am on the same page as you largely, “wait, *THAT* format was supported?” |
| 16:24 |
MTDiscord |
<luatic> I am on board with the removal of redundant formats. I don't like the removal of features. And I don't like breaking compat in a minor release. |
| 16:25 |
erlehmann |
so about the thing that reminds me of mineclone2 here |
| 16:25 |
erlehmann |
they wanted newer mods, but instead of making a clean improvement |
| 16:25 |
erlehmann |
they first ruined the API |
| 16:26 |
erlehmann |
jordan4ibanez tried to improve them one by one |
| 16:26 |
erlehmann |
and in the end they would have been better |
| 16:26 |
erlehmann |
but his idea was “first remove the stuff that *will be useless*, then build something new” |
| 16:26 |
erlehmann |
on master |
| 16:27 |
erlehmann |
let's say it was also a factor in the mineclonia forking decision |
| 16:27 |
erlehmann |
bc jordan kinda lost motivation halfway through |
| 16:31 |
MTDiscord |
<Jonathon> so we have descended to erlehmann ranting about mineclone2 again |
| 16:31 |
erlehmann |
i shall stop with that |
| 16:32 |
erlehmann |
Jonathon thanks for calling me out |
| 16:32 |
erlehmann |
luatic i am really interested in if md2 is used |
| 16:33 |
erlehmann |
luatic any estimate when your analysis will be done? or is contentdb still easily taken down? |
| 16:38 |
MTDiscord |
<luatic> my analysis will probably be done in an hour |
| 16:38 |
MTDiscord |
<luatic> ruben has provided me with a full tar |
| 16:38 |
twoelk |
is adding the glTF format still a thing? |
| 16:39 |
MTDiscord |
<luatic> the download just finished |
| 16:39 |
MTDiscord |
<luatic> now I'll wait 20 min to unpack it |
| 16:39 |
MTDiscord |
<luatic> and after that I'll get to the analysis |
| 16:39 |
MTDiscord |
<Sublayer plank> twoelk: yeah, sometime soon™️ |
| 16:41 |
erlehmann |
luatic, how big is the tarball? |
| 16:41 |
MTDiscord |
<Sublayer plank> 24GB something |
| 16:42 |
* twoelk |
wanders off to tinker some more on his cobblecastle |
| 16:45 |
MTDiscord |
<Jonathon> btw rubenwardy or sfan5 is there a reason https://github.com/minetest/minetest/pull/10324 has two approvals but has not been merged yet? |
| 16:45 |
sfan5 |
we plan to frame it and keep it on a wall in the Minetest office for decorative purpoes |
| 16:46 |
sfan5 |
(no there is not) |
| 16:46 |
MTDiscord |
<Sublayer plank> wait there's a minetest office? :P |
| 16:46 |
MTDiscord |
<Jonathon> lol ? |
| 16:46 |
MTDiscord |
<Jonathon> its probably buried in the minetest-hub center somewhere |
| 16:47 |
erlehmann |
oh i may have found another file format issue, let me check |
| 16:48 |
erlehmann |
so in builtin/settingtypes.txt and minetest.conf.example … |
| 16:48 |
erlehmann |
screenshot_format (Screenshot format) enum png png,jpg,bmp,pcx,ppm,tga |
| 16:48 |
erlehmann |
have fun fixing that |
| 16:48 |
MTDiscord |
<Sublayer plank> yeah... that's been there for a while now |
| 16:49 |
erlehmann |
yeah but if the encoders are removed, what *exactly* happens then? |
| 16:49 |
MTDiscord |
<Jonathon> seems thats a minor 2 line change |
| 16:49 |
MTDiscord |
<Sublayer plank> there's also https://github.com/minetest/minetest/blob/master/src/client/client.cpp#L673 |
| 16:49 |
MTDiscord |
<Jonathon> for documentation at least |
| 16:49 |
MTDiscord |
<Sublayer plank> if you try to screenshot with a removed image format it'll just create an empty file |
| 16:50 |
erlehmann |
that is not very nice |
| 16:53 |
erlehmann |
in fact, i'd say changing “making a screenshot” to “not making a screenshot” sounds like a bug |
| 16:53 |
MTDiscord |
<Sublayer plank> yeah it's a bug |
| 16:53 |
MTDiscord |
<Sublayer plank> albeit an extremely minor one, which was why I didn't feel like going through the hoops for reporting or fixing it |
| 16:54 |
erlehmann |
i mean, i don't particularly care, but it's another piece of evidence for “the file format massacre was at the same time too much and not thorough *enough*” ;) |
| 16:56 |
|
longerstaff13 joined #minetest-dev |
| 16:59 |
twoelk |
the fileformat massacre may have been somewhat hurried but it generated a new reviewer so we get a gain |
| 17:09 |
MTDiscord |
<luatic> erlehmann: https://gist.github.com/appgurueu/63ffccbdd72c18506dc22d5206394de1 |
| 17:09 |
MTDiscord |
<luatic> There even seem to be dae files |
| 17:09 |
MTDiscord |
<luatic> No md2 though |
| 17:10 |
erlehmann |
what is dae? |
| 17:10 |
MTDiscord |
<Sublayer plank> collada model format |
| 17:10 |
MTDiscord |
<Sublayer plank> which... uh, minetest/irrlicht has never supported as far as I'm aware |
| 17:10 |
MTDiscord |
<Jordach> GLTF before GLTF |
| 17:11 |
MTDiscord |
<luatic> phenom: that is wrong |
| 17:11 |
MTDiscord |
<luatic> Irrlicht supports it for static meshes at least |
| 17:11 |
MTDiscord |
<luatic> And IIRC MT does too... |
| 17:11 |
MTDiscord |
<Sublayer plank> oh |
| 17:13 |
erlehmann |
twoelk don't worry too much about me getting anything done, if someone removes the code that makes minetest actually able to run on my machine, i'm gone again! |
| 17:13 |
erlehmann |
luatic lol, there are more .dae than .x files |
| 17:14 |
rubenwardy |
huh lol nbe 19040 |
| 17:14 |
rubenwardy |
(nbe = NodeBoxEditor) |
| 17:14 |
MTDiscord |
<luatic> it's all releases, not just the last release |
| 17:14 |
twoelk |
mt did not support collada but irrlicht did |
| 17:15 |
twoelk |
collada may have been used as import format for blender though |
| 17:16 |
MTDiscord |
<luatic> PSD used to be supported, right? |
| 17:16 |
MTDiscord |
<luatic> Because that shows a couple uses too: https://gist.github.com/appgurueu/63ffccbdd72c18506dc22d5206394de1#file-file_exts_cdb-txt-L162 |
| 17:16 |
erlehmann |
> psd575 |
| 17:16 |
twoelk |
https://wiki.minetest.net/index.php?title=Using_Blender&oldid=26350 befor the file formats where thined out |
| 17:16 |
MTDiscord |
<Sublayer plank> pretty sure most of those are for source image files |
| 17:17 |
MTDiscord |
<Sublayer plank> like, psd is photoshop's non-destructive save option |
| 17:17 |
MTDiscord |
<Sublayer plank> similar to xcf for gimp and pdn for paint.net |
| 17:17 |
erlehmann |
pretty sure you are trash talking available evidence |
| 17:17 |
erlehmann |
do you have any proof that they are not directly loaded? |
| 17:19 |
MTDiscord |
<luatic> wait, I'll extend my thingy to tell me where they are |
| 17:21 |
erlehmann |
the mod name would be good maybe |
| 17:31 |
rubenwardy |
found LMD's mods https://gist.github.com/appgurueu/63ffccbdd72c18506dc22d5206394de1#file-file_exts_cdb-txt-L175 |
| 17:31 |
rubenwardy |
(luatic=LMD) |
| 17:32 |
MTDiscord |
<luatic> phenom: it looks like you were right |
| 17:32 |
MTDiscord |
<luatic> Good Morning Craft, powerrangers_modpack and Pixel Perfection use PSDs the way you described |
| 17:33 |
MTDiscord |
<Sublayer plank> yeah |
| 17:33 |
MTDiscord |
<luatic> So that does indeed narrow actual issues down to TGA I guess. Still kinda sad about the loss of MD2... |
| 17:33 |
MTDiscord |
<GreenXenith> >mcmeta |
| 17:33 |
MTDiscord |
<GreenXenith> wat |
| 17:33 |
MTDiscord |
<Jordach> Yeah wat |
| 17:34 |
erlehmann |
i am concerned about mods delivering .so and .jar files |
| 17:35 |
rubenwardy |
ex: https://content.minetest.net/packages/LMD/adv_chat/ |
| 17:35 |
erlehmann |
what is this, minecraft? |
| 17:35 |
rubenwardy |
Java is needed for a backend for the chat servic |
| 17:35 |
MTDiscord |
<Sublayer plank> what about that one exe file? |
| 17:36 |
MTDiscord |
<GreenXenith> so is actually somewhat useful depending on the context |
| 17:36 |
MTDiscord |
<Jordach> LMD can’t into Lua so he defers his code |
| 17:36 |
rubenwardy |
oh that's probably just malware |
| 17:36 |
erlehmann |
.mcmeta is https://minecraft.fandom.com/wiki/Resource_Pack |
| 17:36 |
MTDiscord |
<GreenXenith> I know what it is |
| 17:36 |
MTDiscord |
<GreenXenith> Im asking why its in a Minetest mod |
| 17:36 |
rubenwardy |
seeing .mcmeta would make me suspect license issues, someone porting a random MC resource pack |
| 17:37 |
MTDiscord |
<luatic> @JORDACH it's just that JDA is about a million times better than the single Lua Discord lib, Discordia, there is. |
| 17:37 |
MTDiscord |
<Jordach> I mean the alternative is just git gud |
| 17:38 |
MTDiscord |
<luatic> The alternative is a shitton of work |
| 17:38 |
MTDiscord |
<luatic> Yes, I am aware webhooks exist |
| 17:38 |
MTDiscord |
<GreenXenith> Just use JS like everyone else ? |
| 17:38 |
MTDiscord |
<luatic> Noooooooooooooooooooooooooooooooooooooo I don't think I will |
| 17:38 |
MTDiscord |
<Jordach> JS interpreter in Lua |
| 17:38 |
MTDiscord |
<luatic> Now that's absolutely disgusting |
| 17:39 |
MTDiscord |
<GreenXenith> So is Java |
| 17:39 |
MTDiscord |
<GreenXenith> btw most things are better tha discordia |
| 17:39 |
MTDiscord |
<luatic> JDA > discord.js too |
| 17:39 |
MTDiscord |
<GreenXenith> +n |
| 17:39 |
MTDiscord |
<GreenXenith> It could be fine if they didnt use luvit |
| 17:40 |
MTDiscord |
<Warr1024> The amount of obvious .gitignore failure in that list is saddening, let alone .gitattributes failure. |
| 17:40 |
MTDiscord |
<luatic> I decided to go with Java because I decided running a JAR is usually quite simple |
| 17:40 |
MTDiscord |
<GreenXenith> whats wrong with including gitignore |
| 17:40 |
MTDiscord |
<GreenXenith> there are usecases |
| 17:40 |
MTDiscord |
<Warr1024> No, I mean all the cases where .gitignore was NOT used, like all the *.lua~ and *.blend1 files |
| 17:41 |
MTDiscord |
<GreenXenith> ah, ok yeah |
| 17:41 |
MTDiscord |
<Warr1024> backup files are a pre-source-control-ism. |
| 17:41 |
MTDiscord |
<luatic> Why do you think Git was used in that cases :lennythink: |
| 17:41 |
MTDiscord |
<Warr1024> By saying "maybe they weren't using git" you're not exactly defending them either :-D |
| 17:41 |
MTDiscord |
<Sublayer plank> just as I thought, irrlicht's psd format loader is completely broken with modern psd files |
| 17:42 |
MTDiscord |
<Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/885580812483985418/unknown.png |
| 17:42 |
MTDiscord |
<GreenXenith> what makes me even sadder is the 23 THOUSAND mts files |
| 17:42 |
MTDiscord |
<Sublayer plank> which was also why I was so sure none mods actually use it |
| 17:42 |
MTDiscord |
<luatic> yeah, that was the point hecks made for removal |
| 17:42 |
MTDiscord |
<Warr1024> If a feature hasn't actually been working in a long time then you can be pretty confident that nobody is using it meaningfully :-) |
| 17:43 |
MTDiscord |
<GreenXenith> wait im thinking of the wrong file type |
| 17:43 |
erlehmann |
look i think if hecks is right about a thing it's mor of an accident |
| 17:43 |
MTDiscord |
<GreenXenith> mtl is the one im thinking of |
| 17:43 |
erlehmann |
with th filetypes |
| 17:43 |
MTDiscord |
<GreenXenith> still a thousand mtl files, which is still sad |
| 17:43 |
erlehmann |
this is clearly the first analysis done |
| 17:43 |
erlehmann |
we are all surprised |
| 17:44 |
MTDiscord |
<GreenXenith> Im curious as to why there are so many text files |
| 17:44 |
erlehmann |
sorry what is the problem with the mtl file? |
| 17:44 |
rubenwardy |
Warr1024: I wonder if ContentDB should inject rules into .gitignore before making releases |
| 17:44 |
rubenwardy |
.blend, .xcf, and others should probably never be included |
| 17:44 |
rubenwardy |
well, I suppose the mod could be implementing a blend/xcf parser but that would be crazy |
| 17:44 |
MTDiscord |
<Warr1024> A warning might be nice |
| 17:45 |
MTDiscord |
<GreenXenith> looks at LMD |
| 17:45 |
erlehmann |
if you have a .obj model then you could load the textures from .mtl right? |
| 17:45 |
rubenwardy |
oh yeah could be a bot message |
| 17:45 |
rubenwardy |
which gives you an example gitignore |
| 17:45 |
MTDiscord |
<GreenXenith> I am 90% certain .mtl files are useless for Minetest |
| 17:45 |
MTDiscord |
<Warr1024> .gitattributes in most cases |
| 17:45 |
MTDiscord |
<Warr1024> it's export-ignore you want in the case of things like blend files, whereas gitignore is more about things like .lua~ |
| 17:45 |
erlehmann |
GreenXenith prove it |
| 17:45 |
MTDiscord |
<luatic> GX: you're 100% right with that |
| 17:45 |
rubenwardy |
right yeah, export-ignore |
| 17:45 |
MTDiscord |
<GreenXenith> lmao prove it? |
| 17:46 |
MTDiscord |
<luatic> TXT is used for API docs where MD should be used. |
| 17:46 |
MTDiscord |
<luatic> MT has set a bad example in this regard. |
| 17:46 |
MTDiscord |
<Warr1024> but I've been told that shit like .lua~ shouldn't go in project .gitignore files but instead into your user-wide ~/.git/exclude or whatever it's called, since the quirks of your editor is system-specific and not project-specific |
| 17:46 |
MTDiscord |
<GreenXenith> how do you want me to prove something isnt supported? |
| 17:46 |
MTDiscord |
<Warr1024> all of this is actually good content for that "how to trim your releases" FAQ :-D |
| 17:46 |
MTDiscord |
<luatic> MTS files don't get sent to clients |
| 17:47 |
MTDiscord |
<GreenXenith> mtl* |
| 17:47 |
MTDiscord |
<luatic> They're not in the extension whitelist |
| 17:47 |
MTDiscord |
<luatic> MTL* right |
| 17:47 |
MTDiscord |
<GreenXenith> MTS is the schem format |
| 17:47 |
MTDiscord |
<luatic> MTS neither :) |
| 17:47 |
MTDiscord |
<Sublayer plank> for the large amount of txt files, description.txt and depends.txt exists |
| 17:47 |
|
Extex joined #minetest-dev |
| 17:47 |
MTDiscord |
<luatic> true |
| 17:47 |
MTDiscord |
<GreenXenith> erlehmann: https://wiki.minetest.net/Using_Blender#Exporting_OBJ |
| 17:47 |
MTDiscord |
<GreenXenith> > There is no need to write the MTL file as Minetest will not parse it. |
| 17:47 |
erlehmann |
GreenXenith ok oh |
| 17:47 |
MTDiscord |
<GreenXenith> "proof" enough? |
| 17:47 |
MTDiscord |
<Warr1024> heh, if you could just set an entity's mesh to an mts file then that would solve the "customizable vehicles" / lua voxel-area entities problem :-D |
| 17:48 |
MTDiscord |
<GreenXenith> I could totally support that inlvae |
| 17:48 |
MTDiscord |
<GreenXenith> in lvae* |
| 17:48 |
erlehmann |
lol Warr1024 |
| 17:49 |
erlehmann |
yeah so irrlicht can load mtl for obj, but minetest does not use it? |
| 17:49 |
MTDiscord |
<GreenXenith> Dunno of irrlicht does or not, but Minetest doesnt so it doesnt matter |
| 17:49 |
erlehmann |
does there exist a test case for it? |
| 17:51 |
|
Extex joined #minetest-dev |
| 17:53 |
|
Extex joined #minetest-dev |
| 17:53 |
twoelk |
source files needed to change a mod/model should be kept in contentdb imho even though mt might not be able to use them |
| 17:55 |
|
Extex joined #minetest-dev |
| 17:55 |
|
erlehmann joined #minetest-dev |
| 17:56 |
|
Extex joined #minetest-dev |
| 17:56 |
MTDiscord |
<Sublayer plank> it's literally just a waste of space |
| 17:56 |
MTDiscord |
<Sublayer plank> if you really need it, clone the git repository |
| 17:57 |
MTDiscord |
<GreenXenith> Yeah, chances are anyone that cares about source files will be cloning |
| 17:57 |
MTDiscord |
<Warr1024> I disagree with full src in every zip, I think source files should be kept in a public src repo and people should go directly there if they want the proper source, and contentdb downloads should be optimized for ordinary users. Since src repos should contain all the source necessary/possible, that would unnecessarily bloat downloads from CDB which is unfairly burdensome against certain users, such as those on crappy mobile networks. |
| 17:57 |
MTDiscord |
We should allow the user to choose between a "for use" vs "for development" use-case. |
| 17:57 |
MTDiscord |
<Sublayer plank> if you're doing development on the mod itself, you'd be doing that anyways |
| 17:57 |
|
Desour joined #minetest-dev |
| 17:57 |
erlehmann |
i think full source in every mod is neat |
| 17:57 |
erlehmann |
please do not *forbid* it |
| 17:57 |
erlehmann |
but warnings are neat too |
| 17:58 |
MTDiscord |
<Warr1024> yeah, I like the warning thing: the idea is to inform them of the choice, not to make it for them. |
| 17:58 |
erlehmann |
also tbh the licensing often says you need to deliver the full corresponding source code |
| 17:58 |
erlehmann |
which is easier that way |
| 17:58 |
erlehmann |
without the user having to navigate somewhere |
| 17:59 |
MTDiscord |
<Warr1024> If I wasn't able to exclude source from NodeCore's CDB download it'd be a little over 10x as large. |
| 17:59 |
twoelk |
interestping problem |
| 18:00 |
MTDiscord |
<Warr1024> What I consider "source" is kinda funny in some cases :-) |
| 18:00 |
twoelk |
what large sources does nodecore use? |
| 18:00 |
MTDiscord |
<Warr1024> For example, there's actually an MT world inside the repo |
| 18:00 |
MTDiscord |
<Warr1024> That world is the "source" for one of the screenshot images, which I need to be able to incrementally modify and then more or less recreate. |
| 18:02 |
twoelk |
so to recreate that screenshot with a new added feature (that is actually visible) you need the complete world? sounds like streching the usecase somewhat |
| 18:03 |
erlehmann |
yeah why not generate the world with a script? |
| 18:03 |
|
Extex joined #minetest-dev |
| 18:04 |
MTDiscord |
<Warr1024> It's not a "complete" world, it's a hand-trimmed map.sqlite and a few metadata files necessary to recreate the world. To make updates I have to run a script to re-delete the out-of-scope mapblocks that get regenned. It's not huge. But it's there, it adds up along with largeish blend files and such, and it would be of no value in the CDB download zip. |
| 18:05 |
|
Extex joined #minetest-dev |
| 18:05 |
MTDiscord |
<Warr1024> It's a piece of actual mapgenned world with heavy hand modifications, I'd hate to have to express all this as a hand-written script. The MT mapblocks are really the "preferred form for editing" for me. https://content.minetest.net/uploads/d9b55adeae.jpg |
| 18:05 |
|
ssieb joined #minetest-dev |
| 18:05 |
erlehmann |
i still do not get it |
| 18:06 |
MTDiscord |
<Warr1024> It's part of the source so it goes in the repo. It's just not part of the finished compiled product so it doesn't need to be in the download. |
| 18:08 |
twoelk |
I consider this a different form of source than a file that you actually need to change a mod because the files that mt actually uses cannot be worked on directly |
| 18:08 |
twoelk |
such as providing .blen files |
| 18:08 |
twoelk |
.blend |
| 18:09 |
erlehmann |
it is the source for the screenshot after all |
| 18:09 |
erlehmann |
in fact the provenance of the mineclone2 mob models is unclear to me :/ |
| 18:10 |
twoelk |
then all texture packs need to supply the world used for the screenshot? |
| 18:13 |
erlehmann |
if the screenshot is GPL or something i guess |
| 18:13 |
erlehmann |
but it is a bad license for that |
| 18:13 |
MTDiscord |
<Sublayer plank> the thing about supplying the world is that it makes it easy to recreate at a later date when textures are changed or new features are implemented |
| 18:16 |
MTDiscord |
<Sublayer plank> plus any texture packs for the game can have a similar screenshot :] |
| 18:19 |
twoelk |
I understand why it is there but I still don't consider it essential to be able to modify the mod while a source model or a source vector grafic for a pixel pic might very well be vital |
| 18:22 |
MTDiscord |
<Warr1024> Each individual texture pack doesn't "need" to supply a world for a screenshot, but the fact that I share this world makes it a lot easier for texture pack authors to make screenshots that are easily comparable to other textures. |
| 18:23 |
MTDiscord |
<Warr1024> If we want to make sure a mod author doesn't just make their repos private or some shit, that's a valid concern, but I'd still have a separate src vs. bin download option. |
| 18:24 |
MTDiscord |
<Warr1024> It's possible rubenwardy may already have to keep cached src repos or something for e.g. release-from-VCS on CDB, so maybe there's already a copy out there that could just be formalized in some way. |
| 18:25 |
sfan5 |
so have we determined that except tga nobody actually used the other formats that were removed? |
| 18:26 |
MTDiscord |
<Sublayer plank> yeah, pretty much |
| 18:49 |
MTDiscord |
<luatic> erlehmann: where can I find the Minetest logo SVG? |
| 18:49 |
MTDiscord |
<luatic> NVM I searched wrong it seems |
| 18:49 |
MTDiscord |
<luatic> it's right there in misc/ |
| 18:49 |
MTDiscord |
<Sublayer plank> https://github.com/minetest/minetest/blob/master/misc/minetest.svg |
| 18:49 |
MTDiscord |
<Sublayer plank> oh lol |
| 18:50 |
MTDiscord |
<luatic> This looks like a permission issue with the snap |
| 18:50 |
MTDiscord |
<luatic> Don't do snaps kids |
| 19:16 |
|
specing_ joined #minetest-dev |
| 20:27 |
pgimeno |
<sfan5> and also the two approvals requirement never really applied to repos other than minetest and minetest_game <-- that's more of an oversight than an actual policy I suppose; it's just that no one thought of updating the policies when the MT fork was created. Or that's what I want to think. |
| 20:29 |
pgimeno |
<sfan5> BMP was always an alternative to TGA (in fact I have no idea why anyone would choose it over BMP) <-- you seem to think that BMP is easier to write than TGA, it's the other way around |
| 20:30 |
pgimeno |
for TGA, write a 18 byte header then the palette if any, then the raw data; for BMP, write the header, then the palette if any, then the *padded* scanlines |
| 20:30 |
pgimeno |
that alone is a reason to prefer it; that and the fact that it supports more formats |
| 20:32 |
sfan5 |
huh ok |
| 20:32 |
pgimeno |
I don't know if mineclone* needs to ever read back the data; if it does, and the data is in PNG format, that'd mean decoding the PNG on the Lua side, therefore a PNG writer might not be suitable |
| 20:34 |
pgimeno |
for converting the TGAs to PNG it will certainly need to read them |
| 20:48 |
MTDiscord |
<Warr1024> Also isn't BMP the only format that requires the scanlines to be in reverse order? |
| 21:06 |
|
Taoki joined #minetest-dev |
| 21:07 |
|
Fixer_ joined #minetest-dev |
| 21:15 |
|
olliy1or joined #minetest-dev |
| 22:39 |
|
erlehmann joined #minetest-dev |
| 22:44 |
|
asdflkj_sh joined #minetest-dev |
| 23:57 |
|
AliasAlreadyTake joined #minetest-dev |
