camera turn

[siska.robert]

Hello.
I would like to implement camera turn. Like you turn your head behind, to look ho's chasing you, but still walk the same direction.
Similar thing is in Duke3D.
The biggest problem will be probably to make player walk in different direction that he's looking to. Any suggestions?
Thanks.

[Error]

hmm, you could set the player punchangle_x and punchnangle_z to something stupid, then when it's done, set them to 0 again. that's a hack-ass way to do it!

[siska.robert]

It looks great (moving the v_* models)! But when punchangle is changed, player goes into that direction - that's what I want to avoid. Maybe modifing the movement buttons is the way, but I don't know where is this controlled from...

[c0burn]

Look at the intermission camera code in client.qc

[siska.robert]

could you please be more specific? The only intermission-related camera controlling I found, is in execute_changelevel...Is that what you meant?

[c0burn]

Yes, it sets the players viewport manually.

[siska.robert]

I still don't know, how to do it... Viewport (view_ofs) is just about position in 3d, not about angles, IMHO. The most obvious seems to be setting v_angle, but that is used for computing shooting and walking direction. It would be easy to adjust w_fire functions according to change in v_angle, but the walking would be still problem.

Or: Wouldn't creating a new camera help?

Or: Do you know any mods, which use something similar?

thanks for answers!

[Spike]

You can force the client's view angle to match their angle by using fixangles. However, by doing so, you'll change their v_angle and thus the direction they move in.
Intermission code locks the client's angles, and prevents them from changing them, but you can't turn it off without a map change, and it would stop them from ever aiming again, certainly they can't look freely while its active.

Using DP, you could provide a replacement SV_PlayerMove function or whatever its called (the annoying one that screws over prediction), I can't remember the exact name. Anyway, its some extension that invokes the QC to carry out the velocity changes each movement frame. You could adjust the angles in there, and change the direction that the player moves in. Be warned, however, that you would still need to use fixangles if you wish to turn the player automatically, and doing so will induce a slight stutter, which will be much more noticable with latency. But it could work well if the button only prevents changing the effective movement angles, without fixangle at all. But whatever you do with this, it will break prediction.

A fairly minimal CSQC could do it by overriding the player's input angles at input frame generation, based on a stat or some such, basically stop it from changing, the player is then free to look around (can adjust the player's view angles when its first activated/deactivated too).
Alternatively with CSQC, you could add 90/180 degrees to the view angle when setting up the view properties for the current frame, which is more likely to work in DP, but is a fair amount more code. With this, the player can still change thier direction of motion, they're just moving backwards.

[siska.robert]

well, it is way more difficult, than i though it was...
Possibly, I could get it working in DP or via csqc, but I'm pretty conservative in modding - i want my mods work on classic id's engine and it's derivations (winquake, sdlquake...)

Thanks for answers to my question - more will definitely come:)

[Spike]

the alternative is to roll your own player physics.
All I can say to that is... gah. walkmove is not really suitable.

[siska.robert]

you mean like bind new impulses to some function that would move player around?

[Wazat]

Wouldn't the camera writebyte work for this? Or will that still change the player's forward direction?

If you wish to use DP, tweaking the player's movement code to be 180 degrees off while his view is backwards should be pretty easy. At least if I remember right...

[siska.robert]

WriteAngle changes forward direction too. In normal quake, movement is probably engine-driven...
And about DP: I just don't like the idea:) Nowadays, the levels and mods are often aimed for DP (or similar) and don't work in classic quake engine - as the owner of 400MHz/64Mr, I'm naturally pissed off:)