skeletons, dp and qc?

[something]

[leileilol]

[something]

[ceriux]

[something]

[leileilol]

Despite the examples in dpextensions.qc, secondary/tertiary/quaternary frames are never "sent" serverside. You can only ever EVER, EVER handle those on the clientside, and I doubt the bone functionality in csqc even works at all. I can't move a single bone or even do frame2 properly when I tried.

Yeah, that makes debugging even simple things like hitboxes on heads on turning torsos a total bitch. You can't ever see what the server sees on skeletons.

[Spike]

[something]

[something]

[jessetc]

Where did you continue?

[toneddu2000]

I think that no one continued this thread. Sending skeletons to CSQC was started by behind_you but he left the forums.

Is it really so hard?

[Spike]

its not that its hard, more that its futile. sending skeletons to the csqc is utterly pointless. it really fecks over any prediction code you might have, its bulky, etc. its much easier to send actions over to the csqc and then animate it in the csqc based upon those actions.
using skeletal objects in ssqc is pointless in all regards except for utilising hitmodel, which will never be entirely accurate anyway, and mostly just annoys people.

doom3 uses server-side skeletal objects and stuff. doom3 is limited to 4 players or something silly. doom3 also does it for consistant ragdolls.

[toneddu2000]

[Spike]

if the client is running its own animations, you can change the speed leg animations play at and stuff for decent mixing of legs and stuff, and you can do that based upon player prediction and other things, which is all still correct in shadows, mirrors and other reflections.
of course DP doesn't really do prediction with csqc-based players. You'll need to get LH to help you there.
anyway, if the client is animating the legs automatically based upon velocities and stuff (dotproduct the velocity against the forward/right vectors and you can get the distance moved in each direction), then you still need to know exactly when the player is shooting. if its a different player you have no choice but to get the server to tell you. if its the local player then you might try predicting it. which is awkward of course... at least if the server disagrees with the timings... anyway, if you have some field which states the current action or whatever, then you can trigger the start of firing animations, death, pain, etc based upon that field instead of using the server's .frame field directly. if you use events instead of descrete actions, you can have the player shooting while in pain and stuff.

But all of my attempts have been hindered by the lack of inverse kinematics, and have all looked somewhat goofy when blending between certain animations, as the blend goes direct, resulting in stretching, instead of mere bending of limbs. you can get away with it when the model is moving fast, but when its moving slowly, like when it comes to a stop, it looks weird if it is not slow. Presumably you could come up with some way to cover these issues if you have additional (blendable) animations to cover the slow movements, but I am not really comfortable with such apps so have made no such animations for any models.

If you want to be lazy, you could just stick with the server-controlled .frame values for the upper part of the model, and apply csqc-based leg/jump animations for the lower parts (remember, skel_build uses all of frame, frame2, lerpfrac, frame1time and frame2time to build the bones in the specified range). You would still need to recognise when the player dies and somehow remove the leg animations changes so the player can turn into a corpse that is not still trying to run.
if you're a fan of quake3, you can actually build the skeleton from two separate entities. if only one is actually visible, the frame etc information from both entities can be merged, such that one entity contributes to bones root to hip, while the other contributes from hip to lastbone.
If you animate the legs in csqc, and the torso based on the frames from ssqc (the ent will need to be known to csqc still or you can't use skel_build), you should have an easy way to create a model that actually runs properly while shooting.
In actual fact, you can have multiple entities drawn using the same skeletal object. This may make the most sense with replacable heads or headwear or some such. if the body does not contain a head, the head does not contain a body, but both models use the same skeleton then its all quite a snazzy way to have alternative details on character models, beyond mere skins. Likewise, you can source animations from a different model entirely, assuming they are compatible, which can be a cheap way of animating many alternative player models (md5mesh/md5anim format basically requires this).

I think DP does actually have some field you can set in order to send its skeletons to the client, presumably its listed in dpextensions.qc but I'm too lazy to check... I'm not too sure its really worth using it other than to debug hitmodels.

These are my thoughts. They may not be useful or even correct. But the important thing is to have fun figuring out my more broken sentances. I'm too lazy to proof read too.

[Nahuel]