Time |
Nick |
Message |
00:19 |
|
AliasAlreadyTake joined #minetest-dev |
03:29 |
|
queria joined #minetest-dev |
03:33 |
|
queria joined #minetest-dev |
03:52 |
|
olliy joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
06:18 |
|
beanzilla joined #minetest-dev |
07:13 |
|
calcul0n joined #minetest-dev |
08:33 |
|
tekakutli joined #minetest-dev |
08:44 |
MTDiscord |
<Sublayer plank> has anyone seen hecks recently? |
09:01 |
MTDiscord |
<x2048> @a floofy ralsei (ROllerozxa) nope. He was tagged on a few items on github, but did not respond |
09:02 |
MTDiscord |
<x2048> https://github.com/minetest/minetest/pull/11747 is ready and needs some testing. Extra pair of eyes would also be helpful |
09:31 |
erlehmann |
> (Almost) Fix self-shadowing of banner entities in MCL2 (offsets?) |
09:31 |
erlehmann |
please elaborate on that? |
09:35 |
|
Yad_ joined #minetest-dev |
09:55 |
|
olliy joined #minetest-dev |
10:44 |
|
Fixer joined #minetest-dev |
11:38 |
|
appguru joined #minetest-dev |
11:55 |
MTDiscord |
<x2048> At some point banners had a huge dark spot in the middle because of self-shadowing of the banner surface. In the latest commit I observed that the spot only appears temporarily when approaching the banner at high speed and shadow map update is spread over multiple frames (I had 16). |
11:56 |
MTDiscord |
<x2048> In short, the situation is much better, but not fully resolved yet. |
11:56 |
MTDiscord |
<x2048> erlehmann: ^ |
11:58 |
erlehmann |
x2048 self-shadowing seems like a dificult beast for complex structures, will it be possible to turn it off? |
11:59 |
erlehmann |
x2048 also, does the mcl2 crystal self-shadow? do the slimes make green colored shadows? |
11:59 |
erlehmann |
the latter would be hilarious (and cool) |
12:01 |
MTDiscord |
<x2048> The slimes should make green shadows, yes. And complex structures should self-shadow properly (checked with trains, drawers, leaves etc.) |
12:02 |
MTDiscord |
<x2048> The problem with banners it the combination of non-uniform SM texels, large flat surface and cloth physics. |
12:03 |
MTDiscord |
<x2048> The banner surface suffers from wrong offsets, and I cannot set them uniformly |
12:03 |
MTDiscord |
<x2048> Disregard the last statement :) |
12:06 |
MTDiscord |
<x2048> My hope with LiSPSM in #11782 is at least to have simpler logic for offsets and filtering and better performance |
12:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/11782 -- Light space perspective shadow mapping by x2048 |
12:16 |
|
HuguesRoss joined #minetest-dev |
13:33 |
|
Taoki joined #minetest-dev |
14:40 |
|
tekakutli joined #minetest-dev |
14:46 |
|
queria^clone joined #minetest-dev |
14:48 |
|
queria^clone joined #minetest-dev |
14:51 |
|
queria joined #minetest-dev |
15:00 |
|
Komodo joined #minetest-dev |
15:44 |
|
queria^clone joined #minetest-dev |
15:48 |
|
queria^clone joined #minetest-dev |
16:00 |
|
queria^clone joined #minetest-dev |
17:03 |
sfan5 |
why are mods allowed to set a different name in mod.conf than their folders are |
17:17 |
MTDiscord |
<luatic> Wasn't this intended as a fix for the usererror of not renaming mod folders? |
17:35 |
erlehmann |
pretty sure the reason is that you may have different mods that satisfy the same dependency |
17:35 |
erlehmann |
doors redux vs doors redo |
17:35 |
erlehmann |
regardless, why would anyone ever care about the folder name? |
17:53 |
MTDiscord |
<Jonathon> using folder name causes so many issues to |
17:54 |
erlehmann |
yeah any code that uses folder names should use mod.conf imo |
17:54 |
erlehmann |
except for, of course, code that reads that file xD |
19:00 |
Pexin |
what is the current attitude/policy about extending the csm api? i gather there may be reluctance to consider it because potential for even more security or cheating risks and i guess the apparent desire to move toward sscsm? |
19:07 |
MTDiscord |
<luatic> Last time I proposed an extension, it was paramatted with the reasoning being "CSM features should not be accepted until SSCSM is implemented." |
19:12 |
Pexin |
mhmm. how long ago? |
19:12 |
MTDiscord |
<luatic> When paramat was still a core dev |
19:12 |
MTDiscord |
<luatic> #10455 |
19:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/10455 -- Implement get_item_defs() client-side call by appgurueu |
19:13 |
Pexin |
heh |
19:13 |
Krock |
will merge #12061 , #12023 and #12018 in 10 minutes |
19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/12061 -- Correct world_format.txt specification by dennisjenkins75 |
19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/12023 -- Add support for 'seed' in disallow_mapgen_settings by Wuzzy2 |
19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/12018 -- Apply texture pack main menu textures immediately by rollerozxa |
19:17 |
|
proller joined #minetest-dev |
19:23 |
Krock |
merging |
19:24 |
Krock |
done |
20:06 |
|
v-rob joined #minetest-dev |
20:36 |
|
v-rob joined #minetest-dev |
22:47 |
MTDiscord |
<LandarVargan> How am I supposed to do https://github.com/MT-CTF/capturetheflag/blob/df09c107b7c9b33bb2927c037d41136208564b68/mods/ctf/ctf_rankings/init.lua#L13 after this? https://github.com/minetest/minetest/commit/9a12e4499ecf5c1a3467af9c831d0d350a21923d#diff-f65d96a13c649554a5df1643c51d66874c21ff698642949cf3b618b4ba3c68f5R252-R256 |
22:50 |
|
tekakutli joined #minetest-dev |
22:51 |
MTDiscord |
<luatic> Why are you using env.core.get_modpath and not simply minetest.get_modpath? No need to involve the insecure env here. |
22:51 |
MTDiscord |
<LandarVargan> Can't other mods override that? |
22:51 |
MTDiscord |
<luatic> Ahh, so that's the reason behind it |
22:52 |
MTDiscord |
<luatic> Then just do env.minetest I suppose? |
22:52 |
MTDiscord |
<LandarVargan> env.minetest has never existed AFAIK |
22:52 |
MTDiscord |
<luatic> Although knowing MT, I wouldn't be surprised if env.minetest == env.core == minetest == core |
22:52 |
MTDiscord |
<luatic> So in the end it wouldn't matter |
22:53 |
MTDiscord |
<LandarVargan> If you look at the comment in sfan5's commit they also say env.core isn't secure either, hence my first question here |
22:53 |
MTDiscord |
<LandarVargan> I guess my 'after this' was misleading |
22:53 |
MTDiscord |
<luatic> Then the answer is simple: It isn't possible. The minetest table has always been insecure. Modders have just been mislead by it being available in insecure environments. |
22:55 |
MTDiscord |
<luatic> To secure it, it would either have to be copied - which would end up a hot, memory eating mess, especially considering the engine relies on indexing it in multiple places - or be protected using a proxy + metatable, potentially harming performance (and messing with raw indexing). |
22:56 |
MTDiscord |
<luatic> TL;DR: Due to this exact issue - having to rely on overridable functions - mod security + loading files currently can't be secured. |
22:56 |
MTDiscord |
<luatic> To secure stuff, you'd have to move it to init.lua. |
23:24 |
MTDiscord |
<savilli> looks like it's possible and even secure env.dofile(env.debug.getinfo(1, "S").source:sub(2, -9) .. "redis.lua") |
23:40 |
|
v-rob joined #minetest-dev |