ID:1192270
 
(See the best response by Stephen001.)
Problem description:

At some point I want to take control of the player's mob to act out a (very) short cut-scene of sorts. So far I haven't had to make a single alteration to Move(), and I fear that doing any may cause more 'lag' issues than lag itself. I'm sure such effects are minute, but I'd much prefer to have none at all, considering Move() is called so often.

So, avoiding the obvious altering-Move() option, is there a way to very temporarily remove control of a mob from the client, keeping their focus on that mob (so they keep looking at it), and then returning control to the client?

OR: am I just being super paranoid with the effects on gameplay from altering Move()?
client/Move()
if(has_control)
return ..()

You're being paranoid, I think. It's actually less processor-intensive to do nothing, by the way.
I figured it'd be less processor-intensive to do nothing, but how much does an "if" cost? I don't like the idea of every single mob in the world having to run through an "if" every single time they move when there's only the slightest chance it might apply to them.
Best response
Move() isn't called /that/ much, as such. It's just heavily loading Move() will be the thing that makes players observe latency, as they press a key, expect a prompt response.

That kind of if statement checking a boolean value, is very inexpensive, and so probably the kind of thing you want. The trick is mostly to make sure you limit what you add to Move() to necessary cases. This is directly control related (and response to keys pressed), so .. an ideal candidate for adding to client/Move().
In response to Ease
1. It's not every mob, just every client.
2. You're being extremely paranoid if you're worrying about if()s, as there's nothing more you can do to make it any faster. You're very likely having lag issues somewhere else, if at all.

If you don't want to see the if(), you can just use an operator. It might even be more "expensive," who knows.
client/Move() return has_control && ..()
Ok, cool. Thank you very much Stephen and Kaiochao. I honestly had no idea and thought it was worth checking before basing/building a whole system on top of an assumption. Glad to know better now ^_^