Why chase_active 1 is a hack ...

[Baker]

Chase_active 1 is a cool feature, but it isn't "right".

Depending on the settings, the chase camera might not be in the same map leaf as the actual player location.

The server uses the player location to determine what entities are visible using the map leaf of the player location. So the point of view of a chase camera may not show all the actual visible entities because the server didn't send entities visible from the chase camera location.

I'm just pointing this out, I've been working through client and server visibility changes lately with some bizarre ideas I really hope to have done (and released) by Friday. Working through client and server visibility is somewhat of a pain if you want to change the rules just a little.

[mh]

I've been aware of this one for a while. It's not line-of-sight visiblity any more either so sooner or later it's also going to break on SV_VisibleToClient.

Because of this and because it's a hack to begin with it's in my "won't fix" bucket.

[Spike]

chase_active is one of the cvars that I never reimplemented in fte (doesn't exist in quakeworld). noone has ever complained about that.
in most nq engines its too flaky to be a serious feature, what with the whole camera-just-went-into-a-wall thing. its probably okay on a banshee though, which had a near clip plane at 0.
there's enough chasecam mods that a chasecam built into the engine is somewhat redundant.
however, even those casecam mods do not center the pvs on the correct point - quake doesn't provide a way to change the pvs origin without also moving the player for it (which would break player physics, well, you could work around that, but gah!).
One issue with chase_active is that you can swivel around the player pretty fast. You'd need a really large pvs sphere to encompas every single possibility.

I don't care about chase_active in any way, but I do care about svc_setview, and with svc_setview the entity is fully known to the server. no issues with the player changing angles really fast... other than latency.

[r00k]

I agree, if you are making a singleplayer mod, in QuakeC, create an entity behind the player,use SVC_SETVIEWPORT set to that ent (only once), check for world collisions, update the ent's position. Online, though, its affected by latency. Doing it engine side, obv is faster cause you dont have to wait for the server to respond with your new origin.

IMHO what is broken with Chase_active and the visible to clients to me is actually an anti-cheat measure, as standing at a corner and using chase_active to view around it with out an opponent seeing you.

[Cobalt]

It has its uses from dev standpoint. I have it bound to my mousebuttons and its a fast way to get a real perspective on the player model if you are say in a listen mode server as first player, testing your mod. If for example you are experimenting with new animation frames and want to see if your QC is doing them right in game.

[Spike]

personally I tend to use r_mirroralpha for stuff like that. whatever works really.

csqc can position the camera whereever it wants (main view or sub view), and flag the camera's entity (read: the player) as rf_externalmodel.
its more tricky when the csqc doesn't have ownership of the player's entity of course - which is what fte's VF_VIEWENTITY hack thing does (strips out RF_VIEWMODEL entities and hacks RF_EXTERNALMODEL flags to the new ent). of course, this also avoids calling addentities again for sub views too (assuming its a regular non-radar view or whatever), and can give a noticable framerate boost thanks to the reduced qc instructions.

[mankrip]

Another reason for it to be a hack: Since it's not in the server messages, it's not saved in demos, and this breaks compatibility with mods that aren't supposed to have a third person view (or that have their own QC camera code).