| Time |
Nick |
Message |
| 02:09 |
|
Edgy1 joined #minetest-dev |
| 02:50 |
|
tuedel_ joined #minetest-dev |
| 02:55 |
|
tuedel joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:07 |
|
Beton joined #minetest-dev |
| 08:29 |
|
calcul0n joined #minetest-dev |
| 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* |
| 10:24 |
|
proller joined #minetest-dev |
| 11:38 |
|
Fixer joined #minetest-dev |
| 12:39 |
MTDiscord |
<IhrFussel> 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 |
<IhrFussel> 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 |
<IhrFussel> 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:52 |
|
calcul0n_ joined #minetest-dev |
| 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:04 |
|
T4im joined #minetest-dev |
| 13:08 |
|
T4im joined #minetest-dev |
| 13:10 |
|
T4im joined #minetest-dev |
| 13:15 |
Krock |
pgimeno: right. I'm mistaken. should be cubic |
| 13:20 |
MTDiscord |
<appguru> 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 |
|
T4im joined #minetest-dev |
| 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 |
<appguru> "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 |
<appguru> 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 |
<appguru> Intelligent modders don't check player:get_controls() == true |
| 13:42 |
MTDiscord |
<appguru> 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. |
| 13:45 |
|
T4im joined #minetest-dev |
| 13:53 |
|
T4im joined #minetest-dev |
| 14:02 |
|
lisac joined #minetest-dev |
| 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 |
| 14:48 |
|
absurb joined #minetest-dev |
| 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 |
| 18:11 |
|
calcul0n__ joined #minetest-dev |
| 19:07 |
|
proller joined #minetest-dev |
| 19:07 |
|
Lunatrius joined #minetest-dev |
| 19:10 |
|
appguru joined #minetest-dev |
| 19:38 |
|
olliy joined #minetest-dev |
| 19:48 |
|
fluxflux joined #minetest-dev |
| 19:56 |
|
Fixer_ joined #minetest-dev |
| 20:12 |
|
Fixer joined #minetest-dev |
| 21:36 |
|
GreenXenith joined #minetest-dev |
| 22:54 |
|
Taoki joined #minetest-dev |
