origin of the "listener" entity in csqc

[Nahuel]

When i toggle a camera in csqc (to change the origin of the view of the player) the sound are "listened" from the origin of the camera, in CSQC_UpdateView:

Code: Select all

  if  (stat_cameras > 0)
       {
 R_SetView(VF_ORIGIN_X, stat_origin_x);
 R_SetView(VF_ORIGIN_Y, stat_origin_y);
 R_SetView(VF_ORIGIN_Z, stat_origin_z);

 R_SetView(VF_ANGLES_X, stat_angles_x);
R_SetView(VF_ANGLES_Y, stat_angles_y);
R_SetView(VF_ANGLES_Z, stat_angles_z);
R_AddEntities(MASK_NORMAL | MASK_ENGINE);

}

this is perfect, but when I espawned a camera from the beginning (without toggle it) from playerprethink every sounds are playing, as if the listener were the world without origin (not '0 0 0', i tested puting different ambient sounds, and normal sounds in this location). Every sounds are listened from the worl without an origin or angle changes, and after if i put in console "restart" the cameras works perfectly and the sounds works fine :? . but if the player dies and after respawn the problem persists, my question is: is there a way to cahnge the origin of the entity "listener" of the sounds in CSQC?
How?

[Spike]

void(vector origin, vector forward, vector right, vector up) SetListener = #351;

origin is the centerpoint, while forward+right+up can be generated by makevectors (beware of the issue with pitch sign).

So...
stat_angles_x *= -1;
makevectors(stat_angles);
stat_angles_x *= -1;
SetListener(stat_origin, v_forward, v_right, v_up);

And that's how you tell the audio subsystem where the player is meant to be listening from, and the angles it should be facing.

[Nahuel]

thank you spike , the listener works fine now
i have another question: how many custom stats with addstat can i add to csqc? whats the limit of the stats?

[Spike]

stats 32 through 127 are guarenteed available to csqc.
128 through 255 *probably* work, but you've got to fight against DP and the player prediction stats it puts at the end of that range, so if you rely upon those make sure you start at the low values.
you can override 0 through 32 too if you want, but the engine may have its own interpretation of those, which might mess things up.

with fte, string stats have a separate set of stats with no clearly defined length limit (1023 chars should be supported), while with dp string stats have a max of 15 chars (rather than 16...) and consume 4 consecutive numeric stats.

If you use a single stat for multiple purposes, note that there may be some lag between each stat change being seen, so your code will need to cope with such things. If its just an ammo display, it shouldn't be an issue for instance, but if you make things blink in response to getting some weapon, you might see some odd results.
If you want more, you'll have to emulate them via entities or some such.