Author Topic: Restrict Player Movement, Server-Sided?  (Read 2523 times)

Code: [Select]
new datablock(CustomDatablock : OriginalDatablock)
Isn't this a thing?

So you're going to do this for every single existing player datablock for every possible "alternate movement state"? Er..

Datablocks are a poor choice due to variables like player models, altered stats, and custom scripts. Also, the change datablock->change back stuff needs to be handled carefully so it doesn't break with other mods that do the same thing. For example, if a player picked up an item and became overburdened while zoomed in with a scope, they could unscope and walk away freely.

Physical zones can stop a player completely, and can be ideal in many circumstances, but in this case you wouldn't want the player to freeze in midair, and as Pecon said, they don't work properly in water.

The orbit-cam method of freezing a player generally works well, as long as you block off any servercmds you don't want them using while out of their body. Unfortunately you'd be out of luck if you still wanted them to be able to shoot. Also, admins can forget it up easily, accidentally or intentionally.

In this case, however, I think Headcrab Zombie had the best suggestion, however instead of mounting them to a shape, you could put them in the driver's seat of an invisible player that can barely move, so you still get your slow movement (albeit with no automatic animation, and the aiming may be a bit weird depending on how you set the control) without messing with the player's datablock directly. Having 2 or 3 datablocks for extra slowdown would let you control speed further by weight. You'd have to do a bit of scripting so the game doesn't treat it like a normal vehicle, but the overall result seems well suited to this purpose.

Would spawning an invisible, drivable player be treated as a bot or a vehicle? That might interfere with the server quotas though. I'll try using the orbit-cam method; which add-ons use it (so I can see how it works)?

Would spawning an invisible, drivable player be treated as a bot or a vehicle? That might interfere with the server quotas though. I'll try using the orbit-cam method; which add-ons use it (so I can see how it works)?
If you use AIvehicles, I really don't think it would be an issue. (I'd probably just arbitrarily increase and decrease the pref value when encumberance vehicles are created)

Code: [Select]
%player.client.setControlObject(%player.client.camera);
%player.client.camera.setMode("Corpse", %player);

To set them back, just set their player as the control object.

Would spawning an invisible, drivable player be treated as a bot or a vehicle? That might interfere with the server quotas though. I'll try using the orbit-cam method; which add-ons use it (so I can see how it works)?
I usually use Space Guy's TF2 Sandman for reference. I don't think players spawned through script use the quotas, though I could be wrong. As long as they have enough failsafes to make sure they're always cleaned up properly, I imagine they'd be fine.

I tried using the orbit camera and it works perfectly; gradually increasing the movement-restriction isn't really necessary. I set it up to re-apply or remove the restriction when items are picked up or dropped, or when a player teleports, respawns or clicks/triggers the observer. I'm not sure if I have to take any other situations into consideration though.

I tried using the orbit camera and it works perfectly; gradually increasing the movement-restriction isn't really necessary. I set it up to re-apply or remove the restriction when items are picked up or dropped, or when a player teleports, respawns or clicks/triggers the observer. I'm not sure if I have to take any other situations into consideration though.
Not in the default game I don't think. You could probably just package GameConnection::setControlObject. I'd do that and set up a 0 ms schedule to call an update function that'd set the control object accordingly, so as to avoid messing up other mods.