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....
First | Previous | Next | Last
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. 
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. 
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?? 
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. 
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. 
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. 
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 
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. 
From Baker: 
Posted by Baker [] on 2018/03/02 11:27:11
Mark V added a ground-breaking mouse driven menu

Whether or not daft people notice today, it is going to have a major long term impact. I want to mention this first because user-interface matters. People don't like a shitty user-interface and frankly that is what Quake has offered and it sucks bollocks (did I get the UK slang right?)

Quake is not only a model community -- it is more than that. We dream. We fight. We try to give our visions, our hopes and aspirations.

We have heroes (sock, SleepWalker, Spirit) and anti-heroes (onetruepurple not to single him out -- I may well belong in such a group) and they all make valuable contributions.

But at the same time, Quake has a number of stodgy cruft-users and Steam me-too! newbies who don't know their arse from a hole in the ground.

So here is the question:

Is what Quake offers today completely satisfactory to you? Or do you demand more?

But I'm not going to kid around. Let's go full "balls out" here because if you man up, there is just no other way to do this ...

Real question: Am I alone in wanting Quake to be more than it is today?

To hell with it, let's see where this conversion goes!!! 
From Shambler. 
Not Sure If You're Talking About Engine Stuff Or Whatever.
#1 posted by Shambler [] on 2018/03/02 12:04:02 spam
But mostly I am very satisfied with what Quake offers me today.

The combination of the enhancements offered by current engines and mods like AD, along with generally really nice, appropriate usage of those features by mappers, executed in a wide variety of maps that still give a good Quakey experience.....I think is great. There's not much I think should be added, except more of the same, and the continuation of a very gradual introduction of minor graphical / design enhancements.

There's a few things I would personally like to see, I'm happy for AD to become a main standard for Quake+++, as long as people remember it's a choice, and vanilla or other mods like Rubicon, Quoth etc are still great to map for. I'd like to see some of the older / less used mod stuff added to AD, specifically Floyds, re-textured Zer Mega Enforcers and Nemesats, the BloodCube, also the Nehahra railgun, all of which I think offer really cool gameplay. Graphically, better fluids would be the next step I think, maybe some subtle surface movement, better textures, even a slight reflectiveness - again the key is subtlety.

Set-up-wise I was going to suggest easier use of the -game malarkey rather than editing shortcuts, but then I realised that works fine changing dir in engine in Quakespasm, so that's fine.

In short, I don't want much more - apart from MOAR MAPS :) 
From OTP 
#2 posted by onetruepurple [] on 2018/03/02 12:36:25 spam
Not 100% sure if this thread is strictly for user experience ideas, or holistically about Quake, but I have a certain Strong Opinion™ that I was meant to post in the "Quake in 2018" thread but it's probably too late to revive that...

The AI in Quake, and pathfinding specifically, is shit.

I mean, we all know it, but it needs to change from "it's shit, but it's ok" to "it's shit, and it's not ok". It's not completely satisfactory (as per the thread title) that even in 2018, Quake gameplay can be lamely cheesed.

Here's an example from Bal's (otherwise 100% excellent) 1024³ map: it's not immediately visible on that shot but the wall can simply be walked around. In a proper scenario, the Fiends would just find their way around the wall and rip me to shreds, but the Fiends wouldn't, since they just follow the one straight line the QC is telling them to follow at all costs.

This will be an unpopular opinion, but as Quake is slowly re-gaining popularity, we as mappers and modders MUST up our game on this end. I find it slightly embarrassing to recommend all the amazing new maps to newcomers and have them encounter idiotic, prehistoric AI.

It's especially embarrassing since such systems already exist as .qc!!

1. sock implemented an extremely robust pathing system in the In the Shadows mod that was then discontinued in Arcane Dimensions.

2. c0burn has another system, based on FBX waypoints (I think?):

3. Numerous older solutions from the inside3d times.

Ten, and even five years ago posts like these would be met with total bollocks like "who cares about smart monsters, I just shoot them :)", maybe it's about time everybody realised that smarter enemies make for a better QUAKE experience. 
#52 Is Still Extremely Important Btw. 
Mark V added a ground-breaking mouse driven menu [...].
Whether or not daft people notice today, it is going to have a major long term impact. I want to mention this first because user-interface matters.

Wrong. There were mouse-driven GUIs for Quake engines before, and most of them never inspired other engines to follow suit. Even Makaqu has a mouse-driven GUI with a minimalistic approach, which uses the mouse wheel and buttons instead of a pointer and is therefore faster in most situations when we get used to it.

Another usability improvement implemented in Makaqu to make menu navigation faster is that the same command used to open a menu can also be used to close it. Press F8 to open the keys menu, and press F8 again to close it. No more pressing Esc multiple times to get back to the game. Has this ever been implemented in another engine? No.

When it comes to trends in engine coding, user interface doesn't matter. Technology matters. Engine coders enjoys to implement challenging technology, and this is why we've got multiple engines with CSQC and MenuQC support, which requires users to learn programming in order to modify the menus.
Meanwhile, the Makaqu engine has menus that are completely customizable through just 2 (menu_keys_clear, menu_keys_addcmd) or 3 (menu_clearmaps, menu_addepisode, menu_addmap) console commands, which any braindead user could do in a simple autoexec.cfg file. For over ten years, this never inspired anyone else to follow a similar approach to Quake UI customization.

Usability generally favors minimalism, but it's hard to not get ambitious when doing engine coding. Unambitious approaches doesn't sell.

Anyway, I've never implemented a maplist command and some of the other usability improvements that other engines have. I've stopped implementing usability improvements after noticing that most people don't care about them.

When usability is good, people don't notice it. And there's no demand for what goes unnoticed. This is why Quake engine usability tends to follow a reactive design-by-committee approach, fixing issues while ignoring improvements.

Real question: Am I alone in wanting Quake to be more than it is today?

You're not alone, but it's difficult to come up with a consensus about what "more" means. Most of what the community at large agrees upon seems to have been done already. Further efforts rarely achieve consensus and are most often considered to detract from what the authentic experience should be. Which is why I don't even try to promote Retroquad as a Quake engine anymore, and instead am developing it towards indie game development. Or maybe I'm just drowning in my own negativity, who knows. 
In Quake you can enter a room, shit yourself, and back out of the room to re-evaluate your strategy in the knowledge that a big conga line of monsters is not going to just perfectly chase you down all through the map.

Any enhanced pathfinding AI needs to appreciate that this sort of soft "tethering" of monsters to an area may be just a quirk of crap pathfinding at the moment, but monster area-limiting would certainly need to be a feature available to the designer in any future AI rewrite. But it can't be rigid, because you'd still want to be able to "pull" a monster to anywhere you want as well. 
Re: OTP's AI Suggestion 
He's spot on. AI needs a refresh. I'm sure there's some way it could be offloaded to the compiling stage like Q3A. So the mapper adds some entities to help with dumb monster behavior and then an external solution takes that data and bakes it into the map. Engines devs would then have the option of supporting the new AI feature or not.

Would this be feasible?

I appreciate the convenience of a mouse driven menu but frankly I have a high DPI mouse that always runs too fast in these types of UI. It's certainly welcome and I am all for making things more usable for noobs.

I think it's important to remember that communities have to grow to succeed in the long run. We want Quake as appealing and accessible as ever. I still think it's possible to create a set of standard that can be voted/agreed upon and then collaborated on by the brightest minds in our coding community. 
So the mapper adds some entities to help with dumb monster behavior and then an external solution takes that data and bakes it into the map.

Q3 looks at the connectivity of the BSP leaves to generate the AAS graph right? Something like that sounds like a possible approach, rather than the designer having to add loads of nodes everywhere.

Of course, once you have perfect pathfinding, it's then up to the designer/modder to write a load of QC code to do all the extra AI logic that stops the whole level playing out like a Benny Hill sketch. 
Honestly, advanced AI belongs to "what do you want to see in a mod", not "what do you want to see in Quake". AD is the perfect candidate to such a thing, and it already has tethered waypoints AFAIK. 
I think my breadcrumb solution is reasonably "ok"... it would mean if you were properly keen on running away you should still be able to do so.

the idea would be:

every 5 seconds or so the player spawns a short lived invisible entity (breadcrumb), if the monster can't see the player, it searches for that breadcrumb, and travels to its location if the breadcrumb has line of sight to the player.

If the breadcrumb doesn't have line of sight, the monster just continues on its usual dumb pathfinding.

this way the monster is likely to get an extra corner or so of pathfinding before losing the player 
Something along those lines could work. Not an invisible entity, but just a .vector field (self.enemyorigin?) containing the location where the player was last seen by the monster.

Since the sight line is a straight line, and monsters only navigate properly across straight lines, this should fit their logic.

Actually, this should be dumb easy. I'll take a look at the QC code now. 
Hmm, that would require a dummy entity anyway, as movetogoal is implemented engine-side. 
Vanilla Quake 2 Does That 
calls em "player trails" 
I'd love to see certain enemies use others as meatshields... chunkier enemies up front and center while the smaller ones try and flank the player

I'd also love to see ogres figure out how to lob grenades over other enemies heads at the player 
rather than the designer having to add loads of nodes everywhere.

I'd rather have control over it though - as no matter how good the implementation is there will be issues. 
what I'd like to see would be engines to FINALLY start supporting tracebox, so that this stuff can actually be implemented...
without that, good luck with this ai stuff... you'll need it...

but yeah, without this being some map-specific thing, you're going to drastically change the balance of various maps. 
AI Is Great 
Breadcrumbs is the only AI "enhancement" that should be considered.

The direct-path, omniscient AI is actually quite good and varied due to the way Quake handles AI states.

AI in Quake is handled on a per frame basis, allowing perfect coupling of the animation with the movement and movements to match the model. This prevents monsters feeling too floaty when walking. The simplistic AI lets the player be smarter, gives smart players a way to control monsters and make in-fights, and gives some monsters character. I always love it wgen shamblers wander off for a bit becahse they don't see me.

Getting caught on lips is bad though. 
Somewhat Intoxicated, But Here We Go. 
Reading the DLL rant made me lose a few IQ points.

Something I'd like to see is an engine which focuses on a modern tool-chain with modern formats. No one is considering Quake engines for bigger TC projects because every project also seems to aim for compatibility and misrepresents itself and its capabilities.

When you look for ways to get started for mapping/modelling for modern Quake engines you still mostly get results for .MDL and Quake 1 BSP creation. I highly doubt most people (unless they are trying to cash in on the whole 90s FPS revival...) would want to work with their limitations. Most noobs stop when they realize that you can't crouch due to hull size limits. I GUESS EVERYONE JUST WANTS TO MAKE SIMPLE QUAKE MODS.

Engines just seem to do a little too much overall with their builtin HUDs, menus and scoreboards. If they don't support CSQC then mods have a harder time customizing the look and feel. Overall all the advanced engines are bloated hogs with an identity crisis.

Thoughts on currently relevant engines:
To me was always a solid GL engine that just did NetQuake stuff well. I'd never consider it for development. Just for playing old NetQuake mods. Extending it to do more complex things might harm it in the long run, because it'll just be another FTE/Darkplaces.

While it somewhat supports CSQC and somewhat supports Quake 3's material/shader system, doesn't do any of it well. It's only half QuakeWorld compatible as well. So as a developer I've run into a few problems.

Does everything and _most_ of it works. Sadly the engine just does way too much. 16 year old code sticks out and things regress more often, because it's all cobbled together in one giant binary, I often have run into bugs/features that hadn't been tested recently or at all. It's like the emacs of Quake engines. But probably more reliable than any GNU project...

Does anyone even consider this for development? I guess if you run a custom QW server you use it to test because there's this invisible community of QW players who seem to use it. I don't know anyone personally who does, but a bunch that have focus on retaining compat with those clients because half their player-base uses it.

Overall, all of the above aim to be Quake 1 compatible. Those who care about Quake and don't need obnoxious high-res texture-packs just usually stick with QuakeSpasm. Why? Because it focuses on one thing well. Technically, FTE is the most complex engine but it has less of an adoption than say Darkplaces because it's mostly competing with ezQuake in the QuakeWorld space. That's because everyone has a hard-time at comprehending what it actually is. The name suggests it's just another ezQuake alternative. That's where it's kinda stuck.

I don't follow QuakeSpasms development (I don't even use it), but I hope that those who maintain it know what they are doing. Don't give in to requests of adding support for non Quake file formats and conventions. Just stick to being a good NetQuake client that offers the feel of the original. Otherwise you're just a few inches away of supporting rtlights and giving little kids the keys to using their Rygel pk3s. It'll be like Darkplaces but with less features.

Having been busy in recent years, I just occasionally take note of what's happening in the engine world. So what I might be talking about is not relevant anymore. 
Does support colored lights.

I can agree on FTE. Not really sure where it fits in, no offense to Spike or anything. 

FTE is a perfect engine for people like me who wants to play Quake with the classic look (pixelated textures and particles) but also can't live without realtime light and shadow.

Now, answering the question "What Do You Want To See In Quake In 2018?"

I just want to see mappers and players noticing how important realtime lights and shadows are for quake.

Seriously, it makes the ambience so much more gloomy and terrifying. Just look how this little and simple old map looks awesome with realtime L&S:

The dark atmosphere, the monster's shadows moving on the walls... reminds me of Severance:Blade of Darkness. That game blew my mind, the gameplay was slow, hard and boring, but I played it just for the lights and shadows, it was awesome runing around the map with a torch on my hand, moving shadows... it makes the place look real. And I wished so bad that quake had it too... And now we have, and looks like nobody care for it. It's awesome when you see a shadow walking at the wall before you see the monster, the shadow grows and shrinks, so you know when he is close or far away, or when you see a rotating shadow from a weapon that you can't reach... these little details add so much to the game. Imagine how mappers could create suspense, paranoia and horror if they think about RT shadows when they are making a map...

Sorry for the long post :P 
Oh No 
Well...I would have a leg to stand on by arguing that Quake needs point lights sprinkled throughout a space as fill lights, but...

ericw already made this method of lighting obsolete with his bounce lighting.

With too many point lights comes dozens of overlapoing shadows = ugly and distracting and poor performance...on older maps that are much more evenly lit. 
Something I'd like to see is an engine which focuses on a modern tool-chain with modern formats. No one is considering Quake engines for bigger TC projects because every project also seems to aim for compatibility and misrepresents itself and its capabilities.

So, you want an engine that works with modern asset formats, but you're also knocking points off engines for being compatible with the original Quake.

Ummm... maybe just do whatever in UE4 or Unity? Not sure I understand why anyone would even want a Quake engine in this situation... 
I've noticed just how out-of-place and incongruous real time lighting looks with Quake's old textures and models, especially with pixel mode on, hope that helps. 
I think it fits perfectly with them =D

but it's ok, let's agree to disagree ;)

i'm not here trying to change anyone's minds, i'm just answering the question of what i would want to see in quake in 2018. But nobody has to agree with me, it's just my two cents ;) 
These engines run on certain ranges of modern hardware, Unity struggles heavily on integrated chips and even dedicated cards from 5+ years ago, also have all sorts of licensing issues and do not contain the same workflow that everyone is used to in the Quake community.

There is a lot of tech in between QuakeOne-level-tech and something like UE4. When it comes to 3D Gaming engines it's probably as big of a gap as there can be. You never have to take full advantage of such things. I am sure that anyone would welcome a Quake engine where the audio, physics and rendering API was on par with something like the Source engine (because no one has $25000 to pay to Havok and RAD Game Tools)

But seeing as only one current Quake 1 engine fork (being FTE) even attempts to take advtantage of things such as a Bullet physics implementation or supporting OpenAL Reverb setups, that's not really happening. So that's what I'm talking about.

Of course, what I named above is an example. People love Quake modding, they are familar with it. Everyone here takes advantage of the GPL all the time and are able to build fantastically open things - but all everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts. 
aal everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts.

Yes, and? 
For what it's worth, engines probably typically want to react to what the community is actually doing, rather than create a brand new content creation paradigm and then hope that some modders pick it up and start doing something worthwhile with it.

DP, FTE have md3 and Q3 bsp, amongst all manner of other things, and have done for a long time. When we start seeing good projects based around those features, we might start seeing support in other engines. 
this thread title is like a legal contract - realistically. Its such a relative term :D I'll try.

Realistically I would love quake's palette restrictions lifted. I understand that its all comes down to the fact that old wads and bsps can't store truecolor images, but (correct me if I'm wrong) you're converting them to truecolor anyway when loading into memory?

So bsp can store palette.lmp. So what if, upon loading said bsp, engine detects it has palette.lmp and uses it for textures from that bsp, instead of default one? Obviously items and weapons would still use original palette.

From my ignorant perspective it sounds very realistic. But then again I have no idea about inner workings of Quake engine, let alone source ports.

Point is - using colors from original palette is very limiting. It might be a good thing to keep things coherent and 'in-style', but from what I've seen so far, people would rather create awfully translated to quake's palette textures than adjust their design decisions. The idea of creating a new mod just so I can change color palette is absurd and discouraging. 
Whoa, you can totally remove all palette restrictions right now by just using external textures! Works in every custom quake engine I know.

You can even keep your new fancy coloured textures looking all limited-palette and pixel arty, but that's an artistic decision now. 
If you're using external textures, you can still have crappy Q1-paletted versions "baked" into the bsp to allow backwards compatibility for any wierdos somehow not using an external-texture-compatible engine, but if you aren't interested in backwards compatibility, you can even tell ericw's qbsp to strip the Q1 textures out of the .bsp and rely only on the externals. 
way to make a bear feel stupid :D oh well, ignore me :P 
What some popular engines doesn't support are special textures like bumpmaps, normalmaps and so on. Regular 24-bit color images are fine. 
The word 'good' is incredibly subjective.

In this community, 'good' means 'like quake', which in turn means 'low res', which to most people from outside the quake community means 'crap'.
That is the problem.

While its true that most engines support high res textures...
1) filenames for those textures is pretty much pot-luck - on a per-engine basis. And good luck with fullbright naming too.
2) supporting all the possible paths results in horrible horrible load times on windows, so expect only one, and for it to not match any other engine.
3) you can't be sure about file types either, for instance, QuakeSpasm pretty much only supports tgas (unless you count pcx as a 24-bit image format - I don't, although per-texture palettes can still be useful). Good luck when it comes to fullbright channels - additive, blended, premultiplied, etc...
4) pk3s(read: zips) are not supported by eg QS, so you'll have to use some large paks instead, along with needing to use annoying tools that have not been updated since q2 era and were never that friendly anyway...
5) except that quakespasm doesn't support miscellaneous pak file names, so they'd have to be numbered exactly and probably break...
6) so instead you'll have to distribute all those files loose which makes it really messy...
7) and they'll get confused with all the other maps because quakespasm lacks per-map replacement textures (even though you need that even for replacement textures with the vanilla quake maps).
8) so you need to create an entirely new gamedir.
9) which requires command-line arguments or console commands that vary in every single engine
10) and you can't use multiple gamedirs so if its an AD mod you have to distribute the ENTIRE ad (the alternative is installation instructions that 'no-one' would bother to follow).

so yes, 24-bit textures work... But you'll screw up every other maps, and you STILL need a wad for your map editor and so the qbsp can get the texture wraps/lightmap correct.

And in writing this post, I remembered that per-map replacement textures is something I overlooked in QSS, so it's still kinda screwed with conflicts despite the png+pk3+naming stuff that I added to it.

And now I'm wondering about tweaking ericw's tools to spit out a hlbsp with its per-texture palettes.

Hopefully you should understand Eukara's stance a little better now.

Additionally, note that while ericw's tools support writing a bsp with no mipmap data, ericw's engine (read: quakespasm) will just give you corruption if you actually try using it. That was my change (and probably only got merged because it was in the same patch as the phong stuff). Both FTE+QSS support it, but apparently no-one else gives a shit about stuff like that. The same is true of embedding the lits inside the bsp (although ezquake supports that one too, but not QS).

FTE is intended mostly for modders (note that the one tool that shares fte's name is a quakec compiler). For it to be useful to modders, it has to cater to users too (like OPTIONAL realtime lights, or its 8bit rendering stuff, its better networking, raised map limits, etc).

At the end of the day, there's a fine balance between compatibility and sanity. The only way to avoid needing to balance is adding lots of extra cvars. Hence the presets, in an attempt to get it configured how people want without them fleeing in terror and bewilderment. 

First, i love your engine.

Second, You sir, are a genius =D

Third, thank you for your awesome work =D 
Where would I find info on how to add real time lights to my map for FTE? I'll be honest I am not a big fan of those BUT I would rather place them myself than have FTE do it automagically. 
In this community, 'good' means 'like quake', which in turn means 'low res', which to most people from outside the quake community means 'crap'.
That is the problem.

For me, 'good' means 'fitting in with quake via gradual enhancements' which in turn means 'a resolution harmonious with the level of models, typical map brushwork, and general graphical effects'. 
This Is The "....see In Quake In 2018?" Thread So... 
We are talking about Quake so I can agree with making it fit with Quake's style.

I would like to have a CSQC HUD template that matches the original HUD so that people could use it as a base to tweak or add things rather than reinvent the whole wheel.

Heck I might make one myself someday. 
Quakespasm inherited per-map external textures from Fitzquake 0.85; they go in /textures/mapname/ (docs: ). 
Probably wise a decision merging my thoughts into this thread, but I wanted to avoid the toxic stew of the unrealistic weird crap in this thread.

Too much crazy talk for me in this thread, I was referring to more pedestrian things.

That being said ...

Appreciate you, Shambler! 
"Wrong. There were mouse-driven GUIs for Quake engines before, and most of them never inspired other engines to follow suit. Even Makaqu has a mouse-driven GUI with a minimalistic approach, which uses the mouse wheel and buttons instead of a pointer and is therefore faster in most situations when we get used to it."

Load up Mark V current beta build.

I'm sorry, but every other engine has tried mouse driven menu has done it wrong.

The Mark V implementation smokes all past failures because it is actually done right.

The closest to "done right" in the past is Spike's implementation in FTE.

The implementation in Mark V nails it.

Try it, I dare you to disagree after trying it.

I am a classic player purist player before I am an engine developer. And this ultra-conservativism is why the menu succeeds.

I went "full retard" to get it how a classic "stick in the mud" would want it work.

I look forward to your "Fuck, I hate to admit it because but you are right Baker and you nailed it!" post, hahahaha!

Btw: I am not kidding. Everyone who has tried said I nailed it. Because I DID NAIL IT! 
May I ask for you try to the mouse driven menu in Mark V build 1050 and share if you if I completely fucking nailed it?

You are a big "stick-in-mud-conservative" which means your opinion is only kind I value.

(If you doubt me, ask Mugwump if I think I value your opinion some time ...) 
I'm sorry if I'm missing something here, but what exactly defines (in this case, at least) if a mouse-driven interface is 'done right' or 'done wrong?' 
Proven good taste for classic Quake is self-evident. If you have to ask, you are not the target audience for such a question.

People with appreciation for the taste of classic Quake and conservative credentials are never in doubt.

They never ask such a question and are pre-loaded with conviction of their righteousness. 
@spud Part 2 
Look -- I don't believe in sugar-coating. I truly don't. I have come to the conclusion that is what ruins most games and millenials.

If I were to rephrase to be more it would go like this: "If you don't know, fuck you".

I'm sincerely not trying to be dick, and I mean that from the bottom of my heart, but isn't your entire screaming "I have shit for taste".

I just CANNOT sympathize with that.

I think that mindset ruins gaming, every game and every form of game.

Now, if you have an open mind, perhaps you can see why I am tearing into your "WTF is good taste" qualification.

I am saying "If you have to ask, FUCK YOU -- disqualified -- go pound sand".

I am do mean that. Without reservation.

If you don't trust your own judgement, go fly a fucking kite, you are the poster-boy for bad taste.

If you understand, and I expect you do. 
What The Christ 
And I thought I had some bad rants. 
I wanted to post with just the face but I have to put some words here, I guess. 
My "bad rants" are purely philosophical perspective and conservative prudeness, otp. Your bad rants tend to be personal.

My "bad rants" are impersonally "perspective oriented", even here.

12 beers down and my honest 3rd person critique of a point-of-view is kinder than yours which has many times been euphemistically "quite unkind".

Baker + 12 beers > bigger morale compass than otp. I still care and am not looking to offend the person. Life lesson for otp perhaps? 
So .. regardless of my rants .. let's hear your honest thoughts.

Try the various mouse driven menus listed above, post your thoughts ..

Don't question your judgment .. just state what you feel ... 
You have already demonstrated you have talents that care for the betterment of Quake. Everyone has seen this.

Why not go with that?

You can't spell anti-hero without hero, so quit being such a dick for no reason maybe?

I'm just saying ...

We all know you have the capacity for good. 
I'm well aware of, and actually quite enjoying, my moral compass not being fully functional, so that's hardly a life lesson.(If anything, your bragging sounds like classic compensation, which is fully plausible, considering some of your older, absolutely callous musings in certain threads)

But I'm still capable of doing good, as are you - so I'm hoping once the drunken haxe wears off, you will reflect on what you've done, which is scream profanities at a potential user for asking an unobvious question.

I have never used a mouse-based menu in Quake, so out of pure curiosity I would be seconding Spud's question. What's in it for me, as another Quake-conservative player? Or does that question reflect on my tastes and design sensibilities (which have been an asset so far) as well?

If it is such a revolutionary implementation, it shouldn't be difficult to explain. 
I Started Writing That Before #220 Btw. 
And no, thanks, I'll be an actual hero where I think it matters, which is not the Internet. 
If it is such a revolutionary implementation, it shouldn't be difficult require installing numerous other, allegedly inferior implementations to explain. 
@219 Er, Okay. 
I downloaded the new Mark V build despite not really wanting to after that drunken outburst (if your faculties are impaired through impending liver failure, consider not going on the internet), and here's the verdict: it feels like a mouse driven menu. Seen it before in ezquake, with much the same functionality- left click to select things, right click to go up a menu, hold left click to slide a slider.

Plus points for highlighting the menu option you're hovering over and for using the system cursor and sensitivity instead of an ugly green one like ezquake. Minus points for not moving the spinning Quake icon when mousing over SP/MP/options/etc, for the scroll wheel not scrolling in the Levels menu or other similar scroll-bar-equipped screens (i.e. the demos menu if you have a whole bunch of demos), and for being advertised as * Fully mouse-driven menu despite the mouse not appearing when the console is open, meaning highlighting text for copying is only possible in the entry prompt itself through holding shift and using the arrow keys to move the cursor and you're out of luck for copying error messages or similar.

I mean, it's neat, but it's still slower than just tapping enter a few times to start a new game, or tapping escape/~ for the console and typing in whatever map you've just downloaded and plunked in your \maps folder. Also, so far as I can see the main menu isn't already open when you launch the game so while the demo is playing you still have to press any key on the keyboard to open it and bring the cursor up.

just state what you feel ...
'What you feel' is a pretty poor way to judge things, though, isn't it? I can think of a number of ways that you could separate a 'good' mouse interface from a 'bad' one, with just a few things experienced not only between source ports of this game, but in various older games themselves: Does the scroll wheel scroll properly? Does the mouse have forced acceleration (or deceleration) in the menus, and does it use a separate, nonadjustable sensitivity different from your OS setting? Is it more sensitive when moving the cursor horizontally than vertically (this shows up surprisingly often now that most people are playing at 16:10 or 16:9)? Do you have to navigate to click a tiny [x] or [Back] button to exit a menu if Escape doesn't work? And so on and so forth.

Not sure if all this belongs in this thread now, but fuck it, we'll do it live. 

You have a taste for conservative Quake, all of us know you do.

Load up Mark V 1050 and give us all your honest unbiased opinion.

Nut up, man. 
Thanks for the feedback, even though your feedback differs from other feedback I have received and I had reason to question to your judgment from the start, don't think for a second I won't take your feedback into consideration.

I'm hardcore that like where I consider the feedbsck from all.

+1 for rising to the occasion.

OTP. Let us hear your opinion. 
Yeah, I am .. well .. it's 17 beers down at this point.

A sincere thanks for your feedback.

I get what you say about the mouse wheel, but I strongly disagree for reasons that are too detailed for me to explain right now (but make perfect sense -- either you honor the mouse position or you don't and in that case you must take the mouse position over the mouse wheel for behavior reasons).

I reiterate that I do respect you. You manned up. I always respect anyone who manned up. You did. Case closed, you have my respect.

I wanted to convey that. 
That was an interesting last 20 posts....

I wanted to avoid the toxic stew of the unrealistic weird crap in this thread.

Too much crazy talk for me in this thread

Oh okay then.

My "bad rants" are purely philosophical perspective and conservative prudeness, otp.

My "bad rants" are impersonally "perspective oriented", even here.


Baker + 12 beers > bigger morale compass than otp.

quit being such a dick for no reason maybe?

...evidently so.

You are a big "stick-in-mud-conservative"

I'm not entirely sure about that, given that half the old skool maps I play on stream I comment with "This would be really nice with some subtle fog and coloured lighting and AD-style breakables", and that I have started a thread about modern improvements to Quake. I suppose I am a big "gradual-improvements-and-harmony-with-current-Quake-style conservative", tho.

Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for. HTH. 
"Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for."

Thank you for taking the time to try out the mouse-driven menu, I invested a lot of time and effort in it.

I'll take this as a good start for today.

Perhaps, tomorrow I hope to win your heart and your soul completely over. I may not have entirely accomplished this today, but I will take that I at least partially won your over.

That will have to do for now.

I appreciate your feedback and thank you for taking the time to do this, Shambler. 
Further 2 Penneth Worth 
Based on me barely having a total of 17 beers-worth of alcohol in the last 2 months.

Mouse-driven menus - never felt a need for it.

Improved AI - why not, I wouldn't mind it if it's done well. Not a fan of uber-strafing bobs and nehahra enemies, and z-aware ogres have to be used sparingly, but some better chasing AI could be pretty fun if used well. Like everything, introduce it carefully. Also better tactical negotiations between different enemies could be funny as long as it doesn't override infighting.

Real-time lighting / high res textures - both completely out-of-place and jarring with the current level of detail and especially the current Quake models. However these things are constantly improving and if/when all the Quake models are improved and a higher level of design / detail becomes standard (subject to mappers being able to do it easily / comfortable), then both of these more advanced graphical effects would be pretty welcome.

I've said it before and I will say it again:

Subtle, incremental, careful, and harmonious improvements to Quake's graphics are great

There's already been a lot of good stuff added: coloured fog, coloured lighting, breakables, transparencies, cobwebs/vines, particles, the new Shambler model (not perfect but I like it and it does fit in) etc. All of these have been small changes that still fit well with the relatively crude models / texture resolution / detail levels, AND they have often been used really nicely and carefully by mappers to enhance their maps. Hopefully there is more of this to come, and in time bigger graphical leaps like hi-res tex, RT lighting, soft smoke etc, will be able to fit in well too. 
I'm tempted to add a big laundry list of stuff, but I'll just mention one thing for now.

- Some kind of thing that works as follows:

Create a brushmodel, place it in your level in a nice position, and flag it as "always draw". Now, throw sky brushes around to seal all your rooms in a sensible "I understand vis-blocking" way....but...plot twist! Wherever you see sky, you can also potentially see your special "always draw" brushmodel, drawn in front of the sky but otherwise sorted with the rest of your geometry.

This would allow the creation of town / city style maps with cool skylines that don't make the engine draw literally the entire level at once.

To make it more optimised you could even give the mapper ability to turn it off in places where you don't need it. 
Keyboard focus should not be tied to mouse focus. I'm not going into the specifics, but there are good reasons why all operational systems' GUI keeps both focuses independent.

All major operational systems have user interface guideline documents describing what makes an interface to be good. From the ones I've read, the Microsoft one was the best, despite their product still having major design flaws. There's also the Apple one, and some others from some Linux distros.

Anyway, for Quake itself, in which mouse aiming has become the main control scheme, the purpose of a good mouse-driven interface should be to remove the need for the user to switch his/her right hand from the mouse to the keyboard. Just that. The mouse should enable the user to do anything that the keyboard would require his right hand for, minus typing text.

So, the main measure of good mouse-driven interfaces in Quake should be that the less right hand movement needed, the better. Arm injuries such as Carp Tunnel Syndrome are very real and some players have them, so the developers must take this kind of issue in consideration when designing their UIs.

User interface design is not a subjective mysterious art. 
A Couple Of Other Bits 
- More widespread adoption of lit water (cough, cough QS)

- FTEs "software banding" option adopted/copied in more engines (cough, cough QS). Quake feels too sterile without it. 
*carpal tunnel syndrome, not carp. 
You're describing "3D skyboxes". AFAIK, the Source and Unreal engines supports that. 
3d Skyboxes 
Do those work with objects that are still very much part of the level though? Say I have a church spire. In one "room" of the map, the church spire is placed as very much a physical part of the room, like any other brushes.... it's just this particular object would get flagged to also be drawn in other "rooms" in front of the sky faces. 
No that would not work in Source/Unreal skyboxes, which basically just draw the contents of the sky-room as really big. What you're describing sounds kind of clunky to setup.
Having Unreal type skyboxes would be neat though, that's for sure, and it's purely visible so kind of backwards compatible (engines not supporting it would just have the normal sky or skybox). 
Hmm, in that case the objects wouldn't be part of the skybox. Getting such a thing to work could be tricky.

We already got visblockers, and your suggestion needs the inverse — a vis unblocker. Also, depending on how the engine handles skies, things can get complicated. 
Probably Already Stated 
But new mappers entering the fray.

With Dumptruck_ds's tutorials I think that's entirely realistic! ;) 
Q3 BSP supports skyportals (for things such as 3D skyboxes)

For The Wastes I pushed Spike to add support for cubemap layers in FTE's sky shader stages. That way you can have a scrolling cloud layer (or 2 or 3...) in a shader and overlay a skybox on top of it. Like a mountain landscape or something. That will get the Unreal effect.

In the end if you want more fidelity like that, pretty much everything is already doable in the Q3BSP/Shader world. 
The stage in question will look somewhat like this

map $cube:gfx/env/mountains
blendfunc blend
tcGen skybox
Thoughts on mouse-driven menus in Quake:

Retrofitting the qmenu is not the most ideal thing. You can get it to feel somewhat okay, but it will never beat a design that actually is designed around the input method.

Simply being able to click on options that were previously able to only be selected with a keyboard does not make the menu usable for mouse driven input.

A good mouse driven menu allows you to jump quickly from one place (that was deeply nested into sub-menus before) into another place with just one click, while still retaining a sense of order. In the case of Quake, that would require dumping menu.c into the trash.

Unreal used to have a very Quake/Doom ish looking menu, but with Unreal Tournament they realized that people actually wanted to move around the menus fast and have a better overview over all of the options available. This was then carried over to Unreal Gold and that's how most people see it today. It was a drastic change but a needed one. 
I Hope You Feel Properly Embarrassed 
in the morning, Baker. 
isn't like RtCW had 3d skyboxes? I vaguely remember seeing some kind of screenshot or something showing small scale far-away environment, later rendered before level as if player in the centre of it? 
As I've said before, Q3 BSP supports skyportals, aka 3d skyboxes. So yes. RtCW probably used them... 
What Is Even Happening In This Thread 
People Are Talking About Improvements They'd Like To See In Quake 
Some people complains that searching for replacement textures through all the possible paths from all the different standards takes a lot of time under Windows.

And then I remembered that when I started expanding the number of savegame slots to 100 saves in the Dreamcast version of Makaqu, it also resulted in massive slowdown when scanning for saves. The VMU interface is freakingly slow. But there was a solution.

When you search for a specific file, the operational system will read each file entry from the specified location, until the desired file is found. This is fine when you just want to load a single file, but it's idiotic when you're actually going to load many files from the same location.

The solution, in the Dreamcast case, was to scan each and every file entry from the location only once, in an unordered fashion (the physical order in the filesystem), while checking every one for compatible savegames. The logic is simple: If the file you want is physically the last file in a filesystem location, the OS will scan all file entries from that location anyway. Subsequent searches for other files from the same location would make the OS scan the same non-matching files multiple times, resulting in lots of redundant work.

I bet a similar solution would work under Windows. Linux probably caches file entries in the RAM automatically to prevent redundant scanning of physical storage devices. 
Texture Loading 
You can enumerate paths one time only at startup then only search the paths that actually exist when loading textures. Sort a PAK file directory and binary-search it. Use the native API which has faster calls for determining if a file exists rather than putting everything through stdio.

The point is, you can be a little intelligent about how you approach problems and it doesn't require creating hugely complex code. 
It's better to do the path enumeration at the beginning of map loading, in case the user alt-tabs to add more assets without closing the engine.

I often add more external textures and reload the map in-game when mapping. 
Yeah, that would work better. 
I Want To See... 
...TB including a GL-filter mode as default so when we're watching streams of people making otherwise awesome looking maps, we don't have to have them ruined by shitty square pixels everywhere when the mapper is zooming around in and out of brushes.

Also I want to see the return of Baker once his hangover finishes. 
Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer. 
Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment. 
TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D ) 
Sigh. Quake Ruined. 
[10:23] Kinn: @Shambler - are you sure that your blurry vision quake mode doesn't just make the surfaces of the world just appear all smooth and sterile and devoid of life?
[10:25] Shambler: i don't have blurry vision quake mode, i have smooth vision quake mode
[10:25] Shambler: and generally to avoid "sterility and devoidness of life" in any imaging situation, my first thought isn't "add lots of little squares like a mosaic"
[10:25] Shambler: unless, of course, i wanted a mosaic
[10:25] Shambler: which i don't 
Shambler Needs More Pixels Not Less 
Texture filtering in Quake was a mistake. 
Your conception was a mistake. Your mom told me as much. 
Quake with unfiltered textures looks great, if you play it in the originally intended resolutions. In 1996, 640*480 was the highest resolution that achieved playable framerates in most high-end machines.

I used to play it at 512*384 in a Cyrix MII-300 in the early 2000s. Had a solid 12 fps which was surprisingly enjoyable, and looked pretty good to me.

Nowadays, its texel-to-pixel ratio at the highest playable resolutions is poor. 
Mankrip Knows What I'm Talking About 
We don't need filtering, just higher texel density. Love my crisp edges!

I wouldn't mind seeing a coop episode in AD. Something that detects coop and requires two people to progress if coop is on. E.g. two pressure plates require both players on them to open a player stand on a pressure plate while another shoots an exposed button juuust out of view of the player on the pressure plate. You could use the dual pressure plate idea to split players up across two sides of a room, Portal 2 style, and have them fighting and helping by shooting across the gap. 
Unfiltered Quake looks fantastic.

Aside from the sharper edges on things, textures just pop with detail compared to the filtered versions.


More than just fullbrights and overbrights was lost in the initial SQUEEEEEEE-fest over GLQuake. 
Good filtering is much more important with high resolution images than it is with low res stuff (where it just makes them blurry). 
One thing i like about filtering is that how smooth it looks in motion, in unfiltered mode is the scene is very noisy/sparkly as you move the camera.

However, filtered mode makes each pixel less vibrant/contrasty, everything gets a little bit more gray and colors shift towards the local average. For example that wall texture in e1m6 has lots of little single pixels of green and blue that pop really nicely in gl_nearest, but in gl_linear they are dulled and dim, and blend into more of an average grey. I feel that's one of the main reasons quake world textures look better unfiltered, it's the pixel art precision of some details that get desaturated and dulled in filtered mode. 
Ok, since metl mentioned it, the sparkly pixel movement phenomena is temporal aliasing. I want temporal antialiasing in Quake. 
Get Him!!! (Yells The Engine Coders) 
GL_NEAREST_MIPMAP_LINEAR is the best compromise IMO. Sparkles are caused more by not using mipmaps than by using nearest filtering, and linear sampling between miplevels eases miplevel transition artefacts. The other improvement is to use screen-space derivitaves from unwarped texcoords when sampling warped textures, otherwise they shift between miplevels as they warp. One of those things you normally don't notice until it's pointed out to you, then you can't stop noticing it. 
yeah my settings are GL_NEAREST_MIPMAP_LINEAR + anisotropic set to the max. The thing i don't like about mipmapping in hardware rendering is how floors (and other edge-on polygons) blur into a solid color, and anisotropic reduces that problem quite a bit. 
Agreed, anisotropic is essential. Different people are different, so I tend to find anything beyond 4x is not that big a deal, but I won't go below 4x. 
Edged Mipmapping Artifacts 
It would be nice if there was a way to detect the edge of a face that also corresponds to the edge of a texture and clamp the texture so that it doesn't bleed the color from the opposite side of the texture over. 
What I Would Like To See!..? 
I want to see all of the models from Banjo Kazooie converted to mdl, with all of the animations kept intact. The Quake marine's model should be altered to have a backpack on his back that Kazooie occasionally pops out of. Also, the Quake marine can now double jump, and on the second jump the player can see Kazooie pop out of the backpack and flap her wings. Also, I would like to see a map that completely re-creates Gruntilda's lair and... Ahh f*ck it, I'm just going to go play Banjo Kazooie...

Seriously, I would love to see some kind of volumetric fog implementation similar to what is seen in Quake 3. 
Centerprint with constant cheesey rhymes 
Gruntilda Says: 
Ranger will end up slobbering,
after the Shambler gives him a clobbering.

And so forth. 
Volumetric Fog Is Definitely A Good Call... 
...given how well normal fog can be used.

Also pretty sure the edges of objects have the same definition i.e. a straight fucking line, regardless of what texture mode you're in. Anyway, you're all wrong, I've been playing with GL since it first came out and fuck everything else. 
Just adopt Q3 BSP already if you want stuff like volumetric fog. :) 
Another thing that no current Quake engine does, AFAIK, is gamma-correct mip-mapping: 
As you should know by now, the value 187 is actually half-way between o and 255. 
And The Actual Quote Is Half Between 128 And 255 
Wrong. The problem is that that article was very poorly written. Here's the actual equation for gamma-correct gray:


Most of the gamma correction articles on the web are poorly written. 
in terms of photon counts, that's entirely correct.
so if you want correct lighting, then you need a pipeline that is actually aware of srgb (eg: vid_srgb 2 - note that you'll need to reload all the textures too).

using hardware srgb extensions to basically disable srgb (yes, backwards, the extensions are all a pain to read, and with drivers giving the wrong results too) gives you brighter darks and also resists oversaturation much better (which makes rtlights+specular much more tollerable).
but yeah, dark areas being brighter kinda hurts the whole quake ambience, and it draws more attention to how rtlights have sudden cutoffs instead of fading to infinity. I'm sure deathmatch players would love it though.

also reduces banding with eg r_lightmap 1.

and regarding gamma-incorrect mipmapping - textures that get darker with distance is a feature, not a bug! :P
(or use dds files that were generated with a proper tool) 
A Tronyn Release 
Er wait the thread said "Realistically" ha ha. Inspiring to see all the ideas people have.

P.S. to Qmaster: Will email you soon (i.e. this month). 
#280 & #281 
That's interesting. I probably should read up on that.

What - Realistically - Do You Want To See In Quake In 2018??

Realtime lightmap generation for in-editor preview. 
@Tronyn, Good Was Wondering 
+1 editor lighting preview. 
Seconding real-time lighting preview. Lighting a map is one of the worst workflows in quake level design, due to the slow iteration cycle.

When I think about this feature, most lighting edits are very localized (adding/moving/deleting a light, editing radius/brightness/falloff on a light.) An individual light usually touches only a small portion of the bsp. If you start with a bsp with all lighting calculated, you should be able to mark and relight only the small number of affected surfaces, after each edit to a light entity. Then you could get into a flow where you just go in and make a bunch of tweaks, seeing the results almost instantly, until you are happy, and then save the changes back to the .map file.

The hard part I think is that such a tool requires a bsp renderer, a map editor, and a lightmap generator, which are traditionally 3 different programs and everyone wants to use their personal favorite of all 3. Not sure where this new functionality could/should be added. 
Speeding Up Lighting Iterations 
What editors support region compiling?

In some versions of radiant, you just drag a brush out to define a region to compile and the editor then only sends that small subset of the map to the compiler, automatically boxed in, with an info_player_start added where the camera was.

That's a pretty straightforward thing to add to an editor, and would massively help you do quick iterations when mucking around with localised lighting. 
The best approach would be to edit the light entities in the engine itself, save a diff file containing the modified light entities, and make the engine call the external light utility to recompile the lights.

Upon parsing the diff, the light/BSP compiler would check which lights were removed/added/modified, and relight only the surfaces affected by them.

However, Quake's lightmap format still has some annoying limitations that restricts the productivity potential of such an approach. Dirtmaps, sunlights and bounce lighting would likely require the.whole lighting to be recompiled anyway. And the lightmap doesn't keep track of which light entities affected each surface. 
Kinn Means Cordons. Hammer Has This. 
He's right I've used it in one of the Radiant's before. Would be a great addition to TB. 
Speaking of editors, I'd like to see JACK being improved. It's sad that its author seems to be very averse to criticism, because JACK is a great editor and could become even better. Now it seems to be discontinued.

I don't understand why XaeroX overreacts when some people talk to him. I don't remember anyone attacking him anywhere. 
The Steam Comments For JACK Weren't Very....helpful 
But ya I agree. I use JACK all the time. 
If you happen to read this, and who knows if you will --

I want to apologize for being an angry beer-drinking guy.

I had a super-frustrating day coding with several layers of unwanted bad news getting in the way of my ideas.

My brilliant thought was "Fuck it, let's get super-smashed, I'm so sick of winter -- let's go!".

I'm quite embarrassed by the idiocy I did. Even more comical, I thought I was thinking.

Anyway, the important part -- you acted with class instead of telling me where to go --- which you probably should have. 
No apology needed as it was pretty hilarious. Welcome back after your hangover :) 
I hope it was hilarious, but obv that is not how I feel about it.

The crazy thing, haha -- my hangover was zero.

My first thoughts when I woke: Wait? WTF? I feel so relaxed. Why don't I have a level 25 hangover? I drank enough to kill small mammals. Maybe I instinctually drank tons of water, but hell if I know.

My second thought when I woke: "Fuck!!! I posted @ func. God dammit. I know not to drunk post. FUCK!!!!!!!" 
It's Spud. 
In retrospect Snug is a much snazzier sounding handle, though.

@Baker: Don't sweat it. 
Ya Don't Worry About It Baker 
In 2018, I want to see at least one map easter egg about drunk Baker. 
@Baker: Don't sweat it.

Thank you. 
@bAKER: Been there, done that, i'm sure you've witnessed more than a few of my own rants :( I hope you're drinking 3.2% cause 17 beers oof!

I tried the menus and they do work great!
some engines in the past put all the options on a horizontal row at the top *bleh!* But yours is just natural; quake-style. And as some have mentioned there's a few spots to buff out. But for the most part nice work! 
2018 For Quake? 
I was just thinking about how cool it would be to have a quake/arcane dimensions 8km x 8km map/mod that had a full 200 players per server with little towns to venture to, to fight hordes of monsters or other players with quests etc. hmm maybe like a world of quake-craft but a merge of coop/pvp on a huge map with faithful art assets.

sorry just mumbling over here at 3:13am :D 
Thanks for checking out the mouse menu, R00k.

Yeah, I'm a stick in the mud conservative that couldn't accept a menu with any changes in the appearance.

I was just thinking about how cool it would be to have a quake/arcane dimensions 8km x 8km map/mod that had a full 200 players per server with little towns to venture to"

If you look at some of capabilities in Mark V, I am angling in that direction. It has a mod installer built-in, ipv6, some severely enhanced coop features.

Combined with some of Spike's work in Quakespasm Spiked, this is almost possible now in theory.

That type of thinking is what I ultimately want.

The ability to co-operative play easily in an immersive multi-player environment.

Makarate once ran a Quakeworld coop server using the Undergate level I made. And obv, my work with RocketGuy on RQuake coop and his then popular coop server.

And of course, Gunter who even now runs a Quake co-op server ;-) 
Given that Ter Shibboleth apparently required some pretty hefty code-monkeying to make happen ("...where [ericw] entirely re-wrote the leak code just so the map would compile"), I don't even want to think about what havoc and even larger map would wreak on editors, compilers, and the engine itself... not to mention the player's framerate. 
@spud - Co-op Used To Be Normal 
I try to not mention this often, but the Quake bsp compile tools -- specifically vis -- does a horrible job.

You can find some discussions where mh, me, ericw and probably Spike discuss this in the Quakespasm thread.

It used to be normal for maps to co-op. Like Tronyn's Mask of the Red Death or Sewage Devastation.

czg's honey coops just fine. <----

Co-operative play isn't an alien idea, it used to be normal and expected that all released Quake maps would co-op.

That thinking kind of got lost in part because many maps required bsp2 and such and wouldn't work in, say, Quakeworld.

Coops ... Yes ...

And probably 90%-95% of all past single player releases that aren't bsp2.

Co-op ability simply used to be normal. There is scarcely a map by czg, necros, tronyn, pulsar, distrans, etc. that doesn't co-op. 
Oh, I Wasn't Talking About The Co-op Part 
More the size and complexity of the map part, regardless of how many info_player_coops it includes. 
Unnecessary Side Note Double Post 
Holy shit Quaddicted works in Waterfox now, neat. 
Needs to be designed for. E.g. a gate closes behind you locking you in to an area, e.g. for an arena fight or a puzzle. Your poor coop buddy gets squished by the gate, resses, runs back only to have to wait for the first player to kill all...crap he died too. Now you have to restart the whole level and cheat yourself back the weapons and ammo you had.

Desigb for coop please. 
I know it's just dreaming but FTE can handle pretty big maps. This isnt a new idea, years ago people were all talking about taking all the id1 maps and combine them into one huge map! I think that is a doable thing. and imagine 200 people playing across all those maps on 1 server doing their thing.. i think either coop of pvp that would be fun to play. and then imagine its not id1 maps but a whole little quake-world.. :boom: mind blown ! :^D 
Half Way Through 2018... 
So, have any of your realistic wishes come true?

I'm still hoping for 5.1 surround and rumble support. 
As of today we're precisely halfway into 2018, a good excuse to revisit the 2018 expectations as any...

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.

This isn't really happening, LOL. With 22 maps in the DM4 Jam and 19 maps in the 100 brush competition the huge spurts of mappage are probably to stay. At least the deadlines are more reasonable now than last year.

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.

In the past 6 months we saw 87 Q1SPs get released. Not sure how much of it is down to "less perfectionism", but the maps are smaller and less polished on average - which is not a bad thing at all.

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

Hasn't matterialised yet, but there's at least 3 regular episodes in development currently.

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.

Hasn't happened yet either, and there are none in development to my knowledge, but I'm still holding out hope.

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.

21 Quoth maps were released this year so far. I'm pretty happy with this turnout but also not 100% satisfied with how Quoth was used in them, obviously the 100 brush limit was harsh but I'm very much down for a necros style map with lots of rotating stuff and clever entity stuff.

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.

None in 2018 so far. Maybe some sort of tutorial would encourage mappers to get more colors in their maps.

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.

Not sure there's much interest for such an event happening, sadly.

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

I'm 50/50 on this, since some people on the list have delivered lots, some have delivered a few, and some not at all (Spud mapping is good, but where's the rest of QUMP?)

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

Now this is the one prediction that has delivered in spades!! Since the beginning of the year we've had 15 map releases from newcomers. With TB and dumptruck's A+ tutorials I expect this number to double in the next 6 months.

More banter from Shambler.

The banter is here alright, as on-point and stingy as ever.

Quakespasm 1.0.

I typed this one without much thought as to what a 1.0 release should actually entail; but there would be high potential for both mappers and players (specifically the newcomers) in having DP particle support, CSQC support, Twitch chat relay support, etc. in one, unified, easy to install, well documented edition of Quakespasm.

TLDR We're doing rather well in 2018, Q.E.D. 
TC Dreams 
Sometimes I think about a TC. And then I think about how much harder it would be to make all those models vs. all the sprites people can use in Doom :( 
@311, 312 
(Spud mapping is good, but where's the rest of QUMP?)
Hey now, according to a quick Quaddicted search, Danzadan, Naitelvenividivici, Newhouse, and Pritchard have all released maps since QUMP, and I think a few others are currently making maps for upcoming map-things. Unless you mean specifically the rest whom QUMP was their first released map in which case nobody here but us chickens, sorry.

And then I think about how much harder it would be to make all those models vs. all the sprites people can use in Doom :(
And all the shenanigans about custom HUD layouts and such that require clientside QC and thus severely limit port choice, and learning QuakeC in general instead of relying on sourceport specific languages that hold your hand all the way through, and the smaller playerbase in general that will end up playing it and tends to be rather picky about what they want in their Quake maps. It's way easier to just kitbash some sprites together, add custom sounds, modify some premade weapons, and boom, Doom total conversion. I'm not bitter at all. 
Sprites can work very well with top-down or sidescroller cameras. And Quake is much better for coding such kinds of TCs than Doom. Examples: Prydon Gate, TargetQuake
I Made A Qump Map... 
Now I'm sitting around with a severe case of Dunning-Kruger. I just about managed to finish my Qump map last year, before hitting the bottom of the slope. 
(Spud mapping is good, but where's the rest of QUMP?)

i may release a map this year, but no promises

i don't have much time, and this year i'm playing xcom 2/skyrim too. i didn't play dmjam4 or 100brush yet! 
More Mods / Modern Tools 
Would love to play more mods or see people revive features from older mods like extras r4's water hacks.

Would also like to see updated tools that are more future proof. I updated my drivers yesterday and now QuArK cannot display MDLs. These issues are likely to get worse. 
+1 For Tools 
I want a simple tool for exporting skins, importing skins on models or frames on sprites. QME is sluggish and has no dragndrop and doesn't support sprites. AdQuedit is worse.

I want a Wally that doesn't crash or basically addons for Gimp that give me the amazing pixelly filters.

An updated Blender addon that has support for multiple skins on export to mdl.

Psst, I'm already reviving features from mods but not wanting to spam that too much, people get tired of hearing about Keep it seems.

Wait...Quark!!?!? Yeesh, what good is that for anymore?? 
Tools are in sore need indeed. I'll create my own tools, but only after my engine work is complete (which should only take a decade or so).

My current toolset is TexMex, fimg, The GIMP, qME, PakExplorer, JACK, EricW's tools, and some other stuff. 
More Stuff Is Good Ya 
The Blender tools is a big +1.
I'm working on a bowl of fruits .mdl for Quake, apples and bananas, maybe some grapes. Quake needs some fruits. But you can't export with more than 1 skin in Blender. How am I supposed to have green apples or red apples?

And don't think about using QMe. It will destroy your vertex normals. Because its evil. 
Also Nth-ing Tools 
The workflow for just mapping and making textures isn't bad but as already discussed above the toolset for modeling is far worse and if you want to do stuff like edit the conchars file you have to pray to your deity of choice that you remember to export and import in the right order in the right programs (including goddamn AdQuedit which is apparently the only editor to properly handle it as the specific console characters file instead of just a .spr). 
Hmm… Creating whole new tools for simple stuff like conchars editing doesn't sound like the best approach for me.

A GIMP plugin for loading and saving LMP images could be enough. 
GIMP is awkward and unproductive.

Takes 5, 10 or 20 clicks to do what many other alternatives can do in 1 or 2.

It also takes things easy to do in most other editors and finds a way to make them needlessly difficult. 
Redfield, you can have a dozen different colored apples. MDL supports multiple skins. Just create additional skins for your model in QME with 1 click. Then recolor your skin with your favorit editor and add it into your mdl file. Yes, adding skin textures is also done with QME with another click.

You may speak bad about QME, but it can do unique things to your mdl file that not many other tools can do. It has its strenght and its weakness. Just like all other tools out there.

If you do not want to use it for modeling thats fine. But do not underestimate all the other things it can do. Yes, also setting (trail) flags to models and so many other stuff. 
re: QuArK. I use it to take a look at models and wads. Wally is really buggy on my machine and the white background makes it difficult to see the textures. QuArk uses a black background and show animations for buttons etc. I've never used the level editor but for other things QuArK is pretty handy. The UI is terrible. 
I would like to revise my answer to:

A single map by me that I actually like which isn't part of any sort of jam or speed scenario.

I'll be happy with that. 
Quark,what good is that for anymore?

I use Quark4.07 for lots of model additions, may be old but gold for me. 
QuArK duplicates all vertices belonging to both front-faced and back-faced triangles. 
I See 
Good for view, not for saving

I miss QuakeWebTools. The dragndrop rocked and worked for viewing sprites and models and exporting skins. What happened to that? 
#329 - It's On Github 
Quake Web Tools
You should be able to run it by yourself. 
Another remarkable fact, although nowadays not so important, is that models loaded in quark and saved again tend to incline a lot of size.

What I'm trying to say is, when a model has a size by example 800kb one upload to Quark and saving it again reduces it to 200kb, without noticing changes.

I have no idea why this is so, but it saves some space, especialy with large models. 
Models saved in qME 3.0 contains additional higher-accuracy vertex coordinates (which are ignored by the engine, but are useful when modifying the same model again). Re-saving them in another editor will delete that data.

qME 3.1 changed that behavior, storing the higher-res vertex coordinates in its MDO format only.

There may also be other kinds of extra metadata stored in MDL files. 
That explains a lot. Never paid attention to it.
I can't see no difference between both. The grid is rather rough I thought, 512x512. 
Quake 2 Stuff, mainly now that we will have the tools and ports to it.

A Tenbebrae Reborn with Quakespasm and vkQuake stuff, or vice versa with vkQ. 
Uncapped Frame Rate 
All I really want is to get an engine like quakespasm to have the ability to use a frame rate higher than 72 without the physics messing up 
Use QuakeSpasm-Spiked then. 
Type host_maxfps 0 in Quakespasm-Spiked console to decouple the framerate. More info at 3.1 here 
Off hand, that is probably is a bad idea.

You'll get a lot of frame rate variation.

And if you get really high fps, you might overheat your graphics card.

Quakespasm, Quakespasm Spiked and FTE love to overheat with no map running ... (not that DarkPlaces doesn't love this also).

Kicking out tons of frames per second rendering the console over and over again.

Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

In contrast, Mark V throttles down when no map is running or not the active application. No point in rendering an idle console 700 times per second or rendering hundreds of frames per second when the app isn't even active.

/My thoughts 
Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

Interesting, that reminds me of when i got my latest computer and began to install old games (from around 1990) and the computer began to overheat, as it happened with several others. Curiously it didn´t happen when they weren´t on fulscreen. 
I set mine to 144 to match my monitor. 
If you really want to let it rip, set sys_throttle 0 too, otherwise it'll still idle a little (and thus struggle to go above 800fps iirc).

cl_idlefps defaults to 30 in FTE - the equivalent of your selling point for your own engine. if you cleared that cvar then you're getting exactly what you asked for.
DP has cl_maxidlefps. Same behaviour. 
Spike, I looked at the code it looks like your intentions are right.

That being said, when FTE is not active app for me, it uses 50% cpu. This laptop is dual-core that is that is the most it could use (100% of one core).

Here is FTE in idle (50% cpu): screenshot

Here is Mark V in idle (9% cpu): screenshot

And right now, my video fan is finally spinning down some after FTE had it screaming.

FTE going idle causes my video fan to go crazy.

FTE operates fine when it is the active application. 
Windows 9x interface will always be the best.

I'm particularly fond of the Windows Me interface, too bad the underlying OS was crippled. 
Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

In contrast, Mark V throttles down when no map is running or not the active application. No point in rendering an idle console 700 times per second or rendering hundreds of frames per second when the app isn't even active.

Oh shit, so that's what that is.

A fix for QS/QSS would be great. I have a laptop, and it will cook itself if I'm not really careful. 
My original interest in throttling down came from ORL.

Long ago, he ran a server and was kind of insistent it needed a feature from Ben Jardrup's Quake named sv_sleep or host_sleep or something so that the server used very little cpu. I was shocked by the cpu usage reduction.

(Quakeworld has always had this in the server side to make it use low cpu).

In ProQuake, in one release I enabled it by default as it seemed to be fine in single player and pretty ok in multiplayer.

Multiplayer complaints came rolling in hard and heavy and en mass, especially those using very high fps for smooth lightning gun aim.

So I disabled it. Later I made it only apply when no map was running or if the application was in the background.

GLQuake does have a lesser form of this, so does FitzQuake. But it never made its way over to FitzQuake SDL or later to Quakespasm.

[For other fun, in windowed mode in Quakespasm ... minimize the window ----> BOOM! Also the mouse moves when the window doesn't have focus unlike FitzQuake or GLQuake ... and Quakespasm Spiked ... do "Single Player"->"New Game". Watch while nothing happens.

No one seems to report these things to the engine developers ... a bit curious.] 
cl_yieldcpu 1

tbh, just use vsync.
with host_maxfps 0 or so, so that you don't confuse any prediction your driver might be doing, and thus get lower latency from it.
with vsync it might report 100% of a cpu core, but your drivers will be using some fancy low-power instruction to wake up as soon as the gpu pokes it instead of depending upon the operating system's (shoddy) timings (same reason I'm too paranoid to default fte's cl_yieldcpu cvar to 1).

any modern game will have some vsync option in its menus, though old opengl programs might leave it to your drivers to force the setting
which might also be useful for any games that don't allow you to use the swap-tear extension (which can help when drivers guess timings badly if nothing else). 
Spike --- no difference. Now this is FTE 5020 from April 2018 +/-.

cl_cpuyield 1 -- screenshot 
@spike - Re-review 
If I set cl_idlefps to 30 and cl_yieldcpu, the cpu usage when FTE isn't the active app is quite good.


But cl_idlefps defaults 0 according to the screenshot. Which was the source of my pain and frustration. 
When I think about this feature, most lighting edits are very localized

Most if my lights are surface lights. Very few of them are very localized. Sunlight and then surface lights coming from light fixtures, liquids and some special textures like teleport destination pads. Maybe the editor should compile the portion in the viewport first and then the rest in background. 
I've had instances where the surface lights didn't line up with the texture. This has only happened on nonorthogonal constructions. Was wondering if you have encountered this and how often to you play with the -surfacelight_subdivide parm? 
I don't know a way to see the generated lights to check for misalignments. I just trust it works. And I never played with surfacelight_subdivide, tbh. I just tweak the light entity. Need to follow one of your tutorials to see those :P 
I still want definable fog volumes via brush (func_fog) or something

and decals 
Thanks for the great info guys. I love the smoother feeling of higher frame rates but hate how many plats and trains hurt the player when HOST_MAXFPS is above 72 in most engines.

Love the mapping tutorials. Keep it up.

I would love to have decals and multiple fogs. It would make maps with multiple distinct atmospheres easier to make. 
decals can be faked well enough with fence textures in my experience. Multiple fogs = multiple settings for fog depending on where you are in the map? If so, AD has it.

My 2018 dream at the moment is actually making a complete map... 
Thoughts And Rumblings 
We have a lot of this stuff if you are willing to use engines like FTE, DP and to some extent QSS.

For example, decals are very much a thing in those engines.

If these are just posts requesting QuakeSpasm to introduce more and more graphical whizbangery, then it needs to be specified really. 
Yeah, that's quite true. Also, isn't the point of QS to be a faithful port that runs the game without any bells and whistles? You can argue that things like decoupling framerate and physics still fits within this mission objective, but I don't think that QS should be adding things like (proper) decals... 
isn't the point of QS to be a faithful port that runs the game without any bells and whistles

Yes, well...kinda. I suppose there's a sort of vague, entirely subjective "yeah that still feels quakey" filter for classifying something as "fits the QS philosophy" as opposed to "unnecessary eye-candy shite".

For example, no-one here will say fog or coloured lighting shouldn't be in QuakeSpasm.

Tough call really! 
Forgive me if I'm forgetting my 'Quake Engine History 101' lessons, but aren't most of the features that QS has that aren't 'standard quake' inherited from FitzQuake? It wouldn't make much sense to try and remove those, but the argument I feel can be made that treating that as the feature cutoff point is a sensible idea.

At least, having such a point is a good idea if you want to be seen as the 'core' engine that provides the basic expected functionality for modern quake. It could be declared today of course, or for QS 1.0... 
It's a really tough one to call and ultimately we should be grateful that QS is curated by people who have sensible opinions on what is "quakey" and what is "not quakey ahhhh my fucking eyes".

I do not agree in having a "not in fitzquake therefore we shouldn't do it", cut-off because there's loads of really good potential future things that would benefit quake and still be quakey.

For example, I would looove at some point to see proper static meshes with lightmaps that integrate with the rest of the world lightmaps (to avoid nasty obj2map abuse).

But it's all down to the QS coders and as I said we're lucky that these chaps tend to be on the same page as us. 
no one here will say fog or coloured lighting shouldn't be in QuakeSpasm.

Fog shouldn't be in QuakeSpasm. It's not featured in any of the official versions of Quake (Quake, GLQuake, QW, GLQW, Saturn Quake, Quake 64, and the obscure official ports to dead hardware accelerators). Coloured lighting, however, is present on both Saturn Quake and Quake 64. The Saturn port doesn't use the Quake engine but still is an official port of the game.

That said, community-made maps uses non-Quake features such as fog and skyboxes in too many maps for these features to be ignored. I don't remember a single AD map not using fog. So, they shouldn't be, but they need to be. 
Fitzquake isn't just an engine for playing id maps. It is also for playing custom maps. Those features were added so you can play most custom maps as mappers intended. When mappers added fog, colored light, external textures, entity alpha, extended entity limits to their maps, I wanted to be able to experience those maps correctly. I think fence textures and bsp2 support (which QS added) are in line with this philosophy. They don't make existing maps look wrong, they only allow new maps to look/work the way the mapper wants. 
Power To The Mapper 
Go map! 
This Here 
They don't make existing maps look wrong, they only allow new maps to look/work the way the mapper wants.

This is why I am more interested in QSS than FTE or DP. From a mapper's POV anyway. 
Fog is perhaps the single greatest feature ever added to these source ports. No better way to instantly create a beautiful atmosphere. 
Oh absolutely.

BTW - it's possible to make FTE look really, really like Quake - more like Quake than QuakeSpasm currently does actually, because you can enable a lovely 8-bit colormap lighting mode, and mdl lighting that's almost identical to WinQuake (the Fitz/QS mdl lighting is still too bright).

But "out of the box" it has a load of silly stuff turned on (as does DP), so I understand why people are instinctively turned off by it. 
The destruction of my config.cfg file is what REALLY turns me off about FTE. 
depends which preset the user picks when they first run it.

Note that you can force cvars to some specific value in FTE using worldspawn keys, eg: _cvar_r_shadow_realtime_world 0 to cripple any attempt by the user to use rtlights on your map.
Whether it works properly with cvars that need a vid_reload is a different matter, but disabling world lights is fine, and probably needed if your map has lots of lights that use the delay field.

FTE does NOT write a config.cfg - it writes an fte.cfg instead. And it usually writes it to your home dir somewhere too (although you can disable that part with -nohome if you really want). 
Note that you can force cvars to some specific value in FTE using worldspawn keys, eg: _cvar_r_shadow_realtime_world 0 to cripple any attempt by the user to use rtlights on your map.

Ooh, that's pretty good to know.... >:} 
Sorry if I am getting confused but I recall my configs and settings being borked the last time I tried FTE and then went back to another engine. I was a while ago. For recent testing I have an isolated FTE install.

So does FTE keep all my video settings and key bindings untouched if I switch between engines? 
Fte Configs 
that's the idea yes - so long as you use the cfg_save command (or quit via the menu and pick 'yes' to save, or set cfg_save_auto 1). 
Thanks for that tip, I'll definitely need it for my maps.

I really should spend more time with FTE. It was by far the easiest solution when trying to set up LAN coop on short notice when I was at a friend's house - other engines had socket errors - and I enjoyed my time with it, as brief as it was. 
1 post not shown on this page because it was spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.