Dancer Archive
Thread: Broken Base Dances
Xyrdre wrote:
... sometimes I think I never have enough coffee...
Sensible woman.
The problem is in how the server tries to sync avatar location with the client during "interruptible" animations. But yes..interruptible animations give up display priority to avatar location syncing..not truly interrupted.."interruptible"/"uninterrutible" being just the labels placed on them.
(there is a man in the chair next to me who is trying to replace a CPU on his own..this is soototally wrong for a Sunday morning..I'll be back later)
To me, the reason that some of the base dances are broken is because there is movement in them and the server has to update our location constantly. Dances such as the exotics do not have this problem as they stay on the same spot. It has also been noted that some of our flos move us around the dance floor but still display properly. The explaination for this is that they can not be interupted and the server will always know where we will be. So, because the base dances have to be interuptable, the server needs to be able to update our postition constantly.
There is an exception to the above rules though. Our flos CAN be interupted. If we /changed during a flo, we will change dances there and then, and be doing the action of the corresponding flo.
For example:
/startd theatrical (Base dance is broken)
/flourish 5 (Flo 5 features lots of small leaps and large strides)
But during the flo (at the furthest part of the inital leaps) I decide to...
/changed exotic3.... What happens next....
At this point, my character will stop leaping and start doing the jiggly flo 5 from exotic3. I'm am also now standing in a different location and dancing which means the server has calculated where I am.
Now, if we are able to /changed during flos and still have themn display properly, why couldn't the base dances use an extension of this? I'm not saying that we should should be given the base dances as actual flos, but the devs should be able to change the code ever so slightly that this would be able to work.
I may be wrong here, but this is how I see it.
Seta_san wrote:
There is an exception to the above rules though. Our flos CAN be interupted. If we /changed during a flo, we will change dances there and then, and be doing the action of the corresponding flo.
Actually what you experience when changing dances in the middle of a flo is that the flourish changes from (as in your example) flo 5 of the first dance to flo 5 of the next dance. Using this technique to transition from one dance to another can look fantastic (or awful..depending on which flos you choose 
).
The difference is that what we see is a graphical representation of the animation code. That graphical representation changes when we change dances. But the coded animation doesn't. (I realize it is a stretch to understand why it doesn't change even though it appears differently to us).
To change the base dances to be as "uninterruptible" (/agree..that is not the most appropriate term but seems to be the label that's been placed on it) as the flo animations would limit when a flo could begin (regardless of when we call it). Ie: if the base dances were uninterruptible, a flo could only begin at the end of a cycle of the base dance (of course break intervals could be coded in, but the more of that you have, the more anomolies we'll have to complain about). This could be done with queuing but I think we'd all be bored to tears withthe end resultrather quickly.
When the devs speak of "problems in our base code" I think this is what they're talking about. Not that there is a problem in the code of the base dances. But there is a discrepency with how the server-side code handles our movement and how movement could be handled to look best in most given situations. What I can see them doing to correct this would in essence create a 3rd type of animation handling. In this instance maybe our base dances could be handled as interruptible animations that did not alwaysparticipate in theavatar location syncing in the game world between server & client. This would definitely take a re-write of our code from the ground up.
I canhonestly cut them huge amounts ofslack on this as it issome pretty complex stuff. Was it designed badly in the first place? No..I think it would be more appropriate to say that it was designed as best it could be, even with attempting to anticipate events that had not occurred.This level of complexity of movement has not beencoded in a game before. We're traveling a road with no maps. But I believe the devs are sincere in wanting it to work.
Message Edited by Esharra on 11-07-2004 08:59 PM
Esharra wrote:
*Snip*
/agree
I was talking to a friend of mine about the this, and we came to the conclusion that my suggestion would probably cause more syncing problems despite having a viewable base dance. Oh well, can't win them all
I do agree that we have to cut the devs some slack though. No other game that I can think of has ever tried to implement a class like this (no bard comparisons please
). And I seriously doubt that after all the effort that has been put into this class so far, that the devs will just turn their backs on us. Our time will come, we'll just have to grin and bare it for a while longer.
Message Edited by Esharra on 11-07-2004 08:57 PM