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. 

is your engine going to be released in 2018? 

Well he calls it retroquad... so looks like a nope for 2018 release. 

Yes, that's what I'm thinking too. Easy change to the engines. Easy change to the mdl exporters. Just mdl with better precision. 

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 

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. 

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. 

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 

Need engine support in the trinity of Quake engines: Quakespasm, FTE, and Mark V.

+1 

- 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. 

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. :) 

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. 

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. 

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? 

a couple exporters exist for blender that are still maintained and there's enough literature to get you rolling quickly. tags are nice, too. 

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? 

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.