Minetest logo

IRC log for #minetest-dev, 2021-07-28

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:19 specing_ joined #minetest-dev
00:21 Extex joined #minetest-dev
00:22 MTDiscord <Jordach> sfan5 reverting that cmake pr might be required
00:23 MTDiscord <Jordach> yes lets remove linking against macOS system libraries required for windowing and input that certainly can't go wrong
00:26 v-rob joined #minetest-dev
00:26 YuGiOhJCJ joined #minetest-dev
00:28 MTDiscord <Jordach> also, removing of -DIRRLICHT_INCLUDE_DIR and -DIRRLICHT_LIBRARY is quite possibly the most incompetant move possible
00:28 MTDiscord <Jordach> cmake prefix is not intelligent
01:02 sofar joined #minetest-dev
01:10 MTDiscord <Jordach> secondly, the documentation for compiling still mentions IRRLICHT_LIBRARY
01:12 hecks Jordach
01:12 hecks you're maintaining the macos port right?
01:13 MTDiscord <Jordach> yes
01:13 hecks can you tell me real quick how the opengl situation looks on that
01:14 hecks for example do you need to use an opengl extension loader or is just using a 2.1 header fine
01:15 MTDiscord <Jordach> 2.1 is default, however opengl context profiles allow using upto 4.3
01:15 hecks but no procaddress monkeying required right?
01:15 MTDiscord <Jordach> nope
01:15 MTDiscord <Jordach> (even mesa ignores khronos group advice about versioning for compat reasons)
01:16 hecks i'm trying to figure out whether i should salvage any GL wrangling code from irr, import a lib, use something like glad or just do it myself
01:16 hecks gl 2.1 seems to support everything es2 does
01:17 hecks that would make pointer monkeying necessary only on windows, linux, bsd
01:17 hecks if gl2 had a real core profile my job would be a little easier
01:18 MTDiscord <Jordach> yeah, you can use core profiles from 3.3 to 4.1 on mac's from the last decade
01:18 hecks i was wondering that too
01:18 hecks would anyone care if i just opened a 3.3 core context on mac
01:18 MTDiscord <Jordach> no
01:18 MTDiscord <Jordach> that opens up better glsl options
01:18 hecks alright =]
01:19 hecks well
01:19 hecks i still have to restrict myself to what android and GL2 cards can do but
01:19 hecks if it's a core profile, that still aligns
01:19 hecks gles2 is also a lot like a core profile, there are no unnecessary functions in it
01:19 MTDiscord <Jordach> the oldest version of macOS that supports 3.3 is Lion, and I target Mavericks as C++11 wasn't added until Mavericks
01:20 hecks so it literally won't compile on versions without the glcorearb header?
01:20 MTDiscord <Jordach> (every mac from 2007 can run that - openGL 3.3 may not be possible on certain ancient systems)
01:20 hecks cool
01:21 hecks so now all i'd have to do is figure out how to efficiently squeeze out just the subset of functions i need on the remaining platforms
01:21 hecks well
01:21 hecks technically that literally requires wrangling what's in the core header
01:21 MTDiscord <Jordach> the GPU driver won't support it
01:22 MTDiscord <Jordach> see: https://developer.apple.com/opengl/OpenGL-Capabilities-Tables.pdf
01:22 hecks i have that open already
01:22 MTDiscord <Jordach> basically the chips are just too old to support 3.3
01:22 hecks the real question is
01:22 hecks are there any mac users who can't afford an upgrade...
01:22 MTDiscord <Jordach> but pretty much all of the macs from 2009+ will likely run 3.3 without issues
01:23 MTDiscord <Jordach> there's some crazy people running PPC still
01:23 hecks actually better question
01:23 hecks no never mind
01:24 hecks no wait it actually is useful
01:24 hecks can i still open an older context
01:24 hecks 2.1 in particular
01:24 MTDiscord <Jordach> 2.1 is the lowest and yes
01:24 MTDiscord <Jordach> 2.1 is the default context
01:24 hecks that'll do really
01:24 MTDiscord <Jordach> for any OpenGL that doesn't use a core profile
01:24 MTDiscord <Jordach> core profiles are required for 3.3 and higher
01:25 hecks then the plan is to open what's possible starting with 2.1 and use the core header on all platforms except android
01:25 MTDiscord <Jordach> yeah tha tworks
01:25 hecks this should be fine on anything except toasters that literally can't handle the amount of geometry MT pushes around
01:25 MTDiscord <Jordach> oh, Radeon HD 2400 was released in 2008
01:26 hecks first gl3 card?
01:26 MTDiscord <Jordach> basically Macs that are practically 14 years old can run 3.3 managably
01:26 hecks actually
01:26 hecks mesa can also run gl3
01:27 MTDiscord <Jordach> software rendered but yes
01:27 hecks but uhhh okay i won't try to make gl3 mandatory.... it won't fly
01:27 hecks although
01:27 MTDiscord <Jordach> macOS' software renderer can do 3.3 as well
01:27 hecks i think i'll do some conditional VAO usage eventually because that's such a great chatter reducer
01:28 MTDiscord <Jordach> whatever introduces the least amount of debt
01:28 hecks we're defaulting on the debt
01:28 hecks we're bankrupt, man
01:28 hecks dead broke, pocket lint
01:28 MTDiscord <Jordach> adjusting for inflation even
01:29 hecks wrangling gl will take one more reason to live away from irrlicht
01:30 hecks what will be left... gui, that's being dissolved slowly too
01:30 hecks and those funny asset importers
01:30 hecks and the crude animator and skinner
01:30 MTDiscord <Jordach> i mean the assimp library exists
01:30 hecks no
01:30 hecks it's too fat
01:30 hecks we can just keep the importers we have and absorb
01:31 hecks i would not add any new 3D formats except gltf
02:27 sofar joined #minetest-dev
03:08 v-rob joined #minetest-dev
04:05 v-rob joined #minetest-dev
05:29 v-rob joined #minetest-dev
06:09 YuGiOhJCJ joined #minetest-dev
06:55 nrz joined #minetest-dev
07:39 entuland joined #minetest-dev
07:50 sfan5 <hecks> sfan5: we need a percentage DPI scale setting on top of it
07:50 sfan5 #10729 adds one but isn't ready yet
07:50 ShadowBot https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail
08:21 sfan5 @Jordach specifying the cocoa+iokit dependency is IrrlichtMt's job now and it already does (well, tries to)
08:22 sfan5 does it show up in one of the IrrlichtMtTargets* files?
09:43 calcul0n_ joined #minetest-dev
10:51 nrz joined #minetest-dev
12:22 specing_ joined #minetest-dev
13:25 hecks joined #minetest-dev
13:27 hecks re 10729 you know, i also wouldn't mind desktop users with mice being able to unlock their cursor with middle click and being able to interact everywhere on screen
13:27 hecks just for consistency and completeness, and to allow the new GUI system to have interactable floating elements
13:28 hecks which would truly make forms no different from hud
13:39 specing hecks: yes! I'd love this!
13:40 specing One very good use of this would be to open two formspecs side-by-side, such as two chests. So you can move items directly, without passing through your inv
13:40 hecks two forms side by side aren't a problem really
13:40 hecks you just have to make a form that pretends it's two forms ;]
13:41 hecks i was thinking of clickable hud elements which wouldn't be modal, they wouldn't disable your controls
13:42 specing spring has this, but in reverse
13:43 specing your cursor is unlocked by default, but clicking middle mouse locks it and moves your viewport
13:43 specing and when it's unlocked, you can interact with lua gui widgets on screen
13:44 hecks i was thinking of system shock and daggerfall
13:44 hecks anyway, the thing is that mobiles are already capable of this and it isn't actually obvious
13:45 hecks i had no idea this was a thing until an android user actually told me
13:46 hecks so at the very least adding the capability to left and right click things that aren't under the cursor would make it consistent, gui aside
13:46 hecks i mean, that aren't under the crosshari
13:46 hecks crosshair
13:46 hecks but on screen
13:46 hecks and perhaps to also manage the hotbar like android users are able to
14:17 Fixer joined #minetest-dev
15:51 Extex joined #minetest-dev
15:54 sfan5 hecks: if you think the png PR is ready you can merge it yourself btw
15:54 hecks so it's just one approval for coredev PRs?
15:55 sfan5 the submitter also counts
15:57 sfan5 so yes
16:14 MTDiscord <josiah_wi> The README still lists the IRRLICHT_LIBRARY etc. variables under the options header.
16:15 MTDiscord <josiah_wi> I should've checked for all occurances of those variables in the README, but I didn't.
16:24 hecks now why does cmake yell at me that it can't find irrmt if i'm literally pointing it to that...
16:25 MTDiscord <Sublayer plank> well, there were some changes to that
16:26 MTDiscord <Jordach> $25 to whoever reverts that PR
16:27 hecks the directory variable names have not changed
16:27 MTDiscord <Sublayer plank> IRRLICHT_* doesn't work anymore, it more or less needs to be in lib/irrlichtmt
16:27 hecks why does it not recognize the irrmt master as irrmt
16:27 MTDiscord <Jordach> Because it needs to be installed as a systemwide package
16:27 MTDiscord <y5nw> you need to copy irrmt to lib/irrlichtmt
16:27 hecks :DDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
16:27 hecks unix weenies
16:27 hecks fix this
16:28 MTDiscord <Jordach> You’re a core dev revert it
16:28 MTDiscord <Sublayer plank> it doesn't need to be installed as a systemwide package, what are you talking about
16:28 MTDiscord <Jordach> make install always implies systemwide install on UNIX
16:28 MTDiscord <Sublayer plank> just make a symlink if you can't put irrlichtmt into lib/irrlichtmt directly
16:28 hecks i am not making symlinks across partitions
16:29 hecks that's harmful
16:29 hecks let me build it on my data drive or heads will roll
16:29 MTDiscord <Jordach> Basically it expects you to use cmakes package finding subsystem
16:29 MTDiscord <Jordach> Which is absolute garbage
16:29 hecks :DDDD
16:29 hecks peak unix
16:29 MTDiscord <Jordach> On exotic systems that use MSVC or macOS Xcode
16:29 hecks when are we switching to hardcoded paths
16:30 MTDiscord <Jordach> It’s what I was using before the PR
16:30 MTDiscord <Jordach> Why remove the one thing that doesn’t break on exotic config a
16:30 MTDiscord <Jordach> It also has likely broken Homebrew on mac alongside macports
16:30 celeron55 what are you complaining about, cmake works fine
16:31 hecks i'm on cygwin building mingw, anyway i'm not installing irrmt on C: because that's a throwaway partition
16:31 hecks celeron55: what doesn't appear to work is -DIRRLICHT_LIBRARY= etc
16:31 hecks which means i cannot point the build script to the folder that i edit and build irrlicht in
16:32 MTDiscord <Jordach> If DIRRLICHT_LIBRARY was specified then ignore CMakes find package
16:32 MTDiscord <Jordach> It’s that simple
16:32 hecks that's how it used to work
16:32 MTDiscord <Jordach> Except now it requires irrlicht to be make installed post compilation
16:32 MTDiscord <Jordach> Which by default installs to where a package manager would install a premade version
16:33 hecks oh well i guess i'm reverting to head~3 until you fine folks fix this
16:33 hecks locally
16:35 MTDiscord <Jordach> Also I thought one of the project goals was to keep it simple
16:38 sfan5 hecks: do you keep an installed copy of irrlichtmt around or just the checkout?
16:39 celeron55 okay yes this is nonsense, there should be a way to use irrlichtmt from an outside directory without installing it
16:39 sfan5 there is
16:39 hecks i build in place in the checkout
16:39 hecks my mt build script also runs the irr build script
16:40 hecks cygwin's weenie directories are on a trash partition and i'm not keeping anything in those
16:41 sfan5 if you don't mind a make install step for irrlicht you can do that and point mt to it via -DCMAKE_PREFIX_PATH
16:42 sfan5 if you do mind you can sort of do that anyway but symlink stuff so you won't ever need to run make install again (what I do)
16:42 hecks 1. what will that do
16:42 hecks 2. i am not symlinking across partitions
16:43 MTDiscord <Sublayer plank> what's the issue with symlinking across partitions?
16:43 hecks it's filthy
16:43 sfan5 I think windows can't do it, but you won't need to
16:43 celeron55 well the question is, is it acceptable that you have to install irrlicht to a temporary prefix in order to use it
16:43 hecks i can junction on windows but it's still filthy
16:43 sfan5 to 1: it will do what c55 just said and then work
16:43 celeron55 i've done that with many things so i'm kind of indifferent
16:43 MTDiscord <Sublayer plank> I've done symlinks on windows across partitions, it's worked with no issues
16:44 MTDiscord <Benrob0329> So wait, building has gotten more complicated now?
16:44 hecks i don't care what "works", i'm not polluting my system to make weenie build systems work
16:44 sfan5 you do not need to install system-wide.
16:44 hecks it worked the way i wanted three commits ago, what changed?
16:44 nrz i'd say the problem is the c++ packagiing, let's move to rust crates
16:44 MTDiscord <Sublayer plank> not really, it's just broke some people's workflows
16:44 hecks what's wrong with giving cmake a path variable
16:44 celeron55 https://github.com/minetest/minetest/pull/11287
16:44 celeron55 this changed
16:45 celeron55 140 lines were removed, 62 added
16:45 celeron55 i.e. it's simpler now
16:45 sfan5 like CMAKE_PREFIX_PATH you mean? I guess not
16:45 hecks not that kind of path
16:45 hecks this is not simpler
16:45 sfan5 not for this workflow no
16:45 sfan5 I miss the convenient option of being able to do this too
16:45 celeron55 basically what was changed is the custom irrlichtmt find script was removed (which supported the variables) and now it uses the cmake standard way of finding irrlichtmt
16:46 hecks and by accident it also removed the ability to just manually set it up
16:46 nrz magic things ❤️
16:47 hecks if you want to piss off a windows user, make him install and use things that don't stay contained in their little jail folder
16:47 sfan5 <sfan5> you do not need to install system-wide.
16:47 sfan5 maybe I shouldn't put it in bold
16:47 MTDiscord <josiah_wi> I wanted to improve things, not cause controversy and be a pain to everyone. I'm frustrated nobody spoke up while I was working on this PR, because now it seems things are descending into chaos and I'm at the center of it.
16:47 sfan5 anyway I will be writing down a "how it was before" and "how it is now" to hopefully fix the confusion
16:47 celeron55 meh, it's not that bad
16:48 celeron55 just add the custom find script back
16:48 celeron55 or somehow otherwise add the variables
16:48 sfan5 the issue is not the variables
16:48 celeron55 IRRLICHT_LIBRARY and whatever the include one was
16:48 sfan5 the issue is that a library found via cmake does more than "here is the .so and here is the includes"
16:49 MTDiscord <Benrob0329> From the perspective of someone who doesn't know Cmake well, what I've gathered is that IrrlichtMT has to be installed now, but it can be installed to a custom directory?
16:49 MTDiscord <josiah_wi> MSVC purportedly does not have a make install step; that seems like a big issue.
16:49 celeron55 let's just wait for sfan5's write-up first
16:49 celeron55 then continue
16:50 MTDiscord <Benrob0329> Fair
16:50 MTDiscord <josiah_wi> Benrob, there's a difference between packaging and installing in CMake terminology.
16:57 hecks serves me right not monitoring build system PRs, but i assumed people know what they're doing
17:01 MTDiscord <josiah_wi> I will probably be around so I can look over the write-up once, but I think sfan understands what the PR did quite well.
17:02 hecks i'm afraid this does not make anything simpler, it just shifts the complexity to the user's machine
17:04 sfan5 https://github.com/minetest/minetest/pull/11287#issuecomment-888472649 here's the thing
17:04 sfan5 before anyone says the obvious: yes, a common developer workflow is made complicated
17:04 hecks but
17:04 hecks /somewhere/ is now the irrlicht checkout
17:05 hecks i mean, that's what it was for me
17:05 rubenwardy if it uses the CMAKE way, won't there be IRRLICHT_ROOT or IRRLICHT_DIR to point to the module cmake?
17:05 sfan5 /somewhere is the IrrMt checkout, correct
17:06 sfan5 you don't need to move it anywhere
17:06 hecks "Technically not doable but you have two options."
17:06 sfan5 oh you were commenting on a previous section, nvm
17:06 hecks here are your options: make install or make install
17:06 hecks what will make install do?
17:07 sfan5 certainly won't install it system-wide
17:07 MTDiscord <Sublayer plank> well where's the DESTDIR?
17:07 hecks what will it do
17:07 hecks which files and symlinks will it create and based on which variables
17:07 hecks this _i subfolder?
17:08 hecks which will... let me guess, contain a /lib/ /bin/ /include/ just like the folder above it, containing the same things?
17:08 sfan5 these http://sprunge.us/gpuH3H
17:08 sfan5 hence option 2 which makes the files you usually have fit that by means of symlinking
17:09 hecks but the thing is
17:09 hecks CMAKE_PREFIX_PATH is just a root folder of sorts where cmake will now look for shit, correct?
17:09 sfan5 yea
17:09 hecks and if you decide to require that some other lib is installed in this way, i will now require a
17:10 hecks .../minetest/dev/git/cmake_root/... to maintain this little weenie root in
17:10 hecks thanks, i hate it
17:10 sfan5 you can specify multiple paths
17:10 hecks but on principle that's what this is
17:11 sfan5 I guess
17:11 hecks unix users really hate the idea of things staying contained in their own folders
17:11 hecks so the most you can do is create a folder pretending it's a shared root for each library =]
17:12 celeron55 is it not possible to support "cmake -DIRRLICHT_INCLUDE_DIR=/somewhere/include -DIRRLICHT_LIBARY=/somewhere/lib/Linux/libIrrlichtMt.a ." now?
17:12 MTDiscord <Jordach> Not at alp
17:12 MTDiscord <Jordach> All
17:13 celeron55 because i mean, there's the list of workflows, just make them all work nicely
17:13 sfan5 certainly, just add the 140 lines back
17:13 sfan5 and we will have gained nothing
17:13 sfan5 and #11402 can be reopened (albeit minor)
17:13 hecks nothing except sanity
17:13 ShadowBot https://github.com/minetest/minetest/issues/11402 -- Linker errors with IrrlichtMt automatically built alongside, using MSVC
17:14 hecks i mean fine, i keep this crap contained anyway
17:14 celeron55 of course the thing is, cmake automates some things that are otherwise very hard or annoying to do
17:14 celeron55 if you let it do so
17:14 sfan5 if we searched for any of the libraries via pkgconfig such things would have been required a long time ago
17:14 hecks and that would also be weenieism
17:15 sfan5 let me guess you don't static link?
17:15 hecks i guess i don't?
17:15 hecks what's that got to do with library paths though...
17:16 sfan5 commendable but that's one thing this approach simplifies
17:16 sfan5 because irrmt's cmake file can now say to please link X11
17:16 sfan5 anyway, I doubt cmake allows you to import a non-installed project's library but perhaps Minetest's CMake stuff can be made to make the workaround less painful?
17:20 sfan5 @josiah_wi do you happen to know / have better ideas?
17:22 hecks well i guess i'm off to make a fake filesystem root for cmake and move the fabled 140 lines to my build scripts instead
17:22 hecks i just find it funny that unix users do this to themselves and then invent things like docker to get out of the tarpit they made
17:33 MTDiscord <Jordach> It’s almost as if they ship things that only work on their machine
17:37 sfan5 on that note I forgot to say that the writeup is only relevant for building the client
17:37 sfan5 the server still builds with just -DIRRLICHT_INCLUDE_DIR as long as it points to the right path
17:37 hecks everything would work if only everyone used the same computer ;]
17:42 hecks ok but
17:42 hecks does this at least have some positive side effect in the form of like
17:42 hecks letting me unpack each of those mingw libs into the same fake root
17:49 hecks joined #minetest-dev
17:51 MTDiscord <josiah_wi> sfan5 I'm not sure I use specifically what you're asking. The reason for the install step is that CMake looks for configuration files in specific locations. The structure of the install tree is actually irrelevant (?). I made it the standard tree for installs, but it could put everything in 1 directory. You could also allow specifying a specific path to the Config file instead of an install prefix.
17:52 MTDiscord <GreenXenith> Do I have this right that we now have to install irrlicht system wide to compile Minetest?
17:52 MTDiscord <josiah_wi> use -> understand*. Stupid autocorrect.
17:52 MTDiscord <Sublayer plank> we don't have to
17:52 hecks either install it system wide or fool cmake into thinking you did
17:52 MTDiscord <Sublayer plank> if you put it in lib/irrlichtmt
17:53 MTDiscord <GreenXenith> Thats system wide buddy
17:53 hecks but.... that's basically installing systemwide :DDDD
17:53 MTDiscord <Sublayer plank> what
17:53 MTDiscord <GreenXenith> So the answer is yes
17:53 hecks linux users...
17:53 MTDiscord <GreenXenith> Hey, don't blame us all
17:53 MTDiscord <josiah_wi> Hang on, we should be able to hax Irrlicht into working with no install.
17:53 MTDiscord <Sublayer plank> I'm talking about putting the cloned irrlicht repo into lib/irrlichtmt in the cloned minetest repo
17:53 MTDiscord <josiah_wi> The build tree can be the install tree.
17:53 MTDiscord <GreenXenith> I'm a Linux user and I think this change is stupid
17:53 MTDiscord <Sublayer plank> how is this system wide?
17:54 hecks is lib/irrlichtmt in the cloned minetest repo gitignored and does that actually work?
17:54 MTDiscord <Jordach> The moment you put shit into your path environment is the moment it’s considered installed
17:54 MTDiscord <Jordach> And I have to use a very exotic build script because I have to link against an ancient OSX SDK and the current release
17:54 MTDiscord <josiah_wi> Doesn't need to be in PATH to work.
17:55 MTDiscord <Jordach> Is this officially documented
17:55 MTDiscord <GreenXenith> What was this change intended to fix?
17:55 MTDiscord <Sublayer plank> lib/irrlichtmt is in fact gitignored
17:55 hecks i guess lib/irrlichtmt is gitignored though probably it should just be lib/
17:55 MTDiscord <Jordach> Nice directory
17:56 MTDiscord <josiah_wi> The change was intended to make the build process more automatic for people who were having trouble with the variables.
17:56 MTDiscord <Jordach> I bet that isn’t even documented
17:56 MTDiscord <Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/870001724977467442/unknown.png
17:56 hecks the thing is that modifying the CI script and replacing the path variables was a lot simpler than actually bothering to learn how cmake works
17:56 hecks =]
17:56 MTDiscord <Sublayer plank> the lib/irrlichtmt thing has existed for a month now
17:56 MTDiscord <GreenXenith> Are we talking about minetest/lib/irrlichtmt or /lib/irrlichtmt
17:57 MTDiscord <Sublayer plank> minetest/lib/irrlichtmt
17:57 MTDiscord <GreenXenith> That makes more sense
17:57 MTDiscord <Sublayer plank> https://github.com/minetest/minetest/commit/fa4dee0e62dcf2bbfb68b17cf97e438eab58be93
17:57 MTDiscord <Sublayer plank> this was a month ago
17:57 MTDiscord <Sublayer plank> and it is in fact documented
17:57 MTDiscord <GreenXenith> I still think we should be able to use the old variables, but mt/lib seems acceptable if it works
17:58 MTDiscord <Jordach> That’s a tiny bit more acceptable but knowing CPackInstall it’ll copy that garbage in
17:59 hecks it's a little arbitrary, and i think i still have to symlink or copy things around
17:59 hecks but it beats making a fake root... for now
17:59 hecks oh we actually have shit in /lib/
18:00 MTDiscord <josiah_wi> I could be wrong but I think lib/irrlicht was exempted from install.
18:00 MTDiscord <GreenXenith> Meaning?
18:01 MTDiscord <josiah_wi> Meaning CPackInstall will not "copy that garbage in"
18:01 sfan5 lib/irrlichtmt is gitignored yes
18:02 MTDiscord <josiah_wi> How does CPack RUN_IN_PLACE=FALSE work with lib/irrlichtmt as a dynamic library?
18:03 MTDiscord <josiah_wi> Does it break the package?
18:03 MTDiscord <Jordach> Mac static links by default
18:03 sfan5 with lib/irrlichtmt it's never dynamically linked
18:03 MTDiscord <Jordach> Ie instead of dyld files strewn about the app it’s all built into the resultant Minetest binary
18:03 MTDiscord <josiah_wi> Phew.
18:04 MTDiscord <Jordach> It’s not like I’m doing a ton of research into an iOS build using the existing macOS frameworks
18:05 sfan5 moving your checkout to lib/irrlichtmt is actually a good idea for development purposes
18:05 sfan5 the only rare downside I can see is that this doesn't work if you want to use one irrmt from multiple Minetest checkouts
18:06 MTDiscord <josiah_wi> People clone Minetest multiple times? I always use branches and I have about 5 build directories.
18:08 MTDiscord <Warr1024> multiple clones can be helpful to avoid having to juggle a ton of stashes, if you're working on a lot of stuff at the same time and haven't reached a good commit point yet.
18:09 MTDiscord <josiah_wi> Interesting. I'll remember that tip.
18:10 hecks screw good commit points, just squash later
18:12 hecks Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11")
18:12 MTDiscord <Warr1024> Or do what I do and screw good commit points and don't squash.  I use a convention of putting "checkpoint" at the head of a commit to indicate that it's a WIP that I'm making just to ensure I don't lose my work.
18:12 sfan5 heh
18:13 hecks so what now, do all the path variables not work anymore?
18:13 sfan5 they certainly do
18:13 sfan5 the buildbot that runs on CI uses every one of them
18:15 MTDiscord <josiah_wi> I asked for thorough testing because I wanted my first PR to me a good one. internal screaming The ZLib thing doesn't sound like something that could be caused by this though, oddly. If you are on Linux and want to provide more information I can try to reproduce.
18:15 hecks guess whose scripts i'm using...
18:17 MTDiscord <josiah_wi> Is this a mingw build?
18:17 hecks yes
18:17 hecks it's a modified buildbot script
18:18 hecks the paths are actually correct and i get
18:18 hecks CMake Error at /usr/share/cmake-3.17.3/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
18:18 MTDiscord <josiah_wi> It says version 1.2.11 of zlib was found; there shouldn't be a version requirement!?
18:18 hecks which leads me to believe that cmake has gone rogue and ignores the path
18:19 hecks does the buildbot actually work right now?
18:19 sfan5 https://github.com/minetest/minetest/runs/3174982877
18:20 MTDiscord <josiah_wi> The path works hecks. It's a version error.
18:20 hecks it's the version from the buildbot......
18:20 MTDiscord <josiah_wi> Wait, is it using the wrong path?
18:20 sfan5 this would be bad but here's my guess: cmake has code to look for zlib, we just call that, it is broken in your version
18:21 hecks it's using the right path...
18:21 Extex joined #minetest-dev
18:21 sfan5 but this wouldn't explain why it's broken now and not before
18:21 hecks i'll delete packages and libs folders
18:21 sfan5 throw away your CMakeCache.txt just in case
18:21 hecks i did
18:22 hecks maybe the buildbot works by accident
18:22 longerstaff13 joined #minetest-dev
18:22 MTDiscord <josiah_wi> mingw grabs its own copies of DLLs for everything. I think it found hecks' system ZLib instead of the one it downloaded.
18:22 MTDiscord <josiah_wi> Hence the wrong version.
18:23 sfan5 but the version is not wrong
18:23 sfan5 and why would it do that when ZLIB_LIBRARY and ZLIB_INCLUDE_DIR are given
18:23 MTDiscord <josiah_wi> Maybe it's because it's not a DLL.
18:23 hecks cmake has gone rogue and demands we do everything its way from now on
18:23 MTDiscord <josiah_wi> The buildbot doesn't try to build with Irrlicht in lib/irrlichtmt.
18:24 MTDiscord <josiah_wi> Maybe that is causing it.
18:24 hecks how
18:25 hecks see, what a wonderful build system, we've now progressed to committing voodoo...
18:25 MTDiscord <josiah_wi> The buildbot pulls a prebuilt archive.
18:25 hecks but why would it break
18:25 sfan5 CMakeFiles contains two log files, maybe those help
18:26 hecks i'd like to restate my earlier question
18:26 MTDiscord <josiah_wi> Running the CMake scripts in irrlichtmt could break (?).
18:26 hecks if i put all the stupid libs in this fake root for cmake, would it find them
18:26 hecks i can just do that
18:26 MTDiscord <josiah_wi> If my hypothesis is correct then yes.
18:27 hecks dcmake_prefix_path right?
18:27 sfan5 yea
18:27 MTDiscord <josiah_wi> But that's a hacky workaround, not a solution, and we haven't even determined the precise cause.
18:28 MTDiscord <josiah_wi> I want to repro but my computer is in use my someone else yet.
18:28 hecks i thought that's the "correct" way?
18:29 MTDiscord <josiah_wi> Putting all the DLLs there? No.
18:29 MTDiscord <josiah_wi> The DLLs should be found where buildbot extracts them.
18:30 sfan5 I don't think cmake searches for DLLs
18:30 hecks i meant includes and libs
18:30 sfan5 just so we're on the same page: you link to a .dll.a but at runtime you require the .dll
18:30 hecks yes i know how linking works
18:30 hecks but josiah is right, this is voodoo
18:30 hecks there's no reason it shouldn't work the way i have it now
18:31 MTDiscord <josiah_wi> My current understanding is that buildbot tells CMake where ZLib is, CMake tries to look for it anyway, boom.
18:31 hecks see: "cmake has gone rogue"
18:32 sfan5 did you check the cmake log files inside CMakeFiles
18:33 MTDiscord <josiah_wi> Ah, so yes using a "fake root" should fix this. Irrlicht has its own mingw scripts afaik.
18:33 hecks yes, and there's nothing about zlib in these =]]]
18:33 MTDiscord <josiah_wi> Irrlicht probably needs to be built first with mingw and then linked. :|
18:34 sfan5 wat
18:34 hecks uhhhhhhhhh
18:34 MTDiscord <josiah_wi> Invoking the Irrlicht CMakeLists.txt during a mingw build probably is the cause of the error.
18:34 hecks ???
18:35 hecks i have a better question
18:35 hecks would cmake traverse down to lib/irrlichtmt and try to build that while i'm trying to build mt
18:35 MTDiscord <josiah_wi> Yes.
18:35 hecks well then placing irrlicht there is pretty stupid!
18:36 sfan5 is it?
18:36 hecks depends
18:36 hecks maybe i can just merge the build scripts
18:36 hecks but i don't really want to
18:36 hecks i want the ability to build irr independently...
18:37 hecks besides the zlib versions are identical and it gets a zlib path anyway so what is its problem...
18:37 MTDiscord <josiah_wi> That's what the "fake root" would do.
18:37 sfan5 so you're testing with irr inside lib/irrlichtmt right now?
18:37 sfan5 because I've never tested the buildbot with that
18:37 MTDiscord <josiah_wi> I'm hypothesizing that one zlib is a .dll.a and one is a .so
18:38 hecks why would either of them be a .so
18:38 hecks i'm doing mingw inside cygwin
18:38 MTDiscord <josiah_wi> Yeah sfan, I'm saying I think that's the issue. It should work though, if it doesn't it's a bug.
18:38 MTDiscord <josiah_wi> Oh. Maybe there is no .so zlib anywhere then.
18:39 hecks let me just figure out how to unpack the libs into the same folder instead, link the stupid irrlicht output there and leave it at that
18:39 hecks i hate unix
18:39 v-rob joined #minetest-dev
18:41 sfan5 I have no idea at this point
18:46 MTDiscord <josiah_wi> Probably too late now but the way to debug this is to run the configuration step in trace mode and see what step caused the error.
18:46 hecks i don't care
18:46 hecks i just want to build this
18:49 celeron55 < hecks> i just find it funny that unix users do this to themselves and then invent things like docker to get out of the tarpit they made
18:49 celeron55 i don't understand this either
18:49 celeron55 unix uses a physical file system as if it was a logical database or something
18:49 celeron55 it makes no sense
18:50 hecks it's because it's a 1970s system for shared computers accessed over a text terminal
18:50 celeron55 well yeah, it works for a router
18:50 celeron55 but for a router anything would work
18:50 hecks it works for a shared computer accessed through a terminal =]
18:51 hecks i have no complaints about my headless openbsd server, it does its job well
18:51 hecks but this is no way to use a workstation...
18:51 sfan5 I don't know which ideal state you are envisioning here
18:52 hecks the ideal state is that a program makes no assumptions and comes with everything it needs =]
18:52 hecks and stays contained in its folder unless otherwise specified
18:52 sfan5 being able to tell cmake to look in /whatever/hello/I/buried/my/files sounds like it'd break the "like a logical database" thing
18:52 sfan5 but apparently that's not enough
18:53 sfan5 I understand how this makes the dev usecase annoying, I use one of the described workarounds myself
18:53 sfan5 but the principles on which cmake's find a package thing is built on are sound to me
18:54 hecks well i'm forced to fool cmake into using a different path, but it still must be a unix style hierarchy and cmake (and every unix thing) is written with the assumption that these folders are just shared by everything
18:54 sfan5 and I don't have a better idea how you could preserve the "files can be whereever with no structure" property
18:54 hecks and it's an absolute nightmare in my case because it's a cross compile
18:55 hecks i have to actively guard this build system from being aware of cygwin
18:55 celeron55 why do you use cygwin, by the way?
18:55 sfan5 you can't blame "running a cross-compile from a system that is actually native or not really" on unix
18:56 celeron55 personally i've found msys to work well on windows
18:56 hecks because it's faster than using a linux vm
18:56 hecks and smaller than msys
18:56 hecks i only use it for two things: building things and ssh
18:57 hecks it's contained to a trash partition and considered disposable
18:57 hecks i've built many things with cmake and mingw but i haven't had to monkey around with it like this until today
18:57 celeron55 is something preventing you from putting irrlichtmt into lib/irrlichtmt and letting cmake automatically build it as a dependency of minetest?
18:58 hecks yes, read the log
18:58 hecks it breaks somehow
18:58 hecks so now i'm trying to just use the fake cmake root, i don't know yet if that'll work
19:00 celeron55 i can only come to the same conclusion that it should work
19:00 celeron55 this is ridiculous
19:01 sfan5 it should and it probably would if I were to try
19:01 hecks if it ain't broke...
19:01 celeron55 either we have some things broken because not enough automation isn't used, or we have some things broken because too much automation is used
19:01 celeron55 well it was broke
19:02 sfan5 but I don't blame cmake for breaking if you are cross-compiling to a system that matches the native system while cmake can't actually use the native libs
19:02 celeron55 https://github.com/minetest/minetest/issues/11402
19:02 celeron55 this is how it was broken
19:02 sfan5 the buildbot sets CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY though, so maybe even that should work
19:06 celeron55 we probably have only one alternative to some variation of this mess: requiring building irrlichtmt separately and setting the variables manually like before. For everyone, no easy pass for users
19:06 MTDiscord <josiah_wi> The structure of the install tree for a "fake root" can be arbitrary.
19:07 MTDiscord <josiah_wi> It's determined by the Irrlicht CMake and is completely configurable.
19:09 v-rob hecks: re making the HUD interactable and multiple forms open at once: I've actually been planning this for a long time (although not the middle click specifically). There will be different "containers" for each GUI (including HUD) that any mod opens so mods can interop without breaking each other. So, to make the HUD interactable, move all HUD containers from the HUD environment to the GUI environment. And, for multiple forms at the same time, just
19:09 v-rob open another container without closing the current one(s).
19:09 v-rob Of course, binding middle click couldn't very well be done from a mod yet.
19:09 hecks i mean to hard bind middle click to release the cursor
19:09 hecks and to lock it back again
19:10 hecks since it's currently unbound anyway
19:10 sfan5 or lock it back in when the user clicks into the world area?
19:10 hecks no, make it act like touchscreen interactions
19:10 sfan5 or do you want users to be able to use android-style touch-where-you-interact controls simultanously
19:10 sfan5 ah
19:10 hecks yeah
19:10 hecks because it's kinda weird that clients from one platform have this superpower that nobody knows about =]
19:12 v-rob Oh, I didn't realize you wanted full touchscreen interactions. Well, making the HUD interactable still will be possible :)
19:12 hecks there's no conflict between the two
19:12 hecks it's just that since there's a PR to make touch available on desktop, and touch has this interaction mode
19:12 hecks and mouse3 is unbound
19:13 hecks it makes sense to do this
19:13 v-rob Yeah, it does
19:15 hecks mmmmm cmake can't find irrlicht again
19:16 hecks oh of course
19:16 hecks cmake wants its magical files, it doesn't suffice to just give it a /lib/ and /include/
19:17 hecks i broke my scripts for nothing
19:17 hecks neither way works for me
19:44 MTDiscord <Jordach> ln -s /Users/Jordach/testfolder2/irrlicht /Users/Jordach/testfolder2/minetest/lib/irrlichtmt
19:44 MTDiscord <Jordach> this works for me
19:44 MTDiscord <Jordach> good fucking show @josiah_wi
19:45 MTDiscord <Jordach> you just broke codesigning
19:45 celeron55 don't get so personal, it's just the cmake way of breaking stuff
19:45 MTDiscord <Jordach> it's not CMake
19:46 MTDiscord <Jordach> since minetest doesn't link to libpng anymore
19:46 MTDiscord <Jordach> while irrlicht does causes it to half static-link minetest and half dynamic like
19:46 MTDiscord <Jordach> link, which causes the mac kernel to shit the bed
19:46 MTDiscord <Jordach> (by extension probably BSD)
19:49 hecks -- Installing: ../libs/irrmt/usr/local/include/irrlichtmt/SSharedMeshBuffer.h
19:49 MTDiscord <Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870030130846785586/Screenshot_2021-07-28_at_20.48.57.png
19:49 hecks aaaaaaaaaaah so this is what make install does :-DDDDD
19:49 MTDiscord <Jordach> left: old CMake, right: new cmake
19:49 hecks see, should have told me i also needed to simulate the existence of /usr/local in my fake root...
19:49 hecks clown world...
19:53 MTDiscord <Jordach> also he forgot to read the damn comment in src/CMakeLists.txt
19:53 hecks oh and of course it still doesn't find it
19:53 MTDiscord <Jordach> Minetest itself does not use them, but we link them so that statically linking Irrlicht works.
19:53 hecks ok so
19:53 hecks i make install to a dummy dir
19:53 hecks i set DCMAKE_PREFIX_PATH to this dummy dir
19:53 hecks it still can't find anything
19:54 hecks what now
19:59 MTDiscord <Jordach> that should theoretically patch macOS
19:59 MTDiscord <Jordach> will jump into msvc land and solve that too
19:59 sfan5 hecks: does the described "option 1" not work for you?
19:59 hecks it just did BUT
19:59 hecks -DCMAKE_PREFIX_PATH=$libdir/irrmt/usr/local \
20:00 sfan5 your ideal setup will look different but I hope at least that works
20:00 hecks this is what you actually have to do
20:00 sfan5 did I accidentally leave out usr/local?
20:00 hecks yup
20:00 sfan5 oops
20:00 hecks anyway this is very brittle, i hope we never ever add any more dependencies in this way
20:01 sfan5 there is no need for them in principle, I removed them in my setup
20:01 hecks no more relying on cmake to find shit
20:01 hecks not everyone uses linux or wants to turn their system into linux
20:01 hecks this is fine to contain irrmt alone but no more
20:02 sfan5 well IrrlichtMt is going away so there won't be more
20:02 sfan5 just less
20:02 sfan5 eventually
20:03 hecks thanks for giving me one more reason to take this thing behind the shed and shoot it
20:07 MTDiscord <josiah_wi> It seems like good internet resources for learning about good dependency structuring are something computer science lacks, or I just haven't been able to find them. I've read many of the papers available online about good CMake design, and that was the foundation for the decisions I made in my PR.
20:07 MTDiscord <Warr1024> and dissolve the body in acid, it's the only way to be sure
20:08 hecks if a build system needs whitepapers to explain how to use it, it's probably byzantine rubbish
20:08 MTDiscord <josiah_wi> If someone could give me some references from people who really understand this stuff (not just controversial opinion) then I'd greatly appreciate it.
20:08 hecks my controversial opinion is that attempting to understand this stuff is the mistake =]
20:09 MTDiscord <Warr1024> There are 2 hard problems in computer science: 1. naming things, 2. concurrency, 2. concurrency, 2. concurrency, and 3. off-by-one errors.
20:09 MTDiscord <Jordach> if i can fix a horrifying cmake setup that only works on one machine and introduce support for vcpkg
20:09 MTDiscord <Jordach> this should be much less aggravating
20:09 hecks oh hey
20:10 hecks it fails to find irrlicht again... i hardly did anything
20:10 hecks this thing is cursed, people
20:11 MTDiscord <Jordach> ???
20:11 MTDiscord <Jordach> >removes cmakecache to force regeneration of files
20:11 hecks done already
20:11 MTDiscord <Jordach> >builds shared libraries as dynamic
20:12 hecks i'm already feeling the enhanced productivity
20:12 hecks this thing creates jobs!
20:16 MTDiscord <josiah_wi> Hecks' point is good, that if a build system is difficult to explain it's probably too complicated. I think that extends to stuff in general. However, this isn't supposed to be harder to explain and I don't understand why it is. I had hoped this would be a learning experience for me, but instead it's turning into a "you need to learn" experience.
20:17 MTDiscord <Jordach> using stackoverflow as a hammer to fix nails is a very bad idea™️
20:17 MTDiscord <Jordach> also - this line https://github.com/minetest/minetest/commit/cf136914cf421ee52f6806eda2fa97740d0ee552#diff-148715d6ea0c0ea0a346af3f6bd610d010d490eca35ac6a9b408748f7ca9e3f4L299 is extremely obvious
20:18 sfan5 yes it's very obvious
20:18 sfan5 because you know what the new cmake importing does
20:18 sfan5 it automatically handles this
20:19 MTDiscord <Jordach> no it's a cock up that makes the british government look functional
20:19 MTDiscord <Jordach> warning: changes being made to the file will invalidate the code signature in:
20:19 MTDiscord <Jordach> it's not static linking
20:19 MTDiscord <josiah_wi> I didn't use stack overflow except for debegging issues. I read papers about the right way to structure CMake builds. I have no other source. I read 3-4 papers and they all agreed. Nobody said there was a better way. Now everyone says I made a mistake but nobody wants to take the time to teach me, or they don't have a clue themselves, and I'm just tired and confused.
20:19 MTDiscord <josiah_wi> This is not how progress is made.
20:19 MTDiscord <Jordach> minetest-5.5.0-dev-osx/minetest.app/Contents/Frameworks/libpng16.16.dylib (amd64)
20:21 hecks if nobody in the room knows how to use cmake "properly" then why are we doing it...
20:21 MTDiscord <Jordach> what we had was human understandable and god forbid
20:22 MTDiscord <Jordach> a reasonably straightforwards user experience
20:22 hecks instead of monkey patching that MSVC build issue
20:22 hecks anyway uhhh
20:22 hecks my shit suddenly stopped working with /usr/local too =] i don't know what happened
20:23 MTDiscord <Jordach> we've reverted worse stuff for less
20:25 MTDiscord <josiah_wi> Based on the discussion I think explaining to Jordach why the static linking thing is irrelevant is unnecessary and pointless because it's internal CMake magic. All I can say is, if it's broken, file an issue. It's supposed to work.
20:25 MTDiscord <Jordach> i'm now hacking and chopping away at the cmake
20:25 MTDiscord <Jordach> because before even with your irrlicht changes it was fine
20:26 MTDiscord <josiah_wi> Ironically most of the magic happens on the Irrlicht side.
20:26 MTDiscord <Jordach> it's the crap job done to CMakeLists
20:26 MTDiscord <Jordach> and i build with clang
20:27 sfan5 this is pointless without further detail
20:27 sfan5 such as your irrmt build flags
20:27 MTDiscord <Jordach> i stuffed irrmt into /libs/irrlichtmt
20:27 MTDiscord <Jordach> for some reason, libpng is dynamic linkingh
20:28 sfan5 didn't you used to need some flag to tell it to not do that?
20:28 sfan5 if so, add it again this time to the MT cmake command
20:28 MTDiscord <Jordach> the correct result is that all libraries staticly link
20:29 MTDiscord <Jordach> and have zero dylib files inside the app
20:30 hecks wow finally
20:30 MTDiscord <josiah_wi> I remember some libpng thing in Jordach's script, and yes, it should just be passed to irrlicht instead, which I'm uncertain about with the lib/irrlichtmt structure.
20:31 sfan5 it should still read global flags, anything else would be bad
20:31 MTDiscord <Jordach> that was because minetest needs to depend on it from generating a linked library to a linked lib
20:31 MTDiscord <Jordach> this prevents that entire scenario
20:32 sfan5 does it?
20:32 MTDiscord <Jordach> building MT with brew caused dylibs to lose their code signatures
20:32 MTDiscord <Jordach> i've had to build every MT dependancy manually
20:36 MTDiscord <Jordach> > cmake . -DRUN_IN_PLACE=FALSE -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DBUILD_SHARED_LIBS=FALSE
20:36 MTDiscord <josiah_wi> There may be an exception to the "it should be simple to use" concept, and that's when you're trying to wrangle the CMakeLists to make Mac work. I should've documented the system very thoroughly, and I'm increasingly convinced I need to go do that rn, but understanding CMake helps with developing it.
20:36 MTDiscord <Jordach> still generates a libpng dyld
20:36 sfan5 minetest does not build libpng so it does not "generate" the .dylib
20:36 MTDiscord <josiah_wi> Aren't you building libpng yourself?
20:36 sfan5 rather it's probably picking it
20:36 MTDiscord <Jordach> it's already compiled locally
20:36 sfan5 so you should point it to the libpng.a
20:37 MTDiscord <josiah_wi> ^
20:37 MTDiscord <Jordach> i've also stripped the offending ARM NEON nonsense from it
20:38 MTDiscord <josiah_wi> Considering that the project's goal is to absorb Irrlicht I'm not sure how much time is worth putting into documenting the CMakeLists in detail.
20:39 MTDiscord <Jordach> full clean rebuild time
20:40 MTDiscord <josiah_wi> You're going to need to set the paths to your static dependencies (e.g. libpng.a) in any event.
20:40 MTDiscord <Jordach> this was with src/CMakeLists.txt changes to ensure png is properly linked
20:40 MTDiscord <Jordach> this test is without
20:41 MTDiscord <josiah_wi> You added it without even testing the original?
20:41 MTDiscord <Jordach> known working state first
20:41 MTDiscord <Jordach> then play with it
20:42 MTDiscord <Jordach> same result
20:42 Extex joined #minetest-dev
20:42 MTDiscord <josiah_wi> I actually highly recommend compiling irrlicht in a seperate directory.
20:43 MTDiscord <Jordach> > Minetest.app/Contents/MacOS/minetest: Mach-O universal binary with 2 architectures: x86_64:Mach-O 64-bit executable x86_64
20:43 MTDiscord <josiah_wi> Did you try the script I modified for you?
20:43 MTDiscord <Jordach> i don't make unknown changes to scripts without testing in a sandbox env first
20:43 MTDiscord <Jordach> i'm not going to YOLO existing builds into the void
20:43 MTDiscord <josiah_wi> The recommendation isn't for general usecase btw, just for this.
20:44 MTDiscord <Jordach> my build argument looks more like
20:44 MTDiscord <Jordach> cmake . -DBUILD_SHARED_LIBS=FALSE -DPNG_LIBRARY=/usr/local/libpng/1_6_37/lib/libpng16.a -DRUN_IN_PLACE=FALSE -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
20:44 MTDiscord <josiah_wi> Well shoot, I tried to get your script updated and here you are calling me stupid and fumbling with CMake without even testing ite
20:45 MTDiscord <Jordach> i distrust other's changes for sanity
20:45 MTDiscord <Jordach> the last time that happened rm and -rf were very good friends with *
20:45 MTDiscord <josiah_wi> I hardly changed much. You could easily check what it does.
20:47 MTDiscord <josiah_wi> The reason I recommend compiling Irrlicht in a seperate directory for this is because you can then deal with them seperately instead of both trying to configure at once.
20:47 MTDiscord <Jordach> i can now safely test that it does build
20:48 MTDiscord <Jordach> it does not mean however it's safe to use
20:48 MTDiscord <Jordach> as MSVC needs checking
20:49 MTDiscord <josiah_wi> I have a fear that I was ignorant and removed the PNG thing, but I will check that now.
20:50 MTDiscord <Jordach> potentially
20:50 MTDiscord <josiah_wi> My fear was unfounded; it's there where it should be.
20:51 MTDiscord <Jordach> i never made a single PR to minetest without triple checking things work as expected
20:51 MTDiscord <Jordach> set_sky went through a ton of personal scrutiny
20:52 MTDiscord <josiah_wi> I checked more than 4 times, on my system. You're the Mac guy; I don't have the tools to test on a Mac and you do.
20:52 MTDiscord <Jordach> OpenCore exists
20:52 MTDiscord <Jordach> you can easily test with a VM under VESA drivers
20:53 MTDiscord <Jordach> but because i'm effectively the Mac maintainer
20:53 MTDiscord <Jordach> also
20:53 MTDiscord <Jordach> running your modified irrlicht command didn't generate them right
20:54 MTDiscord <Jordach> it didn't fix irrlicht being wrong
20:54 MTDiscord <josiah_wi> Wrong how?
20:54 sfan5 Minetest does not run under opencore
20:54 sfan5 it fails to create a GL context
20:54 sfan5 just compiling is fine
20:54 MTDiscord <josiah_wi> Let's not forget I reached out to Jordach before PRing this to get his input.
20:54 MTDiscord <Jordach> it shat the .a out in /lib/OSX/libIrrlichtMt.a
20:55 MTDiscord <josiah_wi> Ok so?
20:55 MTDiscord <Jordach> two months ago in PR hell
20:55 MTDiscord <josiah_wi> It shouldn't have put it in /lib. I'll recheck the script.
20:56 MTDiscord <Jordach> i'm not pasting the command as it's nearly six years long
20:56 MTDiscord <Jordach> https://gist.github.com/Jordach/860ea57263c28c0755ef32cf222e6b28
20:57 MTDiscord <josiah_wi> Ok, so it built.
20:57 MTDiscord <josiah_wi> What's the problem?
20:57 MTDiscord <Jordach> builds fine, doesn't spew the things in the right places
20:57 MTDiscord <Jordach> otherwise cmake won't find it
20:57 MTDiscord <Jordach> which is exactly the problem hecks is havinfg
20:58 MTDiscord <josiah_wi> Did you run the make install?
20:58 hecks well i'm kinda done with that but i still find this disgusting :o
20:58 MTDiscord <Jordach> you think i want to shit up my path
20:58 MTDiscord <Jordach> no
20:58 MTDiscord <josiah_wi> It just puts it in a bin/ folder.
20:58 MTDiscord <josiah_wi> irrlicht/bin
20:59 MTDiscord <Jordach> and i have to run that on every irrlicht change
20:59 MTDiscord <josiah_wi> I fail to see the downside.
20:59 hecks but if this thing placed files anywhere outside of my mt dev folder i'd be furious
20:59 hecks so if this happens to Jordach then it's a pretty bad thing
20:59 MTDiscord <Jordach> why does it even need to bother with any other directory outside of lib
21:00 MTDiscord <josiah_wi> It doesn't.
21:00 MTDiscord <Jordach> APFS doesn't support symlinks
21:00 MTDiscord <josiah_wi> make install can keep everything in your dev directory.
21:00 MTDiscord <josiah_wi> No need to symlink.
21:00 MTDiscord <josiah_wi> Read the script.
21:00 hecks wow wtf
21:00 hecks it's failing again
21:01 hecks oh of course
21:01 hecks now i have to rebase every branch
21:01 hecks every PR in existence is suddenly [rebase needed]
21:02 hecks after you "upgrade" your scripts you cannot build any branches made before
21:02 MTDiscord <Jordach> and this is exactly why i don't want to run his scripts without sandboxed testing
21:03 MTDiscord <Jordach> i've been bit before by bad bash scripts
21:03 MTDiscord <josiah_wi> I just modified yours slightly though.
21:03 sfan5 could pass the old and the new variables at the same time
21:03 MTDiscord <Jordach> you missed certain things entirely lmao
21:03 MTDiscord <Jordach> x64 contains a different build argument to arm64
21:04 MTDiscord <josiah_wi> I can see myself missing that.
21:04 hecks left #minetest-dev
21:04 hecks joined #minetest-dev
21:04 MTDiscord <josiah_wi> That's why I showed you the script early on for review e
21:04 MTDiscord <Jordach> and this is why i basically have a notepad open at all times for note taking of interesting behaviors
21:04 MTDiscord <Jordach> sometimes it'll be there when you're scratching your head
21:04 MTDiscord <josiah_wi> I'm trying to work with you and you've done absolutely nothing to work with you.
21:04 MTDiscord <josiah_wi> to work with me*
21:05 sfan5 I don't think whatever you guys are doing is going anywhere
21:05 MTDiscord <josiah_wi> Yeah obviously. :|
21:06 MTDiscord <josiah_wi> It's just Jordach explaining to me why he's mad at me or something like that.
21:06 MTDiscord <Jordach> i'm not seeing where cmake_install_prefix is even used in irrlicht's cmakelists
21:07 MTDiscord <josiah_wi> It's built in to CMake. I honestly shouldn't have hijacked it for this but I did.
21:07 MTDiscord <Jordach> why does the user need to know arcane cmake arguments
21:07 v-rob Would you like me to try this out to get another person's input? For reference, I use Windows + VS and the CMake GUI
21:07 MTDiscord <josiah_wi> He doesn't because it's documented in the README.
21:08 MTDiscord <josiah_wi> It's up to you v-rob.
21:09 MTDiscord <Jordach> > standard install path.
21:09 MTDiscord <Jordach> that reads as if it's installing systemwide
21:09 MTDiscord <Jordach> and any power user or sysadmin will be largely suspicious
21:09 MTDiscord <Jordach> explain that /bin will largely contain it within it's own folder
21:10 MTDiscord <josiah_wi> Thank you. That's useful input.
21:10 MTDiscord <Jordach> i wrote this https://github.com/Aurailus/Zepha/blob/master/docs/Building.md#windows after unscrewing the completely wack cmake
21:12 MTDiscord <Jordach> and yes, cmake doesn't agree with find_package at times either
21:12 MTDiscord <josiah_wi> v-rob I've heard the CMake GUI has issues with this build process. If I'm writing a solid section in the README knowing more about that might help.
21:12 sfan5 haven't had any issues with msvc
21:14 Pexin I have never heard of "make install" meaning anything except systemwide
21:14 hecks well here it has a magical variable to make it not systemwide... but you can't blame anyone for being suspicious
21:14 hecks or disgusted
21:16 MTDiscord <josiah_wi> I understand. It could install in a bin/ folder by default but the command would still be suspicious...
21:18 v-rob Well, first off, I have IrrlichtMt cloned to a folder, "irrlicht" and I build to another folder, "irrlicht-build" (which is the same way I build Minetest, which is what the Minetest readme says to do for Windows + VS). In the CMake GUI, I still have the options "IRRLICHT_INCLUDE_DIR" and "IRRLICHT_LIBRARY", but they don't work anymore (as expected). There's also one called "IrrlichtMt_DIR" which is not initialized and doesn't seem to do anything. So,
21:18 v-rob how do I proceed from here?
21:19 sfan5 the only sane option here is to move irrlicht to minetest/lib/irrlichtmt and let the rest happen automatically
21:19 hecks it's not sane because it literally doesn't work for some
21:19 hecks (me)
21:19 v-rob Oh, I'm supposed to put Irrlicht directly into the Minetest folder?
21:20 sfan5 it's not a requirement but it's an easy way of getting this to work
21:20 hecks minetest/lib/irrlichtmt (hardcoded gitignored path)
21:20 hecks prepare for cmake to get really confused though
21:21 v-rob (BTW hecks, IrrlichtMt compiles really fast now :D)
21:21 hecks yes it does...
21:22 hecks it'll be even faster, i need to get back to work
21:23 entuland joined #minetest-dev
21:23 MTDiscord <josiah_wi> I technically footshot myself because I installed Irrlicht to root to test it, but my updated install is in ~/.local, so if I forget no point CMake to ~/.local it'll work but be the wrong Irrlicht commit.
21:25 v-rob Ouch, I'd better close some programs. I just got a "compiler out of heap space" error :O
21:25 sfan5 @josiah_wi when/where/how are the Target .cmake files generated?
21:26 MTDiscord <josiah_wi> It looks like make install generates it because I can't find it in the build tree, but I didn't run "find" so I'm uncertain yet.
21:28 MTDiscord <josiah_wi> In the CMake lists the install part of it creates an export for the targets that tells which targets to export. The generation of the file is automatic.
21:31 sfan5 hm
21:32 sfan5 that cmake doesn't allow importing a library from a project checkout is unfortunate
21:32 sfan5 when it could easily internally shuffle that stuff around or whatever and do the right thingtm
21:32 sfan5 oh right my compose key doesn't work
21:33 MTDiscord <josiah_wi> It is unfortunate; that'd be extremely useful. I'm trying to think of a way to hax it in to doing that anyway.
21:34 v-rob MSVC really needs to stop lying that strcpy is deprecated and encouraging me to use its proprietary strcpy_s...
21:34 v-rob Anyhow, the new CMake build system seems to work fine for me.
21:34 v-rob MT built fine and runs fine
21:35 hecks so only osx and mingw got shafted
21:35 v-rob Although, does CMake put IrrlichtMt.dll in bin? I used to have to copy that manually
21:36 MTDiscord <josiah_wi> Bummer. sfan, it is supported.
21:37 MTDiscord <josiah_wi> We can export a Targets file with no install.
21:37 MTDiscord <josiah_wi> Point Minetest to that file and bam. All works without an install.
21:38 sfan5 v-rob: irrlichtmt is statically linked in this case
21:38 v-rob Oh, gotcha
21:38 sfan5 @josiah_wi I don't exact get it yet but please prepare a PR
21:39 MTDiscord <josiah_wi> https://cmake.org/cmake/help/git-stage/guide/importing-exporting/index.html#exporting-targets-from-the-build-tree
21:39 v-rob Well, for me at least, everything works fine then. It's certainly an improvement for my workflow
21:39 MTDiscord <josiah_wi> Tutorial in docs. It's a recent version that has the tutorial but it should work in 3.5 (will check though)
21:41 sfan5 lib/irrlichtmt is an earlier change, in theory it could have been fixed to work with MSVC (it always worked on Linux) before and without this change that is causing all the controversy
21:41 hecks joined #minetest-dev
21:45 calcul0n joined #minetest-dev
21:49 v-rob joined #minetest-dev
21:50 sfan5 <sfan5> lib/irrlichtmt is an earlier change, in theory it could have been fixed to work with MSVC (it always worked on Linux) before and without this change that is causing all the controversy
21:50 sfan5 (repost so it doesn't get missed)
21:58 sfan5 mfw clicked add single comment instead of starting a review
21:58 MTDiscord <Jordach> @josiah_wi wat the fak; building with the pseudo install doesn't generate the bad dylib
21:58 Extex joined #minetest-dev
21:59 MTDiscord <Jordach> even with the PNG library not included
22:01 MTDiscord <Jordach> and what is that segfault
22:02 MTDiscord <Jordach> uh why is loading .x models causing segfaults
22:02 MTDiscord <Jordach> hecks ^
22:02 MTDiscord <Jordach> Unknown data object in material list in x file: Material zsh: segmentation fault  ./Minetest.app/Contents/MacOS/minetest
22:03 MTDiscord <Jordach> devtest boots fine, but other games that use .x don't
22:05 MTDiscord <Jordach> i know this affects your game too hecks
22:05 sfan5 perhaps it doesn't hence it's not been noticed
22:05 MTDiscord <Jordach> his game uses .x like mine
22:06 sfan5 not all files are identical
22:06 MTDiscord <Jordach> mine was made with the ancient 2.7 .x exporter
22:06 MTDiscord <Jordach> his is likely with his variant
22:06 MTDiscord <josiah_wi> sfan5, running a test build to completion before PRing to make sure it works. Looks good so far. Do you want me to PR a change to Minetest to use an IRRLICHT_DIR variable instead of the magic PREFIX_PATH thingymijig?
22:06 sfan5 no prefix path is okay for installed stuff (the buildbot needs it after all)
22:07 sfan5 but an extra IRRLICHT_SOURCE_DIR is what I'm thinking of
22:07 MTDiscord <josiah_wi> Sure thing.
22:07 MTDiscord <Jordach> i think the suspect might be in set_attach
22:08 MTDiscord <Jordach> the hint is that it loads non attached models fine
22:08 sfan5 just grepped for some stuff and
22:08 sfan5 src/inventory.cpp:// Obsoleted on 2011-10-14
22:08 sfan5 heh
22:09 hecks sup
22:09 MTDiscord <Jordach> old blender 2.7 .x files seem to segfault
22:09 hecks .x should not cause segfaults.... i just built and ran everything
22:09 hecks maybe it's the old exporter's fault
22:09 MTDiscord <Jordach> https://gist.github.com/Jordach/774a71aa90f7bf381d2b9b03d38519f4
22:09 hecks which section does it fault on?
22:09 MTDiscord <Jordach> i did get a stack trace
22:09 hecks i slightly edited the importer
22:09 MTDiscord <Jordach> irr::scene::CXMeshFileLoader
22:10 hecks yeah obviously
22:10 MTDiscord <Jordach> namely complaining about materials
22:10 MTDiscord <Jordach> lemme upload a gif to show you, as it loads unanimated meshes fine
22:10 MTDiscord <Jordach> (or unattached)
22:10 hecks what would a gif tell me though
22:11 hecks what i deleted from that importer was parsing the actual materials
22:11 hecks since we do not use those
22:11 MTDiscord <Jordach> how else do tyou apply textures
22:12 hecks i
22:12 hecks we still parse material slots
22:12 hecks just not the actual material content
22:12 MTDiscord <Jordach> ah
22:12 hecks and don't load the textures
22:12 MTDiscord <Jordach> i never included textures as i used cycles materials to export under
22:13 MTDiscord <Jordach> because BI / Internal maps to that
22:13 hecks well minetest does not utilize any of that anyway
22:13 hecks you still have to specify the tiles in the cao def
22:13 hecks so all that matters are the slots
22:13 MTDiscord <Jordach> but yes, it explodes: Unknown data object in material list in x file: Material
22:14 hecks hmmm
22:14 MTDiscord <Jordach> just because we bikeshedded a new exporter doesn't mean we shouldn't test with older formatszx
22:14 MTDiscord <Jordach> exports even
22:14 hecks it's not that, the "new" exporter would also do this
22:15 hecks i only ported it
22:15 hecks thing is that i deleted the "texture loader" feature that this depended on
22:15 MTDiscord <Jordach> at least we have a verified sigsegv
22:16 hecks the warning can be suppressed but what's actually causing it to crash?
22:16 MTDiscord <Jordach> it runs to the end of materials then just segfaults
22:16 MTDiscord <Jordach> i could six materials which would match one of the first person attachments
22:17 MTDiscord <Jordach> well count
22:18 MTDiscord <Jordach> that said with all the changes since 5.4 this might as well be called 6.0
22:22 hecks we don't have to do that if we don't break any supported api too hard
22:22 hecks and TGA files did not count as supported =]
22:22 MTDiscord <Jordach> with all the build changes and internal changes leading up to outright replacements?
22:24 hecks i don't know, ask the people who give a damn about semver
22:24 hecks i didn't, i think the 5.0 version inflation was a joke
22:25 MTDiscord <josiah_wi> irr#49
22:25 ShadowBot https://github.com/minetest/irrlicht/issues/49 -- Export targets to build tree by JosiahWI
22:26 MTDiscord <josiah_wi> BTW this is usable as soon as it's merged by setting CMAKE_PREFIX_PATH to your Irrlicht source directory.
22:26 MTDiscord <josiah_wi> No make install anymore.
22:26 MTDiscord <Jordach> also consider writing that into the readme.md
22:26 hecks are the artifacts gitignored properly?
22:27 MTDiscord <Jordach> as this is rather outdated https://github.com/minetest/irrlicht#build
22:27 MTDiscord <josiah_wi> Artifacts?
22:27 hecks whatever cmake produces
22:27 sfan5 yes?
22:28 sfan5 in general I mean, can't comment on the just linked PR
22:28 MTDiscord <josiah_wi> ...no the Targets file isn't. Thanks.
22:29 hecks install_manifest.txt also wasn't but i guess it won't be needed now
22:29 MTDiscord <josiah_wi> Oh, but it goes in build/ which isn't .gitignored. 😕
22:29 MTDiscord <josiah_wi> Advice?
22:29 MTDiscord <josiah_wi> Oh because I'm using a build directory and some don't.
22:29 MTDiscord <josiah_wi> Nevermind.
22:34 MTDiscord <josiah_wi> I fixed the .gitignore. I'm not sure what I should say in the README.
22:34 MTDiscord <Jordach> about the fact it prints things into /build/ for use with minetest's cmake command
22:37 hecks So now you're supposed to point the cmake prefix dir to the checkout?
22:38 MTDiscord <Jordach> reading the commit, It is insecure and inconvenient to necessitate installing IrrlichtMt to access the target export
22:38 MTDiscord <josiah_wi> Done. Please review.
22:38 MTDiscord <Jordach> basically from what i see all it does is skip the make install step
22:38 MTDiscord <josiah_wi> Correct.
22:39 MTDiscord <josiah_wi> I thought that's exactly what you wanted.
22:39 MTDiscord <Jordach> it still places everything within the folder providing /bin/
22:39 hecks now how will it cope with the fact that the /include/ and /lib/ structure is not the same as the installed one?
22:39 MTDiscord <josiah_wi> No Jordach, it uses the build tree now.
22:39 hecks /include/irrlichtmt became just /include/, while /lib/ became /lib/[system]/
22:40 MTDiscord <josiah_wi> Hecks, those paths are completely flexible.
22:40 hecks we shall see...
22:40 MTDiscord <josiah_wi> I did just test it.
22:40 MTDiscord <Jordach> hecks: prefix was set to =/bin
22:40 MTDiscord <Jordach> https://gist.github.com/Jordach/753e6dde979f2ca7c1f3ffa56e2f2fba
22:40 MTDiscord <Jordach> entire log
22:41 MTDiscord <josiah_wi> The Targets file knows where the library and headers are located. It grabs them straight from the build tree.
22:42 MTDiscord <josiah_wi> It's a testament to how good the Irrlicht build is that I didn't have to modify a single path. I actually thought I might have to.
22:42 hecks okay, the targets file is generated correctly
22:42 hecks wait, uh oh
22:43 hecks it's looking for IrrlichtMtConfig.cmake in the wrong dir now
22:44 MTDiscord <josiah_wi> Did you set CMAKE_PREFIX_PATH to your irrlicht checkout? Even if you did it might fail and I understand why.
22:44 hecks of course, now what
22:44 hecks it's looking for the file in one dir above
22:45 MTDiscord <josiah_wi> Probably have to PR to Minetest to fix that. I use an out of source build which works but many Minetest devs do not.
22:46 hecks uhhhh wait....
22:46 MTDiscord <josiah_wi> I should update the docs.
22:48 MTDiscord <josiah_wi> Updated.
22:49 hecks i cleaned everything and tried again and now it's
22:49 MTDiscord <josiah_wi> Oh. Whups.
22:49 MTDiscord <josiah_wi> Time to revert.
22:49 hecks there's a duplicate IrrlichtMtConfig in the root folder which can't find IrrlichtMtTargets
22:50 hecks in the checkout
22:50 hecks when i deleted that it worked
22:52 MTDiscord <josiah_wi> Ok. I think this is good for final review then.
22:53 MTDiscord <josiah_wi> I should've done this in the first place, or rather researched whether it was possible. I'm relieved I did learn something from this experience.
22:54 MTDiscord <Jordach> i want minetest to be wholly much better when it comes to user experience
22:54 MTDiscord <Jordach> that cannot be possible without holding contributors to standards
22:54 MTDiscord <Jordach> which includes documentation for users who may be first time
22:55 sfan5 I reviewed a PR
22:55 sfan5 time to go to bed
22:55 MTDiscord <josiah_wi> Well, thank you for holding me to the standard, but this could've been done hours ago if we'd discussed solutions instead of arguing about the problem.
22:55 hecks well it works now, it's just slightly fishy (abusing a generic path prefix)
22:55 MTDiscord <Jordach> the lack of documentation was the problem
22:55 MTDiscord <Jordach> it didn't explain what it was attempting
22:55 hecks if this was an irrlicht specific variable again it would be good
22:56 MTDiscord <Jordach> and given anyone with an experience with a computer, installation means administrative rights
22:56 hecks but we will never ever use this mechanism again, i'll make sure of it, so that might be moot
22:56 MTDiscord <josiah_wi> Yes hecks, I'll be PRing that but I don't have time this afternoon as it's getting late and I'm tired.
22:57 hecks now back to the broken .x files
22:58 hecks i could monkey patch that by parsing the material blocks again but
22:58 hecks we literally won't have an SMaterial type soon
22:58 MTDiscord <Jordach> i'd rather it just silently fail or discard the data
22:58 MTDiscord <Jordach> or at least leave a warning in the console to use the newer exporter
22:59 hecks does a newer exporter fix it?
22:59 MTDiscord <Jordach> your one might
22:59 hecks i wouldn't know because i actually strip that block from my files
22:59 MTDiscord <Jordach> not tested it
23:00 hecks but that's not something done by the blender exporter i posted
23:00 MTDiscord <Jordach> suprised you didn;t intergrate that with the updated exporter
23:00 hecks that one is just the 2.7x version updated for the 2.80 depsgraph
23:00 hecks i did not integrate it because that exporter is cancer
23:00 MTDiscord <Jordach> fair
23:00 hecks i don't even use it anymore
23:01 hecks i export lsd, parse it, process it, and write back an .x in lua
23:01 sfan5 fyi having to reexport models does not match minetest's usual compatibility strategy
23:01 MTDiscord <Jordach> yes
23:02 sfan5 now this is a first because irrlicht code has never really seen changes before
23:02 hecks it's a bug, i'll fix it
23:02 MTDiscord <Jordach> that actually would be very annoying
23:02 MTDiscord <Jordach> thanks hecks
23:02 sfan5 but we have to think about it before 5.5 or face complains that N-year old mods no longer work
23:02 * sfan5 now actually off
23:02 MTDiscord <Jordach> other than MCL
23:02 MTDiscord <Jordach> lmao
23:02 hecks aren't we the only .x users
23:02 MTDiscord <Jordach> yes
23:04 hecks MCL... what's that again?
23:04 MTDiscord <Jordach> the most idiotic thing to make with the engine
23:04 hecks literally minecraft?
23:06 MTDiscord <Jordach> yes
23:06 MTDiscord <Jordach> so many interesting topics and they choose that
23:06 hecks so that's where all the stupid feature requests come from
23:06 MTDiscord <Jordach> yeeep
23:07 hecks 'can we have this, minecraft has this, please hardcode this we need this'
23:07 sfan5 that's rare(er)
23:07 sfan5 I'd say most raised in connection to mcl actually show lack of flexibility in the engine
23:07 sfan5 though the proposed solutions aren't always good
23:08 hecks i vaguely remember some requests literally asking to hardcode something
23:08 hecks or really close
23:08 sfan5 when you said hardcoding I was thinking of the dual wielding PR
23:08 sfan5 or in other words hardcoding a second hand
23:08 hecks :DDDD yes that one
23:08 hecks that's a prime example of minecraft myopia
23:09 hecks viewmodels? no second HAND :DDDD
23:09 hecks or this uhhh
23:09 MTDiscord <Jordach> honestly viewmodels would be rather lit
23:09 hecks yes they would
23:09 MTDiscord <Jordach> as long as they had entity like controls
23:09 hecks but instead of viewmodels someone just suggested a second hand, without figuring out how exactly this would logically work
23:09 hecks didn't they suggest a hardcoded inventory cell for it?
23:09 sfan5 there's so many easy targets of hardcoded stuff that can be unhardcoded + nice API
23:10 sfan5 someone just needs to do it
23:10 MTDiscord <Jordach> i actually have a way to sort of hack in dual wielding
23:10 hecks i literally have a second hand in the game... it just doesn't have a first person representation
23:10 MTDiscord <Jordach> exactly
23:10 hecks though with that new CAO flag or whatever that was, it might work
23:11 hecks viewmodels aren't hard, i just have more important things to do
23:28 hecks irr#50 Jordach
23:28 ShadowBot https://github.com/minetest/irrlicht/issues/50 -- Fix .x material slot parsing by hecktest
23:28 hecks try this
23:28 MTDiscord <Jordach> one min king
23:29 hecks i can't actually test out an unoptimized .x file at the moment because uh for one i straight up don't have the pipeline for these now
23:29 hecks and second, any of my models exported as unoptimized .x would not fit within the 8 meg limit
23:30 MTDiscord <Jordach> reconstructing
23:33 MTDiscord <Jordach> halfway there
23:36 MTDiscord <Jordach> loads but segfaults when checking for normals
23:36 MTDiscord <Jordach> 0   net.minetest.minetest             checkMeshNormals(irr::scene::IMesh*) + 96
23:36 MTDiscord <Jordach> i see a frame of the attachments before it segfaults
23:37 MTDiscord <Jordach> ...now it works?
23:39 MTDiscord <Jordach> seems to be kind of intermittent
23:39 MTDiscord <Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870088105259061258/Screenshot_2021-07-29_at_00.38.45.png
23:40 MTDiscord <Jordach> curious
23:40 MTDiscord <Jordach> it happened against after starting a game, exiting to menu, then starting a new game
23:41 MTDiscord <Jordach> hecks: checkMeshNormals(irr::scene::IMesh*)
23:41 MTDiscord <Jordach> seems to be where the fault lies
23:41 hecks hmmmmmmm
23:41 hecks so it no longer dies in the parser, it's just malformed now
23:41 MTDiscord <Jordach> lemme check
23:41 MTDiscord <Jordach> if it's one model
23:41 hecks and if it's random, it's something uninitialized
23:42 MTDiscord <Jordach> nope it's just that one model
23:42 MTDiscord <Jordach> memory leak spotted
23:43 MTDiscord <Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870089006703050752/Screenshot_2021-07-29_at_00.42.36.png
23:43 MTDiscord <Jordach> https://cdn.discordapp.com/attachments/747163566800633906/870089011945959444/Screenshot_2021-07-29_at_00.42.39.png
23:43 hecks :DDDDD oops
23:44 MTDiscord <Jordach> system didn't panic so it's all good
23:44 MTDiscord <Jordach> one model explicitly explods
23:44 MTDiscord <Jordach> https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_shotgun.x shits the bed
23:45 MTDiscord <Jordach> https://raw.githubusercontent.com/Dumpster-Studios/BattleForArkhos/fps_game/mods/weapons/models/arms_spnkrx.x doesn't
23:48 Alias2 joined #minetest-dev
23:50 hecks sure is a lot of materials
23:50 MTDiscord <Jordach> i'm doing a more unique method of texturing
23:51 MTDiscord <Jordach> by having infinitely tileable textures
23:51 hecks be aware that this increases drawcalls
23:51 MTDiscord <Jordach> breathing in minetest increases drawcalls
23:51 MTDiscord <Jordach> what else isn't new
23:51 hecks i'm just sayin
23:52 MTDiscord <Jordach> i tend to use not many]

| Channels | #minetest-dev index | Today | | Google Search | Plaintext