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