Minetest logo

IRC log for #minetest-dev, 2021-03-10

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

All times shown according to UTC.

Time Nick Message
00:30 Fractalis joined #minetest-dev
00:38 Fractalis joined #minetest-dev
00:38 hlqkj1 joined #minetest-dev
00:40 hlqkj1_ joined #minetest-dev
01:02 I_am_6r1d joined #minetest-dev
01:33 EvergreenTree_ joined #minetest-dev
01:33 _0_ joined #minetest-dev
01:34 jomat_ joined #minetest-dev
01:36 EvergreenTree_ joined #minetest-dev
01:37 EvergreenTree_ joined #minetest-dev
01:39 Emojiwiki joined #minetest-dev
01:42 Emojiwiki Foward from Discord
01:42 Emojiwiki Emojidiscord: I got this message while compiling which said I should use minetest's irrlicht fork. I know what happend, but I don't want to globally install minetest's fork of it. How to compile without globaly install irrlicht fork?
01:42 Emojiwiki Rubenwardy: You need to use Minetest's Irrlicht fork now (with some solution)
01:42 Emojiwiki Emojidiscord: I download and compiled irrlicht at /home/foobar/irrlicht with -DBUILD_SHARED_LIBS=OFF on irrlicht then used -DIRRLICHT_INCLUDE_DIR=/home/foobar/irrlicht in minetest but got the same error as not installed the fork
01:42 Emojiwiki Rubenwardy: there are other settings, `IRRLICHT_LIBRARY` probably
01:42 Emojiwiki Emojidiscord: Same (photo https://cdn.discordapp.com/attachments/369137254641303560/819020372304461834/unknown.png )
01:42 Emojiwiki (Continue to IRC)
01:43 Emojiwiki PS: I am Emojidiscord
01:43 rubenwardy the conversation: https://rwdy.uk/JwHBh.png
01:44 rubenwardy the fact that IRRLICHT_INCLUDE_DIR and IRRLICHT_LIBRARY exists implies that it's using a legacy cmake module :(
01:44 Emojiwiki I am using the ninja compiler, is it the reason?
01:53 Emojidiscord Using cmake `-DIRRLICHT_LIBRARY=/home/foobar/irrlicht/lib/Linux/libIrrlicht.` but failed.
01:57 rubenwardy are you missing an a?
01:57 rubenwardy of copy and past issue
01:57 rubenwardy *or
01:57 rubenwardy you might need to delete CMakeCache.txt and CMakeFiles and rerun cmake. Somethings things stick around
02:02 Emojidiscord missing an a: no, just copy and paste typo
02:02 Emojidiscord rubenwardy delete cache and makefiles: still buggy
02:02 Emojidiscord makefiles -> cmake files
02:11 Emojidiscord finally success
02:46 I_am_6r1d joined #minetest-dev
03:30 mw__ joined #minetest-dev
03:54 mw__ joined #minetest-dev
04:22 mw__ joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
05:09 MTDiscord <Techy5> Why is the deleteblocks command so agonizingly slow? Something like /deleteblocks here 32 takes maybe 15-30 seconds. For comparison, deleting those mapblocks using my external program takes less than a second, and MT regenerates the area in a couple seconds when I join the game again.
05:17 MTDiscord <Techy5> I tried deleting a 100+ node radius, and it pretty much crashed the game. Again, deleting blocks with SQL + letting MT regenerate them took only a few seconds.
05:43 indiana joined #minetest-dev
06:45 olliy joined #minetest-dev
07:44 proller joined #minetest-dev
07:56 nerzhul the transition is not so easy
08:00 ShadowNinja joined #minetest-dev
09:37 sfan5 rubenwardy: what is a "legacy cmake module"?
10:24 proller joined #minetest-dev
10:30 hlqkj joined #minetest-dev
10:32 Fixer joined #minetest-dev
10:39 calcul0n_ joined #minetest-dev
10:48 freshreplicant[m joined #minetest-dev
11:24 kb1000 joined #minetest-dev
11:24 Zughy[m] joined #minetest-dev
11:24 Newbyte joined #minetest-dev
11:24 giov4[m] joined #minetest-dev
11:28 hlqkj1_ joined #minetest-dev
11:44 Zughy[m] free PR to merge: #11038
11:44 ShadowBot https://github.com/minetest/minetest/issues/11038 -- Builtin: Italian translation by Zughy
11:45 hlqkj1 joined #minetest-dev
12:01 Lunatrius joined #minetest-dev
12:24 tech_exorcist joined #minetest-dev
13:34 tech_exorcist joined #minetest-dev
13:37 tech_exorcist joined #minetest-dev
14:10 hlqkj1 joined #minetest-dev
14:29 z812 joined #minetest-dev
14:30 sfan5 rubenwardy: can you push this to gitlab so I can see if the ci runs? https://github.com/sfan5/minetest/tree/cmakestuff1
14:31 rubenwardy remember that minetest/minetest pushes to GL automatically
14:31 rubenwardy <sfan5> rubenwardy: what is a "legacy cmake module"?
14:31 rubenwardy It uses variables rather than targets
14:32 sfan5 does minetest/minetest push to gitlab even if it's not the master branch?
14:32 sfan5 i'll just try
14:46 rubenwardy yeah
15:28 z812 joined #minetest-dev
15:32 DS-minetest joined #minetest-dev
15:33 z812 joined #minetest-dev
15:38 z812 joined #minetest-dev
16:01 Krock What's the purpose of m_nnlistsizes within NodeResolver?
16:01 Krock why is it even needed?
16:05 Krock most of the node resolver code seems totally superfluous. it's just an overcomplicated queue
16:15 Wuzzy joined #minetest-dev
16:26 tech_exorcist joined #minetest-dev
16:31 tech_exorcist joined #minetest-dev
16:34 sfan5 ¯\_(ツ)_/¯
16:35 v-rob joined #minetest-dev
16:41 Wuzzy oh wow, you people actually forked irrlicht. i can't believe it. what's that thing about?
16:42 MTDiscord <Jordach> a long list of reasons that would be considered paste spam
16:42 Wuzzy haha
16:42 MTDiscord <Jordach> look it builds under the fancy smanchy M1 Mac
16:43 Wuzzy have there already been changes to the "Minetest irrlicht"?
16:43 MTDiscord <Jordach> yes
16:43 MTDiscord <Jordach> that said, since the difference between M1 and AX CPUs isn't a great deal, an official iOS build isn't hard to do
16:44 v-rob I'll brag a bit -- my push for SDL2 revitalized interest in having the fork
16:46 v-rob However, it'll be really nice to fix bugs instead of working around them.
16:47 MTDiscord <Jordach> if you holler at me i can print macOS M1 builds
16:47 MTDiscord <Jordach> i cannot build Intel however
16:47 MTDiscord <appguru> yes, fixing bugs!
16:47 numzero joined #minetest-dev
16:47 MTDiscord <appguru> especially related to bones
16:48 MTDiscord <appguru> I can't get bones to work
16:48 Wuzzy Who wants to bet that the big Irrlicht release comes out next week, because Murphy's law? 😀
16:48 v-rob If they have SDL2, I'm happy
16:49 MTDiscord <Jonathon> isnt minetest irrlicht based on 1.9 anyways?
16:49 v-rob Yeah
16:50 v-rob To be precise, the OGL-ES branch for Android support
16:50 DS-minetest So, do we want to decouple minetest from irrlicht or do we want to merge it?
16:50 MTDiscord <Jonathon> so not that big of a deal if 1.9 where to release in a week
16:51 v-rob It's kind of a consensus that we're unlikely to ever change from Irrlicht, but I don't think we're going to go all-in either.
16:53 DS-minetest i see
16:55 v-rob That doesn't mean we can't use advanced Irrlicht features, but just that I don't think there will be drastic changes in that direction
16:55 numzero advanced features? aka OpenGL 2.1?
16:56 v-rob No, the absolutely fantastic software drivers, of course
16:57 v-rob The future's in software renderers, as anyone knows
16:57 numzero btw Mesa supports OpenGL 4.6 in software
16:57 numzero as a reference implementation IIRC, to compare hardware drivers against
16:59 v-rob Software renderers aren't necessarily bad, especially when you don't have a GPU (such as on a 15 MHz Motorola 68K embedded system on which I program on occasion)
17:00 numzero exactly
17:00 numzero Intel HD doesn’t count as a GPU too IIRC
17:02 MTDiscord <Jordach> macOS does support OpenGL 4.1
17:02 v-rob But Minetest on the Burning's Video software driver can barely break 30 fps, so they're no good for us :)
17:03 MTDiscord <Jordach> the only thing burning with that driver is Intel CPUs
17:03 v-rob Ha
17:06 numzero btw macOS supports OpenGL core profile only IIRC so MT has to use OpenGL 2.1 there (last version before profile split)
17:06 MTDiscord <Jordach> https://support.apple.com/en-us/HT202823 ?
17:07 MTDiscord <Jordach> ah
17:07 MTDiscord <Jordach> Mac OS will report the GL version to be 2.1 to GL apps that don't explicitly set a couple of flags before opening the window.
17:07 MTDiscord <Jordach> https://stackoverflow.com/questions/19658745/why-is-my-opengl-version-always-2-1-on-mac-os-x
17:07 MTDiscord <Jordach> simple fix
17:08 MTDiscord <Jordach> afaik my M1 enabled Air also supports 4.1
17:08 numzero https://www.khronos.org/opengl/wiki/Core_And_Compatibility_in_Contexts#OpenGL_3.2_and_Profiles
17:08 numzero is the note on MacOSX correct?
17:09 MTDiscord <Jordach> kind of incorrect these days
17:10 MTDiscord <Jordach> glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); is basically what switches 2.1 backwards compatibility mode off
17:10 MTDiscord <Jordach> fortunately it's a real simple #ifdef
17:13 numzero Jordach: explain please. Do you mean it is now possible to create an OpenGL 3+ compatibility context on MacOS?
17:13 MTDiscord <Jordach> has been since mavericks
17:14 MTDiscord <Jordach> which supports macs as far back as 2008
17:19 v-rob On a different note, I'm looking into making a 4x4 transformation matrix and/or quaternion API, but I don't know whether or not it should be modelled after the vector API.
17:19 v-rob Specifically, should it use metatable methods or standalone functions, and should the functions modify in place or return a new matrix/quaternion?
17:23 DS-minetest I think, creating new tables all the time isn't a big problem because luajit can sink them away
17:24 v-rob It's definitely more convenient.  A metatable vector API that returns copies could do v1:dot(v2):dot(v3), which is nicer than v1:dot(v2); v1:dot(v3)
17:25 DS-minetest (might be the wrong terminology or wrong reson, sry) http://wiki.luajit.org/Allocation-Sinking-Optimization
17:26 DS-minetest regarding metatable vs. standalone functions, I'd say allow both
17:26 v-rob Sure, that's how all metatables work
17:28 v-rob Like string.upper(str) and str:upper()
17:28 ircSparky joined #minetest-dev
17:28 ircSparky joined #minetest-dev
17:29 DS-minetest (not necessarily, you can set a metatable {__index=local_table_of_functions} and the user can't get functions from that local_table_of_functions without having an instance)
17:29 v-rob OK, most metatables then :)
17:30 v-rob Also, there was some controversy over vectors having x, y, and z keys instead of an array.  Which is better for quaternions to use internally then?  Because __index can emulate both.
17:30 MTDiscord <appguru> I'd prefer arrays
17:30 DS-minetest I'd prefer arrays too.
17:31 DS-minetest the emulation via __index seems to be slower
17:32 Taoki joined #minetest-dev
17:32 v-rob Yes, __index would slow things down, but then array-based quaternions would be inconsistent with key-based vectors, which would be weird
17:33 DS-minetest it would be more weird having both vectors and quaternions having x, y and z, I think
17:37 sfan5 <v-rob> However, it'll be really nice to fix bugs instead of working around them.
17:37 sfan5 you have probably seen already: #11040
17:37 ShadowBot https://github.com/minetest/minetest/issues/11040 -- Revisit Irrlicht workarounds
17:37 v-rob Yes
17:38 v-rob Although there's no possibility of merging our GUI elements back into Irrlicht because they are too integrated with the current formspec code, e.g. StyleSpec, in case there was any thought of that.
17:39 DS-minetest Then remove the GUI element classes from irrlicht and copy them to minetest.
17:41 v-rob In the line of Irrlicht bugs, IVideoDriver::getViewPort doesn't return the actual viewport for render textures since it uses glViewPort without calling setViewPort, which causes some funky bugs. See https://github.com/minetest/minetest/pull/10801/files#diff-81c0cf94b1691085508abec134d3e6f96b26d5a131cc009a8bb424c1f13ebb15R170-R174
17:42 v-rob I wouldn't be surprised if that's caused problems with render textures for us in the past
17:47 v-rob Back to matricies: I think the best course of action is to use core::matrix4 to do the actual calculations, but if I use a full userdata, that essentially renders ipairs impossible
17:47 v-rob And hence things like minetest.serialize would break on matricies
17:48 DS-minetest doing it in lua is much faster
17:48 v-rob True, but then all calculation have to be copied, and matrix calculations are pretty complex
17:48 DS-minetest especially if you don't even use luajit's ffi lib, which minetest currently doesn't
17:49 DS-minetest Do you mean implementation-wise?
17:49 v-rob Yes, and some matrix calculations are pretty complex
17:50 v-rob Like inverses
17:50 DS-minetest Not for 3x3 matrices.
17:50 MTDiscord <appguru> Why can't you operate on the Lua table?
17:50 MTDiscord <appguru> Like, from C++
17:51 MTDiscord <y5nw> Too much overhead
17:51 MTDiscord <appguru> If you do decide in favor of userdata, just add an iterator like matrix4:ipairs()
17:52 v-rob Right, but that still breaks minetest.serialize, table.copy, minetest.write_json, mod-written iterators, etc
17:52 MTDiscord <y5nw> LuaJIT recognizes the __ipairs metamethod but not the non-JIT Lua :\
17:52 v-rob Not at least in 5.1.  5.2 recognizes __ipairs and __len
17:53 MTDiscord <appguru> well, it would have all the issues of userdata
17:53 MTDiscord <y5nw> IMO we might be able to solve certain problems simply by dropping (non-JIT) Lua 5.1. I saw earlier some code with bitwise operations in Lua and that was horrifying to me (not talking about it further here)
17:53 DS-minetest afaik it must fall back to interpreter whenever a normal lua c api function involved, for obvious reasons. and I don't know in what way ipairs would differ there
17:54 MTDiscord <appguru> one could override ipairs
17:54 MTDiscord <appguru> or pairs and next, for that matter
17:54 MTDiscord <appguru> but it would definitely hurt performance somewhat
17:54 v-rob Ugh, don't want to go down that path just for matricies
17:54 MTDiscord <appguru> Dropping Lua 5.1 support in favor of LuaJIT would be great.
17:54 z812 joined #minetest-dev
17:54 DS-minetest ah, for seraialize you mean. I think the bigger problem is type returning "userdata"
17:54 MTDiscord <appguru> LuaJIT has gotos :D
17:55 MTDiscord <appguru> And a ton of other handy features
17:55 MTDiscord <y5nw> Sounds like we can have BASIC modding now with goto
17:55 MTDiscord <appguru> Plus the performance benefit
17:55 v-rob How much overhead would C++ operations on a Lua table be?  C++ operations would have to copy the array to a matrix and then return a new table, but Lua access with e.g. [] would be faster than full userdata
17:55 MTDiscord <appguru> nah goto is just handy for exiting multiple loops
17:55 MTDiscord <appguru> alternative is a local function
17:56 DS-minetest I would love a drop of Lua5.1. but on the other this would mean that we support less cpu architectures, no?
17:56 MTDiscord <y5nw> The problem with accessing Lua tables from C is that you need to access it via lua using rawgeti() (etc) where the overhead adds up
17:56 v-rob Well, `continue` would be nice, but it doesn't work on repeat...until loops, so it's not in Lua yet
17:56 MTDiscord <y5nw> Afaik LuaJIT already supports the ones that are quite commonly used. ARM and x86 at least, afaik
17:57 rubenwardy <v-rob> True, but then all calculation have to be copied, and matrix calculations are pretty complex
17:57 rubenwardy you'd also have the overhead of calling functions to C++
17:57 MTDiscord <appguru> continue and other handy stuff is why I'm planning a preprocessor
17:57 DS-minetest yeah, but think about the future, what about eg. RiscV?
17:57 MTDiscord <Jordach> Fun fact LuaJIT doesn’t currently compile on ARM64
17:57 MTDiscord <appguru> non-LuaJIT has inacceptable performance
17:57 Krock errorstream appears to bes too slow in fatal_error_fn/sanity_check_fn
17:57 v-rob Is lua_rawgeti() actually that bad?  It accesses the array part directly without __index
17:57 Krock weird. it's supposed to be flushed
17:58 MTDiscord <y5nw> v-rob: not on its own, but when you have a lot of that calls the overhead adds up
17:58 v-rob Hmm, I see
17:59 DS-minetest As a modder I wouldn't use a 3x3matrix/quaternion/similar lua library that's implemented in C/C++. The call overhead is too big.
17:59 v-rob I guess pure Lua it is then
17:59 z812 joined #minetest-dev
18:00 MTDiscord <y5nw> I tried to rewrite part of a mod in C. The interfacing time alone took longer than running in pure Lua IIRC. That's how bad it is (not sure about FFI though)
18:01 v-rob In terms of just rotations, quaternions can do anything 3x3 matricies can do, right?
18:01 DS-minetest FFI in luajit is really fast (even faster than calling a library function via the plt in C) and also pretty easy. but you'll need to be a trusted mod
18:01 v-rob Or is there something 3x3 matricies are better at?
18:02 MTDiscord <y5nw> If you have it as a lua table of 9 elements you might not really need to port that to C IMO
18:03 z812 joined #minetest-dev
18:03 v-rob I want 4x4 matricies for the full benefit of translations (for use with e.g. entities), but I'm wondering if 3x3 matricies have any extra benefits over quaternions.
18:04 DS-minetest if you do a 90° rotation with quaternions, I wonder if vectors with integral numbers suddenly get tiny errors
18:05 DS-minetest mods that does stuff like mesecons (neighbor rules that need to be rotated) will want to compare their rules with ==
18:05 DS-minetest matrices can do that
18:10 z812 joined #minetest-dev
18:14 z812 joined #minetest-dev
18:18 z812 joined #minetest-dev
18:21 v-rob Hmm, from what I can see, quaternion rotations by things like 90 will be fine if you normalize the quaternion afterwords.
18:24 v-rob So I'll probably hold off on 3x3 matricies in favor of quaternions and 4x4 matricies for now.
18:25 v-rob Either way, it'll be nice to not have to work with Euler angles
18:27 DS-minetest If you want to do * with vectors, it will be very useful for you to have metatables on vectors, btw. #11039
18:27 ShadowBot https://github.com/minetest/minetest/issues/11039 -- Add metatables to lua vectors by Desour
18:28 v-rob Does that PR handle C++ code, like push_v2f?
18:29 v-rob that is, v3f
18:29 DS-minetest yes
18:29 DS-minetest oh, no, not push_v2f
18:29 v-rob Sounds great. I'll have to review
18:29 DS-minetest only 3d vectors
18:29 v-rob Yes, that was a typo.  I'm used to working with 2D coordinates for formspecs
18:34 Krock > game tests pass
18:35 Krock > unittests fail
18:35 Krock fml
18:36 DS-minetest how can I run only some unittests? (ie. those that don't trigger the hundreds of lines of warnings)
18:37 Krock I fixed it by commenting those warnings
18:37 DS-minetest in minetest with --run-unittests I mean
18:38 Krock for some reason g_settings is just empty or invalid when these messages are printed
18:39 tech_exorcist joined #minetest-dev
18:40 DS-minetest that helped, thanks
18:41 z812 joined #minetest-dev
18:41 DS-minetest though it's still difficult to find the failed test. why doesn't it say which unittests failed in the summary?
18:42 sfan5 ctrl+f FAIL
18:42 DS-minetest hm, yes, ok
18:44 v-rob Gee, vector.length is kinda inefficient. One square and one square root could be eliminated
18:45 proller joined #minetest-dev
18:46 Krock sfan5: #11011 updated but I have no clue how to test the Mts save/load stuff
18:46 ShadowBot https://github.com/minetest/minetest/issues/11011 -- Schematic: Fix crash after node resolving by SmallJoker
18:47 v-rob math.sqrt(x^2 + y^2 + z^2) is equivalent to math.hypot(x, math.hypot(y, x))
18:49 DS-minetest math.hypot is implemented in lua and does two multiplications, one division and one sqrt. I think I've seen a discussion about length's implementation a while ago
18:49 v-rob The sqrt in the inner hypot gets immediately cancelled by the square in the outer hypot
18:56 * DS-minetest can't find the discussion anymore, maybe it never happened.
18:58 v-rob Well, it's a pretty small change anyway
18:59 v-rob I also like #10324, separate constructors are nice
18:59 ShadowBot https://github.com/minetest/minetest/issues/10324 -- Split vector.new into 3 constructors by Desour
18:59 v-rob I'll review those vector PRs soon
19:00 DS-minetest yey, thx
19:34 BuckarooBanzai6 joined #minetest-dev
19:35 bodqhrohro_ joined #minetest-dev
19:36 olliy_ joined #minetest-dev
19:43 amk joined #minetest-dev
21:47 Wuzzy joined #minetest-dev
21:49 proller joined #minetest-dev
23:32 kilbith joined #minetest-dev
23:33 kilbith man I'm about to give up with Minetest and do something else; I'm horrified about what users are reporting on the Discord server
23:33 kilbith lemme show you
23:33 kilbith https://media.discordapp.net/attachments/369137254641303560/819305254230556690/unknown.png
23:34 kilbith https://cdn.discordapp.com/attachments/369137254641303560/819318734769618954/unknown.png
23:34 kilbith https://cdn.discordapp.com/attachments/369137254641303560/819319194428112956/unknown.png
23:35 kilbith glitches, nodes drawn over the player model, suddenly broken styling for field[], and `setFrameLoop` from Irrlicht plays an animation much much faster now
23:37 luk3yx joined #minetest-dev
23:39 luk3yx kilbith: Hopefully that will be fixed well before 5.5.0 is stable, I'm guessing the Irrlicht change happened early on to catch these bugs so they can be fixed before a release. I can file an issue on GitHub if you want
23:40 kilbith my ass, neither sfan5 or anyone else is qualified in core team to fix these rendering issues in irrlicht
23:41 sfan5 ?
23:41 kilbith forking irrlicht is a really bad move until you can find qualified people to maintain a 3D engine
23:42 sfan5 you say that as if the act of forking has somehow introducted these bugs
23:42 kilbith I'm just disillusioned right now tbh
23:42 kilbith yes it does, I pull commits on the daily basis asshole
23:43 sfan5 misunderstanding my point is no grounds for insulting me
23:43 sfan5 these bugs exist in Irrlicht 1.9, they would have hit us sooner or later when we would have switched to it as it was released
23:44 luk3yx So should I open an issue? If so should I include the crosshair bug in the same one or open a separate issue for that?
23:44 sfan5 I didn't expect severe issues but it's just as luk3yx says, adding it earlier serves as means to test it and see if everything still works alright
23:44 sfan5 luk3yx: yes
23:45 sfan5 another interesting point here is that we've always been using irr1.9 on Android (an older revision though), so that means those bugs may or may not always have existed on Android (did nobody notice?)
23:46 sfan5 anyway please provide a mod to test, I assume I can just install i3
23:46 sfan5 ?
23:46 luk3yx I was using i3, yes
23:47 luk3yx The latest one (according to the content browser at least) from https://content.minetest.net/packages/jp/i3/
23:48 luk3yx And (I complained about this on Discord earlier) the crosshair seems to be misaligned
23:48 sfan5 huh seems like model[] renders the model with the wrong size and angle for a single frame (or is that relating to something i3 does?)
23:49 kilbith what is the "wrong size and angle"?
23:50 MTDiscord <Jonathon> https://cdn.discordapp.com/attachments/747163566800633906/819356564120535051/unknown.png
23:50 sfan5 https://0x0.st/-ZMt.jpg looks like this when switching tabs
23:50 luk3yx That's the good crosshair image @Jonathon
23:50 MTDiscord <Jonathon> https://cdn.discordapp.com/attachments/747163566800633906/819356666331267072/unknown.png
23:50 MTDiscord <Jonathon> ^bad
23:50 MTDiscord <Jonathon> vs good
23:51 MTDiscord <Jonathon> (above)
23:51 luk3yx Weird, I don't have that issue
23:51 luk3yx And the model issue I was having doesn't seem to occur in first person
23:51 luk3yx Or when I'm in the "items" tab with the boat craft guide entry open (this has a model at the top-right) but if I switch back to the main tab the boat model is broken
23:52 kilbith sfan5, before irrlicht 1.9 it was showing like that: https://user-images.githubusercontent.com/7883281/109045805-4f450600-76d4-11eb-90f7-b99ab939246a.png
23:52 sfan5 @Jonathon looks like it's just rotated, but the better question here is thy is that not symmetric?
23:52 luk3yx That's the object crosshair
23:52 sfan5 s/thy/the crosshair/
23:52 luk3yx The normal crosshair has a similar issue but it's easier to see in that one
23:52 sfan5 oh
23:53 sfan5 kilbith: sure that still works https://0x0.st/-ZMw.jpg
23:53 sfan5 it's just temporarily wrong
23:55 kilbith and now we might understand that we better have waited a *stable* version of irrlicht?
23:56 kilbith because the whole picture is a disaster
23:56 sfan5 I'm sure the users who cannot input characters in their native language will be delighted to know their bug is not going to be fixed for another 5 years
23:57 kilbith you decided to fork from 1.9 not 1.8.4
23:57 sfan5 that's a valid point
23:58 luk3yx sfan5: Is it broken for you in third person view?
23:58 sfan5 but the reason there is that 1.8 is a dead end, we eventually need to switch anyway and that 1.8 does not have Android support
23:59 sfan5 luk3yx: first a different question, by misaligned you mean that the top line of the crosshair is 1px longer than the bottom one?

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