send enemy entity to CSQC

[toneddu2000]

[Spike]

your enemy_base function spawns a new entity, which it then ignores and leaks. it instead edits the self(player?) entity, which probably isn't desirable.
there's no think function set (in the given code). which implies that you won't ever set SendFlags, thus the engine will never see that it needs to resend the ent, so you get one send and then nothing (until it leaves pvs anyway). Remember, the entity will only be sent by the server if the server thinks there's a new version. So remember to set some SendFlags bit to tell the server that its changed so that it gets sent. It does not spam updates unless the mod marks that it has changed (ie: put self.SendFlags |= 1; at the bottom of your think function).
If SendEntity is set, the setmodel is optional (and thus so is the precache) in FTE. DP is more annoying than that though. Seeing as you're precaching the model in ssqc anyway, you might as well send the .modelindex and use setmodelindex in csqc to match it. this will reduce traffic a bit. you might need to use a short to send modelindexes (often depends on map), but this is usually noticably smaller than strings.


addentity/addentities should only be used between ClearScene and RenderScene. calling them elsewhere is an error (or just pointless). you should not call it within CSQC_Ent_Update (nor a child function).
I recommend you use .predraw to handle the interpolation/animation. this way the engine can do the nextent stuff for you, as well as drawmask filtering (remember, addentities calls the predraw function on every entity that matches the mask, and then calls addentity on it as appropriate).
use nextent+addentity if you really want, just be sure you do it between clearscene (which wipes+resets all scene state, forgetting all added entities) and renderscene (which renders the current scene state to the screen, including all added entities, without wiping any).


anything I missed? :s

[toneddu2000]

[Spike]

movetogoal/walkmove use stepping physics. they do NOT use velocity.
the client will need to know the expected animation rate, and will need to interpolate at that rate.

skel_build/skel_create are basically utterly pointless in ssqc. they affect MOVE_HITMODEL stuff, but this is typically laggy such that its pretty much pointless in the first place. in dp there's some way to replicate it to the client (not via csqc), but that's so spammy and jerky that its really only usable for debugging.
your existing csqc code does not need to use them. and in fact its use of them is a complete waste of time - it deletes it before it gets a chance to be used.
skeletal objects last a frame or so beyond when they were removed. this is to allow you to addentity+remove in that order. if addentity sees a skeletonindex of 0 then no skeletal object is used (remember that addentity is implicitly called after your predraw function by the addentities builtin).
and because you create+build+delete+clear all without adding the entity, the skeletal object is never used and it just falls back to the traditional pure-frame-based animation system instead. your code would work with an mdl just as well as it would an iqm. any editing of the skeletal object you make is simply thrown away with your code! but hey, at least you don't leak. the last two lines should generally not be in your predraw function. they should be in your CSQC_Ent_Remove handler instead of being called every single frame in a really wasteful way.

frame1time loops automatically if the model format specifies that the specified animation should loop. for smooth movement, you can try something like this:
self.origin = self.oldrigin + (self.neworigin - self.oldorigin)*((time - self.updatetime)/thinkinterval);
self.frame1time += vlen(self.origin - self.lastorigin) / animationdistancepersecond;
self.lastorigin = self.origin;

thinkinterval is 0.04, matching your nextthink=time+foo; from ssqc. self.updatetime needs to be set to time when you receive an entity update. at that time you should also store neworigin into oldorigin, and read a neworigin value. if its new then you'll need to cope with that too. obviously if its not moving then you should probably do something else with the frame1time value, because that code will fail if its meant to be idle (it won't animate an idle animation).

if you want to get fancy, you can figure out how far something moved in terms of the v_right/v_forward/v_up vectors by using a dotproduct. distancemovedright=distancemovedvector*v_right; for instance, will give you the distance moved along the rightwards vector, and will ignore any forwards/up movement. thanks to v_right being normalized, the result is somewhat similar to vlen. remember to makevectors first. this is useful when you want to blend multiple run animations together, but of course this requires that your models have suitable animations.

[toneddu2000]

[Spike]

the IQM format has an 'IQM_LOOP' flag on each animation. if its set, frame times beyond the duration of the animation loop back to the start. if its not set, the animation is clamped to the last frame. this is a file format thing, not a code thing. you can use the frameduration builtin and reset it when the duration is exceeded in order to loop it, but it isn't pretty.

by movetogoal animation rates, I mean the number of times it steps per second. an animation (ie: within a framegroup) rate that was specified by a model editor is an automatic thing that you don't normally have to care about, as it just animates automatically anyway. however, you will generally need to smooth out origins so that it appears to move smoothly despite only moving 10 times a second or whatever.

skel_delete inside predraw means you're always allocating new skeletons every single frame. its just inefficient to constantly make reallocations like that. just keep reusing the same skeletal object until you delete it. there's less set-up then (and is required if you're going to try using the ragdoll extension). despite the inefficiency of extra allocations, the problems with your code are that you clear the skeleton to 0 so addentity can never actually use it, and if you don't clear it then you don't create a new skeleton above. you could make the skel_create unconditional and remove the skeletonindex=0 line, that would work, but it would still be more efficient to not constantly reallocate.

Regarding your UT code: no. QuakeC is not object oriented. Quake's model formats do not have any support for bone sets (which is why skel_build takes a bone range).
Assuming you can write your code to use bone ranges, there's really no reason why you can't write your own state management to call skel_build on each bone range as desired.

[toneddu2000]

[toneddu2000]

[Nahuel]

awesome work !! i really will apreciate the qc source! I do not understand anything about skeletal animations

[toneddu2000]

Thanks Nahuel! the REAL source is coming!
I'm just updating it a little to manage multiple animation states. I'll post it as soon as I can (I hope this evening)!