Why does a client change its mob icon's direction in client.Move()?
Shouldn't location be separate from direction?
For instance, I can make mobs strafe, but client will always make players face their direction of movement (whether mob.Move() returns true or not).
To change this, one could rewrite client.Move(). (I did.) However, given the current limits in building off of client, this does not seem library-friendly. If someone using the library made their own client.Move(), there would be multiple defintitions or something and it wouldn't work.
If client.Move() just avoided changing mob direction when mob.Move() returned false, mob.Move() could control player mob direction. However, client.Move() might not update properly if it depended on the return value of mob.Move().
Could the re-orientation be removed or (possibly better for legacy stuff) placed somewhere like mob with a client check (where it can be overwritten in derived objects)?
Is is better to just wait for objects derived from client instead? (Am I unaware of them already being here?)
Is adding a lot of icon states preferable to avoiding a simple direction change?
Am I just unaware of a library-friendly way around this?
Would anyone but me use such a simple library anyway?
ID:137267
 Jan 5 2002, 7:11 pm
|
|
Turning in place is easily done by changing the dir and not the loc in mob.Move(). However, the direction nazi in client.Move() makes some things impossible.
It's not a problem of mob.dir having the wrong value for an instant as much as it is a problem of the wrong animation playing during that instant. Changes to mob.dir inside mob.Move() are overridden by the default client.Move(). .= will store the return value. However, the code in mob.Move() after .= will occur before mob.Move() is done. The animation still has the wrong dir. I can store the direction. However, updating the direction after mob.Move() (whether with spawn or an update function) leaves a period during which the wrong animation happened already. | |
ACWraith wrote:
Changes to mob.dir inside mob.Move() are overridden by the default client.Move(). .= will store the return value. However, the code in mob.Move() after .= will occur before mob.Move() is done. The animation still has the wrong dir. Hmm .. that shouldn't be the case. In a simple test case, when I do the aforementioned: mob/Move() the direction never departs from NORTH. It is important to do the default call before the dir override, since the default will itself set dir. Correct me if this doesn't work in your case, or if I am otherwise missing the point. That said, your comments make a lot of sense. I think that the Move() proc should probably always set the dir by default, regardless of whether the loc-tests succeed or not. Then none of that would have to be handled in the client, as per your request. However, there may be some non-legacy reason for all of this that is not occurring to me at this late hour. I will write it down and consult with my partner in crime. | |
Tom wrote:
However, there may be some non-legacy reason for all of this that is not occurring to me at this late hour. My movement routines rely on the client setting the direction...because I separate the client move command from the mob moving, so the player can choose a direction, but they don't actually move until their next time to move. However it's important visual feedback for the direction to change immediately when they give the input. No doubt I could put my own direction handling in the client calls, but I just thought I'd mention at least one case where the current behavior is expected by the code. | |
It's important visual feedback for the direction to change immediately when they give the input. I agree. Would you mind explicitly coding that into your movement algorithms? The setting of usr.dir in client.Move() was actually just left over from before Move() took a direction in addition to a target location, which meant there was no way to figure out the direction when the player happened to try to move out of bounds on the map. That's no longer the case, and it does seem unexpected that if one were to override mob.Move() so that it did nothing to the direction, that player mobs would behave differently than anything else, so I'd like to get rid of the setting of the direction in client.Move(). --Dan | |
It's been a while, but I think the idea is to allow mobs to turn in place even when they run into walls and other areas preventing entry or exit. However, you bring up some good points.
Perhaps you could preserve the initial mob direction and change it back inside mob.Move()? Eg:
You may have to do some tricks to store the last valid direction, but other than that I think this kind of system should work without having to override client.Move().