player:set_player_velocity() when?

[Piezo_]

Is this going to be added at some point?

[rubenwardy]

Probably never.

This is something that will be abused and needs to be done correctly in order to avoid lag. It's unlikely to be done in the form you suggest

[Pyrollo]

Too bad...

This would allow to make blast or push effects.

[TenPlus1]

Maybe having a player movement override so the player becomes a normal entity and can be manipulated in the same way, e.g. player:set_physics_override({control = false})

[rubenwardy]

Maybe having a player movement override so the player becomes a normal entity and can be manipulated in the same way, e.g. player:set_physics_override({control = false})

Yeah, this is one of the APIs that should be available in a solution.

Blasts or pushing should probably be done using impulses or forces.

[Piezo_]

Why/how would it be "abused", and how could it cause lag, any more than player:set_pos()? They're both just vectors, and changing them should be stupidly simple...

I would think the internal physics engine shouldn't have any trouble dealing with the velocity change. After all, you can already do this to lua entities...

[Pyrollo]

Maybe the problem is not set_player_velocity causing lag but lag making set_player_velocity very uncomfortable for the player. Like boats when there is lag and you feel like going back and forth in an uncontrolled and unrealistic way.

[Piezo_]

Maybe the problem is not set_player_velocity causing lag but lag making set_player_velocity very uncomfortable for the player. Like boats when there is lag and you feel like going back and forth in an uncontrolled and unrealistic way.

You could always use player:get_player_velocity() to get the player's velocity, and just modify that velocity, rather than overwriting it completely.

Besides, there are already hundreds of badly made mods, what's the harm in adding a tool that could also be used to make good ones?

[rubenwardy]

Why/how would it be "abused", and how could it cause lag, any more than player:set_pos()? They're both just vectors, and changing them should be stupidly simple...

set_pos is less time sensitive. It doesn't matter what time the client receive the message, it will still end up in the same position. A set velocity command could react up to 500ms late depending on network latencies, which would result in weird behaviour.

An API to give impulses and forces makes a lot more sense. Explosions, for example, are already decided on server-side and then sent to the client, meaning that an impulse could be sent alongside the visual effects to cause well timed reactions. Allowing nodes to exert forces (ie: flowing liquids) can also be done very well.

After all, you can already do this to lua entities...

Entities are controlled server-side. Players are controlled client-side. This is referred to as server authority and client authority.

TenPlus1's suggestion is to add an API which allows the server to temporarily change a player into server authority, allowing the player object to be controlled much like an entity.

[Piezo_]

TenPlus1's suggestion is to add an API which allows the server to temporarily change a player into server authority, allowing the player object to be controlled much like an entity.

Why not have it be both? That's what I'm planning on doing in the game I'm designing (Geode Engine). Both the client and server handle it, and when they have a disagreement, the server's perspective wins.

[Hybrid Dog]

There're already discussions about adding this to minetest: https://github.com/minetest/minetest/pu ... -219574694

[runs]

Talking about Rome... Now, there is a method to freeze a player?

[runs]

Well, there is a freeze mod

https://forum.minetest.net/viewtopic.php?f=9&t=19575&hilit=freeze+player

But there is another better method?

[Piezo_]

Well, there is a freeze mod

https://forum.minetest.net/viewtopic.php?f=9&t=19575&hilit=freeze+player

But there is another better method?

As we've seen from the link posted by Hybrid Dog, it looks like the developers prefer not even bothering with the feature rather than finding a proper way of resolving client/server inconsistency in the event of lag.

I'm not sure what the status of the push/impulse concept is, or if anyone's worked on it, but I still think that a solution of intelligently keeping client and server velocity in sync would be worth some effort.

[Hybrid Dog]

server provided CSM could probably do this and more, but somebody needs to implement it
https://github.com/minetest/minetest/pull/7949

[gpcf]

A vector field that specifies a force acting at each point on the player would be nice. This would also be quite lag-free, since the client knows how to act for a relatively long period of time.

[sorcerykid]

Well, there is a freeze mod

https://forum.minetest.net/viewtopic.php?f=9&t=19575&hilit=freeze+player

But there is another better method?

Yes, it's entirely possible to change player movement without the need for a new API.

On my server I do this to simulate slippery surfaces (like ice). I simply attach the player to an entity that has a transparent upright sprite. Then I can completely override the player's velocity, yaw, and acceleration. When the motion is complete, I simply detach the player from the entity and remove the entity from the environment to resume normal game mechanics.

Additionally, it's possible to check the player controls and factor in the corresponding movements (I do this for example by adding input velocity vectors with a given friction factor to the existing slippery vectors to simulate the player attempting to maneuver on the ice).

[TenPlus1]

This is how we do it also but attaching and detatching the player from entities causes visual glitches (the sliding into view glitch) which is why we really need it done in the engine itself.

[sorcerykid]

TenPlus1: I too have seen this glitch, but I'm using an older client (0.4.15). Wasn't that fixed already? I seem to recall a pull request to address this problem on GitHub, but I'm not sure if it was merged or still in progress.