1. Entity key-value listings as per AD in TB.
2. Entity state stuff as per AD.
3. Ersgan quality subtle and faithful improved definitely textures.
4. High quality faithful monster replacements as per the AD shambler.
5. Slightly nicer flame models but retaining a similar style, not some weird fuzzy bloomy shit.
6. Coloured fog per area without hacks.
7. Gamma control that slightly increases contrast and saturation along with brightness to compensate for the washed out high gamma issue.
8. Subtly improved water with gentle surface movement and refined texture.
9. Ability to blend textures into each other across a join (wishful thinking?).
10. There might be more, if in doubt think "subtly improved quality and quake-faithful" .

I have no idea whether these are engine, editor, or game related or whatever. I like Quake tho. 

Lol wtf a monster model is not an engine.

Fog volumes and texture blending are manipulated by shaders in Q3. It would seem more appropriate to port Q1 monsters to Q3 for some kind of single player Q3 mod.

Q3 mapping with terrain and texture blending (actually from Q3:TA), where the artist essentially has to code the shader and specify the textures, is significantly more demanding than Q1 mapping.

Which is why modern engines has node system so artists can design shaders themselves. I'd like to see a node based shader system in Q1... ... ...
But I'm gonna wait for hell to freeze over first cause none of this shit is ever going to happen. 

I have no idea whether these are engine, editor, or game related or whatever.

Emphasis on the "whatever". Also this thread is derived from a "how to attract coders to the Quake scene" thread so I presume general coding might be considered. 

All of the above could be done. Some engines already support different model formats, so it's a matter of content more than engines.

I think there's a lot that can be done with water and fog that doesn't break compatibility and art doesn't violate the esthetics.

Not sure about blending textures though. But a low res masking with multitexturing could be an interesting addition. 

@Serious anon guy
Since you can run Quake3 in FTE, maybe this engine already suports shaders, fog volumes, texture blending and terrains... but i never played Q3 with FTE, so i really don't know... 

There's an argument for saying that 99% of the features that will ever be requested here can just be replaced by the sentence "turn the quake engine into the quake 3 engine", and that's not actually too far off the truth.

Darkplaces and FTE both support Quake 3 bsp and md3. Wraith: Age of Onions is built on Darkplaces to take full advantage of this.

The 2 feature requests currently in the github thing (lit water support and md3 model support) are again Q3 things and you can use them in DP for example.

I think I personally look at the quake engine and see something which is obviously ugly and bad (fullbright water and horrible jelly models preventing you from making big boss monsters that don't look like shit) and then say "would be great if we could fix this in quake 1".

For me I feel like I don't quite want the cross the fine line that has "fix something obviously sucky about quake" on one side, and "make everything like quake 3" on the other. 

Quake's animated textures SUCK. Making a waterfall using animated wad textures looks like crap because the framerate is so low. Also, switching the texture on a brush model is extremely limited - you can currently only toggle between two texture states.

Now, I could put in a request that says "full quake3 style shader support lolol", but really I just want to fix the obvious suckitude with those two existing quake features.

I'll need to have more of a think about it, but I'll probably submit some suggestions along the lines of making quake's existing animated texture support less shit. 

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.