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. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.