ID:160433
 Sep 12 2008, 2:34 pm
|
|
I need to know the best way to make it so a mob is given control over the movement of an object, any object. Thanks
| |
Mobius Evalon wrote:
Dragonn wrote: Well, I set client.eye to the object. Affected nothing but what my center of sight was. What do you mean in more detail? Maybe just make a working example somebody... | |
Well, you believe wrong; it moves the mob stored in src's (the client's) mob var, regardless of the eye or perspective.
Anyway, to answer the OP's question, you'd override the players' (clients) movement initiation procs (client/North(), client/South()...) or the central client/Move() proc to do whatever alternate behavior you want if the player is controlling another object. | |
Kaioken wrote:
Well, you believe wrong; it moves the mob stored in src's (the client's) mob var, regardless of the eye or perspective. Ah, you're right, I frequently forget where BYOND's built-in capabilities end and my own soft code begins. He could still go the client.eye route if he controls the atom/movable assigned to client.eye within the movement procs instead of src. | |
Mobius Evalon wrote:
Ah, you're right, I frequently forget where BYOND's built-in capabilities end and my own soft code begins. I used to suffer greately from that. As for the eye thing, that was one of the first tricks I learned in BYOND. Most BYOND users feel that their control over their own mob is sacrosanct, so when it jumps up and starts arguing with them over where and how to move... let's just say that was one of the best forms of moderation I ever invented. Player not listening to you? Want him to stop what he's doing, or stop blocking a certain spot? Take control of his body, against his own will! This is especially fun when his own flailing attempts to regain control send him into a crowd of hostiles. | |
The simplest way to do this is just...
mob/Move(Loc,Dir)//In capitals so there aren't any var clashes That works and is very simple. You could easily make this a client/Move() too, or add in other features(Like client.eye) when you actually start controlling them. | |
Bakasensei wrote:
The simplest way to do this is just... mob/Move(Loc,Dir)//In capitals so there aren't any var clashes That works and is very simple. You could easily make this a client/Move() too, or add in other features(Like client.eye) when you actually start controlling them. Blech, looping through every object? mob/var/list/controlled | |
Lol, never thought of using a list till you said, "Blech, looping through every object?" then I thought about it and looked down and you already had it! xD
| |
Note you don't actually need to test the var holding the list reference before looping through it; the for()...list loop automatically accounts for this and doesn't run if the var doesn't contain a list, or the list is empty.
And also, client/Move() should still be used instead, or Bad Things could potentially happen. <_< | |
And also, client/Move() should still be used instead, or Bad Things could potentially happen. <_< What bad things? I figured that if he had AI or something else without a client, he could use it for that, too. Also, I'll remove the check. I wrote that out at like 1 last night before I went to bed, and I was tired. | |
Jeff8500 wrote:
And also, client/Move() should still be used instead, or Bad Things could potentially happen. <_< Generally as you know overriding the atom version of the proc (eg mob/Move()) instead of the client's will affect all movements (including initiated by code) and so it could produce unintended or unexpected behavior when called by one of your procs, which certainly would expect to move the mob it called Move() on and not something else, which would be inappropriate. Consider a simple push attack/technique/verb, which will already potentially cause breakage: mob/verb/Push(mob/M in get_step(src,src.dir)) Then if someone is pushed while controlling objects, it will end up causing completely different atoms than the intended ones to be pushed, and the actual player will be immune to it. =P atom/Move() is a widely used/called proc, so this would naturally also carry over to things like teleport procs which will end up teleporting multiple atoms instead of the 1 they intended, etc. I figured that if he had AI or something else without a client, he could use it for that, too. Indeed it could be used like that, but the better method would be to simply program it into your AI; your monsters' actions are not automatic as in player-initiated, you need to program everything they do anyway - might as well make sure they end up actually doing what you want. It often inappropriate to override a proc to do something different than its intended function (ie, instead of moving src, move something else), since it'd cause the caller procs of it throughout your entire project to potentially initiate behavior they did not intend to. They'd then have to pass extra flags to the proc if they specifically want to disable the changed behavior, and it'd get, well, unnecessarily messy. | |
I believe that whatever atom/movable client.eye is set to will be the recipient of any client incited movement. This manner of system will need client.perspective set to a proper value, though.