converting entities to csqc (player)

[ceriux]

Okay so iv finished the Scratch tutorial and for my next endeavor i'd like to convert the player and his animations over to csqc. iv chosen to use FTE because of network code and there seems to be more documentation that i could find for csqc on this engine.

currently im reading CSQC for dummies and plan to go through the stickied thread in this forum. currently im looking into the builtins i need to do what i want to achieve. i'll post any questions and problems i may have here. if anyone has any advice please feel free to post here ahead of time.

to start what are the builtins i need to start with?

[gnounc]

https://gitorious.org/clean_csqc/cleanc ... 879d7ca263:
thats pretty much what you'll want to start with.

as for suggestions, i suggest idling in irc. I saw you jumped in, but you jumped back out too.
You've gotta rack up that uptime son!

[Spike]

set a .SendEntity field on the entity. should be a function.
when the entity is changed, set the .SendFlags field to something.
inside your .SendEntity function, call WriteByte(MSG_ENTITY, foo); etc as required. return TRUE.
the 'flags' argument is a copy of the SendFlags bits that need to be resent.

in your csqc, write a CSQC_Ent_Update function that matches the exact Write* calls that your ssqc will have used. If you're sending multiple types of entity, your first byte will likely need to indicate which type of entity it is, and you can then branch into the right sort of entity after that.
when CSQC_Ent_Remove is called, remember to remove(self), or set up some think function to do it.

if you screw up and the ssqc+csqc's writes don't match, you'll trigger illegible server messages. set sv_csqcdebug 1 (in FTE) to try to get some usable debug info for it.

As this is the player entity that you're talking about, using SendEntity on it will result in some issues for the client. Firstly, the client will no longer know its own entity, and it will depend upon the csqc fully for it. This means that you will _NEED_ to set the VF_ORIGIN view property, or the view will be in the wrong place (0 0 0).
you can do that inside the player's .predraw function (set it up from CSQC_Ent_Update or so). Remember that you will need to provide interpolation or prediction yourself.

For prediction, you'll need to use getinputframe(frameid) from servercommandframe+1 (as determined by the latest entity state received) to clientcommandframe, and apply the player's pending input commands to the entity (the runstandardplayerphysics() function). For the player, you can do this instead of interpolation - the frame matching clientcommandframe will solve timing issues for you, providing smooth extrapolation. You'll likely still want to provide stair smoothing however.
Be warned that other players are a different beast entirely. You can't predict those, you'll need to write some interpolation code for them (check the entity's .entnum field against player_localentnum to see if its the local player's entity or not).


alternatively, you can leave the ssqc unmodified, use deltalisten("progs/player.mdl",someupdateplayerfunction,0) in csqc, and have the client do all of its normal prediction and stuff as normal, and feed that into your csqc player entity. the fields updated by deltalisten are engine/protocol dependant, but will always include smooth origin+angle info by default (you can disable interpolation if you still want to run prediction, but its easier to not do so).
this is more limited (you can't send custom fields), but it is meant to be much easier, and doesn't require ssqc changes.

[ceriux]

[Spike]