| Time |
Nick |
Message |
| 02:16 |
|
pgimeno_ joined #minetest-dev |
| 02:18 |
|
Guest54 joined #minetest-dev |
| 02:25 |
Guest54 |
celeron55 sfan i urge you to reconsider changing the default rendering for optionally framed glass. i found that a large amount glass mods uses that type, but it is quite often used together with glass planes or angled elements that are not framed. minetest game obsidian glass in particular is often used for the grid effect – but becomes |
| 02:25 |
Guest54 |
invisible with connected glass. here are four visual comparisons that show how badly it affects existing builds near spawn on different servers: https://mister-muffin.de/p/C0Pf.png |
| 02:27 |
Guest54 |
besides, it does not really work for texture packs with texture widths that are not multiples of 16 – even if the texture pack author does everything right (i.e. provides the additional texture so there is no fallback to mtg texture), the frame of the connected glass does not match, with does look jarring. |
| 02:35 |
Guest54 |
btw, the connected glass option also changes the generated inventory icon, since the backfaces of it are also rendered while I think they are not with normal glass |
| 02:44 |
MTDiscord |
<Warr1024> Seems like the whole _optional thing is more of a landmine than anything. Mods that want a particular look should just use one or the other drawtypes. Anyone building with a material with optional looks must account for the possibility of either setting on viewers. |
| 02:47 |
Guest54 |
btw, note also that it was rejected to make obsidian glass in mtg glasslike_framed for exactly the reason i am stating: existing builds use it for the frames. |
| 02:48 |
Guest54 |
Warr1024 of course the option is a landmine. should probably never have been added. here someone brought up a particularly funny case of how it affects obsidian glass over a lava pit: https://github.com/minetest/minetest_game/issues/1547#issuecomment-335011698 |
| 02:55 |
Guest54 |
Warr1024 i suspect most builders don't really think about the optionally framed look (i certainly never did when i built stuff entirely out of glass) – but even if they were, glass mods just used the drawtype to provide the option to some. in mineclone2 for example, glass was changed to the optionally framed glass a year ago to cater to some |
| 02:55 |
Guest54 |
users who like the look of the minecraft mod optifine (which does connected glass). most builds I know that use a lot of glass (e.g. stained glass church windows out of full glass nodes) are from before then. a big problem is that there is no way for modders or server owners to change it back to the old default. |
| 02:56 |
Guest54 |
like, if you make it into glasslike, you can't provide the option anymore. |
| 02:56 |
Guest54 |
anyways, it doesn't really work on glass panes or angled elements either, as you can see. |
| 02:57 |
Guest54 |
oh, also a bunch of nodes “support” framed glass by … defining a transparent texture. ;) |
| 03:04 |
MTDiscord |
<kimapr> framed panes when? |
| 03:12 |
Guest54 |
Kimapr i believe there was an issue open for it, but i can't find it at the moment. |
| 03:25 |
Guest54 |
so there is one thing i do not understand: given that several times before changing the default drawtype of optionally framed glass was discussed and always was not done, what exactly was the argument that suddenly made it acceptable to change the default rendering of optionally framed glass in very mod when it was previously agreed to be so |
| 03:25 |
Guest54 |
disruptive to change a drawtype that minetest_game could not even change the node type to glasslike_framed? if i understand it correctly, the PR was only submitted after rubenwardy removed the “supported by core dev” label on the relevant issue (and whatever that may mean I do not know, the change is trivial, yet was never done despite supposed |
| 03:25 |
Guest54 |
approval which was then … rescinded?): https://github.com/minetest/minetest/issues/8290 |
| 03:26 |
Guest54 |
very → every |
| 03:40 |
|
v-rob joined #minetest-dev |
| 03:41 |
|
v-rob joined #minetest-dev |
| 03:42 |
|
v-rob joined #minetest-dev |
| 03:43 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:46 |
|
calcul0n joined #minetest-dev |
| 06:25 |
|
olliy joined #minetest-dev |
| 06:29 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:06 |
MTDiscord |
<Benrob> Someone decided to do it |
| 14:05 |
|
Guest54 joined #minetest-dev |
| 15:02 |
|
Desour joined #minetest-dev |
| 15:03 |
|
appguru joined #minetest-dev |
| 15:10 |
pgimeno |
Microsoft is Not Evil™ |
| 15:18 |
Guest54 |
additional information regarding glasslike_framed_optional rendering: texture packs *larger* than 16×16px also break if connected glass is active, since the glass border needs to be *exactly* 1/16 of the base glass texture, or else the thing is going to look at least slightly weird |
| 15:21 |
Desour |
Guest54: minetest has many issues, if you find more, open issues iff they're not duplicates. irc is not the right place for issuing issues, nor for providing more and more details in a long monologue. but I think you were told this already |
| 15:22 |
Guest54 |
you can see this for yourself if you try minetest game with these texture packs and connected glass: handpainted (border looks fuzzy), sharpnet photo realism 64px (glass becomes invisible, frame has weird double borders and edges) |
| 15:22 |
Guest54 |
Desour well i can't open an issue right now, but i will shut up regarding this, i believe i have provided enough information |
| 15:24 |
Guest54 |
also my previous experience is that if something has been discussed on github and disregarded, clearly explaining it on IRC may make people who dismissed criticism look into it again, but i get it, it's the wrong place. |
| 15:24 |
|
Guest54 left #minetest-dev |
| 15:25 |
Desour |
there's also the forum, in case you don't want to / can use github |
| 15:25 |
Desour |
writing into irc is also ok, but looks like it's starting to get out of hand again |
| 15:27 |
rubenwardy |
honestly, reading that issue it feels more like the solution is to deprecate glasslike_framed_optional and not change the default value of the setting |
| 15:34 |
|
Desour_ joined #minetest-dev |
| 15:40 |
|
Guest54 joined #minetest-dev |
| 15:42 |
Guest54 |
rubenwardy reading https://github.com/minetest/minetest/issues/11546 maybe a new drawtype glasslike_connected to decouple the 1/16 frames from the connected look is an option long-term ig |
| 15:59 |
rubenwardy |
sfan5: users reporting broken models with latest irrlicht |
| 16:02 |
Desour_ |
tell them to try with revision 10 (AFAIK, that's the one we want to ship with the next release, right?). |
| 16:02 |
Desour_ |
https://github.com/minetest/irrlicht/tree/1.9.0mt10 |
| 16:03 |
rubenwardy |
either the engine should require 1.9.0mt10 or you shouldn't be pushing features during a feature freeze |
| 16:07 |
MTDiscord |
<PrairieWind> Guest54: I created the PR before I was aware that the core dev support was removed. |
| 16:07 |
Krock |
added the changelog for 5.7.0 (based on master branch from today) |
| 16:08 |
Krock |
looks like MTG also got some updates. adding them as well now. |
| 16:09 |
MTDiscord |
<PrairieWind> Naturally, the first time I try to contribute to the engine, the change becomes very controversial -_- |
| 16:09 |
MTDiscord |
<PrairieWind> why did I even try. |
| 16:11 |
rubenwardy |
I removed the label because there wasn't a clear consensus in the issue |
| 16:11 |
Guest54 |
well, it was always controversial, you just were not aware of the history of it (or the rendering issues that basically mean your texture pack has to support connected glass stylistically) |
| 16:11 |
Krock |
well, such problems that can happen to everyone |
| 16:11 |
Guest54 |
it happens |
| 16:12 |
Guest54 |
yeah |
| 16:12 |
Desour_ |
s/can happen/do happen/ |
| 16:12 |
Krock |
although I wonder why texture packs have no control about that... ? |
| 16:13 |
Guest54 |
because it does not make sense rendering-wise? |
| 16:13 |
Krock |
why not? texture packs are literally what's used to render |
| 16:13 |
Desour_ |
+1 for per-node <drawtype>_optional decisions using texture packs |
| 16:14 |
Krock |
or as mentioned previously - to remove the optional part |
| 16:14 |
Krock |
I see that it only overcomplicates the matter |
| 16:30 |
Guest54 |
PrairieWind to be clear, the “problems happening to anyone” is not a personal failing, but a failing of a system. humans know at least since the 1960s or so how to develop bug-free software (AFAIK the apollo guidance computer program used for the moon landing had no known bugs, decades later), but it requires *a lot* of effort – think of the |
| 16:30 |
Guest54 |
most effort you could put into making sure a sorting algorithm works and then think what if every line was written by someone different as a hobby project … and then add some. almost no one does it, since developers usually value new features more than not breaking stuff (reasons: it is more fun, it makes economic sense, humans have a limited |
| 16:30 |
Guest54 |
life span etc. pp.). |
| 16:34 |
Guest54 |
PrairieWind in this case, you could have noticed the rendering issues or thought about the consequences more or tried one of the numerous texture packs or read the at least 4 past issues about this, but in the end someone approved it and presumably also did not do all that. you can not blame them as individuals either, as long as minetest is a |
| 16:34 |
Guest54 |
project where developers and users alike prefer getting new stuff instead of getting a bug-free experience (as evidenced by shadows, which were once too buggy to be part of a release). |
| 16:35 |
Guest54 |
so i hope i did not demotivate you |
| 16:36 |
MTDiscord |
<PrairieWind> well, I guess I should stick to the supported by core dev issues, and asking first. |
| 16:36 |
MTDiscord |
<PrairieWind> especially if they are older issues |
| 16:36 |
Guest54 |
PrairieWind besides that, “let's make a release candidate and then wait for complaints” works well enough in practice (as evidenced by me complaining). |
| 16:42 |
Guest54 |
PrairieWind IMO the easiest way to figure out if something is a sensible change or addition to a program is to go outside of your comfort zone. look at the implementation and think of how it could break. e.g. if you want to work on keyboard-related issues, ask people to test it on different machines or with a layout different than QWERTY etc. |
| 16:44 |
Guest54 |
also if someone claims to develop bug-free stuff, ask them how they did it. usually “oh i just don't make any mistakes” means they are charlatans while people who can explain stuff like unit testing or input validation or static analysis are able to help you to become just as good as them. |
| 16:45 |
MTDiscord |
<PrairieWind> speaking of that, I have an add favorite server button that I might need user testing and input for because of how the highlight thing is working. |
| 16:46 |
MTDiscord |
<PrairieWind> if you click the button, it adds the server to the favorites list, and highlights the next server down. But it shows the favorited server information in the side panel still. |
| 16:47 |
Guest54 |
why does it do that instead of keeping the highlight on the server that you added to the fav list? |
| 16:47 |
Guest54 |
(which would be what i expect) |
| 16:47 |
rubenwardy |
The server list selection should probably be based on address/port rather than index, would be more reliable |
| 16:48 |
Guest54 |
oh i see, the index thing makes it “highlight is i positions down in this list” |
| 16:50 |
|
appguru joined #minetest-dev |
| 16:51 |
appguru |
sfan5: re https://github.com/minetest/irrlicht/commit/edb381bd5050712d1eb8875fe3a405000dd09a3d: it is not apparent to me why flipping the sign of the W component of a quaternion representing a rotation should change the handedness |
| 16:52 |
appguru |
I believe that instead the X, Y and Z components should have their signs flipped, since that would be akin to flipping the direction of the rotation axis which turns the rotation converts the rotation to its inverse (as if you would rotate counterclockwise rather than clockwise) |
| 16:54 |
|
Arc_ joined #minetest-dev |
| 16:55 |
Arc_ |
is there any documentation that explains the lighting algorithm? |
| 16:57 |
Guest54 |
Desour_ the security vulnerability here is not exploitable client-server-wise, or is it? https://github.com/minetest/minetest/pull/13315 |
| 16:58 |
Guest54 |
i mean, the client can't arbitrarily trigger it |
| 16:58 |
Guest54 |
in any way, i suggest to issue a CVE because that is what makes linux distributions take note and backport the fix to earlier versions |
| 16:58 |
Desour_ |
a client can only trigger it with the help of a server-side mod |
| 16:59 |
Desour_ |
(by abusing that mod) |
| 16:59 |
Desour_ |
so no |
| 16:59 |
MTDiscord |
<PrairieWind> yah, checking by address and port would definitely be easier than idx |
| 16:59 |
MTDiscord |
<PrairieWind> *index |
| 17:00 |
MTDiscord |
<PrairieWind> the index is whats giving me an issue. |
| 17:03 |
MTDiscord |
<GoodClover> Minetest has existing CVE's that require a faulty mod to be present, such as the minetest.deserialize & ItemStack injection ones |
| 17:06 |
Guest54 |
that last one, in fact, was exploited so thoroughly that you may still be able to find remnants of it on old-enough servers |
| 17:08 |
Guest54 |
funnily enough, everyone i know who used it claimed to just create OP items with it (since rooting a server is outside of the game or so?) |
| 17:27 |
Desour_ |
I haven't used the github security advisories thing yet. (I'm also not sure if I have the rights to create one.) it's not the first and certainly not the last UaF we'll ever have fixed. it's also not as trivial to exploit as the other things that got CVEs. it would probably still make sense to open one though, and in the future open one for every other tiny security-relevant issue |
| 17:54 |
sfan5 |
rubenwardy: if set the release mode cmake will require exactly 1.9.0mt10 no earlier no later |
| 17:54 |
sfan5 |
so irrlicht does not need a freeze |
| 17:54 |
sfan5 |
@appguru I will revert the commit and then we can maybe send a bug report to the irrlicht dev |
| 17:55 |
|
appguru joined #minetest-dev |
| 17:59 |
|
Noisytoot joined #minetest-dev |
| 18:50 |
|
Noisytoot joined #minetest-dev |
| 18:51 |
|
GuestBanana joined #minetest-dev |
| 18:52 |
GuestBanana |
#13349 opened 5hrs ago, coincidentally I went looking for a feature request of that just now. Seems to be a duplicate of the #11362 which was closed by paramat for inactivity. Possiblity of re-opening it? |
| 18:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/13349 -- Defining Crack Animation Per Node |
| 18:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/11362 -- leave cracks while breaking a block |
| 18:53 |
GuestBanana |
Sorry, that second one should be #3540 not 11362 |
| 18:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/3540 -- Provide the possibility to provide a crack texture override per node. |
| 19:42 |
|
GuestBanana joined #minetest-dev |
| 19:43 |
|
behalebabo joined #minetest-dev |
| 19:48 |
|
hmmmmm joined #minetest-dev |
| 20:00 |
|
hrmmmm joined #minetest-dev |
| 20:11 |
|
v-rob joined #minetest-dev |
| 20:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:46 |
|
Noisytoot joined #minetest-dev |
| 20:59 |
pgimeno |
@appguru @sfan5 what commit? note that if a quaternion Q represents a rotation, -Q represents the very same rotation, hence why changing Q.w to -Q.w works to invert the sense of rotation |
| 21:00 |
Desour_ |
pgimeno: https://github.com/minetest/irrlicht/commit/edb381bd5050712d1eb8875fe3a405000dd09a3d |
| 21:01 |
pgimeno |
thanks, looking |
| 21:05 |
Desour_ |
cmake question: why are we using for some compile options set() with CACHE and for some option()? |
| 21:11 |
pgimeno |
I have to give up, Irrlicht's axis convention and choice of Eulers for some rotations is just too horrible for my aging mind |
| 21:12 |
|
v-rob joined #minetest-dev |
| 21:16 |
|
Noisytoot joined #minetest-dev |
