| Time |
Nick |
Message |
| 00:04 |
paramat |
and the 'biomerepeat' mgv7 flag is kept to avoid potential flag breakage |
| 00:05 |
rubenwardy |
lgtm |
| 00:05 |
rubenwardy |
+1 as long as you're confident it won't break existing maps too much |
| 00:21 |
paramat |
ok, well it may alter the biomes of worlds started in this dev cycle but that's low priority, and only if water level was altered or floatlands were enabled, which is rare, floatlands are still officially very unstable anyway |
| 00:23 |
rubenwardy |
good enough for me |
| 01:20 |
paramat |
ugh i created a mapgen bug with my last commit, will now fix |
| 01:24 |
thePalindrome |
inb4 that fix undoes the last commit |
| 01:29 |
paramat |
nah i can fix it and keep the feature |
| 01:46 |
paramat |
ok just a 1 line fix |
| 01:56 |
Hijiri |
this isn't caused by my code is it? https://travis-ci.org/minetest/minetest/jobs/276395807 |
| 02:08 |
paramat |
#6427 will merge later |
| 02:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/6427 -- Biome generation: Fix layers of 'filler' nodes in cliffs by paramat |
| 02:10 |
paramat |
the build error is not your fault, this seems to happen sometimes |
| 02:10 |
paramat |
it's been happening a lot recently, build failng due to a travis error |
| 02:18 |
paramat |
will merge #6427 now |
| 02:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/6427 -- Biome generation: Fix layers of 'filler' nodes at biome y limits by paramat |
| 02:22 |
paramat |
done |
| 02:49 |
|
Robby joined #minetest-dev |
| 04:27 |
|
paramat joined #minetest-dev |
| 04:30 |
paramat |
merging #6425 |
| 04:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/6425 -- Biome API: Revert biomes, decos, ores being relative to water level by paramat |
| 04:40 |
paramat |
done |
| 05:17 |
paramat |
now merging the necessary corresponding mtgame PR game#1893 |
| 05:17 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1893 -- Biome registration: Update due to revert of mgv7 'biomerepeat' option by paramat |
| 05:22 |
paramat |
merged |
| 05:31 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:14 |
|
Hunterz joined #minetest-dev |
| 08:02 |
|
cx384 joined #minetest-dev |
| 08:25 |
|
nerzhul joined #minetest-dev |
| 08:41 |
|
Krock joined #minetest-dev |
| 08:55 |
|
srifqi joined #minetest-dev |
| 08:55 |
srifqi |
~tell paramat I've done fixing my PR, please review. |
| 08:55 |
ShadowBot |
srifqi: O.K. |
| 09:14 |
|
Raven262 joined #minetest-dev |
| 10:22 |
|
Darcidride joined #minetest-dev |
| 10:28 |
|
Krock joined #minetest-dev |
| 10:47 |
|
Fixer joined #minetest-dev |
| 11:07 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:07 |
|
Megaf joined #minetest-dev |
| 12:21 |
|
miner9911 joined #minetest-dev |
| 13:01 |
|
Player_2 joined #minetest-dev |
| 14:26 |
|
Warr1024 joined #minetest-dev |
| 14:39 |
jcalve |
src/script/lua_api/l_server.cpp is missing the headers that define AF_INET in openbsd |
| 14:39 |
jcalve |
src/script/lua_api/l_server.cpp |
| 14:40 |
jcalve |
https://man.openbsd.org/inet_net.3 |
| 14:56 |
|
nerzhul joined #minetest-dev |
| 15:37 |
|
Megaf joined #minetest-dev |
| 15:38 |
|
Megaf joined #minetest-dev |
| 15:50 |
celeron55 |
jcalve: fix it, test it and then pastebin a diff and link it or even better, make a PR |
| 15:50 |
jcalve |
celeron55: I would |
| 15:50 |
jcalve |
however |
| 15:51 |
jcalve |
I'm not sure which header defines it so I just pasted all of them and compiled |
| 15:51 |
celeron55 |
you're not going to get us to research openbsd headers for you |
| 15:51 |
celeron55 |
it's a fact |
| 15:51 |
celeron55 |
however rude you may find it |
| 15:52 |
jcalve |
I don't care I was just letting you know |
| 15:52 |
jcalve |
if I do a pr do you want some #if openbsd macro or as is? |
| 15:54 |
celeron55 |
if you find a single header is needed, it should probably be there for all posix platforms |
| 16:09 |
jcalve |
so #ifndef _WIN32 ? |
| 16:32 |
jcalve |
done #6430 |
| 16:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/6430 -- Fix compile error in openbsd by jcalve |
| 17:58 |
|
Raven262 joined #minetest-dev |
| 19:48 |
|
kensatya joined #minetest-dev |
| 19:49 |
kensatya |
Where can I find the code that renders player skins? |
| 19:51 |
|
nerzhul joined #minetest-dev |
| 20:15 |
|
Xio joined #minetest-dev |
| 20:17 |
|
DTA7 joined #minetest-dev |
| 20:19 |
DTA7 |
Is there a reason that in line 151 in builtin/game/item_entity.lua only vel.y ~= 0 is checked and not the x- and z-directions? |
| 20:26 |
celeron55 |
could be due to items not really moving to any other direction than falling down |
| 20:26 |
celeron55 |
at least historically |
| 20:30 |
celeron55 |
https://github.com/minetest/minetest/commit/aa46e5c5e7285a8ac5c9e096a55c3fa02b90280e |
| 20:30 |
celeron55 |
it was added here |
| 20:30 |
celeron55 |
apparently something to do with nodeboxes in 0.4.5 |
| 20:30 |
celeron55 |
no idea 8) |
| 20:38 |
celeron55 |
0.4.5 to 0.4.16 seems like little but it's actually 5 years, lol |
| 20:39 |
celeron55 |
DTA7: does it cause misbehavior? |
| 20:47 |
DTA7 |
No, sorry, I just noticed it is very much needed this way on non-slippery nodes. |
| 20:48 |
DTA7 |
The problem is that item entities next to TNT with is_physical = false do not have collision detection when the movement takes place. |
| 20:51 |
DTA7 |
It works if the TNT mod sets obj:set_properties({physical = true}) (which it doesn't). Is it intended for the mod to set physical? |
| 20:53 |
|
Fixer joined #minetest-dev |
| 20:58 |
celeron55 |
no |
| 20:59 |
celeron55 |
or, hmm |
| 21:00 |
celeron55 |
so the problem is that items set themselves as having no physics once they stop, and then if something makes them move, they at least initially don't have physics |
| 21:01 |
celeron55 |
i guess it's ok to set physical=true, but... is there a good way to know which entities should be set physical in that situation and which entities to not touch? |
| 21:01 |
celeron55 |
just hardcode items only? |
| 21:02 |
celeron55 |
maybe the engine should be capable of transparently shutting down physics for things so as not to require weird things like what the items do, but... it doesn't |
| 21:02 |
celeron55 |
isn't* |
| 21:02 |
DTA7 |
In src/content_sao.cpp, the test for physics (and if true the collision detection) is performed before the on_step in buitin/item_entity.lua, where only the y direction is considered |
| 21:03 |
celeron55 |
what happens if you make it check x and z also? |
| 21:03 |
DTA7 |
*builtin/game/item_entity.lua |
| 21:03 |
DTA7 |
The items keep moving like on a slippery node, but without deceleration in x- and z-direction |
| 21:04 |
celeron55 |
what did you modify the line into? |
| 21:05 |
DTA7 |
local is_physical = (def and not def.walkable) or (vel.x ~= 0 or vel.y ~= 0 or vel.z ~= 0) |
| 21:05 |
DTA7 |
https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/builtin/game/item_entity.lua#L187-L192 |
| 21:05 |
DTA7 |
Here the item is stopped if is_physical = false |
| 21:07 |
celeron55 |
wait, this doesn't make sense |
| 21:08 |
celeron55 |
tnt sets a velocity, then with that change the item should set physical=true for itself no matter which direction it is going, right? |
| 21:08 |
celeron55 |
but it doesn't? |
| 21:10 |
celeron55 |
i don't see why it wouldn't work, unless the reason why it doesn't work is that physics and on_step happen in different order than you think (i don't remember) |
| 21:11 |
DTA7 |
https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/src/content_sao.cpp#L659-L662 |
| 21:11 |
DTA7 |
No, it only sets m_velocity |
| 21:12 |
celeron55 |
i mean the item's on_step modifies the item's own physical group |
| 21:12 |
celeron55 |
based on whether it has velocity or not |
| 21:12 |
DTA7 |
Which on_step do you mean? In builtin/game/item_entity.lua? |
| 21:12 |
celeron55 |
yes |
| 21:14 |
DTA7 |
https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/src/content_sao.cpp#L350-L394 |
| 21:15 |
celeron55 |
yeah, so physics happen first, or movement with no collision detection if physical=false |
| 21:15 |
DTA7 |
Yes |
| 21:15 |
celeron55 |
that's the issue |
| 21:16 |
DTA7 |
Yeah I think so |
| 21:16 |
celeron55 |
i wonder if switching the order would break something or cause performance problems |
| 21:17 |
DTA7 |
This would affect all server-side entities, right? |
| 21:18 |
celeron55 |
yep |
| 21:21 |
celeron55 |
i think the real question is, how cheap is collisionMoveSimple when an item is resting on a walkable node |
| 21:21 |
celeron55 |
the ideal solution would be to not switch things between physical and non-physical from lua; it's stupid |
| 21:22 |
celeron55 |
just keep items physical always |
| 21:33 |
|
Fritigern joined #minetest-dev |
| 21:33 |
DTA7 |
If it has no velocity, the collision detection is not done in collisionMoveSimple anyway |
| 21:38 |
DTA7 |
So in item_entity.lua, if vel.y = 0, there would only the velocity need to be set to zero if on a non-slippery node, and decelerated if on a slippery one, right? |
| 21:56 |
DTA7 |
https://github.com/minetest/minetest_game/blob/4ccafd15187cf70d06d68ad3931912a3c3c4b4f5/mods/carts/cart_entity.lua#L2 |
| 21:56 |
Hijiri |
Where are the visual positions of entities updated? |
| 22:06 |
DTA7 |
The message for the update is created here: https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/src/content_sao.cpp#L717 |
| 22:10 |
DTA7 |
And after receiving it added to the client here it seems: https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/src/clientenvironment.cpp#L352 |
| 22:10 |
Hijiri |
Sorry, I forgot to specify that I was asking an unrelated question |
| 22:20 |
DTA7 |
I think I found it: https://github.com/minetest/minetest/blob/27144b471678b30156ad3383fb8d26a5bd9b66cb/src/content_cao.cpp#L707 |
| 22:47 |
|
elinor joined #minetest-dev |
| 23:07 |
|
twahm joined #minetest-dev |
| 23:12 |
|
ircSparky joined #minetest-dev |
| 23:46 |
|
paramat joined #minetest-dev |
| 23:48 |
|
Megaf joined #minetest-dev |
| 23:56 |
paramat |
hmm L151 of item_entity.lua probably should have checks for vel.x/z ~= 0 |
| 23:57 |
paramat |
if it's moving it should be physical |
| 23:59 |
paramat |
oh but then "The items keep moving like on a slippery node, but without deceleration in x- and z-direction" apparently |
| 23:59 |
paramat |
which seems wrong |
