Time Nick Message 00:01 kilbith https://www.youtube.com/watch?v=swfWAO7H_lA 00:01 kilbith how not be bored during the lockdown 00:02 MTDiscord private video? 00:02 kilbith oops 00:03 kilbith public now 00:04 MTDiscord looks very nice ? 03:18 MTDiscord Neat 04:42 MTDiscord Guns stopped working after I added the PR. Gonna try the latest version 04:42 MTDiscord *version of it 04:55 MTDiscord Yep, fixed in latest version of the PR 12:51 zughy[m] declarations: do you prefer the former or the latter? https://i.imgur.com/wVG31xL.png 12:56 sfan5 there's a third option: v3d rotation(0,0,0); 12:56 sfan5 I prefer the = v3f(0, 0, 0); notation, I don't think our code style covers this though 13:25 rubenwardy I prefer the third option 13:26 zughy[m] am I wrong or the bone should be always declared? https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_object.cpp#L593 13:29 sfan5 I think it can be empty, but don't ask me for what reason 14:04 MTDiscord zughy: don't - "" is equivalent to the Node's true origin 14:05 MTDiscord not all ActiveObjects will contain an armature bone 14:05 MTDiscord like sprites 14:10 zughy[m] thanks Jordach :) 14:25 MTDiscord i'm deadly aware of node origins 14:25 MTDiscord t. wrote first person attachments 17:32 pgimeno aren't we in C++11? isn't v3d rotation{0, 0, 0} valid? 17:32 pgimeno v3f* 17:36 nerzhul we are in C++11, but i think we can bump to C++14 at a point 18:16 sfan5 if you ask me {} initializers are the ugliest syntax the C++ commitee has come up wtih 18:16 sfan5 with* 18:23 rubenwardy including [[]] annotations? 18:34 sfan5 I guess those are second place 18:34 nerzhul the annotations are omg 18:38 Krock will merge game#2761 and game#2772 in 10 minutes 18:38 ShadowBot https://github.com/minetest/minetest_game/issues/2761 -- more accurate russian translation. by CyberDonk3y 18:38 ShadowBot https://github.com/minetest/minetest_game/issues/2772 -- Slovak translations by daretmavi 18:42 Krock rubenwardy: is this change intentional? https://github.com/minetest/minetest/pull/10547/commits/0945d7e8f3c63 18:47 Krock merging 18:49 rubenwardy yes 18:50 Krock it reverts the original idea 18:50 rubenwardy which wouldn't have worked anyway 18:51 Krock how come? it seemed like a good approach 18:51 rubenwardy because the rotation is sent in the interact packet 18:52 Krock badly hacked clients could still be tricked this way 18:52 Krock it also makes sense to have the rotation sent together with the interact so that the exact rotation is known at the time 19:04 MTDiscord sometimes during lag anti-cheat accuses players from interacting with far away things 19:05 Krock that's already compensated IIRC 19:05 MTDiscord that's good to hear ? 19:05 Krock if not, it's as simple as velocity * avg_lag_time 19:06 Krock meanwhile players can still noclip and fly everywhere 19:07 MTDiscord because it's handled client side ? 19:08 MTDiscord best counter for forced flight is behavioral tracking 19:08 Krock calculating the distance to the next walkable node 19:09 MTDiscord sounds good, but what if the player is jumping? 19:09 Krock and never allow Y to increase in velocity when there's no node nearby 19:09 MTDiscord or holding sneak to prevent falling? 19:09 Krock hence "walkable node nearby check" 19:10 MTDiscord yeah, it would be a solution 19:10 Krock expensive to calculate, tho 19:10 MTDiscord how about gravity? 19:10 MTDiscord indeed expensive 19:10 Krock gravity is always negative, so the Y speed must decrease each step 19:11 Krock no such checks when gravity is 0 19:12 MTDiscord how often do you think the check should be applied? 19:13 Krock every second, perhaps? 19:14 MTDiscord how about this: 19:14 MTDiscord you check one player at a time 19:14 MTDiscord every 0.1 seconds 19:14 MTDiscord shouldn't be too bad 19:14 MTDiscord then you won't have a lag spike every one second 19:14 Krock though the range of nodes to check increases by velocity. if this isn't controlled well, velocities of 100m/s will cause enormous node lookups 19:16 pgimeno what's enormous here? 19:16 pgimeno 100m/s is 1.67 m/frame 19:17 Krock pgimeno: it's about server-side checks per player, per step 19:17 pgimeno ah ok 19:17 MTDiscord when you fly, your y velocity is pretty uniform, right? 19:17 MTDiscord contrary to when you jump 19:17 MTDiscord could you apply that somehow? 19:18 Krock right, the center of the node sphere to check would move towards the player's moving direction 19:23 MTDiscord also vertical behavior depends on minimum speed times speed physics override value 19:24 MTDiscord when falling, y velocity keeps decreasing past maximum speed till halted by unloaded blocks 19:25 MTDiscord when flying, y velocity drops and stays the same less than or equal to the max speed that a player can move 19:26 MTDiscord walkable node nearby check is a good way to track forced flight hovering behavior 21:45 celeron55 anti-cheat is kind of interesting because it forces the question of what actually are the rules in the game 21:46 celeron55 are the rules really the frame-by-frame physics or are the physics just a weird way to implement a simpler set of rules 22:39 MTDiscord The only rules in place at the moment is permissive free movement (ie: fast, fly, noclip), limited interaction distances, and group-based interaction limits 22:40 MTDiscord Other rules depend on a game