| Time |
Nick |
Message |
| 00:00 |
rubenwardy |
diff between last good and current bad: https://github.com/minetest/minetest/compare/468eb4bf5710e851b2599baeff870518f979c71a..master |
| 00:00 |
Sokomine |
it didn't crash immediately for me, Lone_Wolf. took a few seconds. i'm not sure what triggered it |
| 00:00 |
rubenwardy |
I have a suspicion that this is related to the weight removal, as that touched packets |
| 00:01 |
Sokomine |
could be. afaik packet message problems where mentionned when it crashed |
| 00:07 |
Lone_Wolf |
I was on Craig's for a minute or two |
| 01:26 |
p_gimeno |
It crashes in this line: SharedBuffer<u8> chunkdata(chunkdatasize); with chunkdatasize = 495 |
| 01:28 |
p_gimeno |
well, actually in this other line: data = new T[m_size]; with T = u8 and m_size = 495 (called from the line above) |
| 01:30 |
p_gimeno |
'The "invalid size" that the message refers to is not your size argument but an internal "chunk size" used by the memory manager, which has an unexpected value. Since that is invalid, you must have a memory corruption bug somewhere in your code.' |
| 01:30 |
p_gimeno |
so, double free or buffer overflow (probably the latter) |
| 01:42 |
|
ANAND joined #minetest-dev |
| 02:04 |
|
Lone_Wolf joined #minetest-dev |
| 02:57 |
|
fluxflux joined #minetest-dev |
| 03:37 |
|
pmp-p joined #minetest-dev |
| 04:04 |
|
ANAND_ joined #minetest-dev |
| 04:18 |
|
ANAND_ joined #minetest-dev |
| 04:28 |
|
ANAND joined #minetest-dev |
| 04:31 |
|
ANAND_ joined #minetest-dev |
| 04:34 |
|
ANAND_ joined #minetest-dev |
| 04:36 |
|
ANAND_ joined #minetest-dev |
| 04:38 |
|
ssieb joined #minetest-dev |
| 06:53 |
|
pmp-p joined #minetest-dev |
| 07:27 |
|
troller joined #minetest-dev |
| 07:58 |
|
ANAND joined #minetest-dev |
| 08:37 |
|
ShadowNinja joined #minetest-dev |
| 09:42 |
|
troller joined #minetest-dev |
| 10:16 |
|
erlehmann joined #minetest-dev |
| 10:36 |
|
df458 joined #minetest-dev |
| 10:39 |
|
erlehmann joined #minetest-dev |
| 12:09 |
|
proller joined #minetest-dev |
| 12:30 |
|
proller joined #minetest-dev |
| 12:42 |
|
erlehmann_ joined #minetest-dev |
| 13:34 |
|
Fixer joined #minetest-dev |
| 13:48 |
|
pmp-p joined #minetest-dev |
| 13:54 |
|
Taoki joined #minetest-dev |
| 14:37 |
|
absurb joined #minetest-dev |
| 14:50 |
|
proller joined #minetest-dev |
| 15:19 |
|
pmp-p joined #minetest-dev |
| 15:23 |
|
erlehmann joined #minetest-dev |
| 15:29 |
|
proller joined #minetest-dev |
| 15:55 |
|
proller joined #minetest-dev |
| 16:51 |
|
indiana joined #minetest-dev |
| 17:40 |
|
Krock joined #minetest-dev |
| 18:24 |
rubenwardy |
merging #9314 in 10 |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/9314 -- Update translations by rubenwardy |
| 18:28 |
Krock |
what is ChatBuffer::formatChatLine() even supposed to do? |
| 18:28 |
|
erlehmann joined #minetest-dev |
| 18:30 |
|
Wuzzy joined #minetest-dev |
| 18:30 |
Krock |
the text wraps automatically even without that |
| 18:30 |
Wuzzy |
I fixed pathfinder. Sorta. #9339 |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/9339 -- Fix pathfinder bugs: returning nil frequently, broken A*, jump through solid nodes by Wuzzy2 |
| 18:31 |
Wuzzy |
afk |
| 18:32 |
rubenwardy |
thanks so much, Wuzzy |
| 18:33 |
rubenwardy |
Krock: did we decide on rebasing-merge or squash-merge for #9314 ? |
| 18:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/9314 -- Update translations by rubenwardy |
| 18:33 |
Krock |
rebase is OK |
| 18:34 |
rubenwardy |
done |
| 18:51 |
Krock |
finally gdb provides valid backtraces on "throw NULL;" |
| 18:52 |
Krock |
previously it seemed to be connected to a garbage bin |
| 18:54 |
rubenwardy |
isn't it recommended not to throw heap initialised objects? |
| 19:10 |
p_gimeno |
Wuzzy: well done, kudos! as for your question, I vote for XZ only. |
| 19:11 |
p_gimeno |
Wuzzy: what's the height for fitting through doors? 2 nodes? (and shouldn't that be a parameter?) |
| 19:17 |
|
erlehmann_ joined #minetest-dev |
| 19:20 |
|
Lone_Wolf joined #minetest-dev |
| 19:35 |
Krock |
Wuzzy: background_chat.jpg is not documented |
| 19:44 |
Krock |
will push fix for #9338 in 15 minutes: https://krock-works.uk.to/u/patches/0001-EnrichedString-Fix-substr-segfault-caused-by-non-for.patch |
| 19:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/9338 -- Memory corruption (recent) |
| 19:44 |
Krock |
interestingly I never got two identical backtraces in gdb |
| 19:50 |
Krock |
Wuzzy: https://i.imgur.com/4XteJPw.png |
| 19:50 |
Sokomine |
p_gimeno: afaik most pathfinders can *not* find paths through doors. it'd surprise me if the one in the engine would be aware of them |
| 19:56 |
sfan5 |
Krock: s/assert/SANITY_CHECK/ maybe |
| 19:57 |
Krock |
I thought about that as well, but I don't see a need for this check in release builds |
| 19:57 |
Krock |
it means that EnrichedString is again malfunctioning internally |
| 19:58 |
Krock |
well, adding it doesn't hurt either |
| 19:59 |
sfan5 |
better than hard to debug memory corruption for sure |
| 19:59 |
Krock |
mmh.. longer compiling time again |
| 19:59 |
Krock |
whatever, will add it |
| 20:01 |
|
ssieb joined #minetest-dev |
| 20:06 |
Krock |
works. pushing... |
| 20:11 |
Wuzzy |
p_gimeno: height clearance is not implemented. the pathfinder is only on a node-per-node basis |
| 20:11 |
Wuzzy |
but I agree, that's a required and important feature for pathfinder. but not for this PR |
| 20:12 |
Wuzzy |
first step is to actually make the pathfinder work at all ^^ |
| 20:12 |
Wuzzy |
oh you mean doors? |
| 20:12 |
Wuzzy |
ha, doors are an entirely different beast |
| 20:16 |
sfan5 |
perhaps mods should just be able to specify a list of nodes that the pathfinder will consider to be air |
| 20:17 |
Sokomine |
sfan5: that might be helpful, yes. mobs that can open doors can then specify them and pass through. that might save some problems |
| 20:18 |
Sokomine |
however, doors are not the only problem regarding pathfinders. we do have nodeboxes and meshes. in a house built by me, pathfinders have a hard life. thin slabs as walls and handrails block the path in some directions only. handling that would probably be too much for a pathfinder in the engine |
| 20:19 |
Wuzzy |
specifying which nodes are "free" and which are "blocked" is also an idea that I had |
| 20:20 |
Wuzzy |
nodeboxes are one of the biggest challenges for a pathfinder, true |
| 20:20 |
Sokomine |
though the existing ones i've seen usually have an extra function that checks weather a particular node can be reached. if there could be a callback there, that could help a lot for some mobs |
| 20:20 |
Wuzzy |
i have experimented with burli's [pathfinder] mod a bit to automate a bit the handling of nodeboxes |
| 20:21 |
Wuzzy |
its very basic and only looks at 1-box nodeboxes if they are thin enough |
| 20:21 |
Sokomine |
Wuzzy: i did to some degree as well, but only with particular, known nodes - not on a general nodebox- or rather collision-box-level |
| 20:21 |
Wuzzy |
I try to keep hardcoding away |
| 20:22 |
Wuzzy |
my code basically checks e.g. if the single-box nodebox is far to the side, thin enough and not too far in center. then my code concludes its passable in that direction |
| 20:22 |
Sokomine |
mobs acting as npc will need to interact specificly with some specific objects (things they can sit on, beds, workplaces, ..) so it's acceptable for me to have specific handling for that kind of mob |
| 20:23 |
Sokomine |
that is very good, wuzzy. better and more general than what i attempted with burlis pathfinder |
| 20:23 |
Wuzzy |
its still makes my head hurt and is far from complete |
| 20:23 |
Sokomine |
Wuzzy: can this checking be included in the engines pathfinder at least in theory? |
| 20:24 |
Wuzzy |
you also need to consider rotations thanks to facedir and wallmounted ... |
| 20:24 |
Sokomine |
(i mean as a callback) |
| 20:24 |
|
fluxflux joined #minetest-dev |
| 20:24 |
Wuzzy |
sorcerykid claimed to have made a lua pathfinder with callbacks, but with the callback results cached so it doesnt need to be called over and over again |
| 20:25 |
Wuzzy |
sorcerykid says the callback idea is basically only meant for the highly complex cases that somehow cannot be automated away |
| 20:26 |
Wuzzy |
note my notebox analysis still needs overthinking as well |
| 20:26 |
Wuzzy |
there needs to be awareness of how big the nodebox tolerance will be... |
| 20:26 |
Wuzzy |
but i guess this stuff could be done very efficiently |
| 20:27 |
Wuzzy |
just cache the "passable" flag for each node |
| 20:27 |
Wuzzy |
maybe even globally so it's always O(1) for pathfinder |
| 20:28 |
Wuzzy |
there only needs to be one loop at startup that checks in which dirs nodes are passable... |
| 20:28 |
Wuzzy |
but i'm not sure how well this works out for differently-sized entities |
| 20:29 |
Wuzzy |
Sokomine: But yes, i suppose in theory, you could do the callback thing |
| 20:30 |
Wuzzy |
i am just not sure if its a good idea. more code ... |
| 20:30 |
Wuzzy |
we should try to keep code size small. i mean of lua code at least. Let the engine do the "hard" things |
| 20:31 |
Wuzzy |
figuring out how to collide with nodeboxes is something i consider "hard"/complex |
| 20:32 |
Wuzzy |
Krock: whats with that Bender img? |
| 20:34 |
Krock |
scroll up further |
| 20:46 |
Sokomine |
Wuzzy: sounds like a good plan. diffrent-sized entities are always a problem |
| 20:47 |
Sokomine |
i agree, wuzzy. perhaps that cached list might help there as you already suggested - so that lua does the checking of each node and direction, and the engine just gets that node list as a parameter |
| 20:48 |
Wuzzy |
I propose to also keep the features relatively lightweight, in order to not drown in complexity. good design is important |
| 21:15 |
Sokomine |
wuzzy: definitely. it's more a remaining aware of such features beeing necessary in some situations and not to close doors there too early if possible |
| 21:19 |
|
mizux joined #minetest-dev |
| 21:38 |
|
erlehmann joined #minetest-dev |
| 21:47 |
|
df458 joined #minetest-dev |
| 21:52 |
|
An0n3m0us joined #minetest-dev |
| 23:02 |
|
proller joined #minetest-dev |
| 23:19 |
|
DI3HARD139 joined #minetest-dev |
| 23:21 |
p_gimeno |
Wuzzy: I meant height clearance. I said doors to make it simpler. So 1 node height? |
| 23:21 |
Wuzzy |
yea |
| 23:21 |
Wuzzy |
still |
| 23:21 |
Wuzzy |
its a pathfinder for things that a 1 node tall |
| 23:22 |
Wuzzy |
height clearance is an important feature for the future, definitely |
| 23:22 |
p_gimeno |
ok, thanks |
| 23:22 |
Wuzzy |
I think it would be pretty easy to implement, but it will come at a price ... |
| 23:22 |
p_gimeno |
what about e.g. lava? is it considered air? walkable? unwalkable? |
| 23:23 |
Wuzzy |
pathfinder only knows "walkable" and "non-walkable" |
| 23:23 |
Wuzzy |
and in Minetest Game, lava is non-walkable |
| 23:23 |
Wuzzy |
in other words, pathfinder happily guides you into lava ? |
| 23:23 |
p_gimeno |
I see |
| 23:23 |
Wuzzy |
yeah being able to exclude nodes from search will also be important feature, sure |
| 23:24 |
Wuzzy |
i had the same throughs as you |
| 23:24 |
Wuzzy |
because those featurs are no-brainers |
| 23:24 |
p_gimeno |
I'm just reflecting on the future of pathfinding for minetest :) |
| 23:25 |
Wuzzy |
I'd say height clearance would be top priority, with custom node exclusion on rank 2 (because liquids are common) |
| 23:25 |
p_gimeno |
the distinction "walkable" / "non-walkable" is a bit ambiguous to me |
| 23:25 |
Wuzzy |
walkable = solid |
| 23:25 |
Sokomine |
the bugfixes from today seem to work. latest mt runs smoothly again |
| 23:25 |
p_gimeno |
so, a wall is walkable? |
| 23:25 |
Wuzzy |
yes |
| 23:26 |
p_gimeno |
ok, I see |
| 23:26 |
Wuzzy |
walkable means that entities will collide with it |
| 23:26 |
Wuzzy |
and players |
| 23:26 |
Wuzzy |
all objects |
| 23:26 |
Wuzzy |
it's called "walkable" because you walk on it |
| 23:26 |
Wuzzy |
its a weird term, its just the same word you find in node definition |
| 23:27 |
p_gimeno |
I see |
| 23:27 |
Sokomine |
exactly. there's also climbable...havn't found a solution for that in pathfinding yet. i'm afraid a 2d pathfinder may run into problems there |
| 23:27 |
Wuzzy |
but this means that pathfinder will be able to walk through e.g. most plants since they dont collide |
| 23:27 |
Wuzzy |
climbable is a bonus =) |
| 23:28 |
Wuzzy |
for later |
| 23:28 |
Wuzzy |
hmmm i should maybe write down all ideas |
| 23:28 |
p_gimeno |
sounds like a good idea |
| 23:28 |
p_gimeno |
and making an enhancement proposal issue with them |
| 23:29 |
Wuzzy |
one thig that sounds really problematic are mobs that are wider than 1 node ... |
| 23:29 |
Wuzzy |
I'm afraid they might require a new algorithm even |
| 23:30 |
p_gimeno |
well, a more sophisticated collision algorithm than examining just the immediate node's type I'd say. It would need to check its neighbours too. |
| 23:31 |
Wuzzy |
but the thing is, in which direction do you check? |
| 23:31 |
Wuzzy |
if you have a 2×2×2 mob |
| 23:32 |
Wuzzy |
if you just slap many checks on every A* iteration, i think the runtime will quickly explode |
| 23:32 |
* Sokomine |
compresses the mob into a neat 1x1x1 cube, squeezes it through the path, and then inflates it again |
| 23:33 |
Wuzzy |
i wonder how MC does it ... MC has big mobs, too |
| 23:33 |
Sokomine |
if mobs are solid and collide with each other and with players, mobs may easily block paths as well. but those are more complex things where there really isn't a good solution yet |
| 23:33 |
Wuzzy |
maybe big mobs don't actually pathfind until player is close? ? |
| 23:34 |
Sokomine |
could make sense. big mobs won't want to move quickly most of the time (too much mass to move or brake) |
| 23:35 |
Wuzzy |
hmmmm objects could trigger all nodes they touch to be "occupied", so A* would treat them as solid nodes. the challenge is how to do it efficiently |
| 23:38 |
p_gimeno |
I'm trying to think about a groups system so that depending on the type of mob, certain nodes are walkable or not |
| 23:39 |
Wuzzy |
i'd rather keep it simple. just tell the function your nodes config |
| 23:39 |
p_gimeno |
yeah, that makes sense too |
