RiftQuake

[Dutch]

Everything's been going great, turning out lots of content, but I finally hit a small snag I can't seem to find an answer, although I suspect I know the answer.

When the player dies, the viewpoint is tilted on the z axis by about 45 degrees until respawning, where it is set back to zero. I want to disable this, or at the very least bypass it, because I'm coding a death camera to show off all the disgustingly gruesome ways monsters can kill the player, and the z-axis tilting needs to be zero at all times. Additionally, I am actually creating animated entities for dying/dead players and setting the player's model to a null sprite until respawn, meaning that I am setting a new origin and fixing angles of the player himself to view the entity that represents his dying body. (I understand, and even accomplished, sending a protocol byte for setview, but decided this was simpler both in code and theory, especially because there's a shit-ton of different dead body models for partial gibs and what not, and it didn't make any difference in the angle problem).

I can't find any angle adjustments upon death in the QC, so I bet it's in the engine code. Especially because this angle adjustment doesn't happen when using a built-in engine chase cam ("chase_active 1"). I don't want to rely on a cvar setting, I'm trying to stay as far away from non-standard cvars as possible to preserve compatibility.

Any thoughts on how to sidestep this? I tried bypassing self.th_die(), thinking the angle adjustment was occurring in that built-in function, but no luck. Apparently the engine is reading the player's health at any given time?

Thanks in advance, I'll be searching for an answer as well.

EDIT: just remembered about FrikaC's viewpoint of other players in the FrikBot where you can be dead and still watch others, adopting their angles. Gonna go check out his source code right after dinner and see if I get anything.

EDIT2: Turns out the player's health is restored to the currently followed player during botcam, as well as the deadflag, which would likely restore the angle tilt. Forget that idea.

EDIT3: Did a little experiment and set the player's health to 1 after dying occurred, but before respawning is allowed...and the view angle is back to normal. This suggests to me that my previous assumption was right. So I tried manually fixing the z_angle in PlayerPostThink and PlayerPreThink if health is less than 1 before any other code is reached. Still no results. This is starting to get a little sloppy, I might ditch this idea of a death cam. What I really need to do is start learning how the internals of the engine c code works. So far I've been strictly QC. My goal isn't to modify an engine, but it I would have a better understanding of what I could and could not do.

[Dutch]

Nice sweet. I hate facebook. ugh go on there and click x everytime after viewing the first 2 posts.

edited try to keep this thread slightly cleaner

Facebook is lame as hell, I got on it cause of a girl, got off of it for a while, got back on cause of another girl, and got back off cause I decided it was just stupid. You wanna get a hold of me, pick up the phone. Lol.

Don't worry about keeping the thread clean, I don't care. Say whatever you want man.

In other news....

Here's a quick update. No videos or pictures, I have too much to do on the mod to spend too much time on an update, I've been working on it like a madman trying to get closer to an alpha release. This post is really just to let y'all know what's up.

I've polished gameplay quite a bit, meticulously testing for bugs in the code and addressing any and all issues as I work. I have built 6 weapons from the ground up, including special alt functions. They are based on earlier weapons I made but completely re-vamped in every way possible. There's so much shit for these weapons each has its own QC file. They are:

1) Combat Axe. Gotta keep it old school. No alt function.

2) Stinger Assault Rifle with a smart laser. Glows red by default, turns yellow on enemies.

3) Condor Shotgun with a high-beam flashlight.

4) Tenderizer Flak Cannon with a last-stand mode (high rate of fire but wildly inaccurate)

5) Kodiak Sniper Rifle with an adjustable zoom scope (mouse wheel up or down to zoom in or out). Adjusts the fov cvar setting but has dozens of checks in the code to keep it consistent and restores player's previous fov setting PROVIDED the player's setting was between 85 and 95 (anything else screws up view weapon models, is basically unplayable, and is pretty much cheating).

6) SlugPuppy Grenade Launcher that fires high velocity grenades or proximity (proxy) grenades that attach to walls. Normal grenades deal blunt force damage if they hit a target, fall to the ground, and explode. Proxy grenades fire at half the velocity (which is vanilla Quake's normal grenade velocity) but explode on contact (like vanilla Quake).

Also added Q3 style weapon switching. I decided to allow players to hold all weapons, it's more fun than having to choose between two weapons to carry around.

On second thought, I might throw up some pics, but not for awhile.

Also might add that everything has custom sounds and models. When the mod is done, there will be very few (if any) original sounds/models. I'm re-working everything. Last night I re-coded and re-modeled the fireball and bubble entities. I'm getting down to the smallest of details lol.

[Nickelbawker]

Right on, thanks man! I haven't had much time to work on it lately, I've been pulling some overtime at work and come home exhausted. I'm currently working on a simplified version as an alpha or beta or whatever you would call it. Basically to showcase some weapons.

Nice sweet. I hate facebook. ugh go on there and click x everytime after viewing the first 2 posts.

edited try to keep this thread slightly cleaner

[Dutch]

Right on, thanks man! I haven't had much time to work on it lately, I've been pulling some overtime at work and come home exhausted. I'm currently working on a simplified version as an alpha or beta or whatever you would call it. Basically to showcase some weapons.

[Nickelbawker]

Still excited about this been playing some dark places, needs the extra features so that some people consider it playable.

[Dutch]

@talisa: thanks for the link, been looking through nahuel's code and learning quite a bit about it. Awesome.

@spike: dot product. damn, I'm having flashbacks to vector calculus, it's been a while. Thanks a lot, I tried it out on the current model I'm using and that worked perfectly. Back to looking at IQM formats.

frankly, laughing at people is always the easiest solution.

lmao

[Spike]

vector*vector = dotproduct
technically, the result is x1*x2+y1*y2+z1*z2.
this means that for axial values, it just pulls the value out, for instance x1=1,y1=0,z1=0 basically just returns x2. while x1=-1 returns -x2. in other words, if you use one vector as a normalised direction, the result is the distance the other vector is within that axis. this works for *any* direction, even non-axial ones.
so...
forwardspeed = v_forward * self.velocity;
sidespeed = v_right * self.velocity;

distancemoved = self.origin - selforiginfromlastframe;
selforiginfromlastframe = self.origin;
distancemovedforward = v_forward * distancemoved;
distancemovedright = v_right * distancemoved;
distancemovedup = v_up * distancemoved;

simple really.
compensate for speeds as desired too.

note that for some things you may want to use the player's desired movement values instead of their current velocity (in ssqc, the desired values is the .movement field, in csqc this is more commonly the input_movevalues global, but note that this is specific to the local player). depends wether you blend multiple leg animations together or if you twist the legs and only have forwards+back animations.

the real problem is basically that animation code is really quite specific to the set of animations you have available, and there are many different ways to actually do it. on top of that, you tend to need to modify ssqc a bit too. it cannot easily be tutorialised as it were, which is why I'm too lazy to bother. base mods are probably the way to go, but the problem there is that few people would choose to use an 'overcomplicated' mod that extensively depends upon 'extraneous' features like csqc. :s
if it ain't trivial to drop into vanilla, it ain't interesting. maybe I'm just being excessively paranoid. mneh.

[MadGypsy]

@ - "If only people were not too lazy to write some decent example code for this junk."

Do it up, man. You seem to fully grasp exactly what needs to be done. That's the kind of code that can go a real long way in helping people get off the ground. Do you need a rigged model or something? I have such things hanging out on my old system. I'd be more than happy to give them to you if it meant having something a little more solid to work with for bone codes.

I would have written a tutorial on it long ago if I had any clue how the shit worked.

[talisa]

you could ask nahuel for how to do this

he's once made a soldier which used skeletal animation and a split upper- and lower-body
so that they could be animated seperately and the soldier would actually look at you and have his weapon aimed right at you at all times
http://quakeone.com/forums/quake-mod...aces-only.html

he also included the QC-source with his mod, so that you could look at how he's done it

[Dutch]

Thanks for the tips guys. I thought about using two separate models but was hesitant because of the amount of work, but I think I need to just jump in and get it done, it bothers me not having sensible animations.

To determine the direction of leg movement (forward, backpedaling, sidestep), is there an effective way of using makevectors(self.v_angle) and checking self.movedir or self.velocity against angle directions of v_forward and v_right? I suspect this would be done client side, or by reading the clients command input for movement. I'll start reading some more on it when I get off work.

[Spike]

use skeletal models, csqc, and skel_build. this will give you separate control over the torso and legs without weird glitchy holes that don't twist properly at the waist.
its a huge pain to use though, what with needing to send a whole load of info over to csqc then to reimplement prediction because of it. it is the ideal method to use however, just horribly complex. If only people were not too lazy to write some decent example code for this junk.

or you can use setattachment and glue a torso model to a legs model, animate both separately in ssqc, and laugh at anyone that points out that models coming apart at the waist looks stupid. frankly, laughing at people is always the easiest solution.

[Seven]

Hello Dutch,

If you start thinking about additional strafing animation for the player, you should consider the shooting+running animation too.
And once you decided to add the shooting+running you will quickly see that a split player model is the best approach for that.
Having split the player, the strafing animation will be then done a lot easier, as it only affects the legs. And you can play shooting animations without having to worry to interefere/interrupt with running/jumping animations for the legs.

Fortunately you are focusing on FTE + DP, so you will need to use their extensions for this.

Nevertheless, there is always Armagon (from mission pack 1), that comes to my mind when thinking about this topic. He was as far as I know the first monster/model to use this splitted model technique with vanilla code. It did it quite good.

Best of luck.

[Dutch]

It only happens if you have the proper shield and the "throw an exploding copy" thing only happens with a certain brand name of gun.

Sounds pretty stupid. Lol. I'm not a huge stickler for realism in a game (Quake's physics are great, for example), but there's some things that are just too ridiculous.

On a side note, I'm looking to add side-step and backpedal animations to the player model, and eventually enemies. What's the best way of reading this?

A couple ideas I have: If I read the player's angular vectors in movement, this could determine the correct animation. So for example, if the player is only moving forward, then the normal forward running animation plays, so on and so forth. Problem is correctly reading the velocity vectors in relation to player movement. I have to play with this.

The other method (which I think Q3 uses) is to read the client's command input. If the button that induces forward movement is pressed (like the right mouse key) and no other side-stepping buttons are pressed, then the forward running animation is played. Problem there is I need to learn how to tie client inputs into keyed values, which I know can be done in DP and FTE.

Stuff to play with. I'm gonna keep doing my homework, but any advice is mucho appreciated.

[MadGypsy]

It only happens if you have the proper shield and the "throw an exploding copy" thing only happens with a certain brand name of gun.

[Dutch]

You should make it to where if you get hit by a ricochet you have a small percentage of absorbing the bullet and it magically ending up back in your gun. Borderlands 2 is retarded.

Haha. The bullet has a small chance of re-indexing correctly, sliding back up the barrel, and adding one to the ammo count. Does that seriously happen in that game? I'll steer clear of it then.

Thanks man!