Time Nick Message 08:30 nerzhul hello, nice to see such activity on MT, sorry i am very very busy, i try to do some reviews sometimes. For the client it seems we are always stuck in terms of design improvements :( 08:49 specing the client needs more CSM APIs and CSMs 08:49 specing *incoming hate* 12:39 MTDiscord Sure but then it also needs a way to make csm restriction flags non-cheatable cause right now those are useless if you know what to modify to disable them 12:41 sfan5 as an open source game minetest cannot prevent users from editing the code 12:42 MTDiscord Btw wouldn't it be super easy to implement a method (or something similar) that allows servers to check when exactly a client loses connection? I'm not talking about the timeout, I mean I would like to check "when did the client sent the last 'heartbeat'" and then adjust somethings so that the user is not at a huge disadvantage cause they lost connection for a few seconds 12:43 sfan5 sure that'd be possible 12:44 MTDiscord Do clients send 'heartbeats'? And if so how often? 12:47 celeron55 they have to, otherwise it wouldn't be possible to detect a disconnection 12:48 celeron55 (doesn't mean i know where it happens) 12:53 celeron55 the easiest way to find out is probably to start a server and a client and watch with wireshark after there's no apparent activity... 12:55 celeron55 realistically though, if the player moves at all position packets will be sent 12:56 celeron55 and if anything happens in the world the server will be sending some reliable packets to which the client will respond 12:57 celeron55 if even just progression of time is enabled, the server will regularly send reliable packets for that and requires a response from the client 12:58 celeron55 and the default for time_send_interval is 5 seconds 12:58 celeron55 actually it's sent even if the time is stopped 12:59 celeron55 so there's one heartbeat, the client's responses to those packets 13:15 Krock pgimeno: right. I'm mistaken. should be cubic 13:20 MTDiscord https://www.wolframalpha.com/input/?i=solve+x%5E3+%3D+a%5Ebx 13:33 m42uko I'm currently looking a bit more into the input system to make it work better with analog inputs (joysticks / touchscreen). 13:33 m42uko What are your thoughts about completely removing the up/down/right/left keys, and replacing them with direction+speed floats, somewhat like that: https://github.com/m42uko/minetest/compare/fix/joystick_analog_rewrite...m42uko:fix/input_analogify_DONOTMERGE 13:34 m42uko I tried to make it look the same to the outside (aka server), but I'm sure I'm breaking some things here and there. But before I try to fix all of that, I wanted to hear your opinion on whether this approach even worth the time. 13:35 Krock makes sense 13:36 Krock though the modding API requires left/right/up/down so that mods work correctly 13:37 Krock CSM (l_localplayer) is okay, but the l_object changes break mods 13:37 Krock though that can be implemented by checking the direction 13:37 m42uko Yea I already suspected something like that when I saw the lua bindings 13:38 Krock > TODO: what is this? 13:38 Krock that's a feature where the player moves towards the pointed position without holding any keys 13:39 Krock should be exposed in the ESC menu key mapping 13:39 Krock / TODO: Proper float zero check! 13:39 Krock basically just "> 0.001f" is enough 13:41 m42uko Ah okay, so I'll just set the speed to 1 for autoforward and it should be fine. 13:41 MTDiscord "though the modding API requires left/right/up/down so that mods work correctly" I say go for it 13:41 Krock right 13:41 MTDiscord The truthiness (truthyness?) is preserved 13:41 m42uko Do we have a define for the float check threshold somewhere or should I create one -- or even hardcode the value? 13:41 MTDiscord Intelligent modders don't check player:get_controls() == true 13:42 MTDiscord You should set it to false if the input is below a certain treshhold 13:42 Krock so far I didn't see any constant. it's also easy to understand where this close-to-zero number comes from 13:42 Krock well at least to me it is 13:42 m42uko Yea I just think it should be the same everywhere. I don't like random constants in the code. 14:24 rubenwardy So, regarding physics modifier APIs: there seems to be quite a lot of bikeshedding over how it should behave 14:26 rubenwardy I see two options: 14:26 rubenwardy 1) C++ solution where it does all multipliers then all adders. Similar to raymoos PR 14:26 rubenwardy 2) Lua solution with cooperation from C++. This would do a similar thing by default, but would allow games and mods to change the behaviour. The C++ coop will be to add methods to the player ref 14:27 rubenwardy The difference is where the overall override is calculated from the modifiers 14:27 rubenwardy 1) could always be done before 2), hmm 14:27 rubenwardy 2) is slightly harder to implement than 1) but may resolve the road block 14:28 sfan5 I don't see what's wrong with 1 14:30 rubenwardy I'll just do 1) and see if it's accepted 16:27 rubenwardy anyway: #10731 16:27 ShadowBot https://github.com/minetest/minetest/issues/10731 -- Add physics modifiers API by rubenwardy 16:27 rubenwardy although, please prefer my serverlist PR :D 16:27 rubenwardy or anything else 16:46 rubenwardy PlayerSAO *playersao = (PlayerSAO *) getobject(ref); 16:46 rubenwardy errr, shouldn't this be a dynamic_cast? 16:46 rubenwardy you don't know whether it's a player object or not 16:56 sfan5 isn't the type checked beforehand? 16:58 rubenwardy not that I can see