RiftQuake

[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

[Nickelbawker]

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

[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]

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]

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.

[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]

In regard to the previous post I made...found it!!! Started sifting through FitzQuake source code:

/*
==============
V_CalcViewRoll

Roll is induced by movement and damage
==============
*/
void V_CalcViewRoll (void)
{
float side;

side = V_CalcRoll (cl_entities[cl.viewentity].angles, cl.velocity);
r_refdef.viewangles[ROLL] += side;

if (v_dmg_time > 0)
{
r_refdef.viewangles[ROLL] += v_dmg_time/v_kicktime.value*v_dmg_roll;
r_refdef.viewangles[PITCH] += v_dmg_time/v_kicktime.value*v_dmg_pitch;
v_dmg_time -= host_frametime;
}

if (cl.stats[STAT_HEALTH] <= 0)
{
r_refdef.viewangles[ROLL] = 80; // dead view angle
return;
}

}

Well there you go. I hope anyone else modding QC who didn't already know this can learn from this little journey I went on. Lol.

[Spike]

csqc can override the angles completely. setviewprop(VF_ANGLES, input_angles); will remove any death/idlescale/viewkick angle changes, and will use exactly what the client is sending to the server.

[Seven]

Hello Dutch,

I can on one side fully understand that you do not want to play around with engine cvars and edit their default settings for your game/mod. As the engine cvars have been set by the player (and especially the engine dev).

But when you look on it from another side:
Your game/mod will have his own code ssqc/csqc, so you have to use a separate subfolder for it anyhow. And this subfolder is totally dedicated to your game and its very special settings (independent to all other mods).
This would be reason enough for me to adjust the look and feel of the game to match it your vision you have for your game/mod. It does not disturb the id1-config settings in any way.

See, when you want to make the players view angle not tilted to 80�, as it is default in Quake, then you can do it by changing engine cvars, or by using csqc (as mentioned by Spike) or write some dedicated code to achieve it.
But by doing this, you will change the "regular" Quake behaviour, that the player knows.
And that is absolutely OK.
It is your game/mod and you have your own vision of how it shall be and look like.

So in my opinion, do not think about NOT editing engine cvars or engine behaviours, as it only affects your game/mod folder and it adds a lot to your in-game feeling.
It doesnt matter which path you go (mentioned above), you will always edit the "default behaviour" of the engine.

While talking about it, Darkplaces has this cvar to disable the tilted deathview: v_deathtilt
Set it to 0 and you can use any behaviour you want in your qc.
I am sure that FTE also has a similar one.
That might save you some code lines to bypass the "regular" engine behaviour via xxqc.


By the way, will you be able to use the same code for both DP + FTE (and as far as I remember you also focus on Quakespasm) for your game ? There are some serious differences as you know between these engines and their extensions.
Or will you include 2 or 3 different setups in your release, dedicated to the single engines ? Or did you already gave up 1 or 2 of the engines supporting your game ?
While talking about csqc, you surely have followed the discussions and rants at i3d about this topic and how different the engines supporting it.
It is a very interesting discussion, that you should definitely read, if you didnt have already.

The small mod I am working on also makes use of a different death-view, and I asked myself the same question as you did. But I didnt had the balls to enable it by default, as many users of the mod puts it into id1 folder to be able to permanently use it. So I disabled it by default to not interfere with the expectations and habbits of the users.

Looking forward to your game/mod.

Best wishes.

[Spike]

'v_deathtilt' won't fix all your problems. simply put, an entity can only have one angle. in order to have the view follow your killer, you need to change the player/corpse's angle to track it. which means your corpse is now spinning on the spot.
even if you override angles on the server and hide it from other clients, any mirrors (reflective water etc) will still show the corpse as rotating weirdly. while you could copy the player to the body queue straight away combined with externalmodelforclient, you may find csqc is the easier/simpler way - send the target entity index via a stat and calculate the required angle with vectoangles(getorigin(getstatf(STAT_DEATHCAMTARG), VF_ORIGIN)-getorigin(player_localentnum, VF_ORIGIN)), or so. You probably need a few more checks, but that's the core logic.

[gnounc]

yeah, I complained some time back about engines tilting the view based on player health. I was told its too entrenched for me to expect change.

I still think thats gamecode territory.

[Dutch]

Thanks for the responses guys!

I was a little vague about the death cam though. It's not a camera to view the perspective of your killer, it is an invisible entity that spawns near your player with angles towards the player's origin, where it then does a half-spin around the player using constant traceline and setorigin updates until the player respawns.

csqc can override the angles completely. setviewprop(VF_ANGLES, input_angles); will remove any death/idlescale/viewkick angle changes, and will use exactly what the client is sending to the server.

Excellent. I'm adding that to my list of csqc notes.

By the way, will you be able to use the same code for both DP + FTE (and as far as I remember you also focus on Quakespasm) for your game ? There are some serious differences as you know between these engines and their extensions.
Or will you include 2 or 3 different setups in your release, dedicated to the single engines ? Or did you already gave up 1 or 2 of the engines supporting your game ?

At the moment, I have to be careful about choosing advanced only or faithful compatible, because I may hit a roadblock in the faithful department. As of now, I'm trying to stick faithful in the interest of time and compatibility. I know I keep flipping back on forth on that, but as I'm sure you understand, it is difficult to produce all of the content intended for an advanced engine by yourself, sometimes it is better to keep it simple, at least for the time being.

What I want to do is create a separate release for FTE and DP (likely one for each) that uses CSQC and advanced features, but for the most part keeps gameplay and content the same.

[talisa]

@dutch
if you would develop your mod for darkplaces you wouldnt have to use an invisible entity for a death-cam
just check out seven's SMC, he has a death-cam implented into it which works through usage of darkplaces chasecam feature
[ame=http://www.youtube.com/watch?v=7Uok05g-BmU&list=UUbX7uVIXqMzBza0YmLJuMdw]SMC death-cam[/ame]


perhaps you could use seven's code for death-cam, and modify it to prevent the player from rotating cam themselves and make the cam rotate slowly

[Dutch]

I have downloaded and tried Rift on:

Qrack
JoeQuake
reQuiem
FitzQuake
FTE
DP
QuakeSpasm

Here's the results:

QuakeSpasm: considering I'm building the mod primarily with this engine, it works flawlessly.

DarkPlaces: takes everything from the QuakeSpasm build and implements it great.

FTE: Only noticeable problem is the model for the assault rifle laser (a simple circle that traceline's to a surface and orients through trace_plane_normal) appears all black in color. It should be a solid fullbright red, or fullbright yellow if contacting an enemy. Besides that, works awesome. @spike: any idea what is causing this?

FitzQuake: Fucked. Crashes on load-up, guessing the precache list is too much for it.

reQuiem: works good, but has random little bugs. Has the same laser skin problem as FTE, and incorrect ammo values are displayed if over 100 (2 weapons in Rift hold well over 100). Other than that, works great.

JoeQuake: Weaponframe glitch on weapon changing and incorrect ammo value display. Other than that, works great.

Qrack: Same as JoeQuake.

Obviously some cvar settings have to be adjusted. Another problem is the configuration structure of cfg files across some engines.

I would like Rift to be as "out-of-the-box" as possible, because nothing turns players off from a mod like having to piss around with settings, file/folder structures, and what not. So there will have to be some engine-specific packages for the mod.

@talisa: that is exactly what I was trying to do, thanks for the heads up!

[Dutch]

Hit another small snag tonight, so it's time to once again expose my rookie-status in QC and coding in general. Lol.

I'm coding a weapon called the ForceShot. If anyone here plays Dead Space, you'll recognize this as being similar to the Force Gun. Basically, it fires a shockwave immediately in front of the player with intention of sending the target (a monster or a client) flying away from the player.

Everything works great, except it will only apply the force velocity to one entity at a time (naturally), and I'm struggling in declaring multiple entities using findradius(). Basically, it keeps 'finding' the same entity. The whole goal is to knock back enemies if the player is being swarmed and overwhelmed.

Here's my code. It is the initial shot fired (which checks target entity position and ensures it is in front of the player - I nabbed that bit of code from the monster infront() function), as well as an attempt at declaring a new entity within the same radius if there are any. Any help is mucho appreciated. I tried looking at id's method of locating more than one intermission camera, thinking it was similar. Gonna keep playing with it.

void(entity targ, float dot, vector vec, vector dir) MoreTargs =
{
local entity targB;

makevectors(self.v_angle);

// find a new target different from last:

targB = findradius(self.origin, 12;
vec = normalize(targB.origin - self.origin);
dir = targB.origin - self.origin;
dot = vec*v_forward;

// apply velocity if new target:

if (targB && targB != targ)
{

// make sure target is in front before applying velocity/damage:

if (dot > 0.3)
{
targB.flags = targB.flags - (targB.flags & FL_ONGROUND);
targB.velocity = dir*12;
targB.velocity_z = 300;
T_Damage(targB, self, self, 10 + random()*10);
}
// repeat:
targB = targ;
MoreTargs(targ, dot, vec, dir);
}
};

//==================================================

void() W_FireForceShot =
{
local vector vec, dir;
local float dot;
local entity targ;

sound(self, CHAN_WEAPON, "weapons/ragnarok_force.wav", 1, ATTN_NORM);

makevectors(self.v_angle);
targ = findradius(self.origin, 12;
vec = normalize(targ.origin - self.origin);
dir = targ.origin - self.origin;
dot = vec*v_forward;

if (targ)
{
if (dot > 0.3)
{
targ.flags = targ.flags - (targ.flags & FL_ONGROUND);
targ.velocity = dir*12;
targ.velocity_z = 300;
T_Damage(targ, self, self, 10 + random()*10);
}

MoreTargs(targ, dot, vec, dir);
}
};

EDIT: added some comments