Minetest logo

IRC log for #minetest-dev, 2017-09-17

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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/minet​est/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/commi​t/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/b​lob/27144b471678b30156ad3383fb8d26a5bd​9b66cb/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/b​lob/27144b471678b30156ad3383fb8d26a5bd​9b66cb/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_ga​me/blob/4ccafd15187cf70d06d68ad3931912a​3c3c4b4f5/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/27144b471678b30156ad3383fb8d26​a5bd9b66cb/src/content_sao.cpp#L717
22:10 DTA7 And after receiving it added to the client here it seems: https://github.com/minetest/minetest/b​lob/27144b471678b30156ad3383fb8d26a5bd​9b66cb/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/27144b471678b30156ad3383fb8d26​a5bd9b66cb/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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext