Texture velocity vector could be something to consider. It'd be a simple per surface value, not a complete shader system. 

CSQC needs to improve drastically, I believe the way it is done can be better thought out. Maybe a higher level API to handle UI specific things?

@Kinn, we could also have a cvar to increase overall texture framerate speed and even maybe texture animation interpolation, or support for UV coordinates animation.

I also agree that we should think of things with a "make a better vanilla quake" mindset instead of adding "next gen" stuff until engines turn into the Q3 engine or into DarkPlaces. The doom community makes a beautiful distinction between "new age" doom with models and polygons and the "vanilla" experience, and the vanilla experience is way more valued as it should since the game is supposed to look like that.

Ω 

This thread is a great idea anyway as a place to bounce ideas around before determining whether it’s worth adding to the github thingy 

Func_playBinkVideo
I have idea for maps with cool pre rendered video cutscenes. 

Bink/Smacker requires a license, no? In order to preserve Quake asthetics Huffyuv or Lagarith would probably be a better idea. 

I think Bink is proprietary format, so I should think Lagarith or mp4 playback would be awesome feature.

You can make Quake animation and render in Mental Ray or Eevee then play video in game. Imagine Nehahra with better cutscenes. 

Nitpicky I guess but mp4 is just a container. It can hold pretty much anything, but it typically stores h264 (which, probably, will be superseded by h265/hevc at some point) and an audio track. But h264 is not only covered by patents but also lossless (huffyuv and derivatives aren't). Quake output is not really high fidelity so huffman-based codec should work fine. Maybe. 

That said VP8/VP9 is probably the best option if one were to stream videos since it wouldn't require transcoding and has some HW acceleration support (vaapi supports VP8). 

lit water:
-splitspecial
Compile your maps with that argument (at least with ericw's tools) and you should get lit water as a result, at least in FTE+DP. QS does not support it still afaik.
Its backwards compatible so start using it and maybe other engines will get the idea a little bit sooner...

animated textures:
texture names have 15 chars to express everything, which isn't really enough to have x+y speeds etc while trying to avoid breaking other texture prefixes.
so the options are to just use q3 shaders, make some more limited clone of q3 shaders (or rather, more normal material descriptions), or to do some weird manipulation of quake's miptex lumps and fix up the qbsp to not mangle the extra data.

q1-vs-q3:
quake3 standards at least have an existing sample implementation.
the biggest issue with q3 is that eg q3bsp implicitly requires q3shaders, etc, which makes it quite messy to implement into an existing q1 engine.
on the plus side, q3 tools already exist, and there are q1 engines that support the formats albeit with varying levels of compatibility.

ultimately, using existing formats like q3's is the only option if we keep on forgetting about feature wish lists for tools too...
(or for that matter, requests for eg pbr textures instead of blinn/phong ones. we at least already have some replacement md3 models for engines to use)

csqc:
trying to standardize csqc now is to give up and mandate DP's clumsiness.
In terms of higher-level apis then yes, QSS's implementation is higher level, its also more limited. On the plus side the qss devkit contains a wrapper for dp so that you should be able to get the same mod working in fte+qss+dp. Let me know if you have more specific complaints.

video playback:
fte+dp have some support for decoding anything that ffmpeg supports (license/patent/etc willing).
Assuming its all set up right, you can 'just' use the playvideo command to play stuff.

alternatively, you should also be able to use 'videomap' in a q3 shader to play your videos on walls/models/csqc's drawpics/etc... 

-Get some way to use more than gold/silver keys in a map without relying on Runes.

This is just for consistency if nothing else. I like it when the Runes are special and not used to open a third door. That just annoys me.

-Being able to change the key set if you so choose

Being able to change keys for a map would make for more variety in map aesthetics.

-Expand weapons/bestiary list

Being Quake faithful's great, but it'd also be interesting to be able to fight other enemies or use different weapons sets like Malice for example.

I don't want to impose too much here, but these minor things would be fun to have access to. 

 

I don't know if this is engine or progs related, but i really like to see maps in quake using trees and foliage, like in those Valve games:
https://twitter.com/goldsrcflautist/status/1137706314866614272
or like in "Pyramid of the Magician" Q3 map:
http://www.simonoc.com/pages/design/mp/pom.htm

I think with plants, trees, grass and general foliage support mappers could make new/fresh looking awesome maps. 

These are best made as mdl models, and you can now use alphatest (aka "fence") textures in mdl to get leafy stuff looking ok. You could even animate the mdl to get some swaying going on.

HOWEVER, where all this falls apart is in the lighting integration.

Mdl models never look integrated with the environment with the current state of the q1 tech. The light compile would have to recognise static mdl meshes, and not only have them cast shadows onto the rest of the environment, but it would also need to generate special lightmaps which the engine could then use on the static mdl models. It would be a fairly involved compiler+engine feature.

I once had a fair stab at making bsp-based trees, but it's probably the worst possible thing to use bsp for and I gave up after all the glitches and issues and hacks I had to do, which made it more trouble than it was worth. 

In hearing why are BSPs so ill-fitted to host trees, that is causing all these glitches you mention? 

The bsp algorithm starts to really creak when you have a lot of detail involving faces at arbitrary angles. You've seen HOMs right? Where a face is dropped and you can see the grey void. When trying to make a tree that's slightly more attractive than something from 1992, the probability of the bsp process b0rking and you getting these dropped faces is rather high. The bsp algorithm just isn't really cut out for dealing with arbitrarily detailed and complex mesh geometry. You're in "here be dragons" territory in terms of bsp tree complexity. At the very least you will need to make each tree a func_wall or func_illusionary so the bsp tree mangling doesn't also affect the rest of the map (which can result in odd PVS glitches amongst other horrors).

I gotta scooch now but I'll elaborate more on the mdl idea later. 

some example maps of way back when you attempted to create those BSP-supported trees still available? I’d love to see these artifacts and glitches by myself, try and understand what’s going on within the engine with them. 

Foliage would probably require additional lighting mechanism in order to look acceptable.

First: in order for trees and what not to cast shadows, some simplified impostors/low LOD models would be used in vis to cast shadows on a static geometry.
Second: Vis would probably need generate low frequency lighting information (spherical harmonics every 64 units or whatever) which could be used for foliage shading. This way shadows would not be baked onto models and swaying trees (or grass) wouldn't look too jarring. 

Now that I think about it: SH would also affect trains and enemies plus SH exported out of the bsp could serve as a rough lighting hint in TB. 

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.