| Time |
Nick |
Message |
| 00:03 |
est31 |
#3230 |
| 00:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/3230 -- Better gettext support for protocol version mismatch messages by est31 |
| 00:33 |
paramat |
papyrus/biome tweak merging soon game#696 |
| 00:33 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/696 -- Papyrus: Grow on dirt and grass only, remove from desert ocean by paramat |
| 00:45 |
paramat |
now merging game 695 and 696 |
| 00:50 |
paramat |
complete |
| 01:02 |
paramat |
now merging #3223 |
| 01:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3223 -- Mgv5: getGroundLevelAtPoint searches a larger range by paramat |
| 01:06 |
paramat |
complete |
| 01:39 |
|
younishd_ joined #minetest-dev |
| 01:44 |
|
VanessaE joined #minetest-dev |
| 01:44 |
|
Player_2 joined #minetest-dev |
| 02:07 |
|
Lunatrius` joined #minetest-dev |
| 02:16 |
paramat |
http://i.imgur.com/yX6BaLQ.png hybrid dungeon |
| 02:16 |
|
paramat left #minetest-dev |
| 02:18 |
VanessaE |
looks like a geometry argument is mandatory now: |
| 02:18 |
VanessaE |
GD Warning: product of memory allocation multiplication would exceed INT_MAX, failing operation gracefully |
| 02:18 |
VanessaE |
bash: line 1: 25953 Segmentation fault ./minetestmapper --drawscale --drawalpha -i $worldpath"/"$worldname"/" -o $imagepath"/"$worldname".png" |
| 02:19 |
VanessaE |
(without a geometry arg to limit the size, I guess it does the whole world now, and throws that ^^^ error) |
| 02:24 |
VanessaE |
(also, I'm pretty sure a segfault is rather opposite of "graceful" :P ) |
| 02:33 |
kahrl |
rather graceful if you ask me. I mean, it doesn't rewrite random mapblocks in the database and corrupt them |
| 02:34 |
VanessaE |
maybe. heh |
| 02:34 |
VanessaE |
still pretty sure a crash is unwanted ;) |
| 02:36 |
kahrl |
probably just a missing return value check somewhere |
| 02:38 |
VanessaE |
a feature that I think would be useful is if the mapper tool could slice the output image into several smaller pieces |
| 02:38 |
VanessaE |
(say max 4096x4096 or so) |
| 02:39 |
kahrl |
https://github.com/minetest/minetestmapper/blob/master/TileGenerator.cpp#L349 |
| 02:39 |
kahrl |
this is where a NULL check is missing, I think |
| 03:14 |
VanessaE |
est31: leaftest needs a tweak -- geometry arg for minetestmapper takes X:Y+W+H but you have X,Y+W+H (comma instead of colon). |
| 03:17 |
|
EUGD joined #minetest-dev |
| 03:20 |
|
EUGD joined #minetest-dev |
| 03:44 |
|
EUGD joined #minetest-dev |
| 03:58 |
|
EUGD joined #minetest-dev |
| 04:09 |
|
EUGD joined #minetest-dev |
| 04:14 |
|
EUGD joined #minetest-dev |
| 04:20 |
|
EUGD joined #minetest-dev |
| 04:36 |
|
EUGD joined #minetest-dev |
| 04:47 |
|
celeron55 joined #minetest-dev |
| 04:48 |
|
Miner_48er joined #minetest-dev |
| 05:31 |
|
Calinou joined #minetest-dev |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 06:58 |
|
Zeitgeist_ joined #minetest-dev |
| 07:28 |
|
julienrat joined #minetest-dev |
| 07:33 |
hmmmm |
wow, caverealms is a pretty cool mod |
| 07:34 |
hmmmm |
i haven't been able to reproduce that crash yet, however |
| 07:40 |
|
nrzkt joined #minetest-dev |
| 07:41 |
hmmmm |
unfortunately the slowness of block loading among other things breaks player immersion and ruins something that otherwise would be very neat |
| 07:42 |
nrzkt |
you are right |
| 07:43 |
nrzkt |
this is a pain to wait for map loading many times... :( |
| 07:43 |
hmmmm |
specifically with map generating mods |
| 07:43 |
hmmmm |
i have an idea though it's a lot of effort |
| 07:44 |
nrzkt |
why not having a lock per mapblock ? EmergeThread commit directly to map with a lock on the mapblock memory area itself instead of the whole map |
| 07:44 |
hmmmm |
there are a lot of mapblocks dude |
| 07:44 |
nrzkt |
yes, but an intelligent locking system, allocate locks at mapblock first creation |
| 07:44 |
hmmmm |
if the platform in question does not implement pthread_mutex_* as a futex then that would wreak havoc on the OS |
| 07:45 |
nrzkt |
futex ? |
| 07:45 |
hmmmm |
user-mode mutex |
| 07:45 |
nrzkt |
i see :) |
| 07:46 |
hmmmm |
freebsd and linux do this with pthread_mutex_ functions, and Windows does if you use "critical sections" |
| 07:46 |
hmmmm |
in other words, on windows, CreateMutex() et al. are NOT user mode mutexes |
| 07:46 |
hmmmm |
you need to be careful there |
| 07:46 |
hmmmm |
in any case, an idea I would be more open to is maybe a "locking region" or some shit |
| 07:47 |
hmmmm |
which might be defined as a 4x4x4 cluster of mapblocks...? |
| 07:47 |
hmmmm |
shrug |
| 07:47 |
hmmmm |
even if you do this, there's still an enormous amount of work |
| 07:48 |
nrzkt |
8x8x8 ? :) |
| 07:48 |
hmmmm |
small steps first |
| 07:48 |
hmmmm |
break up envlock into maplock, playerlock, objectlock, etc. |
| 07:49 |
hmmmm |
then when we get that working really well, then we'll look into breaking up maplock |
| 07:52 |
nrzkt |
i do it in a separate branch |
| 07:52 |
nrzkt |
i have map_lock and SAO_lock |
| 07:52 |
nrzkt |
i did* |
| 08:00 |
nrzkt |
technically this separation is not a problem |
| 08:17 |
|
julienrat left #minetest-dev |
| 08:19 |
Megaf |
Hi all, little help please, So, I updated my server today and now this happens |
| 08:19 |
Megaf |
https://paste.debian.net/plain/314451 |
| 08:20 |
Megaf |
I'm afraid it had overwriten my world =/ |
| 08:21 |
|
Krock joined #minetest-dev |
| 08:22 |
Megaf |
Ok, it might not be a minetest fault |
| 08:26 |
Megaf |
ok, nevermind, I think is not minetest fault this time, game on |
| 08:31 |
nrzkt |
it's you |
| 08:32 |
nrzkt |
+x missing |
| 08:32 |
Megaf |
Thanks |
| 08:39 |
|
julienrat joined #minetest-dev |
| 09:19 |
|
julienrat left #minetest-dev |
| 09:24 |
|
kilbith joined #minetest-dev |
| 09:24 |
|
kilbith left #minetest-dev |
| 09:41 |
|
julienrat joined #minetest-dev |
| 09:41 |
|
julienrat left #minetest-dev |
| 11:40 |
|
eeew joined #minetest-dev |
| 12:26 |
|
Lunatrius joined #minetest-dev |
| 12:28 |
|
Darcidride joined #minetest-dev |
| 13:30 |
|
eugd joined #minetest-dev |
| 14:05 |
|
Darcidride joined #minetest-dev |
| 14:28 |
|
T4im joined #minetest-dev |
| 14:39 |
|
JohnnyComeL8ly joined #minetest-dev |
| 14:42 |
|
celeron55 joined #minetest-dev |
| 14:44 |
|
Taoki joined #minetest-dev |
| 14:51 |
|
jin_xi joined #minetest-dev |
| 15:01 |
|
younishd_ joined #minetest-dev |
| 15:08 |
|
hmmmm joined #minetest-dev |
| 15:11 |
|
JohnnyComeL8ly joined #minetest-dev |
| 15:33 |
|
eugd joined #minetest-dev |
| 15:33 |
|
Hijiri joined #minetest-dev |
| 15:51 |
|
Player_2 joined #minetest-dev |
| 16:05 |
|
eugd joined #minetest-dev |
| 16:05 |
|
Hunterz joined #minetest-dev |
| 16:50 |
|
nrzkt joined #minetest-dev |
| 17:05 |
|
est31 joined #minetest-dev |
| 17:05 |
est31 |
I dont like locks as they might allow for deadlock |
| 17:05 |
est31 |
e.g. what if you have a mod that has a mob that modifies the map |
| 17:06 |
est31 |
e.g. on its on_step, it automatically farms |
| 17:06 |
est31 |
so you aquire the map lock while holding the object lock |
| 17:06 |
est31 |
now what if sth else has the map lock and wants to spawn an object? |
| 17:07 |
est31 |
e.g. you place a windmill block, and it has a rotating part |
| 17:07 |
est31 |
which is an object |
| 17:07 |
est31 |
--> deadlock |
| 17:07 |
est31 |
better is an event system, asynchronous |
| 17:08 |
est31 |
we could introduce the rule that you can't aquire more than one lock |
| 17:08 |
est31 |
then the modders would have to use event util functions we provide for them to avoid that situation |
| 17:09 |
est31 |
This would be a hybrid approach |
| 17:10 |
hmmmm |
lol |
| 17:12 |
hmmmm |
that's pretty silly. this is a non-problem. a deadlock is a bug you encounter from using locks in the wrong manner. |
| 17:12 |
nrzkt2 |
agree with hmmmm |
| 17:15 |
hmmmm |
although I agree it's going to be tough to interface this properly with mods |
| 17:15 |
hmmmm |
modders are generally incompetent and they don't actually understand what it is they're coding |
| 17:15 |
hmmmm |
you get a handful who actually know what's going on and they write their own mods, and then everybody else copies and pastes from the working mods |
| 17:16 |
hmmmm |
but they introduce subtle differences and bugs that didn't exist in the original version |
| 17:16 |
est31 |
I dont want to get deadlocks regardless of what modders code |
| 17:16 |
hmmmm |
I'm floating around the idea of letting mods control envlock in a limited manner |
| 17:16 |
est31 |
part of the "manner in which we use locks" isnt influenced by us |
| 17:17 |
hmmmm |
maybe mods will only have access to envlock |
| 17:17 |
hmmmm |
and then when envlock gets split up, envlock will become multiple locks underneath but still appear as one single lock to the mod interface |
| 17:17 |
hmmmm |
this helps keep things simple |
| 17:18 |
est31 |
ermmm |
| 17:18 |
est31 |
so what does splitting up envlock use then? |
| 17:18 |
hmmmm |
there's a lot more engine code than there is mod code |
| 17:18 |
est31 |
i mean you cant run a mobs mod parrallel to a mod that affects nodes only then |
| 17:19 |
est31 |
well, okay, that would be a good first step |
| 17:20 |
est31 |
engine side only split up |
| 17:22 |
est31 |
hmmmm, is it a bad goal to not allow modders to introduce deadlocks? you agree to it? |
| 17:22 |
est31 |
and nrzkt2 |
| 17:23 |
hmmmm |
I agree that it needs to be made safe |
| 17:23 |
hmmmm |
that's the number one reason why nothing has been done with regards to locks |
| 17:24 |
est31 |
argh #3231 |
| 17:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/3231 -- Server Error: A fatal error occurred: Invalid position (expected table got nil). |
| 17:24 |
hmmmm |
i've been persuaded by VanessaE to give modders a chance however |
| 17:24 |
hmmmm |
maybe they will be able to 'rise to the challenge' of synchronization |
| 17:25 |
est31 |
yet another somebody who has encountered a crash, and submits it without any info |
| 17:25 |
hmmmm |
I mean it may have took a while but it seems they're able to use LuaVoxelManip without problems now |
| 17:26 |
est31 |
still bad it does no range checking |
| 17:27 |
est31 |
easily exploitable |
| 17:27 |
est31 |
hrmm, perhaps I try precisely that later on... |
| 17:54 |
|
FR^2 joined #minetest-dev |
| 18:30 |
|
Darcidride joined #minetest-dev |
| 18:37 |
|
Darcidride_ joined #minetest-dev |
| 18:48 |
|
Amaz joined #minetest-dev |
| 19:03 |
|
technics joined #minetest-dev |
| 19:08 |
|
nanepiwo joined #minetest-dev |
| 19:12 |
|
nanepiwo joined #minetest-dev |
| 19:21 |
|
Robert_Zenz joined #minetest-dev |
| 20:09 |
|
DFeniks joined #minetest-dev |
| 20:27 |
eugd |
i'm going to ask it again; mapblock->octree? |
| 20:27 |
Krock |
PLease code it for us. |
| 20:27 |
eugd |
ha, ok |
| 20:28 |
eugd |
just trying to brainstorm stuff |
| 20:28 |
eugd |
as far as i can reckon it wouldn't suffer transversal problem |
| 20:32 |
eugd |
is everyone in agreement with paramat regarding #3199> |
| 20:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/3199 -- split map_generation_limit into x/y/z components by EUGD |
| 20:32 |
eugd |
just change the name? |
| 21:21 |
|
troller joined #minetest-dev |
| 21:27 |
|
eugd joined #minetest-dev |
| 21:48 |
|
paramat joined #minetest-dev |
| 21:51 |
paramat |
sfan5 ShadowNinja any comments to add on https://github.com/minetest/minetest_game/issues/480#issuecomment-145301062 ? |
| 21:56 |
paramat |
hmmmm sometime can you add comments to #3199? my opinion is here https://github.com/minetest/minetest/pull/3199#issuecomment-144213976 |
| 21:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3199 -- split map_generation_limit into x/y/z components by EUGD |
| 21:59 |
paramat |
btw AFAICR caverealms is slow due to placing lots of schematics (each with a separate lighting update) |
| 22:09 |
hmmmm |
you mean it doesn't register the schematics to be placed on map generation? |
| 22:10 |
paramat |
it might use 'place schematic' ... i might have misremembered |
| 22:10 |
hmmmm |
what the hell... why |
| 22:11 |
|
est31 joined #minetest-dev |
| 22:11 |
paramat |
the biome api can't place schematic decorations in some situations |
| 22:11 |
paramat |
so i see modders using 'place schematic' during lua mapgen |
| 22:11 |
paramat |
we need a way to blit a schematic into the lvm |
| 22:12 |
hmmmm |
well why don't they say something about it instead of using an extremely inefficient function as a workaround |
| 22:12 |
est31 |
eugd, I like ShadowNinja's idea as well |
| 22:12 |
eugd |
i'm looking at the code now |
| 22:12 |
paramat |
i should check caverealms code .. |
| 22:13 |
eugd |
but i still really don't like it, for the reasons i said in the comment page |
| 22:13 |
est31 |
what was it again |
| 22:13 |
ShadowNinja |
Hmmm? |
| 22:13 |
est31 |
https://github.com/minetest/minetest/pull/3199#issuecomment-143392234 |
| 22:14 |
paramat |
eugd it's okay if you don't want to make the PR, someone else can |
| 22:14 |
eugd |
can actually do it in one, i think |
| 22:14 |
ShadowNinja |
Ah, thanks. |
| 22:14 |
eugd |
no i'm working on it now, i just increasingly dislike it overall |
| 22:14 |
eugd |
really should be part of map structure |
| 22:15 |
eugd |
piling hacks on top of hacks |
| 22:15 |
kahrl |
I agree that it should be map metadata |
| 22:16 |
paramat |
hmmmmm i was wrong about caverealms, no heavy use of schems |
| 22:16 |
ShadowNinja |
kahrl: Good point, you'll have issues with multiple worlds other wise. |
| 22:17 |
est31 |
yea kahrl is right |
| 22:18 |
paramat |
oh per world .. |
| 22:18 |
est31 |
better having it be map metadata |
| 22:18 |
est31 |
but that has nothing to do with having it as setting |
| 22:24 |
paramat |
agreed, if we have map gen limit at all it should be per-world |
| 22:25 |
est31 |
well we do need one |
| 22:25 |
est31 |
as our addresses are limited :) |
| 22:42 |
|
paramat left #minetest-dev |
| 23:33 |
|
eugd joined #minetest-dev |
| 23:43 |
eugd |
this settings code is, bad. |
| 23:43 |
eugd |
like half of it is unused |
| 23:43 |
eugd |
i'm trying to sus out the 'standard' for doing this but there isn't really one |
| 23:56 |
est31 |
okay, what about not doing it? |
| 23:56 |
est31 |
and waiting until it becomes a param for the map? |
