| Time |
Nick |
Message |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:02 |
|
CoolJar10 joined #minetest-dev |
| 05:53 |
|
calcul0n joined #minetest-dev |
| 09:00 |
|
proller joined #minetest-dev |
| 09:21 |
nrz_ |
cool optimization sfan5, than should reduce lookup |
| 09:25 |
|
proller joined #minetest-dev |
| 09:42 |
|
HuguesRoss joined #minetest-dev |
| 10:01 |
|
Alias joined #minetest-dev |
| 13:16 |
|
Fixer joined #minetest-dev |
| 15:38 |
rubenwardy |
#12314 and #12315 |
| 15:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/12314 -- Add warning when writing to mod directory by rubenwardy |
| 15:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/12315 -- Add world-independent storage directory for mods by rubenwardy |
| 15:40 |
rubenwardy |
may I could merge them, that probably makes sense |
| 15:40 |
rubenwardy |
yeah |
| 15:41 |
rubenwardy |
merge into one PR that is |
| 15:43 |
MTDiscord |
<Warr1024> Interesting. Seems to imply there is already some existing use-case in the wild for mods writing stuff cross-world. Any known examples you can share? |
| 15:43 |
rubenwardy |
Schematics |
| 15:44 |
rubenwardy |
localscoreboards |
| 15:44 |
rubenwardy |
the issue is #4821 |
| 15:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/4821 -- Add world-independent storage directory for mods |
| 15:44 |
MTDiscord |
<Warr1024> Oh, nat |
| 15:44 |
MTDiscord |
<Warr1024> neat* |
| 15:57 |
rubenwardy |
Ok I guess one reason to keep them separate is to stop people mixing them up |
| 15:57 |
erle |
wdym mixing them up |
| 15:58 |
erle |
i think its pretty obvious where stuff needs to go |
| 16:00 |
rubenwardy |
Them being those PRs |
| 16:09 |
sfan5 |
rubenwardy: are there any mods that store global data in the mod dir? |
| 16:13 |
MTDiscord |
<Bastrabun> Wasn't it rhotator tries to create a new lua file each server start? |
| 16:49 |
erle |
hmm, where do the skin mods store their skins? |
| 16:54 |
MTDiscord |
<Jordach> Usually in their textures folder |
| 16:58 |
erle |
Jordach, that means data in the mod dir, right? |
| 16:58 |
MTDiscord |
<Jordach> It means the textures folder like any other mod |
| 16:59 |
erle |
well, then any mod that downloads textures or lets users edit them is a candidate for “this needs to store global data, i.e. outside of world folders” |
| 16:59 |
MTDiscord |
<Warr1024> "Traditional" skins mods don't really "store" their textures anywhere. The server admin installs the textures and then restarts the server, and then the mod can load them. |
| 17:00 |
MTDiscord |
<Warr1024> global dynamic textures could probably just as easily be using world storage though. For more "universal" storage, cross-world might make some sense, but you're getting much closer to the "http API" point by then. |
| 17:10 |
rubenwardy |
Yeah exactly |
| 17:12 |
erle |
i guess i should not try to speak for people who make mods like skinsdb and epidermis. my own mods only ever write to world folder ;) |
| 17:15 |
MTDiscord |
<Warr1024> I've only ever made the kind of skin mod where players submit skins to me, I approve them, and then my server update scripts pick them up and install them on the server. I haven't messed with some of the HTTP API stuff yet. It does look pretty fancy, but then there's also more moderation risk involved... |
| 17:16 |
MTDiscord |
<luatic> Warr1024: in the strict modlib PNG & JSON parsers trust you must |
| 17:17 |
MTDiscord |
<Warr1024> Yeah, parsers are not really going to help ensure that players don't wear skins that make their players look like giant dicks. I think you might have the wrong threat model in mind. |
| 17:18 |
MTDiscord |
<luatic> anyways, epidermis persistence only writes to the world folder - see https://github.com/appgurueu/epidermis/blob/b7cd469284c2f682c57eefa9185e1456a2deab02/persistence.lua#L4-L11 |
| 17:19 |
MTDiscord |
<Warr1024> Well now as of an upcoming release, assuming rubenwardy's change is in, you'll have the option for your mod to maintain a cache shared across worlds, which would probably be nice for stuff like reducing your skinsdb API traffic. Assuming, of course, you can dynamic media out of it, I guess. |
| 17:23 |
sfan5 |
could anyone quickly look at #12289 |
| 17:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/12289 -- Support packing arbitrary graphs by TurkeyMcMac |
| 18:18 |
|
hlqkj joined #minetest-dev |
| 19:27 |
|
proller joined #minetest-dev |
| 20:26 |
sfan5 |
thanks |
| 20:26 |
sfan5 |
merging #12297, #12152, #12310, #12289, #12309 in 10m |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12297 -- Fix possible unreliable behavior due to uninitialized variables by Endi0n |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12152 -- Add doc to list breaking changes for the next major release by Zughy |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12310 -- Fix cooking and fuel crafts with aliases by TurkeyMcMac |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12289 -- Support packing arbitrary graphs by TurkeyMcMac |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12309 -- Use native packer to transfer globals into async env(s) by sfan5 |
| 20:40 |
sfan5 |
aaand we're past 10k commits |
| 20:41 |
rubenwardy |
need a tweet |
| 20:42 |
rubenwardy |
maybe a screenshot of 10,000 nyancats/mese or something |
| 20:42 |
MTDiscord |
<MNH48> don't forget toot as well |
| 20:42 |
MTDiscord |
<luatic> just screenshot the commit graph |
| 20:42 |
MTDiscord |
<Warr1024> nyancats doesn't seem right, what with them having been 451'd out of the game... |
| 20:43 |
rubenwardy |
zofc |
| 20:44 |
MTDiscord |
<Warr1024> congrats though, that's almost 4x as many commits as NodeCore ? |
| 20:45 |
MTDiscord |
<Warr1024> I always miss the fun milestones. It seems like you should plan to make it a particularly salient commit or something instead of just something like "fix a typo" but it almost never works out that way. |
| 20:46 |
rubenwardy |
10k is https://github.com/minetest/minetest/commit/d17d7eba14f6a1328a3b58ee086df5ffa56304d6 |
| 20:46 |
rubenwardy |
!title |
| 20:46 |
ShadowBot |
Fix cooking and fuel crafts with aliases · minetest/minetest d17d7eb · GitHub |
| 20:47 |
MTDiscord |
<Warr1024> seems like a good enough one |
| 20:47 |
MTDiscord |
<Warr1024> I'm sure it will never be a thorn in our side like every time somebody says something like "...but my #1 reason is..." and then the bot drags up that ancient issue... |
| 20:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome |
| 20:54 |
Zughy[m] |
I was commit 9999, so close |
| 20:59 |
Zughy[m] |
by the way, development is on steroids in these days |
| 21:03 |
MTDiscord |
<Warr1024> I would rather see development on the engine, tbh |
| 21:03 |
MTDiscord |
<Warr1024> Is the disagreement about numbering based on starting at 0 vs 1 or something? |
| 21:21 |
MTDiscord |
<Bastrabun> More than on steroids. Unrelated: Thank you, core devs ? |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 23:15 |
erle |
sfan5 sadly i can't show you a screenshot (another miscompile), but i believe that if you set chunksize 6, then the map ends at 31055 (visible map ends at 30959, add 96 nodes to it for the outermost invisible mapblock). this leads me to believe that 31007 is probably not a safe value to avoid bugs for chunksizes other than 5 – and my original assertion “do not use MAX_MAP_GENERATION_LIMIT for bounds checks” has been correct. |
| 23:16 |
erle |
i'm sorry for not having realized this weeks or months ago, i just didn't think of it. |
| 23:18 |
erle |
i am very sleepy, but if you want to keep these kinds of bounds checks, i guess a safe value for bounds checks always the smallest multiple of (16 × chunksize) that is bigger or equal to MAX_MAP_GENERATION_LIMIT |
| 23:19 |
erle |
hmm, this is wrong |
| 23:20 |
erle |
celeron55 do you know the position of the most central mapblock, like where it starts? |
| 23:25 |
erle |
anyways, to my knowledge mineclone5 sets a chunksize of 4, so i predict fun times |
| 23:42 |
MTDiscord |
<Jordach> the hint is 0,0,0 |
| 23:42 |
erle |
Jordach, explain? |
| 23:43 |
MTDiscord |
<Jordach> i don't know which corner 0,0,0 explicitly belongs to |
| 23:43 |
MTDiscord |
<Jordach> it can be x+ and z- |
| 23:43 |
MTDiscord |
<Jordach> ie which of the 8 corners of a mapblock it could theoretically be |
| 23:44 |
erle |
well, with chunksize=5 (i.e. blocksize 80) your map sharply ends at x=31007. |
| 23:44 |
MTDiscord |
<Jordach> 31006 |
| 23:44 |
erle |
however often you remove 80 from that, you are not going to end up at 0 |
| 23:44 |
erle |
classic off-by-one haha |
| 23:44 |
erle |
regardless, you are not going to get to 0 that way |
| 23:44 |
MTDiscord |
<Jordach> 7 is there for safety reasons |
| 23:44 |
MTDiscord |
<Jordach> because trimming the edge off a mapblock might go wonky# |
| 23:45 |
erle |
if i am not mistaken you can't “trim the edge off” a mapblock |
| 23:45 |
MTDiscord |
<Jordach> and a hard trim as in MMGL would do so |
| 23:46 |
erle |
you either stop generating exactly at mapblock boundary OR your outermost mapblock lies partially within and partially outside of MAX_MAP_GENERATION_LIMIT (which is where all the funny bugs occur) |
| 23:46 |
erle |
the only thing i know that stops exactly at the stated boundary is biomegen |
