Scripters take control of people with three script functions:
Only one of those is necessary. SelectPlayer actually does changeCamera on its own, and remoteControl is for controlling turrets, not players.
|This image has been resized. Click this bar to view the full image. The original image is sized 1027×765.|
Name: selectPlayer Name (Long): selectplayer Arg1: unit Description: Switch player to given unit. Example Use: selectPlayer aP Category: General Function: 0x7ADF17
That’s selectPlayer. It does a lot. It messes with the AIBrain in the entities, then does things with the network managers and network clients if you’re in multiplayer, and sends a message to the server in one of those networkManager functions. That message is important, because it tells the server to give your client locality over the target. This is why if you set your local player pointer to the entity of another player, nothing you do to them ‘sticks’. If you move, you get pulled back. If you fire, their ammo goes down but no bullet comes out. All you can do is things on the scroll wheel, and that’s why: you don’t have locality of that entity, so the server doesn’t accept your changes to it.
So by calling selectPlayer, we can get locality of the target. Then, any changes we make ‘stick’, and the previous owner of the entity’s changes don’t ‘stick’. So when you take control of someone, whenever they move, they get pulled back. When they fire, the ammo count goes down but no bullet comes out. Sounds familiar, right?
Calling selectPlayer is easy. The first argument is a buffer in which it can build a gameValue object, just make an 8 byte buffer for that. The second argument is sometimes the GameState object, and sometimes 0. selectPlayer never actually uses this argument, so passing it 0 is safe. The third argument is what I call unitInfo, it’s the link object that points to an entity. Like dfcdd8] + 13a8].
And that’s all there is to it. Give it a second or two and you’ll be controlling your target completely.
selectPlayer( buffer, 0, target );