FTEQW - check active player view

[toneddu2000]

[Spike]

the player entity should be added to the scene with renderflags&RF_EXTERNALMODEL;
this allows the entity to cast shadows and appear in mirrors without blocking vision.
thus you need this somewhere (inside an isnew check is fine):
if (self.entnum == local_playerentnum)
self.renderflags = RF_EXTERNALMODEL;
else
self.renderflags = 0;

if you use SendEntity to send the player entity to the client, you will be using a network protocol that the client is not able to directly interpret (the client sees only entity numbers - it is only the csqc that can correctly interpret the meaning of the actual data contained inside).
this means that the client is no longer aware of the actual origin of the player.
this means that you must use setviewprop(VF_ORIGIN, foo); in order to tell the renderer the correct position to use (remember to adjust by the view height stat).
you will likely also wish to implement either interpolation or prediction, as the engine cannot do this automatically. you may also wish to implement view bob.

using deltalisten on player entities does not obscure the player entity from the client, and can simplify all of this. however, you are more limited in the available set of fields.

[toneddu2000]

[Spike]

[toneddu2000]

[Spike]

ssqc's skeleton indexes working in csqc is a ssqc-debugging 'feature' (ie: intentionally not checking ownership), and will not work when networked. you shouldn't network those numbers, unless in strictly single-player debugging scenarios, as I make no guarentee that they'll always have a shared namespace for skeletal objects.
predraws happen between clearscene and renderscene. they are not special, just a convienience.
remember that if your entity has a valid .skeletonindex value, then the addentity builtin will pass a reference to that skeletal object to the renderer, and this will COMPLETELY REPLACE any skeletal state generated from the .frame etc fields.
if you wish to use skeletal objects with model animations, you will need to use skel_build to read the current pose data implied by .frame etc into the skeletal object beforehand. Note that skel_build allows you to scale the data in order to interpolate multiple frames together, it allows allows you to specify bone ranges for separate torso+legs animations.

the getentity builtin peeks at the client's most-recent delta-entity state for the specified entity. this information is exposed only via getentity or deltalisten (feather vs hammer) - one returns a single field (or matrix), the other makes an entire csqc copy of the networked ssqc entity with the correct post-interpolation origins.
remember that entities are abstract things. the csqc and ssqc have completely independant entities that are tied only via the csqc's .entnum field, and some sort of ssqc->csqc table inside the engine which is only used when parsing entities (so that the csqc has the same 'self' value for each individual ssqc entnum).

deltalisten is good because it just queries+interpolates the entity, and prevents the client from adding it automatically as part of addentities - unless it has a drawmask anyway. In doing so, it allows you to change that data freely. however, its quite a heavy operation (hence the 'hammer' remark earlier)
getentity is good for its simplicity, but bad because you cannot do anything to modify the data other than using some sort of invisible modelindex (which makes using modelindex to distinguish between entity types really quite messy). if you know the entity index in advance (stats?) then it can be useful, but if you don't, you have to resort to polling. its lack of storage necessitates using some sort of array or loop(including find/findfloat) to associate any state to the entity (like previous position in order to animate things correctly). while it copies only the data that it needs, calling it 5000 times is not a light (knocking down a wall with a feather is not a good idea).

alternatively you have pure-qc entities that are networked using the MSG_ENTITY stuff. You can send exactly the stuff you want this way without the engine making any interpretation of the data you sent (like using float origins instead of limiting the game to +/-4096 qu). as such, they have less special cases, and are thus easier to explain, but also have less automatic behaviour being handled behind the scenes, which can result in much more work for you, as the csqc may be expected to reimplement half of the engine running within the (cs)qcvm.

there is no relationship between the player's entity and the camera. in fact, you do not even need a camera, or you may have multiple cameras. renderscene can be called multiple times for multiple cameras - note that you will likely wish to use VF_VIEWENTITY to hack the renderflags so that any RF_EXTERNALMODEL flags get updated without having to go through all the different predraw functions over and over again.
You can set VF_ORIGIN to some fixed position for an intermission camera. you can make it follow behind the player entity if you want 3rd person. you can make it follow a spline if you want something weird, or attach it to the nearest camera spot if you want something spooky like alone in the dark. If you're ssqc-centric, you can use stats to hold the new view position.

Using deltalisten allows you to reuse more of the legacy engine code than SendEntity does, and is thus typically less qc code, but it will have more expectations about engine behaviours.
ultimately, there is no single correct way.

[toneddu2000]

[Spike]

[toneddu2000]

[Spike]

input_angles is part of the local input state (you can query specific entries in the input log via getinputstate using values between clientcommandframe(equal to this obtains the current state that can change each frame, and which the server has not been told about yet) and servercommandframe(equal to this is the first frame that has not yet been applied to the latest raw data received from the server).

each client->server packet contains a copy of an input_angles value. this will be present within the SV_RunClientCommand function (assuming its present), and would normally be propogated into the player's v_angle field by the runstandardplayerphysics builtin which is assumed to be there (obviously, you can replace this if you wish, in which case you'll likely want to update v_angle or rewrite much of your ssqc to cope).
at the tail end of runstandardplayerphysics (or your equivelent), there will be some logic to set the player's angles field. typically using this formula: self.angles = [self.v_angle_x*-0.333,self.v_angle_y,self.v_angle_z]; this works around the input/renderer pitch difference, as well as prevents the player model from lying on his back when viewing vertically upward. with skeletal models, you'll probably want to discard the pitch entirely.
your SendEntity will then propogate the player's angle value somehow back to the csqc.
your csqc will receive that value and will then draw the entity using that angle.

basically, what I'm getting at, is that you need to separate the hips angle from the view angle. your player's hips will need to track the view/head angle over time (when moving, you can use the direction of travel to define the hips angle, and otherwise bound it so that its updated to match the view angle if the two angles diverge by more than 20 degrees or so).
but ultimately, you need to stop using input_angles to describe the angles of other players, because doing that really doesn't make sense.
if it IS the local player's entity, then you can override the view angle received from the server with the input_angles value, but if it is any other player, you cannot do that, and HAVE to use a value received from the server.
note that the hips angle can either be determined locally(in csqc), or in ssqc. if its in ssqc then all clients will have the same value. if its in csqc, you can more easily work with input_angles to avoid weirdness when lagged or paused.

also, addentity+PREDRAW_AUTOADD is redundant. you're generating two copies of the same entity.

side note:
distancetraveledtotheright = (neworigin - oldorigin) * v_right;
(the * is a dotproduct).
you can use the same maths to calculate the distance traveled forwards.
you can then rescale this by the distance the animation appears to move by per second, and adjust frame1time or so
self.frame1time += ((neworigin - oldorigin) * v_right) / 320;
note that this will also play the animation backwards if you travel to the left, which might be weird.
assuming the player only travels right, and the current .frame specifies a framegroup/sequence/animation that also travels right at a speed of exactly 320qu per second, this will make your player's feet exactly sync with the ground.
by determining the various strengths of the animations (ie: if travelling left instead, add in more of the move-left animation and decrease the move-right animation), you should be able to blend out the weird animations and thereby keep the player's feet synced with the ground regardless of the direction of travel.
also note that you can use v_forward instead of v_right to determine how far forwards you've gone.
deciding how far through an animation you are is easy. however, deciding which animations to play and the weight of those animations is an art form.
the total weight of all of your animations must equal 1 - any other sum total will result in scaling. you can use the addfrac and retainfrac arguments of skel_build in order to merge the varous animations together into the pose displayed that frame. just update the .frame+.frame1time fields between each call to skel_build to blend in the different animations.
it is unfortunate that .frame has this dual purpose. instead of adding lots of code to preserve its value, my recommendation would be to create a new .action field instead, and (within predraw) decide the .frame values based upon that. you can use the frameforname builtin to look up an animation by name from a model. this means you can provide models with animations used purely by name (allowing you to omit entire animations in certain models, potentially allowing you to use the same code to animate most monster types or whatever).


oh, and regarding your sidenote/question about csqctest, I'm not entirely sure how relevant csqctest still is. it was very much bolted on the side of vanilla quake with lots of random pointless things that are useful to test parts of the engine, but don't really do anything useful in themselves. it also lacks polish (in part because it was never written to be an actual worthwhile mod to play). parts of it are useful, but its not a mod I would recommend anyone use as a base.
I'd release the code for 'spark', which was some standalone mod I was hacking together ages back now, which was meant to include stuff like custom physics, skeletal animation blending, etc etc (ie: all the modern stuff and none of the quake stuff), but I don't own the content or half the qc code, and as such its not really usable as a demonstration of much at all. it would take a lot of work for it to be practical (as well as content so you can actually see it in action), and I have too many other distractions/projects right now.
maybe one day I'll get an itch to publicise+polish it.

[toneddu2000]