News | Forum | People | FAQ | Links | Search | Register | Log in
What - Realistically - Do You Want To See In Quake In 2018??
Let's assume that a full HD but true-to-spirit Quake remake, guaranteed 200 maps, AD 3.0, and PC Gamer cover shots fall under "un-realistic", but there might be other exciting ideas and desires that will come true.

So what do you want?? Map-wise, theme-wise, mod-wise, meta-wise?? Let's get the hype started....
 
I’d love to see something like a mega-map jam. Maps with a few hundred monsters and loads and loads of secrets and extra little hidden bits and pieces. I think that’d be great fun! 
TB 2.1 
 
Scripting 
I would love to see an engine like Quakespasm implement a robust level scripting language so we can get away from these unwieldy entity chains.

I would love local fog volumes and volumetrics to make their way into the game (but in a suitable Quakey way).

And finally, I'd like a repeat of the bumper map release year that 2017 was. So many cool maps! :) 
More Base/horde Maps 
I want to see more maps in a vein similar to Rubicon Rumble Packs.

I also want to see more releases from Tronyn. Unforgiven, SOE: Indian Summer and other maps/mods from him are among my favourites. 
#2 
I did say realistic aims....:P 
Tasteful Low Poly Remakes Of All Quake Models 
Something like about 700 polys per monster model, proper UV maps and better animation, full compatibility with WinQuake.

The original models are quite bad, as it was id's first foray into 3D modeling and they tried to apply 2D graphics concepts to it (like the UV maps being simple front/back shots of a creature). It'd be really cool to have the models remade by somebody with a good understanding of low poly graphics. For example
Split Screen Multiplayer 
with controller support. 
Cuntor 
 
 
I'd love to see some support for fog brushes and water that settles into its area. 
 
oh and decals.... definitely decals 
New Low Poly Models + Reborn Of Multiplayer 
 
Volumetric Fog 
Would rule actually. 
Less Drama, More Mapping 
 
 
- seeing software-rendererd Quake on RISC-V Linux development boards (needs a 64-bit clean engine with a pure-C software renderer - is something like this available?). No 3D hardware can be assumed at this stage.
- more widespread engine-support for MD3 and IQM
- DP particles in more engines 
Reallistically 
Commercially wise i would be fine with something similar to the last Doom in terms of gameplay ported to Quake's theme and style, so at least a bit more vertical and less arcade-like.

In custom maps, more variety in types of gameplay and brushwork style. Even with all the fresh blood, i think that has been reducing with each passing year bit by bit in the last three-four years. 
Engine Development *cough* Eric *cough* 
Three things I'd like to see added to Quakespasm:

I'd love 5.1 surround sound. Quake's dark eerie atmosphere is just crying out for it.

I'd also love rumble support for controllers... I mean, the game's called Quake for goodness sake!

Finally, I'd love full Nehahra support. It's a seminal work and I'd love to play it in a seminal port.

Obviously, these are just wishes and not demands. :)

Other than that, I'd love to see more AD maps. The touches that AD bring to Quake are wonderful.

Also, Trent Reznor to FINALLY release the OST vinyl and shine a spotlight onto this great game once more. 
Nehahra Support In QuakeSpasm 
I'd rather vote against it to be honest.

Now let me explain myself.

Nehahra does so many things in a weird way, e.g. loading skyboxes and music tracks via console commands instead of using worldspawn (basically the "properties" area of a level) like all the other Quake engines and id's later games. It's using MOD music instead of MP3s/OGGs because bandwidth considerations was a thing back then. It's got custom formats for maps, sprites and demos because reasons. Nehahra should ideally be updated to be inline with the modern engines, not the other way around, where you would include all kinds of ass-backwards code just to support a single mod. It's a great mod mind you, I had plenty of fun revisiting it this year, but yeah, it needs to be updated. The source code (both QuakeC and engine) is available, so somebody should really do it. I've got a big stash with all original Nehahra downloads if somebody needs it.

Might as well fix all the random fullbright pixels and the extra twitchy AI while you're at it. 
 
Nehahra should ideally be updated to be inline with the modern engines, not the other way around

This times a million. I don't think Quakespasm should be cluttered with a ton of #ifdef NEHAHRA crud. 
^Good Point(s) 
Okay then, I would like to see Nehahra updated to modern standards. :P 
Fog And Better But True-to-Quake Models. 
I am really liking those ideas. Seeing the new Shambler model shows the potential for actually getting it right.... 
5.1Surround In QS .0.9x 
I second this. Would be cool and doable as all q1 assets are mono. Tons of 5.1 and 7.1 headphones out there. This would be a great addition.

Would like to Mod menu and Demo menu added to QS as well. 
 
Split-screen and controller support, definitely. 
 
Xmasjam2017 released 
Hmm.. 
Keep 1.0
TB featureset match or exceed JACK (ALT+RMB!)
Large release from long forgotten mapper(s).
Alpha support on fence textures below 0.666.
Retroquad 1.0
Volumetric fog.
Surround sound support.
AD-level quality models for everything.
AD 3.0
Splitscreen
Advanced qc support to fix "entity chains". (I could maybe do this ;) ).

200 MAPS. GO MAP!! 
Wishes... 
Spike FX fully integrated in official QS.

Also a new vore model with puffy tits and a dripping bloody snatch with teeth. 
 
Robust multiplayer (including QW support, server browser) in QuakeSpasm so we could have a single engine to point people at for getting into Quake for any degree of single or multiplayer, maps, and mods.

Fog brushes

Lightmaps on liquids

Alpha dictated by material and relative depth (water on the shore is more translucent than water a few feet out - and the base value is impacted by the texture used)

Physics correct (to Quake's logic) movable liquids

More Quake mods in general, not TCs, not experiments, not appended content and mapping tools, but gameplay mods that let you meaningfully replay existing content. 
 
personally i would like to see if i kill an enemy i get his weapon 
/s 
Steam Workshop Support 
Decouple Physics From Rendering Framerate 
 
 
 
Skeletal mesh support and blend / morph so I can use the best of both worlds.

Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though.

Limb loss for monsters. In general a more expanded gore system. I like making custom gibs and it be fun to shoot off bodyparts and the monster still keeps fighting.

I second more advance water volumes that accept lighting and foam. Murky swamp water with bits floating in it would be nice. Stuff inside water volumes like pond scum.

Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...

Reflections on water and glass... :) and a nice FX editor for particles. 
Kinn 
An option to emulate the 8-bit colour look of software quake (with its crunchy banded lighting etc.) in Quakespasm. 
 
not to self: Title != Name 
I Would Specifically Like To See... 
NO split-screen.
NO fucking controller support you arse suckers.

Deep-coding in Quakespasm and all other major engines to prevent split-screen and controller support being added. 
Wtf Shambler Ha 
Thats some dark ages type thinking hehe. Heresy i say! The 8bit color banding with dithering would be nice. Easy enough to do as a shader. 
OTOH 

TB 2.1

I would love to see an engine like Quakespasm implement a robust level scripting language so we can get away from these unwieldy entity chains.

I would love local fog volumes and volumetrics to make their way into the game (but in a suitable Quakey way).

Tasteful Low Poly Remakes Of All Quake Models

In custom maps, more variety in types of gameplay and brushwork style. Even with all the fresh blood, i think that has been reducing with each passing year bit by bit in the last three-four years.

I'd love to see some support for fog brushes and water that settles into its area.

oh and decals.... definitely decals

Lightmaps on liquids

Alpha dictated by material and relative depth (water on the shore is more translucent than water a few feet out - and the base value is impacted by the texture used)

Physics correct (to Quake's logic) movable liquids

Limb loss for monsters. In general a more expanded gore system. I like making custom gibs and it be fun to shoot off bodyparts and the monster still keeps fighting.

I second more advance water volumes that accept lighting and foam. Murky swamp water with bits floating in it would be nice. Stuff inside water volumes like pond scum.

Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...

Reflections on water and glass... :) and a nice FX editor for particles.


All of these sound interesting / promising / potentially desirable if done well. They are pretty much in line with one of my main desires:

Keep having Quake graphics / effects / features slowly and tastefully enhanced while keeping true to Quake. I.e. no big crazy leaps with HD monster shaders or whatever bullshit. Just keep adding the small stuff like has already been done with fog / particles / skyboxes / breakables etc etc, and encourage people to use them subtley and Quakily. I think stuff like ad/spikespasm is doing this pretty well and far more effectively than the pseudo-AAA OTT jumps in Darkplaces etc, and I hope that can continue with some of the ideas above. 
Also. 
I'd like to see more smaller / non-horde / non-epic maps with interesting gameplay, convoluted layouts and cool designs. Not everything has to be a mega-map, mappers don't need to tie themselves into knots trying to emulate Swampy/RR/Sepulchre/Marcher etc.

And finally for now...

I want to see ALL maps showing a strong theme with their design language and architectural styles, not just their texture sets. 
More Skiffy Models 
 
Shambles 
Quakespasm already has controller support. I always use it because I much prefer it to mouse & kb. I play my quakes on a 43-inch TV screen whilst sitting back in a comfy chair with a controller.

Split-screen would be awesome btw. 
Well. I Hope For No More Kinn Maps Then. 
#realistic :P 
Wish List 
fog volumes

Decouple Physics From Rendering Framerate

An option to emulate the 8-bit colour look of software quake (with its crunchy banded lighting etc.) in Quakespasm.

Mod menu and Demo menu added to QS

+1

Personally, I'd like to see a nice vanilla episode (or set of four).

In regards to some of the suggestions concerning graphical niceties (fog, lightmapped water, reflections, alpha and other blend modes, etc): fully supporting q3map2 and its shaders would get you all of that. 
 
i would like to have the time in the first place and then the inspiration to release a couple of maps

more short AD maps.

gameplay tweaks for vanilla and/or AD. for example i would have liked scrags that stay in their Z plane and shoot from there instead of flying to the same Z plane that the player. or that they fly above the player instead of towards the player. smarter fiends that don't get stuck, monster that can jump without trigger_monsterjumps 
Better Standard HUD 
I'd love to see an option to show picked up keys on the ARMOUR/HEALTH/AMMO HUD in QS a la Hipnotic and Quoth. Or even show the keys in the top right corner of the screen.

Also, a nice animated face like Doom... It always kinda felt like a step backwards going from Doomguy's dynamic mug to a static image. 
 
I'd love to see an option to show picked up keys on the ARMOUR/HEALTH/AMMO HUD in QS

Quite honestly we need a system to create a totally custom HUD / GUI via QuakeC.

Custom GUI stuff has been criminally missing from Quake since forever, and I think it has stifled mod creativity. 
I'm Actually 
Planning to do a QS fork that adds custom hud manipulation in qc. Something along the lines of WriteByte commands. This for items, weapons, whatever. Someday. 
Also 
There was a discussion a while ago about a way of supporting 16-bit vertex accuracy with minimal changes to the mdl format.

One suggestion kept backwards compatibility by requiring a standard .mdl file, which all engines can read, and then optionally an additional .m16 (or whatever) file which just contained 16-bit vertex information for engines that supported it (hint hint quakespasm) 
Custom Hud Manipulation 
Is a CSQC matter.

I'd be up for a CSQC implementation in QuakeSpasm. 
 
I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both. They're available in Source, so if the features are so important to me I can always just make a Half-Life 2 map, but I've often pined for them in Quake. I'm picturing a classic Unreal-style floating island level, with the sky camera attached to a func_train that gives the impression of drifting slowly over some eldritch landscape as you progress through the map.

Of course I hate to get all "anything I don't understand must be easy"; I couldn't say whether they're realistic desires. 
 
Custom GUI stuff has been criminally missing from Quake since forever, and I think it has stifled mod creativity.

CSQC in Quakespasm.

RMQ engine did that years ago and was actually based on QS. *cough* Spike did it separately as well, IIRC. It has technically been done for years, it's just that the community didn't really want it. Also, mods like Hellsmash definitely had custom GUIs. So does Brood Hunter. So did Scout's Journey when it still ran on the Quake engine. It had a friggin' drag and drop inventory (other mods did as well). Various mods by gnounc were all about custom HUDs. It's been possible for years, it has just been stifled by being "uncool".

There is even a cleancsqc source kicking around, also years old. https://gitlab.com/gnounc/cleanQC_merged

This thread is really funny to read. Suddenly you guys want volumetric fog, reflections, lightmapped water, custom GUIs, particles and all models remade. But Darkplaces etc. are still the Grand Evil. It all has to be crammed into Quakespasm instead of simply using a more capable engine. It seems the requests for features develop at the same pace as certain regulars' tastes (slowly).

Q3map2

I suggested switching fully to an extended (lightstyles...) Quake 3 map format, shaders and IQM models for PCs five or six years ago to the rest of the RMQ team and people looked at me like I was mad. It was mostly that mappers were unwilling to give up using Worldcraft (can you imagine that in 2017?). Instead we got BSP2, which is a hack, and lots of q3map2-like functionality (AO...)crammed into tyrutils lately.

It's really funny to watch.

These particles you always complain about in darkplaces could be fixed in a weekend if someone made a faithful particlefont.tga for the engine. That could have been done 10 years ago.

The cruddy SW-style lighting has been in FTE for years as well. AFAIK FTE got an entire "faithful preset" a couple years ago, even. Why all these things are slowly rotting instead of being used by the community, I fail to grasp. It really must be a comfort zone limitation. Or a pissing circle one.

You got a faithful looking engine with good Q3 shader support, RBSP/FBSP support, CSQC, and Quakeworld support, plus heightmap terrain and shadowless rtlights that don't impact performance too much, custom GLSL support even, and last I heard most of the bugs had been fixed, so what the HELL are you waiting for?

Does it have to do the dishes as well? (Spike probably has that prototyped already.) 
Other Shite I'd Be Up For In 2018. 
Fewer huge, but irregular ejaculations of maps and a more balanced stream of output through the year. Jams are great but somewhere down the line they turned from short "turtle mapping 2.0" sessions into gruelling, multi-month mapping marathons. I'd prefer to have 4 jams with 4 entries each than 1 jam with 16 entries.

Less perfectionism, more releases. Who really cares if a map is rough around the edges. Polish is important but it's become a bottleneck. We could have hit 200 maps this year if it hadn't been for perfectionism.

Less hubisodes, more episodes, playable from beginning to end. Either community episodes or solo ventures.

Conversely to scar3crow, I want more PCs. (Partial conversions, not personal computers, or more of the PC police that bullied skacky away.) Quake hasn't had its own Back to Saturn X or Valiant yet.

More Quoth content. Quoth maps, or Quoth features jumbled into custom mods. I think jam 9 showed that the old friend still has some juice left.

More True Color maps. I don't mean hi-res bullshit, I mean recolored external textures (ne_marb, sm179_otp). There are so many colors that have been barely brushed in Quake.

Some sort of reinvention of the QExpo. qbism was right that the booth/exhibiton format has gone past its expiration date, but some sort of cross-community, content driven event should be a Thing.

New maps from muk, ionous, negke, ijed (ok, too unrealistic), Kell, G1ftmacher, Bloodshot, Nait, and the QUMP team.

New maps from people whom we haven't even met yet.

More banter from Shambler.

Quakespasm 1.0. 
 
Suddenly you guys want volumetric fog, reflections, lightmapped water, custom GUIs, particles and all models remade.

TBH, I, and probably a considerable number of others, don't. 
Also. 
Broken record, but I want our #tf discord emotes as func post icons. 
 
FWIW, personally I don't want a bunch of special effects and whatnot.

On the tech side of things, usability is the biggest hurdle for new (or returning) players. Most of the Quake engines don't have a Maps selection menu or a Mods menu. And actually just the proliferation of different engines and forks-of-engines is a stumbling block as well. No ill will from me toward anyone who wants to putter around on their own personal project, but from a player's perspective the gaggle of all-somewhat-different engines is just a pain in the ass.

On the content side, like Shambler above I'd love to see more medium-scale cleverly-assembled maps. Also connecting a set of maps into a simple thematic and/or gameplay progression is neat. (Really interested to see how the episode jam handles this.)

Of course anyone who makes stuff for this weird old game deserves a pat on the back regardless of whether they cater to my tastes or not! Just throwing in my 2 cents since the thread explicitly asks. 
Jonas 
Actually, take each person individually and they're only asking for a small number of things. It's just everyone has a different wishlist.

I get your point about Darkplaces and FTE already having a lot of this stuff, but I think the unwritten (or in many cases written) rule here is that if it don't work in Quakespasm, it's probably not going to be played by the func crowd.

Personally, just 16-bit verts in models and custom HUD and I'm good to go. Different strokes for different folks.

For example I wouldn't request flashy eyecandy with reflections and shiny shaders. 
 
I wouldn't know what to do with fancy shaders to be fair.

I just want to play Quake using Quakespasm or Mark_V on the couch in DM when I am hosting guests (which is often enough that I'd play it almost every week).

The upshoot of this is that I'd be making more co-op friendly maps and deathmatch levels. 
@Jonas 
Unless or until someone makes the original hud inside CSQC as a base...AND Quakespasm gets CSQC support, CSQC isn't that useful. Also, Darkplaces doesn't have twisty water so it does not count as a legitimate engine as it does not have all of the most utterly basic features. Also, we DO NOT want HD shinovision effects like Darkplaces. We want subtle improvements that align with Quakiness such as AD does. I don't really care to have reflections. 16bit fog would be nice.

I'll add another couple desires:
Square particles for Darkplaces.
Twisty water for Darkplaces.
Fence texture support for Darkplaces and FTE.
Fence texture support on models in Darkplaces and FTE.
Merge MarkV features and Quakespasm and Retroquad into one highly cuatomizable QUAKE (2018) engine.

(Ok this last list is unrealistic) 
#50 Is A Strong Post. 
To be clear, I want more FANCY EFFECTS, but only introduced carefully and subtly as many of the current good ones have been. 
@qmaster 
Also, we DO NOT want HD shinovision effects like Darkplaces.

The eye-melting ass you're referring to is wrongfully attributed to Darkplaces. The blame belongs to the artist who misused the engine's capabilities. This would be the case with any engine. Darkplaces has the capability to look exactly like quakespasm, too.

Square particles for Darkplaces.

a quick edit of effectinfo.txt and particlefont.tga will get you this.

Twisty water for Darkplaces.

a quick shader referencing the water texture with tcMod turb will get you this as well (or something comparable). Same deal with fence textures.

I'm not trying to jump up your ass, I just wanted to correct some misinformation :D 
 
Quake isn't bright enough for anything to reflect. 
"misinformation"? 
Darkplaces has the capability to look exactly like quakespasm, too.

Don't be daft. Quake engines shouldn't need user-made particle fonts or shaders to look like Quake. 
Purps 
Quake engines shouldn't need user-made particle fonts or shaders to look like Quake.

I agree with that 100%. Darkplaces should look vanilla out of the box (still puzzled as to why it doesn't). Fortunately, that vanilla look is five minutes of tweaking away. The 'misinformation' that I was referring to was that Darklpaces inherently looks like this
Killpixel 
would you be interested in making a package consisting of the necessary config settings, modified particle.tga files etc. etc. that people can just download to have DP up and running in a non-eye-rapingly-offensive way? 
 
because looking at effectinfo.txt - that is not a 5 minute fix unless you know exactly what you are doing, and the casual player most certainly will not. 
Kinn 
good idea, putting that on my list. I just did a little test and it turns out I was wrong, you don't need to touch effectinfo.txt. Just drop an any color/size image called particlefont.tga (i used 4x4, black) into id1/particles. However, I would mess around with effectinfo just to get it a little more "quakey". 
Not A Black Image; Medium Gray. 
 
Cool 
Cheers killpixel, yeah a "DP-no-ass" package that can be slapped in the title post of the engines thread would be pretty useful.

Out of interest does DP run ad_sepulcher? Last I checked DP hasn't been updated since 2014 :p 
 
DP has had development since then and has automated builds posted to https://icculus.org/twilight/darkplaces/files/?C=M;O=D

(doubt it can do sepulcher tho)

For me, because DP also changes some behaviors of lighting and physics, it doesn't seem worth fiddling with for "normal" Quake stuff (i.e. not taking advantage of DP-specific features). 
 
@Kinn - DP-no-ass. I imagine that would be painful. But yeah, I would have liked such a mod before QS came around.

@Johnny Law - Yeah, same here. MarkV and Quakespasm fulfill my quake needs.

anyway, I won't clutter this thread with DP related suff anymore (apologies). 
Johnny Law 
DP has had development since then

Good to know. The latest Windows 10 update has completely trashed mouse input in the 2014 DP build (same way it trashed mouse input in earlier versions of QS, but the latest QS has that fixed), so if the latest DP has fixed that, that's welcome.

But yeah, as a player, I can't really think of a reason why I should use anything other than Quakespasm. It feels right, it looks right, has proper controller support, and runs cooler on my laptop than any other engine by far - seriously, the fan doesn't even come on ever with QS, whereas it's blowing like a jet engine with every other engine I've tried - what's with that? 
 
- A digs map.
- Release one or two maps myself.
- Halo Forerunner-themed mapjam
- Silent Hill Otherworld-themed mapjam
- uhhhh.... 
 
More solo releases. From myself or others.

Shorter jams with stronger themes(not that theyve been lacking lately). More than "use this texture set"

Id love to see people talk more openly about their design process. I included a changelog in my xmasjam entry and this is something Ill continue to do and then some. 
 
Isn't the other issue people have with using DP the fact that it's pretty incompatible? Like, aren't there a bunch of cvars you need to change to get it to behave sorta like regular Quake, physics wise?

Something I want to do in 2018 is release a map that I'm proud of the gameplay for, and not just the visuals. Preferably as a solo release. 
 
An improved model format. I don't want fancy features, just better (preferably floating point) accuracy on both vertices and texture coords. Normals can be easily reconstructed if needed (the original code in modelgen.c is a good base to work from).

What I'm talking about here is the equivalent of a BSP2 for MDLs. BSP2 had no fancy-dan features meaning it was easy to implement, meaning it actually *was* implemented, meaning it succeeded. Adding extra features - "can we have skeletal animation/multipart models/detachable limbs/32-bit skins/etc" - just increases the complexity of implementing. There are already plenty other formats that support those features - go implement one of those instead. What I'm talking about is a format that does what MDL does, does no more than what MDL does, but with better accuracy and raised limits. 
Improved Model Format YES 
Yea for me this is why MD3 would be a good one or IQM which has bone support! As for some new format be careful because that can get tricky with supporting proper exporters for various art authoring tools. Something that can convert an FBX file to this new format would be a good middleground since tons of software can export to FBX. 
 
#24 Retroquad 1.0

Definitely not happening in 2018.

#26 Lightmaps on liquids

I've tried encouraging other engine coders to implement this in their engines, I've showed how to properly detect if a map was compiled with lit liquids, EricW coded full support for lit liquids in his compilers, but other engine coders were against it.

Mappers were also against it, by shutting down my suggestion of enabling lit liquids by default in EricW's compilers because not all engines supports it, despite there being no side effects in engines that doesn't support it. Interestingly, not all engines supports translucent water either, but nobody complains about translucent water being enabled by default.

Darkplaces does support it, and FTEQW probably does too. What's funny is, even if someone maps for DP, they'll never casually find out that DP does support lit liquids, because the map compilers won't lit the liquids by default.

If lit liquids were enabled by default, we'd have dozens of new maps using it already, and people would start to figure out how to take advantage of it in their maps.

So, it's not going to happen. People are against it. 
 
No, please. Give me lit water. My maps look like ass without it. 
@Mankrip 
is your engine going to be released in 2018? 
 
Well he calls it retroquad... so looks like a nope for 2018 release. 
#73 
Yes, that's what I'm thinking too. Easy change to the engines. Easy change to the mdl exporters. Just mdl with better precision. 
2018 
Engine stuff:

I guess weather supported across the engines. An implementation where you can just stick a weather entity in a map and tell it to either rain or snow! QSS works really well of course!

Another vote for fog brushes.

Maps:

I'd also like to see less huge hub-like maps and more dense and original designs. Small episodes or just plain ole medium sized individual maps would be a fun change of pace. I also agree with some people saying about more focused jams with strong themes vs texture usage or one gimmick.

Themes:

Hmm I don't know, the fun part about that is mappers constantly come out with crazy cool ideas. So I suppose let's just keep doing that! I know I would like to release at least one episode myself personally. The Episode Jam will be a nice early year treat I hope! ;O 
#48 
I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both.
Not exactly 3d skyboxes but one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense. 
Lit Water 
There's always a stick in the mud somewhere, especially when it comes to engine or mod coding, it seems.

I hope we do get to see lit water in 2018, especially since on paper a lot of the issues have been sorted out. Perhaps we'll see it in a QS fork, or perhaps even in QS itself...

I wonder how much of the pushback against it is because it's supported by DP and no one wants to be on the same side of an issue as DP ;p 
 
...one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes...

I'd love to see that. I brought it up during RMQ development but it was shot down at the time. The idea I had was that you could have 2 or 3 layers of skyboxes and blend between them, so you might have a rotating "clouds" layer and a static "scenery" layer, or whatever. 
MDL Support 
If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.

.MDL (Source Engine)
====================
Pros:
Skeletal anims
Morph anims
Higher precision
Multi-skin support
Uses qc (wierd am-I-right?)

Cons:
Difficult to create
Pipeline is horrible
Creation is not streamlined (okay so that's really only 1 con)

FBX:
======
Pros:
Skeletal anims
Higher precision
VERY common, de facto Standard

Cons:
Proprietary so there is limited support in some tools (still avail. in Blender)
No morph anim support 
Lit Liqs 
Need engine support in the trinity of Quake engines: Quakespasm, FTE, and Mark V.

+1 
QTWID 
- Quake the Way id Did
- optional PS1-style vertex jitter
- +1 for gameplay mods 
 
#77
See #75.

#31 Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though.

Super8, Engoo and MarkV already supports alphamasked models, and Quakespasm likely does too.

Glowing eyes and flowing lava can be faked by using fullbright colors and animated skingroups. Animated skingroups are part of the original Quake MDL specs but were never used in the main game, so most people aren't aware it exists.

IIRC, support for animated skingroups was broken in GLQuake, but custom hardware-accelerated engines fixed this ages ago.

What I don't remember is if animated skingroups supports custom timing, like animated framegroups does.

Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...

Lit liquids with luma textures can break the tiling. But again, lit liquids aren't going to happen, and I don't know if MarkV and Quakespasm supports luma textures.

I second more advance water volumes that accept lighting and foam.

Foam could be faked by using "negative dirtmapping" on lit liquids. Dirtmapping makes surfaces darker at the edges, but if it suddenly cranked up the lighting at the edges all the way to fully white instead, it could look pretty close to foam.

Even without negative dirtmapping (which could also be called "foam lightmapping") in the light compiler, this could be faked by manually placing lots of tiny lights on the liquids.

The other sensible way would be to implement texture crossfading, which I'm going to do in the future (at the moment I'm faking it through soft depth), but I don't know if any of the other engines supports it. Also, each engine (Q3A, etc.) does texture crossfading in a diferent way, and getting some consensus on standards for such things is near impossible given how different each Quake engine is today. 
Simple Quake Launcher By MaxEd. 
I'd like to see it included with new releases of source ports. It would lower the barrier of entry massively for newcomers who don't know how to, or even want to, create shortcuts and BAT files.

A simple front-end for loading maps should be a no-brainer in this day and age. :) 
#85 
If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.

I suggest neither. Any additional complexity is a barrier to implementation. What most people really want is just MDL but without the vertex dance. Better texturing comes second. 
 
What most people really want is just MDL but without the vertex dance.

Exactly. Cuts to the chase. 
Models 
either md3, iqm, or its a waste of time - the tools are much more important than the format itself, and bsp2 meant the same tools could be used (or at least the user-visible ones).
mdl tools pretty much universally suck, worse - the main one that people seem to use is closed source.

md3 already works in qss(r8), fte, dp, ezquake, and _multiple_ others. And there's been at least one software-rendered engine that supported it.

iqm works in fte, dp, and rmqe... and oh noes! quats! flee in terror!

So yeah, md3. Trying to push some other format is pretty much pointless now, especially as there's ALREADY two 16bit q1mdl-derived formats (that noone uses). q1mdl just isn't worth it, imho, especially when the various incompatibilities will persist regardless. 
Wait, What 
I didn't know QSS already supported md3.

That hugely increases the chances of it being implemented in other similar engines then. Just need some md3 content, and I'm sure increased support will follow. 
 
Maybe the lovely chaps behind the AD monsters could export some md3 versions of them? 
Md3 
a couple exporters exist for blender that are still maintained and there's enough literature to get you rolling quickly. tags are nice, too. 
Spiked 
I'll admit I haven't looked at QS-Spiked (or really anything quake) for the better part of a year - does QSS support crunchy pixel filtering on the fancy particle system yet? 
@Kinn 
yes, 'nearest_texture foo.tga' instead of 'texture foo.tga', though I think it requires ALL foo.tgas to use the same type, which is a bit annoying - I didn't tweak QS's texture manager code that much. 
Cool Beans 
 
Shambler Is MD3... 
My shambler model is exported to MD3 and then converted to MDL in my pipeline... sooo I will have to give it a try in QSS... did not know it supported it ha. I just want bones support to have nicer arching clawing animations. Animating at 10fps with vertex interpolation makes for some wonky sweeping movements. :P 
Lit Liquids Will Happen Despite Mankrip's Best Efforts 
(At least I hope so) 
 
#49 It has technically been done for years, it's just that the community didn't really want it. Also, mods like Hellsmash definitely had custom GUIs. So does Brood Hunter. So did Scout's Journey when it still ran on the Quake engine. It had a friggin' drag and drop inventory (other mods did as well). Various mods by gnounc were all about custom HUDs. It's been possible for years, it has just been stifled by being "uncool".

I'm of the simple opinion that it's about workflow.

CSQC is incredibly complex, because it was made to interoperate with Quake's client/server architecture and stuff like physics and AI. People who just want to do simple stuff like making the Ranger face animate in the HUD feel overwhelmed by all of the extra complexity that they don't need.

Custom HUD and GUI coding needs to be as simple as possible. There's no need to create a whole dynamic programming language for it when the user just want to do some tweaks. A static definition format, like a simplified CSS, would be enough.

The power of CSQC lies in massively reducing network traffic, and allowing the creation of really complex works. Its learning curve is too steep for simple cosmetic tasks like "display that icon at position xy if this bitfield is set".

#81 one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense.

What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.

#90 What most people really want is just MDL but without the vertex dance.

And a big part of the vertex wobbling happens because the animations are not skeletal. Animating models without skeletal animation is a living hell, because anything that rotates gets distorted while interpolating. Swords gets shorter, tubes gets crushed, etc.

As Spike said, the tools are much more important than the format itself, and bsp2 meant the same tools could be used. People create Quake maps because the tools are good and they have fun doing that. But creating Quake MDLs is a pain. 
MDL Is Easy Enough 
Odd way of saying it... Making monsters is simple for me compared to making a map. But you do end up using tools like 3dsmax, Maya or Blender for modeling and animating. I myself use 3dsmax. I do all my painting using 3dcoat which makes the task of painting the texture in 3d a breeze. Again not a free tool. Blender does have a very good 3d painter as well.

As for converted to MDL, I just export every frame from 3dsmax as a new mesh and then use Inferno's MD3 compiler to make the model. Then I convert the MD3 to MDL and inject the correct textures I want.

Everyone has their tools chain they need to run through. Making monsters or enemies does require a lot of other knowledge that has nothing to do with the tools change. Good mesh construction and unwraps, a sense of form and anatomy, good color and design. Making your own animation rig that is easy to use and deforms well. Good animation! Sense of weight and timing for those attacks and run animations which are seen most of the time by the player... Just different interests is all.

I should just make a video showing my workflow to get a model in game I guess. Tons of resources on making maps for quake but very little when it comes to making MDLs. 
 
2018 is the year I want to properly learn 3d model making for quake. Any tutorials would help a huge amount 
Fifth 
This was posted last year sometime by the author. It's a solid tut that I found very useful (if you're out there, thank you).

Are you looking for quake-specifc modeling tutorials or just modeling in general? 
What I Want 
... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.

Mark V has an option to enable it, but it doesn't work properly on viewsizes higher than 100 (WQ didn't keep it consistent either, but imho this should be fixed, and I've fixed it in Makaqu).

Seriously, this is my main problem with most Quake engines. This is what makes most engines feel wrong for me, because the weapon is displayed the whole time and I can't avoid noticing that its not where I expect it to be.

Also, I like how the on-camera position of the weapon changes when looking up and down in WinQuake's viewsize 100. This happens because the weapon is higher in world space, not in screen space, but I remember that there's an engine that uses screen space instead of world space in its higher weapon position option. 
Ok Then 
QSS to be merged into master. 
Hardware Accelerated Vis Replacement 
This is an idea I had some time ago.

Draw the entire world. Pick a leaf to be the viewleaf. Using occlusion queries determine which other leafs are visible from it, from all 6 directions. Read back the results, that's the PVS for the viewleaf. Pick the next viewleaf, repeat until done.

Vis time should become linear, with no more weird extreme cases.

Vis time should no longer be a function of geometry complexity.

PVS should be tighter and nonsense like geometry half way around the map being included should go away. 
@mh 
Occlusion queries?:
•Raycasts? 6? Would be woefully insufficient. In a room with 4 world columns in a square in the middle, the 4 corner leafs wouldn't get drawn when you stamd inside the center leaf in the square space between the columns.
•6 Renders - ortho? Possibly if each leaf is assigned a different color. 
#108 
Nope; nothing to do with raycasting; using the GPU for rendering to a small enough viewport - 256x256 should be sufficient - do 6 standard renders with 90 degree horizontal and vertical FOV for each. For each, run a bunch of hardware occlusion queries to determine samples passed for each leaf. Any leaf with 1 or more samples passed is visible.

This is nothing to do with raycasts and nothing to do with any software-based approach; it's pure hardware using standard rasterization techniques (that have been available since OpenGL 1.5) based on similar thinking to that used for shadow mapping. Because if you think about it, shadow mapping is just an occlusion/visibility problem so the same thinking should be able to apply to the more general case of determining actual occlusion/visibility. 
 
That sounds like it could massively improve vis quality in big outdoor Tronyn-style facemelters. 
Not Sure If This Realistically 
but i'm still waiting for a something new from Kinn

@Kinn , there's a TF discord channel, if you're willing to join to https://discord.gg/P56HXr 
 
... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.

Mark V has an option to enable it...


Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

It'll probably never happen in DP because Religious Reasons. 
Episode 1 Remake With AD Bells And Whistles. 
I'd love to see the top tier mappers start a project expanding on the shareware episode maps the AD's extra beastiary and projectile weapons.

I want to play E1M1 with the Widow-maker, dammit! 
#101 
What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.
Hey, that's pretty neat. At risk of sounding like a complete moron, what exactly causes it to be a pain in the ass? I'm sure it's somewhat difficult to make it look good, but honestly, any sort of happy medium between the standard tiling two-layer skies and the static but six-sided skybox textures supported by newer engines would be fantastic. The extra detail given by the skybox is great but given how lively some Quake maps tend to look within the play area itself, the completely stationary skies and backgrounds can sometimes stick out like a nailed thumb. 
#114 
...what exactly causes it to be a pain in the ass?

I assume that's specific to the software renderer. In hardware it's just some cubemaps and some texture matrices. 
 
#112 Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

Thanks, I've found it now. There's no menu option for it in QuakeSpasm, and I usually don't bother searching through cvars in game engines anymore, so I didn't notice it was implemented.

After enabling it, paying in QuakeSpasm got 200% better for me now!

#114 what exactly causes it to be a pain in the ass?

The zero-overdraw architecture of Quake's software renderer is incredibly monolithic and gets in the way.

In my implementation, each side of the skybox is vertically cropped twice, one time for the fully opaque section of the image, and another for the section that contains some transparent texels, while the fully transparent vertical area of each side if fully cut out. The fully opaque section gets drawn as an opaque surface, and the rest is drawn as an alphamasked surface.
Also, the background layer's sides are cropped from the bottom of the alphamasked portion of the foreground, to the absolute height of the skybox.

Dynamically resizing surfaces like this, specially when all of them are shared by the same cube, causes complete chaos in Quake's monolithic BSP architecture.

The hybrid skybox implementation in previous versions of Retroquad was far simpler, resorting to much more overdraw, which is much slower. 
Spawnflags For All 
I noticed that some universal flags like Not in ... don't work for all entities, even though they work for entities that aren't documented as having them in .fgd and .def files.

How hard would it be to do this without mods so i can use an existing mod that i have no source for? Or is it better to leave that to mods just in case someone used those flags on theirs? 
MH: 
Unless I misunderstand, it seems like there are two issues with that idea. First, there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts but never eliminated. Second, leaf PVS has to be valid for all points within a leaf, while any raycast-based system will be treating the leaf as a single point (or a small number of points) 
 
...there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts...

I really don't understand this part, and it's second time around.

Why the fixation on raycasts?

I'm not talking about raycasts.

Forget about raycasts.

There are no raycasts. 
 
isnt a "sample" in a hardware occlusion query effectively a raycast? I admit to not knowing the tech behind it. 
How Do You Know What To Render In Your 6 Renders? 
Unless you raycast for each pixel or something? 
 
If, however, you assign a unique color to each leaf and render flatscale color into a buffer, then parse each render to see what colors are visible... 
 
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_occlusion_query.txt

Occlusion queries use the depth buffer. Raycasts are absolutely nothing to do with it. 
 
In full HD, surfaces smaller than 7*4 pixels would be invisible. 
I Want To See More Infighting With Tarbabies. 
And raycasts, lots of raycasts. Whatever the fuck they are. 
HUD, Scripting, Water 
+1 for new scripting system
+1 for flexible HUD

Movable liquid volumes. Like turning a water brush into a func_door I could lift to flood an area. I understand that it envolves translating a volume where special physics and render takes place in runtime, but how hard it is to do? 
Oh And +1 For Lit Water In QS 
spy, cheers I might visit that discord place as long as it's not full of weird porn like the irc channel was. 
A Proper 
comprehensive co-op mod, with a selection of purpose-built maps by the community and an easy way to play online with friends who aren't really bright enough to play anything that's not on Steam. 
Unrealistic Request 
This basically requires all engine authors to agree on a feature so hahahaha, but anyway one thing that has always peeved me is how mod folders all have to be a child folder of a main quake (engine) folder.

When you have hundreds of mods, taking up gigagbytes, you only really want a single instance of your mod collection to exist on your hard drive.

This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.

Yes, of course you can create a separate Quake folder for each engine, and duplicate all your mods across each of these, but as I said earlier, that rather sucks, can take up too much space, and it soon becomes a synchronisation nightmare.

I guess what I am saying is it would be great if you could tell any engine to reference a mod folder that's ANYWHERE on your drive, so you can just keep your mods centralised and separate to the engine installs. 
 
This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.

Sorry I should have clarified a bit more - this sucks arse mainly because it becomes nearly impossible to then later remove a particular engine when they are all dumped in the same folder because all the dlls for each engine and other secondary files are all just mixed up together in one massive unorganised clutter, and you don't have a clue what can be deleted. 
@Kinn 
Any decent engine will still respond to the -basedir argument (otherwise the vanilla behaviour is to use the working directory).
You can then install your (decent) engine inside some subdir and then tell it to use the parent dir for content.

Note that this won't help when it comes to the numerous config.cfg file conflicts. You'll need homedirs or alt-config hacks (eg: fte.cfg) for that, which is still ugly.
There's probably still a few other conflicts too (like console input history), though I don't think I've seen any such issues more serious than config.cfg conflicts.


Unfortunately a few engines are buggy and force the basedir to where the exe is (regardless of working directory), and in doing so ignore the -basedir argument.
You can create symlinks as a workaround (or reparse points on windows), but as this is per-mod-per-engine then its just annoying to do unless you want to spend a while creating some kind of fancy script to maintain them for you.

Tbh though, if a dll isn't backwards compatible (and didn't get renamed) then that library just sucks, or whoever built it does.


And then there's a few engines where all the important stuff is statically linked so that it works even with no messy dlls at all! 
Spike 
Thanks, I now feel like a right knob that I typed all that out without knowing about -basedir. 
 
afaik, metl's concerns in #118 are still applicable to rasterization / occlusion queries. The visdata is supposed to be valid for all locations within a leaf's volume and all camera angles, so if you generate it by sampling a few camera positions (or just the center) and a few angles, and rasterizing, false negatives will be possible (homs/grey flash).

I still think it's a cool idea worth trying, the question is just how many views (camera positions/angle combinations) you have to render to make the false negatives a non-issue. I don't have any sense of how fast it is to render these 256x256 (say) views and doing the occlusion queries. If you budget 1ms per leaf, that would give 64 second vis time for a 64k leaf bsp. I wonder how many FPS for rendering these views would be expected on a decent graphics card.

e.g. this would allow vising ORL's latest pack which has unvised maps.

PS the "showing the other side of the map" bug is fixed as of v0.15.10 of my compile tools, as far as I know the only cause of that symptom was the way func_detail was added to qbsp. 
@Kinn 
Was just lurking and spotted this. If there are issues using -basedir as Spike alluded to, you could always use Symbolic links, not sure what OS you're on but they're fairly easy to setup. 
Kinn. 
I've saved some especially for you, there's a secret sub-channel specifically for that stuff :) 
Ericw 
How many camera positions does vis compute anyhow? Or does it figure out how many positions to account for and only compute those?? 
Also 
It's funny how a lot of people's requests are already possible or exist. We need this sort of thread more often to help spread the word. 
Hey Kinn, Who The Fudge Said Engines Need DLLS? 
Who the fuck says an engine needs DLLs?

WinQuake doesn't need DLLs.
FitzQuake 0.85 doesn't need DLLs.
FTE doesn't need DLLs.
Mark V doesn't need DLLs.

The idea of needing DLLs is a shitty LINUX concept.

LordHavoc was a Linux user when he made DarkPlaces. The original Quakespasm authors (not ericw) were Linux users.

Linux ideas like DLLS and OGGS should be rejected and shunned.

NOT normalized, like a dopey person would do.

Don't be a dopey person. I'm just saying. Who the fuck said engines need a folder full of shitty DLLs?

Well -- answer: Linux people who do not use Windows.

In fact, in the compile tool chain for Linux friendly engines there is a static linking option that would eliminate the DLLS.

Demand better! Don't buy into the "need to have shitty DLLs" way of thinking. It's a lie.

/Against my better judgment I click submit! 
+1 For DLL Free QS/QSS 
That would make updating so much nicer, as well as having multiple engine/single directory coexistance. 
Kinn 
I might visit that discord place as long as it's not full of weird porn like the irc channel was.

no worries, the nsfw channel's hidden now 
OH, Another Thing I'd Like To See In 2018 
is some sort of new visual thematic. It seems like the past 4 or 5 years have been dominated by mashups or updates of old themes. I'd like a comprehensive new texture-set that stands up on its own and looks just as good in a vanilla engine as it does in one with advanced features. 
@Baker 
DLLs are, of course, a Windows (and OS/2) thing. On Unix and Linux you have .so files. The concept of shared objects and libraries is present in any modern operating system. A vanilla install of WinQuake comes with:

GENVXD.DLL
PMPRO16.DLL
QUAKEUDP.DLL
WDIR32.DLL
GETINFO.DLL
PMPRO32.DLL
WDIR16.DLL

No idea what connection to Linux you see there.

Also, as someone with a Xiph.org connection a few years ago, I hereby kindly request Ogg Vorbis support in all engines ;-) (or, perhaps even better, Opus support - awesome for music, sfx and voip). 
Aye 
Yeah, was gonna say WinQuake also had its fair share of dlls too.

Anybeans, now that I have discovered the sheer wizard magic of -basedir, I'm keeping all my engines quarantined in their own individual folders and the dll thing doesn't bother me now. Others' mileage may vary obviously. 
#42 
reading the documentation i see that AD already has what i said in #42 about scrags, and possibly demons

the third thing would be level-aware monsters, but in some ways they would start acting like multiplayer bots, so i don't know... 
+1 QS With DLL's Baked Into The Exe 
 
Topher 
If you are asking for enemies that are aware of the player since spawn, that exists already. Just trigger them with a trigger_once on the player's spawn.

If you want proper pathing enemies, necros ne_dynamic mod does that, plus some more things. 
And 
Scrags that don't move on z axis with clip brushes. And the player will never notice if he can't reach that height.

Smarter daemons: slopes instead of stairs, abundant use of clip brushes, no low ceilings, complement on axis walls with 45º ones, and a lot less doors or make them as wide as the rooms they connect.

Monsters that jump without monster_jumps can be achieved by making them land on brushes too small for them. This can be repeated with the brushes below them and to the infinite. 
Higher Resolution Wizards And Flying Daemons... 
Currently, the Quoth/AD wizards, flying daemons and minotors have a poor resolution mesh. They don't look as good as all the other monsters (especially the default models).

I think they need some love. 
#144 
AD has vertically-aware ogres that can aim grenades at anywhere.

Oh, you mean path-aware, not height-aware. I second the notion that they'd become bots.

It could be interesting to have area-specific waypoints to help monsters battle around their intended place without hunting the player through the whole map. When you leave the area, they'd stay back waiting for you. The concept of territorialist monsters is cool indeed. 
 
r_softwarebanding from FTE in QS and QSS please please please? :} 
Muk Finish His Honey Map And Medieval Map And Ikwhite1024 Map The Cunt 
 
Some New Quake Machinima... 
Or, at least, some cool cut scenes like the good ol' Zerstorer or Malice. I miss that cheesy, clunky but utterly charming style of animation. :) 
The Marcher Fortress Strikes Back 
I can dream can't I?? 
Baker 
I'm a filthy linux user. Is the argument for external libs not an argument for ease of upgradability?

If my SDL libs are statically linked into the executable, and I want to upgrade to a newer version of SDL, I need to recompile my whole game.

Also on my wishlist for this year is for Baker to incorporate my IRC mod into QS master... Oh wait... Realistic, that's not going to happen with my coding skills XD 
 
If my SDL libs are statically linked into the executable, and I want to upgrade to a newer version of SDL, I need to recompile my whole game.

I think that's the promise, yes. The reality is that never happens in real life settings. 
@mankrip 
It could be interesting to have area-specific waypoints to help monsters battle around their intended place without hunting the player through the whole map. When you leave the area, they'd stay back waiting for you. The concept of territorialist monsters is cool indeed.

AD has this functionality, although I have not tested it. It's a "tethering" system. Don't have the entity info handle but Simon mentioned it was used in ad_tfuma I believe. It sounded pretty handy. 
Dumptruck_ds 
That depends on whether this tethering system works as waypoints (chained paths) to also help the monster navigate the area. Vanilla Quake already had waypoint-style paths for patrolling, so that may be the case. 
 
I've always wanted to do a Quake mod that was basically Left 4 Dead, in that there was a director written in QuakeC that just spawned monsters as needed. I don't know that it would be all that hard ... sort of like Qonquer, but with more intelligence. 
 
My concern with that kind of mod is that you really lose a lot of what makes Quake work - that being hand crafted encounter design. Having the computer spawn enemies for you to fight means that you can't design combat scenarios that are tailored to the environment the player's fighting in, which takes away a lot of the variety of gameplay.

Quake really isn't a horde combat game. 
 
You could mix it. Hand crafted encounters with director filled areas between set pieces ... 
 
I think it's weird now because AD is the defacto version of Quake we play ... but that means you can't run any other mods alongside it. Hmm.... 
 
I think it's weird now because AD is the defacto version of Quake we play'

No, it's just a mod like any other. 
I Don't Play AD. 
Quoth is still my Quake mod of choice. AD has tried too hard to harmonise (for lack of a better term) Quake's thematic in a fantasy direction, and in doing so has lost what I always really loved about Quake, which is the thematic dissonance. Easy example: I like seeing sci-fi health boxes in a medieval castle.

I have played some AD and it's very well made, but to me it will never be Quake, because unlike Quoth it changed Quake rather than simply adding to it.

Anyway, back on topic, Warren I have also dreamed of a Quake/L4D mashup for a long time. I envisage the director choosing between some pre-crafted encounters (and scaling them) in response to the players actions. You would also need to add a few new enemies, such as fast grunts with melee weapons and mini-bosses that have to be attacked from multple directions, etc. 
AD 
Was never meant as a replacement or even an upgrade. AD is it’s own thing, there will still be new maps for quoth and other mods.
AD is definitely the most polished mod though, I’m proud to have been a part of the team 
 
Rubicon 2 style AD episode is my wet dream 
That would be rather lovely. :) 
Quoth Vs. AD 
I'm glad we have both to choose from. I tend to learn toward AD but I do enjoy Quoth. I have only made one map for each and I have to say the entity state system for AD and the DelaySpawn spawn flags for Quoth gives mappers so many more options with encounters that you could really simulate the LFD gameplay Warren is talking about. 
Quoth Vs. AD 
I'm glad we have both to choose from. I tend to learn toward AD but I do enjoy Quoth. I have only made one map for each and I have to say the entity state system for AD and the DelaySpawn spawn flags for Quoth gives mappers so many more options with encounters that you could really simulate the LFD gameplay Warren is talking about. 
+1 For Spike FX In Official Quakespasm Release 
I'd really like to see this happen as well. Ever since The Forgotten Sepulcher I'm always trying to play the latest releases (and older) with these effects. Would be nice to just have a toggle option in menu instead of moving files to the AD folder and risk breaking stuff lol

Hopefully if this DOES become a thing they include all the cool effects (armor, items etc) borrowed from the AD mod.

Noticed there's not many Quakespasm videos (let alone spike) on YouTube so I recorded some coop gameplay yesterday with a friend playing QS spiked https://youtu.be/hxcbEliwpxQ 
Don't Play Quoth Or AD 
ID1 for life.

I'd like to see more rule 34 ranger art.

Seriously though, just more maps is fine, and 2017 was already great for that. 
1 post not shown on this page because it was spam
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.