| Time |
Nick |
Message |
| 00:01 |
|
Seirdy joined #minetest-dev |
| 01:03 |
LoneWolfHT |
Is there something stopping the win32 and win64 irrlicht builds from being uploaded as artifacts? |
| 01:03 |
LoneWolfHT |
I'm looking into a GIthub action for compiling Minetest installers |
| 01:05 |
LoneWolfHT |
*Minetest Windows Installers |
| 01:22 |
|
amk joined #minetest-dev |
| 01:32 |
|
specing_ joined #minetest-dev |
| 02:04 |
LoneWolfHT |
I guess MT needs the /lib/ and /include/ dirs |
| 02:05 |
LoneWolfHT |
I can make a PR that zips those two dirs in the same folder and puts them up as an artifact |
| 02:18 |
LoneWolfHT |
This is what I have hacked together for the Minetest Installer action so far. I'm taking a break until tomorrow, input on it might save me a lot of googling time https://github.com/LoneWolfHT/minetest/runs/2274514807 |
| 02:18 |
LoneWolfHT |
Just trying to get it to compile atm, will go with a better more informed approach once I achieve that goal |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:25 |
|
Seirdy joined #minetest-dev |
| 04:59 |
|
absurb_ joined #minetest-dev |
| 06:01 |
|
x2048 joined #minetest-dev |
| 06:11 |
|
x2048 joined #minetest-dev |
| 06:15 |
|
x2048 joined #minetest-dev |
| 06:21 |
|
x2048 joined #minetest-dev |
| 06:30 |
|
x2048 joined #minetest-dev |
| 06:33 |
|
x2048 left #minetest-dev |
| 07:56 |
rubenwardy |
The original pr for GitHub actions made a Windows installer |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:15 |
|
hlqkj joined #minetest-dev |
| 08:46 |
|
olliy joined #minetest-dev |
| 09:34 |
|
calcul0n_ joined #minetest-dev |
| 10:27 |
MTDiscord |
<appguru> Building Minetest with Irrlicht isn't all that hard |
| 10:32 |
|
proller joined #minetest-dev |
| 10:57 |
|
Fixer joined #minetest-dev |
| 11:00 |
|
calcul0n__ joined #minetest-dev |
| 11:08 |
|
tech_exorcist joined #minetest-dev |
| 11:58 |
|
Fixer joined #minetest-dev |
| 12:16 |
MTDiscord |
<appguru> I am under the impression that node meta is quite broken |
| 12:17 |
MTDiscord |
<appguru> reportMetadataChange usually operates with m_meta = NULL, meaning that probably always is_private_change = false |
| 12:18 |
MTDiscord |
<appguru> As already known, empty meta isn't deleted (I was trying to fix that) and returned by find_nodes_with_meta |
| 12:18 |
MTDiscord |
<appguru> And, meta doesn't appear to be sent immediately. When setting infotext and deleting it right after, it took another mapblock change (such as digging a block) to update. |
| 12:22 |
MTDiscord |
<appguru> See #11170 |
| 12:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/11170 -- Attempt at fixing handling of node meta data by appgurueu |
| 13:08 |
|
tech_exorcist joined #minetest-dev |
| 13:08 |
|
tech_exorcist joined #minetest-dev |
| 13:32 |
|
specing_ joined #minetest-dev |
| 13:32 |
|
tech_exorcist joined #minetest-dev |
| 13:33 |
|
tech_exorcist joined #minetest-dev |
| 13:36 |
|
tech_exorcist joined #minetest-dev |
| 13:52 |
sfan5 |
if you find that reportMetadataChange is called wrongly I'd investigate that first |
| 14:02 |
|
appguru joined #minetest-dev |
| 14:12 |
|
proller joined #minetest-dev |
| 14:20 |
LoneWolfHT |
rubenwardy: Yeah, I'm just trying to get this to work with mtirrlicht now |
| 15:39 |
sfan5 |
LoneWolfHT: I don't think you can link to the library built with mingw when the final build is msvc |
| 15:39 |
sfan5 |
also the separate builds for irrlicht and then donwnloading the artifact is ... weird |
| 15:40 |
sfan5 |
the normal mingw builds are already uploaded by gitlab-ci, but if you want an installer you run into a problem since that stuff only works on windows |
| 15:50 |
LoneWolfHT |
Hmmm, I forgot I was trying the mingw method because compiling with msvc was giving me errors |
| 15:51 |
LoneWolfHT |
Will run the msvc errors by here if I can't solve them this time around |
| 15:52 |
sfan5 |
worked for me in VS2019 |
| 15:53 |
|
Wuzzy joined #minetest-dev |
| 15:58 |
|
pauloue joined #minetest-dev |
| 16:05 |
|
I_am_6r1d joined #minetest-dev |
| 16:14 |
LoneWolfHT |
Probably me incorrectly configuring it then |
| 16:15 |
LoneWolfHT |
I think it's completely working this time around, no issues other than me not setting the build dir correctly |
| 16:21 |
sfan5 |
any suggestions for when exactly 5.4.1 should happen? in a few days? this weekend? |
| 16:22 |
rubenwardy |
I'm not available before thie weekend |
| 16:22 |
rubenwardy |
but the Android can be released late, or nerzhul could do that |
| 16:38 |
nerzhul_ |
me ? yep i can but never released android since a long time |
| 16:39 |
nerzhul_ |
sfan5 i think it depend on release team availability |
| 16:39 |
nerzhul_ |
5.4.1 is 5.4.0 with backports, right ? |
| 16:58 |
* LoneWolfHT |
uploaded an image: (11KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/bEObfxToMZbFyZJSsZpxZjWX/image.png > |
| 16:58 |
LoneWolfHT |
I'm stumped here, no such file anywhere AFAIK |
| 16:59 |
LoneWolfHT |
https://github.com/LoneWolfHT/minetest/runs/2280196896 |
| 17:09 |
rubenwardy |
why does it say Win32-gcc? Shouldn't you build IrrlichtMt with MSVC? |
| 17:49 |
|
MTDiscord1 joined #minetest-dev |
| 17:53 |
sfan5 |
it always says Win32-gcc |
| 17:53 |
sfan5 |
nerzhul_: yes |
| 17:54 |
sfan5 |
LoneWolfHT: why do you think there should be an obj? |
| 17:55 |
LoneWolfHT |
It seems to be trying to link one |
| 17:56 |
sfan5 |
https://0x0.st/-cva.png these are the irrlichtmt build artifacts |
| 17:56 |
sfan5 |
the .lib is what you give as IRRLICHT_LIBRARY to cmake |
| 17:58 |
LoneWolfHT |
Yeah I passed that: -DIRRLICHT_LIBRARY=lib/irrlichtmt/lib/Win32-gcc/Release/IrrlichtMt.lib |
| 17:58 |
sfan5 |
judging from the output you must have written .obj |
| 17:59 |
* LoneWolfHT |
uploaded an image: (23KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/rgqHMBRSBrxLKdyclbwOZQbh/image.png > |
| 17:59 |
LoneWolfHT |
My dir is right too afaik |
| 18:01 |
sfan5 |
try with an absolute path |
| 18:26 |
sfan5 |
requesting reviews: #11133, #11152 and I guess #11159 is pretty simple too |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/11133 -- Isolate library tables between sandbox and insecure env by sfan5 |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/11152 -- Fix server favorites not saving when client/serverlist/ doesn't exist already by sfan5 |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/11159 -- Fix rotation for falling mesh degrotate nodes by Wuzzy2 |
| 18:32 |
LoneWolfHT |
absolute paths worked |
| 18:36 |
LoneWolfHT |
Time to test |
| 19:03 |
pgimeno |
sfan5: about 11133, that's a step in the right direction, but not the whole story |
| 19:03 |
sfan5 |
yes I know, we've talked about it |
| 19:04 |
pgimeno |
debug.getmetatable and debug.setmetatable should probably be removed from the secure environment too, and for that, debug should probably be copied as well |
| 19:05 |
pgimeno |
er... never mind, it would just need to be removed from the whitelist |
| 19:06 |
pgimeno |
I'll take a closer look later |
| 19:07 |
sfan5 |
it doesn't fix what we talked about once, but fixing that while accomodating existing usecases is essentially impossible |
| 19:07 |
pgimeno |
is it? well, it's an incompatible change, but currently it's plainly a security hole |
| 19:08 |
rubenwardy |
you can just use setmetatable and getmetatable |
| 19:08 |
pgimeno |
and there aren't a lot of mods affected, just those who fiddle with the string metatable (I only know of luacontroller) |
| 19:09 |
pgimeno |
rubenwardy: yes, you don't really need debug.setmetatable and debug.getmetatable in most applications (except Luacontroller) |
| 19:09 |
sfan5 |
breaking those without a replacement is kind of an issue |
| 19:10 |
pgimeno |
the replacement is making the luacontroller need an insecure environment |
| 19:10 |
|
tech_exorcist joined #minetest-dev |
| 19:11 |
sfan5 |
ok true |
| 19:17 |
LoneWolfHT |
The installer isn't packing IrrlichtMt.dll, or I did something wrong |
| 19:17 |
sfan5 |
set IRRLICHT_DLL? |
| 19:18 |
pgimeno |
previous discussion about metatables here, for reference: https://irc.minetest.net/minetest-dev/2020-06-01#i_5696585 |
| 19:18 |
sfan5 |
you can set it to a ; delimited list btw, it probably needs to inlude the libpng and libjpeg dll too |
| 19:39 |
|
hlqkj_ joined #minetest-dev |
| 19:40 |
|
hlqkj joined #minetest-dev |
| 19:50 |
|
specing joined #minetest-dev |
| 19:57 |
|
proller joined #minetest-dev |
| 20:10 |
|
tech_exorcist joined #minetest-dev |
| 20:17 |
* LoneWolfHT |
uploaded an image: (3KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/yAtmHRHhiuypRzpHsvhpQELR/image.png > |
| 20:17 |
LoneWolfHT |
-DIRRLICHT_DLL=D:\a\minetest\minetest\lib\irrlichtmt\lib\Win32-gcc\Release\IrrlichtMt.dll |
| 20:18 |
LoneWolfHT |
Unless you mean I should set it in the cmake files |
| 20:26 |
LoneWolfHT |
(Now that I reread that, no, I shouldn't set it in the cmake files) |
| 20:32 |
LoneWolfHT |
I'll go learn Cmake instead of hacking my way around |
| 20:56 |
Taoki |
Is there any good, logical reason why Minetest suddenly decided to require its own fork of irrlicht? Just noticed this now while testing a Git compile and it did surprise me. |
| 20:57 |
Taoki |
I'd be happy if at least this meant better graphics / shaders are implemented. I'm assuming that's not the case though. |
| 20:58 |
Taoki |
I'll have to redo the entire build setup someday considering this change. I cloned the new irrlicht repo for the time being. |
| 21:00 |
pgimeno |
it's a necessary step for fixing stuff in irrlicht; check https://github.com/minetest/irrlicht/commits for what it has been done to it as of now |
| 21:05 |
Taoki |
I see. I take it vanilla Irrlicht hasn't been as actively developed any more? |
| 21:05 |
rubenwardy |
Taoki: it's required to fix bugs that we haven't been able to for a long time |
| 21:05 |
rubenwardy |
Yeah, upstream Irrlicht is pretty dead |
| 21:05 |
Taoki |
I see. That's sad. It makes sense then. |
| 21:05 |
Taoki |
rubenwardy: Any chance we might see some graphical improvements this way? Possibly even performance. |
| 21:06 |
pgimeno |
not exactly dead, but I'm not sure there's a 1.9 in sight |
| 21:07 |
pgimeno |
latest commit is from march 19 |
| 21:07 |
Pexin |
"graphical improvements" often mean requiring more powerful hardware. one strength of MT right now is it runs on practically anything. |
| 21:08 |
Pexin |
everything's still gonna be made out of cubes anyway :] |
| 21:11 |
Taoki |
Pexin: True. Thinking of optional new features which don't need to be enabled if not supported (or are too slow). |
| 21:11 |
|
mizux joined #minetest-dev |
| 21:12 |
pgimeno |
extending the coordinate range beyond 32K would be possible now (a lot of work, but possible) |
| 21:13 |
MTDiscord |
<Jonathon> eye candy is nice, however it is also nice to have the option to turn it off |
| 21:17 |
appguru |
pgimeno: hash_node_position doesn't really allow it |
| 21:19 |
pgimeno |
well, it can be doubled, doubles have 52 bits and that hash uses 48, so 1 bit per coordinate is possible |
| 21:20 |
MTDiscord |
<appguru> Yes |
| 21:20 |
pgimeno |
and it can actually be tricked into using 21 bits per component |
| 21:21 |
appguru |
if we start abusing the exponent... |
| 21:21 |
pgimeno |
that's 1M in every direction |
| 21:21 |
pgimeno |
I've done similar things, it works |
| 21:23 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/objectkey.cc |
| 21:25 |
pgimeno |
in lua it would involve some fiddling with ldexp |
| 21:30 |
|
Guest65864 joined #minetest-dev |
| 21:35 |
LoneWolfHT |
Is this check not needed since vcpkg no longer handles Irrlicht or am I missing something? https://github.com/LoneWolfHT/minetest/blob/76ee9784aa51536de75ffab68c84ca04b1cabb18/cmake/Modules/FindIrrlicht.cmake#L38-L42 |
| 22:23 |
MTDiscord |
<josiah_wi> I can help with CMake questions. I'm trying to work on it everywhere I can to get more experience. |
| 22:25 |
MTDiscord |
<josiah_wi> I don't think you're missing anything there. |
| 22:27 |
pgimeno |
sfan5: suggestions on #11333: copy_table -> shallow_copy_table; whitelist2 -> whitelist_tables; string metatables -> string metatable |
| 22:27 |
ShadowBot |
pgimeno: Error: That URL raised <HTTP Error 404: Not Found> |
| 22:27 |
pgimeno |
oops #11133 |
| 22:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/11133 -- Isolate library tables between sandbox and insecure env by sfan5 |
| 22:27 |
LoneWolfHT |
Yep that was the problem, now to add the jpeg dll... |
| 22:28 |
Pexin |
"I've seen the future! O_O And we're still not done yet!" |
| 22:28 |
pgimeno |
sfan5: looks fine to me but I haven't checked the stack positions |
| 22:29 |
|
kilbith joined #minetest-dev |
| 22:29 |
MTDiscord |
<josiah_wi> I was going to PR improvements to the find scripts but I didn't get much interest. |
| 22:30 |
appguru |
Now that I think of it, proper mod security might actually be possible |
| 22:30 |
appguru |
Just protect: 1. setfenv/getfenv, 2. minetest, 3. minetest.request_insecure_environment |
| 22:31 |
appguru |
And make the insecure environment contain "secured" copies of everything |
| 22:31 |
appguru |
So you could just do setfenv(1, insecure_env) and then comfortably operate in your insecure environment |
| 22:32 |
pgimeno |
and avoid using the string metatable in the insecure env. |
| 22:37 |
pgimeno |
sandboxing lua code is a minefield, it's too easy to miss a case and leave a security hole |
| 22:37 |
MTDiscord |
<appguru> True for plenty of scripting languages |
| 22:41 |
pgimeno |
sfan5: setting getmetatable("").__metatable = false and keeping the metatable of string would allow using the string metatable in an insecure mod |
| 22:44 |
pgimeno |
basically, keep the string table as a copy but the metatable of strings as the original, and protected from direct access via __metatable |
| 22:45 |
pgimeno |
(it still needs banning debug.get/setmetatable in the secure env) |
| 22:47 |
|
DS-minetest joined #minetest-dev |
