RiftQuake

[MadGypsy]

Pretty damn good, Dutch! My only suggestion would be to lighten up the textures on the first 2 weapons. They almost look like silhouettes because they are so dark. Alternately, you could probably just use lighter textures on key details to better define the darker weapons visually.

Your RL (looking weapon) is the perfect contrast. If you go up through the images from there they just get darker and darker. If you used the RL contrast as a standard you'd be on the right track.

Edit: I moved this browser window to my other monitor (on a hunch) and realized a lot of the blackness was my monitor settings BUT the first weapon is still too dark, and instead of the RL having the proper contrast, now it looks "washed out" in comparison to the richness of the colors that your other weapons have. You need to add some love to the red and blue channels or simply raise the saturation.

If you don't know how to do that or otherwise need help with it, you can PM me the texture file and I'll do it for you. I'm working in the program I would use for that, right now so, it would be no problem to adjust it real quick and send it back.

[gnounc]

Your weapons are coming along nicely, the textures on all of them are much improved, they look good. With 1 or 2 looking great! I'm not really surprised to see your models looking so much better, I could tell with the first 2 art passes that you had some talent for it and just needed practice.

Now I'm anxiously awaiting the next demo to see what you've done in the way of coding and mapping! Good work, keep it up!

[Dutch]

@Bloodshot

Thank you sir! Gore and guns is the highlight of this here project. So far. Lol. Yes, I actually have considered maintaining a double-barreled shotgun with the benefit of extra damage and the drawback of manual reload of the barrels. My only hang-up though is that the shotgun I currently have is fucking brutal up close. It uses a non-linear damage infliction based on distance to the target. If you're far away, it doesn't do a whole lot, but if your right up on the target it deals instant death regardless of health or armor (on players and small enemies, not the big boys like the Shambler and his big brother the Gore...god I can't wait to start making the monsters). I'm kind of hesitant to change that because I spent hours fine-tuning the code for it. Maybe with a SSG I can extend the damage range because of the extra barrel. That could work. I'll put it on the list. Thanks for the input!

===================

Time for an update on the arsenal so far. A few of these you've seen, but are finalized in all aspects. Also, I've included the descriptions from my working game manual (yes, manual...no one likes to read READMEs so it's gonna be a PDF with pictures that us dumb Quakers can read ).

1)Combat Axe: Standard issue old-school weaponry for all Slipgate Rangers. This is your last resort when all other ammo runs dry and you find yourself cornered in some dim-lit god-forsaken place that's crawling wall to wall with the undead. It's gotten you out of tight spots before, and likely will again...but don't put too much faith in that.

Pros: Deals a massive amount of damage if you're tough enough to get up close and personal.
Cons: Using it probably means you're out of ammo.
Capacity: N/A
Alt Function: N/A

2)'Stinger' Assault Rifle: The MD86 .300 BLK Assault Rifle, aptly named the 'Stinger', is a fully-automatic standard issue assault rifle. Tried and tested, aged but reliable, it will not let you down when the combat situation calls for sheer volume of bullets. It's a pretty hardy weapon against soft-bodied combatants that can feel pain, but larger beasts and the undead will shrug off the comparatively small .300 Blackout rounds. Note that firing in full-auto significantly reduces the accuracy of the rifle. The longer you hold the trigger, the worse it gets. Firing in short, controlled bursts will give this firearm a respectable range. Lastly, recent upgrades include an MD GLX4 'Smart' Laser. The laser projects a conical beam, making it pin-point accurate up close but easily viewable from afar. It is normally bright red in color, but turns a light yellow when an enemy is traced. Great for scanning dark rooms for lurking predators without drawing attention.

Pros: Incredible rate of fire and reservoir magazines.
Cons: Limited range and terrible recoil in full-auto, and doesn't handle large enemies well.
Capacity: 60 per mag, 360 total.
Alt Function: Smart laser with unlimited use.


3)'Condor' Shotgun: The MD2 8-gauge Shotgun is as rugged and mean as the North American raptor it was named after. Featuring a full bodied polymer case, reinforced pump mechanism, and fully-enclosed barrel, it is basically bullet-proof and will be your best friend in every dismally dark hallway you traverse. It will shred any ugly son of a bitch in your way and leave a path of soggy, dripping gibs behind you. Firing a large 8-gauge 3-1/2" magnum buckshot shell, it's perfect for close-quarter combat in tight spaces, but almost useless at medium to long ranges. The built-in flashlight is blindinly bright and has an incredible range, but it seems to be the weak point of the weapon; field use leaves most of them shaky. Although the flashlight will light your way in the darkest of places, it will also alert any enemies that see the light to your presence, so keep that in mind.

Pros: The most powerful close-quarter combat weapon in the arsenal.
Cons: Limited range and slow rate of fire.
Capacity: 8 per mag, 64 total.
Alt Function: Ultra-high beam flashlight with unlimited use.


4)'Tenderizer' Flak Cannon: In a research effort to develop and deploy low-maintenance, non-lead based weapons with zero muzzle-flash, the United States Army recently contracted Fuller-Lathron Defense Technologies to produce such a firearm. One of many results is the FLT2 Flak Cannon, creatively dubbed the 'Tenderizer' by the ground-pounders equipped with it. Although still a prototype in its early stages of development, the Flak Cannon has already proven itself a reliable and deadly weapon when situations get messy. Firing 8 rounds of flak (a glorified nail) per shot, it can quickly fill a tight area with lethal projectiles given its respectable rate of fire. Instead of primer charges, the flak is launched via 8 high-tension springs, and auto-loads the next set of 8 self-indexing projectiles. In short, it's bulky and cumbersome, but is worth its weight in function. Keep in mind that launched flak has a tendency to ricochet and can turn against you in a hurry, but you can use this to your advantage to damage targets around corners.

Pros: High rate of fire, sheer volume of projectiles, and no reloading to boot.
Cons: Eats ammo like popcorn and fired flak can harm the attacker as much as the target.
Capacity: 512 total.
Alt Function: Rapid Fire mode. Flak nails are fired one at a time and are more accurate.


5)'Kodiak' Sniper Rifle: Hands-down the most lethal weapon in the entire arsenal, Grizzly Defense Arms prides itself for the Army's adoption of it's state-of-the-art big-game hunting rifle, named the 'Kodiak' after Earth's largest brown bear. The GZD48 fires a fearsome .50 BMG round with enough force to take down the largest of game animals on recently terraformed worlds. Imagine what it will do to the other-worldly scum you're about to go toe-to-toe with. There is no distance outside of its range, and it will pass through anything that isn't solid wall. See how many baddies you can line up and gib in one shot. Although it doesn't have the tactical look of other comparative military sniper rifles, it has earned its place with the best.

Pros: Nothing stops it, nothing can run from it.
Cons: It's a manual loading rifle, meaning a lengthy reload after each shot.
Capacity: 1 per shot, 16 total.
Alt Function: High-powered scope with four range settings.


6)'SlugPuppy' Grenade Launcher: If mishandled, the S10 25mm 'SlugPuppy' Grenade Launcher can be as deadly to its owner as to the target it's fired upon. That being said, nothing makes an enemy combatant scurry towards cover like a hail of highly bounceable grenades. The 'SlugPuppy' (often called the 'Pup') fires unique "Smart Grenades" that can be armed as conventional grenades or as proximity (proxy) grenades with the flick of a switch. By default, grenades are launched at a high velocity and, upon contact with a solid object, initiate a 1 second detonation timer. They deal blunt force damage to enemies when struck. Conventional grenades glow red in color. Proxy grenades launch at roughly half the normal velocity (to prevent pre-mature detonaton upon contact), glow blue in color, and stick to any solid surface. Any enemy in motion close enough will set off the grenade. Additionally, proxy grenades detonate automatically upon contact with an enemy while still airborne. The action of the Pup features a highly magnetic bore which aids the user in quick reloads after each shot by guiding the rubber-coated mild steel 25mm shells in.

Pros: Creates a lethal environment with highly erratic grenades and proximity mines for your enemies.
Cons: Said lethal environment probably includes you as an occupant. Take care how you use the Pup.
Capacity: 1 per shot, 48 total.
Alt Function: Proximity (proxy) grenades.


7)'Ragnarok' Rocket Launcher: Named after Norse mythology's apocalyptic event, the S9C 32mm "Ragnarok" Rocket Launcher may not bring about the end of the world for all, but it certainly will for your target. Firing a highly explosive 32mm shell at a respectable velocity with incredible range and accuracy, it makes the user a force to be reckoned with. Upon launch, fired rockets deploy four spring-loaded fins that keep their trajectory true, even underwater. Contact with any solid surface will induce detonation. The 'Ragnarok' features the same magnetic bore as it's 'SlugPuppy' brother, meaning quick and easy reloads after each fired shot. Also like the 'SlugPuppy', it is incredibly dangerous in close quarter combat. That 'DANGER' sticker isn't on the firearm for aesthetics. It's Alt Function re-programs the fired rocket to detonate as a scatter bomb upon impact that will deal less initial damage to large enemies, but is great for dealing splash-damage to lots of small ones.

Pros: Accurate and deadly.
Cons: Somewhat slow rate of fire, dangerous to the user up-close.
Capacity: 1 per shot, 48 total.
Alt Function: ScatterBomb detonation



============================

Hopefully that will keep everyone tied over till the next update, which could be awhile. The Combat Axe is a dressed up (poly and texture) version of CapnBub's axe on his Ranger model, which I am using as one of the playable characters (outstanding work on that model, I aim to do it justice). The remainder of the weapons to be made are:

* 'ForceShot' Kinetic Booster (knocks enemies back and deals decent damage)
* 'HellBringer' Flamethrower
* Rift Rifle (with a deadly charge shot...think Spartan Laser from Halo3)
* Rift Phaser (full-auto)
* Rift Disruptor (breaks organic molecular bonds...this is the melting death gun )
* Rift Launcher (gruesome bone-crunching black hole)
* Rift Shotgun (only Rift energy, not lead pellets)
* possibly Bloodshot's double-barreled shotgun

[Bloodshot]

God damn this mod looks awesome. The melting effect reminds me of the great fallout 1/2 plasma weapon deaths.

Just curious, have you considered keeping the super shotgun and making it reload like Doom 2's? It would be in line with the pump shotgun in your mod. (I also feel Q1's default shotty feels like a pistol and super shotty feels like a shotty) but I just adore a good SSG.

[Dutch]

local entity head = findradius(self.origin, 256);
while(head)
{
print(sprintf("found a %s\n", head.classname));
head = head.chain;
}

findradius should only be called once, unlike find. it returns a linked list rather than the next entity.
naturally, this sucks with recursion, like stuff that does T_RadiusDamage in its th_die function, as this can corrupt the .chain linked list.

Worked beautifully. Another good lesson learned, thank you sir.

[Spike]

local entity head = findradius(self.origin, 256);
while(head)
{
print(sprintf("found a %s\n", head.classname));
head = head.chain;
}

findradius should only be called once, unlike find. it returns a linked list rather than the next entity.
naturally, this sucks with recursion, like stuff that does T_RadiusDamage in its th_die function, as this can corrupt the .chain linked list.

[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

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

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

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.

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

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

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

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.

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