Would love post-processing options. Even basic color tinting to high, low, and mid values would add so much power.

Proper height fog would also be nice, instead of just distance fog. 

progs_dump 1.1.0 RC3 has persistent keys so you can use multiple gold / silver key doors with the same key (as in DooM.) 

I mean being able to have different kinds of keys instead of multiple gold or silver keys. It's something that I think would be cool. 

some example maps of way back when you attempted to create those BSP-supported trees still available?

I had a look but I only keep the last 5 iterations of any given map, and that old stuff has long been cast into the digital abyss.

To reproduce, just go as far as you can with obj2map buggery of organic mesh structures and see how far you can get before it starts causing problems that make you think "this is such a dumb thing to be doing using existing q1 tech". 

So let's keep in mind that engine features should be thought out with engine standardization in mind while mapping features only rely on progs distributed by third-parties.
Some mapping features are not worth to "hard code" into engines imho 

Yeah the idea is to come up with ideas for obvious (and realistic!) engine features that would get a lot of use and deserve to be widely adopted on all engines, not just the niche "eye candy" engines that none of the mappers here seem to be interested in. 

That sounds like a feature that would sit great within the existing quake vibe, and in fact enhance it, like the distance fog does. Literally every map now uses distance fog and I would imagine height fog would be similarly popular. 

Is this different than volumentric fog or an updated way of referring to the same thing? 

While height fog could fix this a bit, i would be interested in seeing real fog, one that needs to be lit and in which the increase of fog per distance and the formula can be changed like with lighting attenuation, as it is now it looks cool, but the fact that has nothing like real fog save if i make it real thick or light the entire map strongly has made me not use it ever, even after trying on several maps.

On the other side i see the current one good to use as a sandstorm/heavily concentrated dust, or as darkness to make it look like the player lights around. 

Fog volumes could also be nice, but that's different.

@cocerello are you talking raymarching fog? Or some other tech? 

What I would like to see in Quake, are rain effects (like in AD Sepulcher under QS Spike), realistic snow storms, thunderstorms and lightning effects. More realistic fire and smoke...

And better looking trees and bushes. 

Can you lot stop beating around the bush and just rename this thread "Stuff we want in Quakespasm because it's not like any of us are ever going to give a shit unless it's in Quakespasm".

May as well at least be honest about it. 

"honest" says the anon 

As I've said a number of times now, it's "Realistic ideas for engine features that would be broadly popular amongst the contemporary mapping community and thus have a good case for being standard across all engines in the same way that coloured lights and distance fog are".

Not sure if thread titles can take that many words.

May as well at least be honest about it.
Thanks for that advice, "anonymous user". :ohtheirony: 

beaten by dumptruck! 

Rotating skyboxes?
Multiple skybox layers (e.g. cloud layers) with ability to independently rotate the layers?
Lerp different skyboxes over time?

Just shooting the shit here... 

I forgot about that, was totally on my list to ask for! 

I do not know what would be required, but probably not much of a change, but i do not know much about code.

I am talking in results' terms, so i will use examples instead:
- In my last map, i put on a side of a big room a hole from where an enemy will ambush the player and another with some items, so i kept them in the dark so they would be harder to spot, but with the fog on, those holes are lit by the fog because it is always lit like water, making the hole stand out with light instead of being hidden. And there is no way around save for making the fog almost non-existant, as if i darken the fog it will no longer look like fog and i would need to turn it almost black to achieve it.
Another side of this is that darker parts stand out in general more than bright with the fog on, so the fog needs to be dark like dust clouds like in most Quake maps, or to be used to blur the farthest parts of the map like in honey.

- Another is that fog is a lot thicker in real life and more sudden, and with this linear attenuation, it end up sticking out more in the corners (because they are further) and not working for anything else apart from blurring the horizon, or block most of the line of sight if made a bit thick. Also if intended to be used as fog most rooms need to be of similar size and the rest way different and even with that it still does not look like fog. If we could change the attenuation (best would be something like a logaritmic formula where the distance at which it begins can be changed), there would not be even a need for height fog or fog by area, as we could work around it to make it look as intended in each room with a global key.

If i think about it, i still have not seen a Quake map with fog, only blur in the distance, dust in the corners, or tricks with darkness like OTP did in mapjam1. 

I've added new request that would benefit from input of mappers. It boils down to "it would be nice to have a single map that works on engines with and without new features". Technical details are here:

https://github.com/quake-mapping-community/quake-engine-features-wish-list/issues/4

On the topic of fog - I'll have a look at the ability to define arbitrary volumes in the map and specify what should happen in those volumes (e.g. sepia tint; green fog within this volume; etc.). Initial implementation would make it impossible to have crossing volumes (well, behavior would be unspecified) but ultimately I think that falloff around the volume edges and interpolation between adjacent/crossing volumes would be a must. Does this sound like something that directly answers your needs? 

Engine feature requests typically fall into 3 categories.

1. "I really should be using the Q3/HL/whatever engine but I don't want to for some reason. Can you port this feature from it to Q1 so that I can continue not using it?"

This is an arms race nobody can win. Better off working on resolving the reason why the mapper doesn't want to use the other engine.

2. Stuff that's actually content rather than tech. No further comment necessary.

3. Vague, ill-defined stuff; it must be "Quake-ey", if must be "subtle", it must be "tasteful", but it's never actually clearly stated what it actually is. This is also a waste of everybody's time as chances are nobody's going to be happy with the end result.

Getting into detailed discussion about how something might be implemented and how it might interact with light/etc can be useful, but it can also be useful to just throw a working prototype together and see how it looks. Chances are it might look just fine, but even if it doesn't you've now got something to work from, rather than spending more and more time on complex and arcane discussions with nothing to show for it.

The best engine features, the ones that last, are in response to real problems that mappers are actually facing. "How do I deal with format limits without compromising my vision?" "How do I have animated lightstyles on the entire world without performance that sucks?"

Pie-in-the sky wishlists are fun and novel ideas that might otherwise never happen can and do come from them. But mappers - people actually, currently making maps - also need to be talking about what problems and frustrations the Q1 engine is causing for them.

My challenge is: list the one major problem you are having. Don't say what you think the solution is - the actual solution might be something completely different - say what the problem is. If somebody needs to ask "but what would this actually solve for you?" you're probably doing it wrong. Be as specific as possible. Help engine people to actually understand what you actually need.

Enough people do that and we should start getting a nice idea of what kind of engine features are needed to be more useful to mappers. 

Well, firstly I disagree with your "3 Categories" - the most common category I think is this:

"I think it would be awesome if I could just do this one, particular, extra thing, which Quake currently doesn't do, which would really get me excited about making new stuff for Quake."

These people have 99% of what they want in their engine of choice, and are just wondering if they can convince someone to implement that extra 1% of stuff.

They don't want to make a massive Q3 total conversion, or a HL total conversion, they just want to carry on making Quake stuff but with a little extra "something".

As for the second part of your post, I agree with the basic gist of it. An engine request has pretty much zero credibility unless the mapper has thrown something together to prove that he can talk the talk and walk the walk, and a programmer takes a look at it and thinks "yes this rather nifty content that actually exists would really benefit from that one extra thing that the creator would humbly like". 

I'll take the bait.

I am frustrated with the music limitations in id1. I need the ability to play a music track with a unique name.

https://github.com/quake-mapping-community/quake-engine-features-wish-list/issues/5 

Feasible and "correct":
- Add/improve support for X base file format (mdl, iqm, midi, mp3)?
- Add support for a Y way of incrementaly adding mods without having to fuse and recompile a few mods together
- Support for Z basic feature in CSQC

Infeasible and not quite a fit:
- Add support for X flashy effects, shaders, physics
- Add models or Y mapping capabilities for vanilla quake
- Support for Z game engine features in Quake

I think the infeasibility lies on whether the feature should be something particular to a sourceport or something that can improve/add to quake engine across all engines (such as tooling or better control over existing features). Or even extending existing features to allow basic game features such as an user interface. But when you go into the are of flashy effects, models or brushes you should look into engines or mods that support that.
I know it can be a gray area sometimes but I think the "vanilla" mindset should overcome the desire to add that-new-thing-that-engine-or-game-has.
Take a look at Doom foe example. ZDoom is treated as the standard, but it won't support advanced lighting effects, 3d models, volumetric fog or state-of-the-art particles technology, or shaders or anything. GZDoom on the other hand support a number of new features, so users are free to pick and choose.

I think we should think more of:
1) Make easier and more attractive at some level for new modders and mappers to use Qengines
2) Make it compatible across all engines, trying to standardize as much as possible implementations and specs
3) Don't bloat up the "base" engine features with stuff

That's my opinion though, you're all free to disagree. 

My personal wishlist leans toward standardized features like:

- lifting dated memory/count/range limitations
- HUD/menu setup and flashy effects accessible with API expansion (e. g. additional params for particle generation style)
- water transparency, splat decals can change the gameplay, should be mod-controlled && map-controlled