Restrict Player Movement, Server-Sided?

[[GSF]Ghost]

What would be the best way to restrict a player's movement, without relying entirely on client-sided code? I wanted to setup an encumbrance system so that, if someone exceeds the maximum allotted weight they can carry, they can't move until they drop some items.

I had originally tried over-riding the move functions, but the client-sided code can easily be removed by the player, thus breaking the encumbrance system. Also, is there a way to gradually reduce movement speed (without using walk(1))? I would prefer to set it up so that a player's movement speed is reduced relative to the amount their max weight is exceeded. Thanks!

[Ad Bot]

[otto-san]

depending on the kind of situation, you may just have to have multiple datablocks

[John Constantina]

it's possible,  i remember port made it, I had it at one point, but my os crashed in july.

[[GSF]Ghost]

Multiple datablocks is probably my best option; I can set different movement speeds for each and assign players to certain ones depending on the amount of max-weight exceeded. It may cause problems with other add-ons that use specific datablocks, but I don't think there's any way around that. Thanks guys.

[Swollow]

the only other way I can think of doing it would be creating mini zones on the player that have drag

[[GSF]Ghost]

I tried using zones with triggers and it seems to work just fine; is there a way to mount a zone to a player, rather than constantly update it's position relative to the player?

[Port]

I tried using zones with triggers and it seems to work just fine; is there a way to mount a zone to a player, rather than constantly update it's position relative to the player?

Nope, but constantly updating the position works just fine.

[Pecon]

The only issue with using a zone is that it will not be effective in water.

[[GSF]Ghost]

That's alright, I think using a zone and constantly updating it's position is the best solution. I had to offset the zone to align with the player, but it's working great now.

[$trinick]

I disagree, I'm positive that the overhead for a secondary datablock is much less than constantly updating a zone's position.

You should be able to parent Player::setDatablock to refuse to change datablocks from your immobilized playertype unless they have satisfied some condition.

[[GSF]Ghost]

I would prefer to use custom datablocks instead, but I don't want to interfere with other custom player datablocks that might be used. I guess I could include both options and let the host choose...

[Headcrab Zombie]

You could completely stop a player by mounting them to an invisible shape.
You'd want to wait until their touching the ground so they're not floating, though. And it would stop them from any type of knockbacks.
You wouldn't be able to gradually slow them using this method though

[elm]

I would prefer to use custom datablocks instead, but I don't want to interfere with other custom player datablocks that might be used.

How would they interfere, i don't understand..

[[GSF]Ghost]

Like if a custom maxTools amount or player model was being used for one datablock, but then after being over-encumbered, they revert back to the standard maxTools / player model with the encumbrance datablock.

However, I've decided just to use custom player datablocks anyway, instead of using zones; it might not be that big of an issue, plus I can revert the player back to their previous datablock if they are no longer over-encumbered (even if the maxTools amount changes, they don't loose items in their tools inventory when reverting back, which helps).

[Scout31]

Code: [Select]

new datablock(CustomDatablock : OriginalDatablock)
Isn't this a thing?