RiftQuake

[talisa]

both weapon-models look great

[vegetous]

Do you guys read minds or something? I was asking myself the same question yesterday. I can do so much more with half the BS to deal with in the two advanced engines. I am really glad you two brought this up. I'm a big fan of the features and support offered by DP and FTE. And now that I've been drastically increasing the scope of RiftQuake, trying to stay 'faithful' is becoming silly. Like trying to shove 20 pounds of shit in a 5 pound bag, basically. My biggest reason for staying vanilla compliant was basically keeping the old school crowd happy. I didn't want to limit my audience.

I'm tired of dealing with limitations, especially when LordHavoc and Spike have offered a way around them. The mod is going advanced engine, or else I will be fighting and playing around with limitations and I'll never get the project done. If any of you faithful guys were keeping up on the mod, I do apologize. But there are areas of modding I'd like to dig into that a vanilla engine just won't handle.

Way to go, dude!

[Dutch]

Thanks y'all! I'm slowly but surely getting more Blender-fluent...in other news, I have completely stripped down the QC code for the mod. By stripped down I mean completely started fresh. With all of the features and content I've added so far (and plan to add), modifying id's source code was becoming a jumbled heap of hacky/sloppy coding. By doing this, I will know exactly what is in every corner of the code, and it will be much more clean and reliable.

This, of course, renders the original Quake campaign unplayable, as I am starting from scratch on entities/triggers/doors etc. Some will remain, most will be new. This allows me to craft the game in the exact vision that I have for it. Once the coding and modeling is done, I will be making a large episode, hopefully with cutscenes and the works. I have already begun drafting a story for the game (still in my head at the moment). I figure since I'm straying so far off the beaten path, and with enough dedication I can make an infinitely better campaign, it's only another limitation to keep the original intact.

This is ambitious, that I understand. But it is totally do-able and I figure what the hell, I'm having a blast. Never thought I'd get this deep into it and I still want to go deeper.

Naturally, it will take me a loooong time to finish all this alone, especially since I'm going to utilize whatever features I can with the advanced engines, which increases complexity. Expect a "RiftQuake is now hiring" post once I get the foundation of the code and some more modeling finished

But for now, back to NotePad++

[Nickelbawker]

Looks awesome!

I'm a newb to quake mods, mostly play ProQuake 4.71 on psp and Qrack 24bit max'd out, single player unfortunately need more gaming friends.

Do you think you can check out Qrack 24bit textures see if you can put something like that in it those are one of the non-vanilla things I really like about quake!

Another feature that would be cool is have a toggle to center the weapon, sounds retarded and un-realistic but quake doesn't have Aim Down Sights, yet and centered weapons are so different and neat from other shooters.

[Dutch]

Thanks Nickelbawker!

I'm a newb to quake mods,

Been there brother! No more than 5 or 6 months ago lol.

Do you think you can check out Qrack 24bit textures see if you can put something like that in it those are one of the non-vanilla things I really like about quake!

Replacing textures isn't really mod specific, so as long as you are using DP or FTE (the only two engines RiftQuake is designed to run on as of recently) inserting custom textures is totally do-able, to my knowledge. RQ will definitely have custom, updated textures for the episode. After all this work I'm not going to package it with old school grainy textures lol.

Another feature that would be cool is have a toggle to center the weapon, sounds retarded and un-realistic but quake doesn't have Aim Down Sights, yet and centered weapons are so different and neat from other shooters.

Because RQ will feature dozens and dozens of different viewweapon frames *including Aim Down Sights), the centerview may not work out. I am still working this out (among a hundred other things), but when you see it all in action, you will see that RQ won't have conventional offset weapons like in EVERY first person shooter made nowadays. Running, jumping, firing, aiming, reloading, etc will have different viewweapon frames.

Thanks for keeping up with RQ man! Seeing as you're showing interest in mods, here's a list of older and current mods to dig into if you haven't already:

* SMC
* Marcher Fortress
* Altar of Storms
* Unforgiven
* Soul of Evil
* FrikBot (multiplayer...this should solve your problem of no one to play with, the bots are pretty smart and tough. Good coding)
* Anything that uses Quoth

There's a ton more, and you can find them all over this site and Inside3d and Quaddicted to name a few websites. If you have any questions, let me know. I was new not too long ago and I had to figure some things out that weren't readily obvious.

Happy fragging dude!

[Nickelbawker]

all good i got darkplaces now fully installed its really awesome so i wont need weapon centered, ill just keep both versions when yours comes out.

[Dutch]

Got so wrapped up in coding I forgot about an update. If any of you keep up in the General Help section, you're already up to speed. If not, here is what I've accomplished in the last few days (another shout out to Spike for his help, thank you sir).

* Crouching function that allows players to duck under low hanging, non-BSP obstacles (I have coded in a func_crouch_ceiling object with a SOLID_BBOX property to side-step hull clipping issues...see the Crouch Function Problem thread in General Help if you are unaware of this issue, this was Spike's offered solution). This crouch function also re-defines player's hitbox size, so you can now duck for cover in SP and DM.

* Prone (laying down and army crawl) function coded to the same specs as the crouch function. Currently working on lowering the turning (yaw) speed of the player while in prone for realism.

* Lowered player movement speed while crouched or in prone.

* Also a jump function like id's original. In PlayerPreThink(), the player's position state (crouch, stand, or prone) is checked. If standing, the player jumps when self.button2 is pressed (jump button). If in prone or crouch, instead of jumping the player will stand up.

Remember, I started from scratch on the code, so all of the physics are being re-coded to comply with new RiftQuake features. For the most part, they remain the same as id's Quake (fast paced).

EDIT: Crouch and prone functions are called by Impulse commands, of course.

[MadGypsy]

I was new not too long ago

LOL! You are still new. You may have some scratches, possibly you have even achieved a dent but, you are still new. You'll see. This rabbit hole is hella deep, brother. When Spike starts getting real technical and you get it, you aren't new anymore. So far, he has merely farted cause, even his flatulence is a genius. For real though you have a long way to go, my friend.

But hey, you are at least going there. No doubt about that.

(I have coded in a func_crouch_ceiling object with a SOLID_BBOX property to side-step hull clipping issues

Send me the code one day and I'll add it to your radiant .ent. Actually if you tell me exactly what compilers you are using, I could start a RiftQuake gamepack that is specific to your game and QC.

Considering how different and robust your game will be. I think it is ideal to have it's own gamepack. It will make it a lot easier to build maps for your game if all of your entities are defined and the pack is slimmed down to only include what you use as-well-as have a default build menu written that uses the exact builds you do (production and release)

Much of this is going to be something that comes in time, as you get further. Make a note that we can get this done though and making the ent match the QC will be a lot easier if the ent is customized as new QC is created.

Actually, do this - as you write QC that will appear as an entity in the map copy and paste just that chunk in a text file. At the end of every week send me the new text file. I'll change the .ent and mail it back. As long as all of the code is just the actual entities it doesn't really matter how much code you have. It's when the code is all of the code that it becomes a bitch to pick through it.

For real, do this. I'll keep you current. This will also serve another purpose. You'll have a second set of knowledgeable eyes on your QC early on. When I go to turn it into an ent I may realize ways that it can be tweaked to be even better. I can pass that info back to you. Actually, I could completely rewrite it (if necessary) and pass the rewrite with an explanation back to you. That way, you don't have to do shit but like/dislike it.

There is one other perk to this. How cool would it be to map in a custom gamepack for a game that doesn't even exist yet? That's some hella pro stuff, right there. I can make it happen.

[Dutch]

LOL! You are still new

Let me rephrase that: I didn't know a damn thing about anything that has anything to do with anything about a Quake mod, including installing, playing, and coding for that matter. Now I know a little bit. My favorite analogy is "if [insert skill here, in this case QC] is an ocean, you've barley scraped sea foam." So yes, you are right, I'm still a damn rookie and I have no problem admitting that. But all things considered, it sure feels like I've come a long ways so far. Let's just see how far I can take it

As for the ent file...way ahead of you brother! I took the stock Q1 ent file you included with the gamepack and stripped it down to a player_info_start. Then I added in my func_crouch_ceiling. These are the only two entities so far. I loaded up Radiant, inserted both for testing, compiled using the BSP1 build menu set, and tried it out. It works great. Still some things to iron out for the Radiant settings but I'll get there.

I'm still going to send you the code and ent file though. You are right, two sets of eyes on a project of this scope is a good idea. Feel free to alter/add stuff to the code. You've got way more experience on me, so let's get this game top notch. When I PM you tonight or tomorrow you we can hash out what you think the best compilation procedures would be. And I'm digging the idea of a Rift gamepack.

It's a lot more work, but starting clean and from scratch is amazing; I don't have to sift through loads of bullshit to code in my own stuff. As long as we stay current on the code/ent file, everything should stay organized.

How cool would it be to map in a custom gamepack for a game that doesn't even exist yet? That's some hella pro stuff, right there. I can make it happen.

Love the sound of that. Let's do it man, we can put a polish on this project that will amaze.

[Dutch]

Been really busy getting a few technical things done on the project, so not a lot of exciting news. A quick list of what I've been up to:

* Fully optimized NetRadiant for Rift, including a work-in-progress .ENT file, a build menu that I like for compiling, figured out some things about LordHavoc's hmap2 compiler, figured out some texturing issues, so on and so forth. Huge shout out to golden_boy and MadGypsy for their tutorials on Radiant on this very site. Learning the interface (although not totally foreign, but still different) is a big curve for me because I've only ever known one editor, and I can tell you hands down that I wish I had been using Radiant after all these years. Superlative editor. Another shout out to Gypsy for his gamepack that I played around with to set up the editor to where I like it for the mod. I even learned a little bit about xml and NetRadiant structures. I know I said I'd get you the mod folder and .ENT file but there's still not a helluva lot there, let me make a few tweaks and add a little more.

* Really polished up the crouch/prone functions, and also included some custom engine cvars to give a polished appearance to the player's view (breathing, small bobs when running, slight weapon swinging...basically the little things that you might not initially notice but give a great appearance). These are included in a custom .CFG file that will be shipped with the game, so it's all editable of course.

* Coded in basic lighting. Basic targeting triggers are up next so I can be sure lights are switchable on/off.

* A couple more weapon models in Blender.

I'm taking this all one step at a time. I'm pretty scatter-brained at the moment, because the size of this project is getting big. Really big. My next steps are basic triggers, more lightstyles (including a flashlight), and finishing all weapon models, then texturing them. I'm just glad I got the map editor set up to where I like it.

Here's a few pics of the weapons I'm modeling just for shits and giggles.

Perspective viewpoint of the "Stinger" .300 BLK Assault Rifle:


Perspective viewpoint of the "Talon" 10 gauge Shotgun:


Side view of the "Tenderizer" Flak Cannon:


Perspective view of the Tenderizer:


And finally some work-in-progress (it's not finished) pics of the "SlamCannon" Grenade Launcher:




The SlamCannon will fire grenades at incredibly high velocities for a long range shot, and grenades will detonate on impact. It will basically perform the function of the rocket launcher, only with a slight arc on the shot and less accuracy. This is the primary fire. It will also have an alternate fire that launches grenades at a slower velocity and the grenades will not detonate on impact, including on enemies (more like standard Quake GL). Useful for bouncing around corners and what not.

[Dutch]

Apologies for the double post, but this really has nothing to do with the previous post. I'm a bit unclear on the behavior of SSQC in regards to setting cvars in code. Basically, I want to adjust the player's viewpoint bobbing when in crouch, prone, or if the over-the-shoulder camera is initiated. I believe I can do this without messing with player's preferred cl_bob settings by floating the current value of the cvar and then doubling it while the player is in crouch, so on and so forth. Therefore, if the player has a value of zero on the cvar, it will not set it to any other value in code, since 2 * 0 = 0.

BUT, I found this on the QuakeC Reference Manual:

float cvar(string console_variable)
Returns the value of a console variable. Note that this reads the console variables of the server only and
cannot read the console variable of network server clients. Note also that some console variables cannot
be read by
cvar()
at all
, such as �maxplayers�.

Does this mean that in a DM game, the cvar setting will be read by the server exclusively, thus over-writing the client's setting? If so, I reckon it's about time to dig into CSQC and start doing my homework. Thanks.

[Spike]

it means that if you're only using 'cvar' to read/preserve the current value, you should use only 'localcmd' to set it (this is of course natural in csqc too).

if you're using stuffcmd to change cvars, you can do "cmd mybob $cl_bob\n" and then parse the response with krimzon_sv_parseclientcommand. obviously, this can have syncronisation issues in that when you get the response you may have already tried to change it again or whatever.

alternatively you can ignore whatever the user has set and just send the default value to reset it. yay for lazyness.

but yeah, csqc has full control over cvars and other stuff. while not strictly needed for this, it would be simpler if you have a little csqc already - that initial hurdle puts far too many people off, its like they're all cowards or something.

[MadGypsy]

Your gun models are the shit, man! I like your style.

@PM me stuff - It's all good. Whenever you are ready.

[gnounc]

it would be simpler if you have a little csqc already - that initial hurdle puts far too many people off, its like they're all cowards or something.

https://gitorious.org/clean_csqc/cle...d17879d7ca263:

@Dutch:
Clean Csqc is on my repo specifically to be used by people who need a csqc base.

It has comments and the like. Its based (in a roundabout way) on dresks scratch base that everybody and their mother uses, and cleaned up a lot to be more up to date.

Also it has the benefit of being on a repository, so if there are errors, tell me and I'll fix them, and if theres anything that could be better commented, tell me what the ambiguities are, and ill add a comment to the sourcef or the next unfortunate soul.

[talisa]

great looking weapon models dutch!
they look very cool even without textures