Time  Nick       Message
12:28 MTDiscord  <Warr1024> #11405 is now a week old, no controversy raised, and apparently approved by 3 core devs.  Can it be merged now?
12:28 ShadowBot  https://github.com/minetest/minetest/issues/11405 -- Add API for mods to hook liquid transformation events by Warr1024
12:36 rubenwardy go ahead
12:38 MTDiscord  <Warr1024> Okay, I've never done one of these before.  Do I just hit the GH "squash and merge" button, or am I supposed to do it manually in git directly?
13:14 pgimeno    isn't it squash and rebase?
13:15 MTDiscord  <Warr1024> Yeah, ruben walked me through it on a side channel.
13:15 pgimeno    ah
13:15 MTDiscord  <Warr1024> I just distrust github's buttons because I know that some projects specifically don't like what those things do automatically.
13:16 MTDiscord  <Warr1024> I believe Linus for example has a great tirade somewhere out there about how much he hates the stuff that's produced by GH's interfaces, like bad merge message formatting and such.
13:16 MTDiscord  <Warr1024> I just didn't want to make the assumption that "whatever is fine" :-)
19:42 hecks      ahem. i need this, can i do this? https://github.com/minetest/irrlicht/pull/45
20:13 MTDiscord  <josiah_wi> That's called encapsulation.
20:32 hecks      and does it help anyone in this case?
20:33 hecks      we're the only user and the reason to encapsulate this is now gone (alternative video drivers)
20:35 sfan5      you're moving everything though, not only video driver headers
20:36 hecks      video driver headers pull other internal headers
20:37 hecks      and headers cost nothing until someone includes them
20:39 hecks      so i figured this was better than manually walking the include chain and moving one by one
20:40 hecks      it of course reflects my attitude that this code is headed for the trash bin anyway
20:51 hecks      but i try to imagine what harm could this actually cause and i really can't
20:51 celeron55_ i think it's fine due to our plans to not extend the use of irrlicht
20:52 celeron55_ this could backfire though
20:53 celeron55_ the other option is to add the gl specific code to irrlichtmt and maintain the encapsulation
20:53 hecks      here's the thing
20:53 celeron55_ but given irrlicht is to be gotten rid of in the long term, it may not make sense at all
20:53 hecks      irrlicht already has a type i need, it's just internal for some stupid reason
20:54 sfan5      at least gui headers should not be made public
20:54 hecks      because name conflicts?
20:54 sfan5      no just out of principle
20:54 celeron55_ can you consider making public only those headers that contain opengl stuff?
20:54 sfan5      since manual is too much work, walking the include tree of just the gl headers sounds doable with cpp
20:55 celeron55_ or does it immediately get impossible due to header dependencies
20:55 hecks      well i'll definitely end up pulling a huge chunk of the internal headers anyway
20:55 sfan5      I sure hope the gl drivers don't include the gui :D
20:55 hecks      and then i thought, what's the point of this encapsulation charade anyway ﾂ
20:56 celeron55_ if it's actually practically impossible to publish only the headers needed, then i think we should accept the PR
20:56 hecks      let me actually try walking the deps
20:56 hecks      but here's the thing, i only vaguely know which headers i'll actually need...
20:57 sfan5      we can defer this until the renderer is close to done I guess?
21:06 hecks      sure i can write it against a private branch or just add source/Irrlicht to my include paths for now
21:07 hecks      i just think this issue will recur as the migration progresses
21:21 hecks      but fine, i'll close that for now
21:28 MTDiscord  <Warr1024> I poked around at #11378, compiled it, tried it out, looked over the code, and couldn't find any flaw.  Is that adequate for a "one approval" tag?  Is it an issue of I'm not familiar with the internals of the particular system (main menu) being modified?
21:28 ShadowBot  https://github.com/minetest/minetest/issues/11378 -- Add disable_settings to game.conf to get rid of "Enable Damage"/"Creative Mode"/"Host Server" checkbox by Wuzzy2
21:46 rubenwardy you don't need to understand the main menu, just the bits that are touched
21:46 rubenwardy so the tab_local tab
21:47 rubenwardy I find it suspicious that it's getting the current game rather than game of the world
21:56 rubenwardy huh, looks like you can never not have a game selected
21:59 rubenwardy !setting is also like not setting, maybe setting! would be better
21:59 ShadowBot  rubenwardy: Error: Factoid "setting" not found.
21:59 rubenwardy although I guess it is a double negative
22:40 MTDiscord  <Warr1024> setting! kind of triggers ruby memories for me of mutate-in-place methods.  I also never see a unary not in suffix position.  !setting seems the least unnatural.
22:41 rubenwardy another option would be something like    disabled_settings = enable_creative=false, enable_damage=true,
22:43 LW         Would be nice if you just added a button called 'Game Settings' which you could choose to add settings to
22:44 LW         I have game-specific settings that I want easily accessible from the world menu