custom chasecam tutorial

how would i set up bakers rpg cam positions with out effecting, chase_active 1?

how would i set up bakers rpg cam positions with out effecting, chase_active 1?

One of a great many ways ...

One example:

Make a "chase_active 2" that uses hardcoded values or different cvars than chase_active uses.

But perhaps a better question, why is this a goal?

Let me explain: if you are intending to switch the camera type via cvar then why not switch them all at the time of the camera type switch? I'm just saying that if you are going to switch the chase_active value then it isn't much more work to switch the other few values too [assuming you are working in the framework of this tutorial where chase_active 2 sets an alternate camera type].

well, honestly the camera tutorial is just for me to learn a little bit. my best way to learn is ask how to do something and do it so i can see the difference in between each way of doing something.

Good tutorial!

I found when I did this, the third person model would be present... which made things a bit ugly. This was my fix (let me know if it's wrong or whatever):

In r_main.c, head to "void R_DrawViewModel" and below this:

  Code:

currententity = &cl.viewent;
if (!currententity->model)
return;

And add:

  Code:

if((int)chase_active.value != 0)
return;


So if chase_active is NOT 0, then don't draw the gun model.

Good tutorial!

I found when I did this, the third person model would be present... which made things a bit ugly. This was my fix (let me know if it's wrong or whatever):

In r_main.c, head to "void R_DrawViewModel"

Yep. A WinQuake source release bug. A bug not present in the GLQuake engine source.

Should I use GLQuake instead?

(Well, I actually can't run GLQuake because it crashes... I suppose because it's not meant for Windows? )

TBH I didn't bother to test the tutorial in WinQuake, so if it's not working as expected, I must apologize for that.

Thoughts on possible future modifications of this type based on other games ...

1) Perhaps have a figurative diamond shaped bounding box or maybe a circle and only move the camera when these bounds are crossed. This would allow for greater viewing area in front of the player when walking in a specific direction. This would require previous chase_active coordinates to be stored and to be aware of things like teleportations. Since I guess this would be useful for up/down as well and since introducing 2D into 3D would be bad. Maybe cvars to define a tolerance and stick with a sphere for simplicity purposes (simple radius). If the player's origin exceeds the current bounds of the sphere, relocate the sphere and refresh the camera position.

2) Perhaps the option to not try to clip move the camera from a wall and use a calculation for each brush or object that is between the player and the view origin and apply alpha.

Yes, certainly not new ideas but occasionally I think of the overhead view style of play.