the 'cl' array thingie is a mod-set array.
fteqcc does not officially support such hacks.
fteqw and dp do not support such hacks either, of course (memory access is sandboxed, and offsets would be wrong anyway).
The 'official' way for either dp or fte to read the forward/right/up directions is to somewhere define:
.vector movement;
The server will notice the field is defined and fill it up with the forward/right/up values in each field of the vector (basically what would be in your self.cl[CL_CMD_FORWARD], as a float)
If you want to keep proquake compatibility, you're probably best off just using preprocessor conditions based on which qcc is being used and thus which sort of engine to support (qccx=vanilla vs fteqcc=sandboxed+extended).
That said, you can directly specify asm in fteqcc, like so:
asm {
STORE_F source dest;
}
source and dest can be variables, constants, etc. there's no type checks or automatic type conversions so you can specify integer values as 42i for what would be %42 in qccx.
you can also do this with fteqcc: float *ptr; ptr = &ent.field; *ptr = 42; and you should be able to pass that pointer to functions etc if needed too, as well as use them with either 'asm ADDRESS self modelindx ptr;' 'asm STOREP_F 42 ptr;'. Note that array notation on pointers will not work, as fteqcc cannot emulate the required integer manipulation operations (potentially I guess it could), nor will it let you obtain the address of a global (could be emulated for vanilla, but would break any engines that changed the hunk layout). However, you can't *read* pointers without weird hacks involving assumptions about entity offsets.