#1 posted by Quaker on 2017/12/26 15:20:20
I’d love to see something like a mega-map jam. Maps with a few hundred monsters and loads and loads of secrets and extra little hidden bits and pieces. I think that’d be great fun!
 TB 2.1
 Scripting
#3 posted by DaZ on 2017/12/26 15:34:35
I would love to see an engine like Quakespasm implement a robust level scripting language so we can get away from these unwieldy entity chains.
I would love local fog volumes and volumetrics to make their way into the game (but in a suitable Quakey way).
And finally, I'd like a repeat of the bumper map release year that 2017 was. So many cool maps! :)
 More Base/horde Maps
#4 posted by Kingold on 2017/12/26 15:41:01
I want to see more maps in a vein similar to Rubicon Rumble Packs.
I also want to see more releases from Tronyn. Unforgiven, SOE: Indian Summer and other maps/mods from him are among my favourites.
 #2
#5 posted by Shambler on 2017/12/26 15:41:20
I did say realistic aims....:P
 Tasteful Low Poly Remakes Of All Quake Models
#6 posted by iriyap on 2017/12/26 17:53:20
Something like about 700 polys per monster model, proper UV maps and better animation, full compatibility with WinQuake.
The original models are quite bad, as it was id's first foray into 3D modeling and they tried to apply 2D graphics concepts to it (like the UV maps being simple front/back shots of a creature). It'd be really cool to have the models remade by somebody with a good understanding of low poly graphics. For example.
 Split Screen Multiplayer
with controller support.
 Cuntor
I'd love to see some support for fog brushes and water that settles into its area.
oh and decals.... definitely decals
 New Low Poly Models + Reborn Of Multiplayer
#11 posted by +Icaro+ on 2017/12/26 19:16:16
 Volumetric Fog
Would rule actually.
 Less Drama, More Mapping
#13 posted by Breezeep_ on 2017/12/26 19:36:07
#14 posted by SavageX on 2017/12/26 19:40:22
- seeing software-rendererd Quake on RISC-V Linux development boards (needs a 64-bit clean engine with a pure-C software renderer - is something like this available?). No 3D hardware can be assumed at this stage.
- more widespread engine-support for MD3 and IQM
- DP particles in more engines
 Reallistically
#15 posted by Cocerello on 2017/12/26 20:16:39
Commercially wise i would be fine with something similar to the last Doom in terms of gameplay ported to Quake's theme and style, so at least a bit more vertical and less arcade-like.
In custom maps, more variety in types of gameplay and brushwork style. Even with all the fresh blood, i think that has been reducing with each passing year bit by bit in the last three-four years.
 Engine Development *cough* Eric *cough*
Three things I'd like to see added to Quakespasm:
I'd love 5.1 surround sound. Quake's dark eerie atmosphere is just crying out for it.
I'd also love rumble support for controllers... I mean, the game's called Quake for goodness sake!
Finally, I'd love full Nehahra support. It's a seminal work and I'd love to play it in a seminal port.
Obviously, these are just wishes and not demands. :)
Other than that, I'd love to see more AD maps. The touches that AD bring to Quake are wonderful.
Also, Trent Reznor to FINALLY release the OST vinyl and shine a spotlight onto this great game once more.
 Nehahra Support In QuakeSpasm
#17 posted by iriyap on 2017/12/26 20:51:33
I'd rather vote against it to be honest.
Now let me explain myself.
Nehahra does so many things in a weird way, e.g. loading skyboxes and music tracks via console commands instead of using worldspawn (basically the "properties" area of a level) like all the other Quake engines and id's later games. It's using MOD music instead of MP3s/OGGs because bandwidth considerations was a thing back then. It's got custom formats for maps, sprites and demos because reasons. Nehahra should ideally be updated to be inline with the modern engines, not the other way around, where you would include all kinds of ass-backwards code just to support a single mod. It's a great mod mind you, I had plenty of fun revisiting it this year, but yeah, it needs to be updated. The source code (both QuakeC and engine) is available, so somebody should really do it. I've got a big stash with all original Nehahra downloads if somebody needs it.
Might as well fix all the random fullbright pixels and the extra twitchy AI while you're at it.
#18 posted by Kinn on 2017/12/26 20:58:13
Nehahra should ideally be updated to be inline with the modern engines, not the other way around
This times a million. I don't think Quakespasm should be cluttered with a ton of #ifdef NEHAHRA crud.
 ^Good Point(s)
Okay then, I would like to see Nehahra updated to modern standards. :P
 Fog And Better But True-to-Quake Models.
#20 posted by Shambler on 2017/12/26 22:04:58
I am really liking those ideas. Seeing the new Shambler model shows the potential for actually getting it right....
 5.1Surround In QS .0.9x
I second this. Would be cool and doable as all q1 assets are mono. Tons of 5.1 and 7.1 headphones out there. This would be a great addition.
Would like to Mod menu and Demo menu added to QS as well.
#22 posted by narcos on 2017/12/26 22:51:54
Split-screen and controller support, definitely.
#23 posted by muk on 2017/12/27 00:10:10
Xmasjam2017 released
 Hmm..
#24 posted by Qmaster on 2017/12/27 00:35:14
Keep 1.0
TB featureset match or exceed JACK (ALT+RMB!)
Large release from long forgotten mapper(s).
Alpha support on fence textures below 0.666.
Retroquad 1.0
Volumetric fog.
Surround sound support.
AD-level quality models for everything.
AD 3.0
Splitscreen
Advanced qc support to fix "entity chains". (I could maybe do this ;) ).
200 MAPS. GO MAP!!
 Wishes...
#25 posted by Barnak on 2017/12/27 01:52:52
Spike FX fully integrated in official QS.
Also a new vore model with puffy tits and a dripping bloody snatch with teeth.
#26 posted by scar3crow on 2017/12/27 02:52:00
Robust multiplayer (including QW support, server browser) in QuakeSpasm so we could have a single engine to point people at for getting into Quake for any degree of single or multiplayer, maps, and mods.
Fog brushes
Lightmaps on liquids
Alpha dictated by material and relative depth (water on the shore is more translucent than water a few feet out - and the base value is impacted by the texture used)
Physics correct (to Quake's logic) movable liquids
More Quake mods in general, not TCs, not experiments, not appended content and mapping tools, but gameplay mods that let you meaningfully replay existing content.
#27 posted by R00k on 2017/12/27 03:04:43
personally i would like to see if i kill an enemy i get his weapon
 /s
#28 posted by PRITCHARD on 2017/12/27 03:12:31
Steam Workshop Support
 Decouple Physics From Rendering Framerate
#29 posted by Qmaster on 2017/12/27 04:12:19
#30 posted by yhe1 on 2017/12/27 05:44:24
#31 posted by Skiffy on 2017/12/27 10:39:46
Skeletal mesh support and blend / morph so I can use the best of both worlds.
Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though.
Limb loss for monsters. In general a more expanded gore system. I like making custom gibs and it be fun to shoot off bodyparts and the monster still keeps fighting.
I second more advance water volumes that accept lighting and foam. Murky swamp water with bits floating in it would be nice. Stuff inside water volumes like pond scum.
Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...
Reflections on water and glass... :) and a nice FX editor for particles.
 Kinn
#32 posted by anonymous user on 2017/12/27 12:16:37
An option to emulate the 8-bit colour look of software quake (with its crunchy banded lighting etc.) in Quakespasm.
#33 posted by Kinn on 2017/12/27 12:17:37
not to self: Title != Name
 I Would Specifically Like To See...
#34 posted by Shambler on 2017/12/27 12:40:23
NO split-screen.
NO fucking controller support you arse suckers.
Deep-coding in Quakespasm and all other major engines to prevent split-screen and controller support being added.
 Wtf Shambler Ha
#35 posted by Skiffy on 2017/12/27 12:44:52
Thats some dark ages type thinking hehe. Heresy i say! The 8bit color banding with dithering would be nice. Easy enough to do as a shader.
 OTOH
#36 posted by Shambler on 2017/12/27 12:47:14
TB 2.1
I would love to see an engine like Quakespasm implement a robust level scripting language so we can get away from these unwieldy entity chains.
I would love local fog volumes and volumetrics to make their way into the game (but in a suitable Quakey way).
Tasteful Low Poly Remakes Of All Quake Models
In custom maps, more variety in types of gameplay and brushwork style. Even with all the fresh blood, i think that has been reducing with each passing year bit by bit in the last three-four years.
I'd love to see some support for fog brushes and water that settles into its area.
oh and decals.... definitely decals
Lightmaps on liquids
Alpha dictated by material and relative depth (water on the shore is more translucent than water a few feet out - and the base value is impacted by the texture used)
Physics correct (to Quake's logic) movable liquids
Limb loss for monsters. In general a more expanded gore system. I like making custom gibs and it be fun to shoot off bodyparts and the monster still keeps fighting.
I second more advance water volumes that accept lighting and foam. Murky swamp water with bits floating in it would be nice. Stuff inside water volumes like pond scum.
Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...
Reflections on water and glass... :) and a nice FX editor for particles.
All of these sound interesting / promising / potentially desirable if done well. They are pretty much in line with one of my main desires:
Keep having Quake graphics / effects / features slowly and tastefully enhanced while keeping true to Quake. I.e. no big crazy leaps with HD monster shaders or whatever bullshit. Just keep adding the small stuff like has already been done with fog / particles / skyboxes / breakables etc etc, and encourage people to use them subtley and Quakily. I think stuff like ad/spikespasm is doing this pretty well and far more effectively than the pseudo-AAA OTT jumps in Darkplaces etc, and I hope that can continue with some of the ideas above.
 Also.
#37 posted by Shambler on 2017/12/27 12:50:02
I'd like to see more smaller / non-horde / non-epic maps with interesting gameplay, convoluted layouts and cool designs. Not everything has to be a mega-map, mappers don't need to tie themselves into knots trying to emulate Swampy/RR/Sepulchre/Marcher etc.
And finally for now...
I want to see ALL maps showing a strong theme with their design language and architectural styles, not just their texture sets.
 More Skiffy Models
 Shambles
#39 posted by Kinn on 2017/12/27 13:17:24
Quakespasm already has controller support. I always use it because I much prefer it to mouse & kb. I play my quakes on a 43-inch TV screen whilst sitting back in a comfy chair with a controller.
Split-screen would be awesome btw.
 Well. I Hope For No More Kinn Maps Then.
#40 posted by Shambler on 2017/12/27 13:33:23
#realistic :P
 Wish List
#41 posted by killpixel on 2017/12/27 16:49:44
fog volumes
Decouple Physics From Rendering Framerate
An option to emulate the 8-bit colour look of software quake (with its crunchy banded lighting etc.) in Quakespasm.
Mod menu and Demo menu added to QS
+1
Personally, I'd like to see a nice vanilla episode (or set of four).
In regards to some of the suggestions concerning graphical niceties (fog, lightmapped water, reflections, alpha and other blend modes, etc): fully supporting q3map2 and its shaders would get you all of that.
#42 posted by topher on 2017/12/27 17:59:18
i would like to have the time in the first place and then the inspiration to release a couple of maps
more short AD maps.
gameplay tweaks for vanilla and/or AD. for example i would have liked scrags that stay in their Z plane and shoot from there instead of flying to the same Z plane that the player. or that they fly above the player instead of towards the player. smarter fiends that don't get stuck, monster that can jump without trigger_monsterjumps
 Better Standard HUD
I'd love to see an option to show picked up keys on the ARMOUR/HEALTH/AMMO HUD in QS a la Hipnotic and Quoth. Or even show the keys in the top right corner of the screen.
Also, a nice animated face like Doom... It always kinda felt like a step backwards going from Doomguy's dynamic mug to a static image.
#44 posted by anonymous user on 2017/12/27 18:44:06
I'd love to see an option to show picked up keys on the ARMOUR/HEALTH/AMMO HUD in QS
Quite honestly we need a system to create a totally custom HUD / GUI via QuakeC.
Custom GUI stuff has been criminally missing from Quake since forever, and I think it has stifled mod creativity.
 I'm Actually
#45 posted by Qmaster on 2017/12/27 19:03:42
Planning to do a QS fork that adds custom hud manipulation in qc. Something along the lines of WriteByte commands. This for items, weapons, whatever. Someday.
 Also
#46 posted by Kinn on 2017/12/27 19:22:06
There was a discussion a while ago about a way of supporting 16-bit vertex accuracy with minimal changes to the mdl format.
One suggestion kept backwards compatibility by requiring a standard .mdl file, which all engines can read, and then optionally an additional .m16 (or whatever) file which just contained 16-bit vertex information for engines that supported it (hint hint quakespasm)
 Custom Hud Manipulation
Is a CSQC matter.
I'd be up for a CSQC implementation in QuakeSpasm.
I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both. They're available in Source, so if the features are so important to me I can always just make a Half-Life 2 map, but I've often pined for them in Quake. I'm picturing a classic Unreal-style floating island level, with the sky camera attached to a func_train that gives the impression of drifting slowly over some eldritch landscape as you progress through the map.
Of course I hate to get all "anything I don't understand must be easy"; I couldn't say whether they're realistic desires.
#49 posted by Jonas on 2017/12/27 19:55:01
Custom GUI stuff has been criminally missing from Quake since forever, and I think it has stifled mod creativity.
CSQC in Quakespasm.
RMQ engine did that years ago and was actually based on QS. *cough* Spike did it separately as well, IIRC. It has technically been done for years, it's just that the community didn't really want it. Also, mods like Hellsmash definitely had custom GUIs. So does Brood Hunter. So did Scout's Journey when it still ran on the Quake engine. It had a friggin' drag and drop inventory (other mods did as well). Various mods by gnounc were all about custom HUDs. It's been possible for years, it has just been stifled by being "uncool".
There is even a cleancsqc source kicking around, also years old. https://gitlab.com/gnounc/cleanQC_merged
This thread is really funny to read. Suddenly you guys want volumetric fog, reflections, lightmapped water, custom GUIs, particles and all models remade. But Darkplaces etc. are still the Grand Evil. It all has to be crammed into Quakespasm instead of simply using a more capable engine. It seems the requests for features develop at the same pace as certain regulars' tastes (slowly).
Q3map2
I suggested switching fully to an extended (lightstyles...) Quake 3 map format, shaders and IQM models for PCs five or six years ago to the rest of the RMQ team and people looked at me like I was mad. It was mostly that mappers were unwilling to give up using Worldcraft (can you imagine that in 2017?). Instead we got BSP2, which is a hack, and lots of q3map2-like functionality (AO...)crammed into tyrutils lately.
It's really funny to watch.
These particles you always complain about in darkplaces could be fixed in a weekend if someone made a faithful particlefont.tga for the engine. That could have been done 10 years ago.
The cruddy SW-style lighting has been in FTE for years as well. AFAIK FTE got an entire "faithful preset" a couple years ago, even. Why all these things are slowly rotting instead of being used by the community, I fail to grasp. It really must be a comfort zone limitation. Or a pissing circle one.
You got a faithful looking engine with good Q3 shader support, RBSP/FBSP support, CSQC, and Quakeworld support, plus heightmap terrain and shadowless rtlights that don't impact performance too much, custom GLSL support even, and last I heard most of the bugs had been fixed, so what the HELL are you waiting for?
Does it have to do the dishes as well? (Spike probably has that prototyped already.)
 Other Shite I'd Be Up For In 2018.
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.
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.
Less hubisodes, more episodes, playable from beginning to end. Either community episodes or solo ventures.
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.
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.
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.
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.
New maps from muk, ionous, negke, ijed (ok, too unrealistic), Kell, G1ftmacher, Bloodshot, Nait, and the QUMP team.
New maps from people whom we haven't even met yet.
More banter from Shambler.
Quakespasm 1.0.
Suddenly you guys want volumetric fog, reflections, lightmapped water, custom GUIs, particles and all models remade.
TBH, I, and probably a considerable number of others, don't.
 Also.
Broken record, but I want our #tf discord emotes as func post icons.
FWIW, personally I don't want a bunch of special effects and whatnot.
On the tech side of things, usability is the biggest hurdle for new (or returning) players. Most of the Quake engines don't have a Maps selection menu or a Mods menu. And actually just the proliferation of different engines and forks-of-engines is a stumbling block as well. No ill will from me toward anyone who wants to putter around on their own personal project, but from a player's perspective the gaggle of all-somewhat-different engines is just a pain in the ass.
On the content side, like Shambler above I'd love to see more medium-scale cleverly-assembled maps. Also connecting a set of maps into a simple thematic and/or gameplay progression is neat. (Really interested to see how the episode jam handles this.)
Of course anyone who makes stuff for this weird old game deserves a pat on the back regardless of whether they cater to my tastes or not! Just throwing in my 2 cents since the thread explicitly asks.
 Jonas
#54 posted by Kinn on 2017/12/27 20:16:36
Actually, take each person individually and they're only asking for a small number of things. It's just everyone has a different wishlist.
I get your point about Darkplaces and FTE already having a lot of this stuff, but I think the unwritten (or in many cases written) rule here is that if it don't work in Quakespasm, it's probably not going to be played by the func crowd.
Personally, just 16-bit verts in models and custom HUD and I'm good to go. Different strokes for different folks.
For example I wouldn't request flashy eyecandy with reflections and shiny shaders.
I wouldn't know what to do with fancy shaders to be fair.
I just want to play Quake using Quakespasm or Mark_V on the couch in DM when I am hosting guests (which is often enough that I'd play it almost every week).
The upshoot of this is that I'd be making more co-op friendly maps and deathmatch levels.
 @Jonas
#56 posted by Qmaster on 2017/12/27 21:56:41
Unless or until someone makes the original hud inside CSQC as a base...AND Quakespasm gets CSQC support, CSQC isn't that useful. Also, Darkplaces doesn't have twisty water so it does not count as a legitimate engine as it does not have all of the most utterly basic features. Also, we DO NOT want HD shinovision effects like Darkplaces. We want subtle improvements that align with Quakiness such as AD does. I don't really care to have reflections. 16bit fog would be nice.
I'll add another couple desires:
Square particles for Darkplaces.
Twisty water for Darkplaces.
Fence texture support for Darkplaces and FTE.
Fence texture support on models in Darkplaces and FTE.
Merge MarkV features and Quakespasm and Retroquad into one highly cuatomizable QUAKE (2018) engine.
(Ok this last list is unrealistic)
 #50 Is A Strong Post.
#57 posted by Shambler on 2017/12/27 22:06:42
To be clear, I want more FANCY EFFECTS, but only introduced carefully and subtly as many of the current good ones have been.
 @qmaster
#58 posted by killpixel on 2017/12/27 22:08:04
Also, we DO NOT want HD shinovision effects like Darkplaces.
The eye-melting ass you're referring to is wrongfully attributed to Darkplaces. The blame belongs to the artist who misused the engine's capabilities. This would be the case with any engine. Darkplaces has the capability to look exactly like quakespasm, too.
Square particles for Darkplaces.
a quick edit of effectinfo.txt and particlefont.tga will get you this.
Twisty water for Darkplaces.
a quick shader referencing the water texture with tcMod turb will get you this as well (or something comparable). Same deal with fence textures.
I'm not trying to jump up your ass, I just wanted to correct some misinformation :D
#59 posted by scar3crow on 2017/12/27 22:35:38
Quake isn't bright enough for anything to reflect.
 "misinformation"?
Darkplaces has the capability to look exactly like quakespasm, too.
Don't be daft. Quake engines shouldn't need user-made particle fonts or shaders to look like Quake.
 Purps
#61 posted by killpixel on 2017/12/27 23:18:11
Quake engines shouldn't need user-made particle fonts or shaders to look like Quake.
I agree with that 100%. Darkplaces should look vanilla out of the box (still puzzled as to why it doesn't). Fortunately, that vanilla look is five minutes of tweaking away. The 'misinformation' that I was referring to was that Darklpaces inherently looks like this.
 Killpixel
#62 posted by Kinn on 2017/12/27 23:33:38
would you be interested in making a package consisting of the necessary config settings, modified particle.tga files etc. etc. that people can just download to have DP up and running in a non-eye-rapingly-offensive way?
#63 posted by Kinn on 2017/12/27 23:39:40
because looking at effectinfo.txt - that is not a 5 minute fix unless you know exactly what you are doing, and the casual player most certainly will not.
 Kinn
#64 posted by killpixel on 2017/12/28 00:04:47
good idea, putting that on my list. I just did a little test and it turns out I was wrong, you don't need to touch effectinfo.txt. Just drop an any color/size image called particlefont.tga (i used 4x4, black) into id1/particles. However, I would mess around with effectinfo just to get it a little more "quakey".
 Not A Black Image; Medium Gray.
#65 posted by killpixel on 2017/12/28 00:07:14
 Cool
#66 posted by Kinn on 2017/12/28 00:49:21
Cheers killpixel, yeah a "DP-no-ass" package that can be slapped in the title post of the engines thread would be pretty useful.
Out of interest does DP run ad_sepulcher? Last I checked DP hasn't been updated since 2014 :p
DP has had development since then and has automated builds posted to https://icculus.org/twilight/darkplaces/files/?C=M;O=D
(doubt it can do sepulcher tho)
For me, because DP also changes some behaviors of lighting and physics, it doesn't seem worth fiddling with for "normal" Quake stuff (i.e. not taking advantage of DP-specific features).
#68 posted by killpixel on 2017/12/28 01:34:12
@Kinn - DP-no-ass. I imagine that would be painful. But yeah, I would have liked such a mod before QS came around.
@Johnny Law - Yeah, same here. MarkV and Quakespasm fulfill my quake needs.
anyway, I won't clutter this thread with DP related suff anymore (apologies).
 Johnny Law
#69 posted by Kinn on 2017/12/28 01:53:21
DP has had development since then
Good to know. The latest Windows 10 update has completely trashed mouse input in the 2014 DP build (same way it trashed mouse input in earlier versions of QS, but the latest QS has that fixed), so if the latest DP has fixed that, that's welcome.
But yeah, as a player, I can't really think of a reason why I should use anything other than Quakespasm. It feels right, it looks right, has proper controller support, and runs cooler on my laptop than any other engine by far - seriously, the fan doesn't even come on ever with QS, whereas it's blowing like a jet engine with every other engine I've tried - what's with that?
#70 posted by lpowell on 2017/12/28 02:50:07
- A digs map.
- Release one or two maps myself.
- Halo Forerunner-themed mapjam
- Silent Hill Otherworld-themed mapjam
- uhhhh....
#71 posted by muk on 2017/12/28 03:09:49
More solo releases. From myself or others.
Shorter jams with stronger themes(not that theyve been lacking lately). More than "use this texture set"
Id love to see people talk more openly about their design process. I included a changelog in my xmasjam entry and this is something Ill continue to do and then some.
#72 posted by PRITCHARD on 2017/12/28 05:36:09
Isn't the other issue people have with using DP the fact that it's pretty incompatible? Like, aren't there a bunch of cvars you need to change to get it to behave sorta like regular Quake, physics wise?
Something I want to do in 2018 is release a map that I'm proud of the gameplay for, and not just the visuals. Preferably as a solo release.
#73 posted by mh on 2017/12/28 06:26:19
An improved model format. I don't want fancy features, just better (preferably floating point) accuracy on both vertices and texture coords. Normals can be easily reconstructed if needed (the original code in modelgen.c is a good base to work from).
What I'm talking about here is the equivalent of a BSP2 for MDLs. BSP2 had no fancy-dan features meaning it was easy to implement, meaning it actually *was* implemented, meaning it succeeded. Adding extra features - "can we have skeletal animation/multipart models/detachable limbs/32-bit skins/etc" - just increases the complexity of implementing. There are already plenty other formats that support those features - go implement one of those instead. What I'm talking about is a format that does what MDL does, does no more than what MDL does, but with better accuracy and raised limits.
 Improved Model Format YES
#74 posted by Skiffy on 2017/12/28 06:57:42
Yea for me this is why MD3 would be a good one or IQM which has bone support! As for some new format be careful because that can get tricky with supporting proper exporters for various art authoring tools. Something that can convert an FBX file to this new format would be a good middleground since tons of software can export to FBX.
#75 posted by mankrip on 2017/12/28 08:19:45
#24 Retroquad 1.0
Definitely not happening in 2018.
#26 Lightmaps on liquids
I've tried encouraging other engine coders to implement this in their engines, I've showed how to properly detect if a map was compiled with lit liquids, EricW coded full support for lit liquids in his compilers, but other engine coders were against it.
Mappers were also against it, by shutting down my suggestion of enabling lit liquids by default in EricW's compilers because not all engines supports it, despite there being no side effects in engines that doesn't support it. Interestingly, not all engines supports translucent water either, but nobody complains about translucent water being enabled by default.
Darkplaces does support it, and FTEQW probably does too. What's funny is, even if someone maps for DP, they'll never casually find out that DP does support lit liquids, because the map compilers won't lit the liquids by default.
If lit liquids were enabled by default, we'd have dozens of new maps using it already, and people would start to figure out how to take advantage of it in their maps.
So, it's not going to happen. People are against it.
#76 posted by muk on 2017/12/28 08:21:41
No, please. Give me lit water. My maps look like ass without it.
 @Mankrip
is your engine going to be released in 2018?
#78 posted by Skiffy on 2017/12/28 11:28:54
Well he calls it retroquad... so looks like a nope for 2018 release.
 #73
#79 posted by Kinn on 2017/12/28 11:33:16
Yes, that's what I'm thinking too. Easy change to the engines. Easy change to the mdl exporters. Just mdl with better precision.
 2018
#80 posted by mjb on 2017/12/28 13:01:14
Engine stuff:
I guess weather supported across the engines. An implementation where you can just stick a weather entity in a map and tell it to either rain or snow! QSS works really well of course!
Another vote for fog brushes.
Maps:
I'd also like to see less huge hub-like maps and more dense and original designs. Small episodes or just plain ole medium sized individual maps would be a fun change of pace. I also agree with some people saying about more focused jams with strong themes vs texture usage or one gimmick.
Themes:
Hmm I don't know, the fun part about that is mappers constantly come out with crazy cool ideas. So I suppose let's just keep doing that! I know I would like to release at least one episode myself personally. The Episode Jam will be a nice early year treat I hope! ;O
 #48
#81 posted by Spud on 2017/12/28 13:30:48
I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both.
Not exactly 3d skyboxes but one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense.
 Lit Water
#82 posted by PRITCHARD on 2017/12/28 13:43:10
There's always a stick in the mud somewhere, especially when it comes to engine or mod coding, it seems.
I hope we do get to see lit water in 2018, especially since on paper a lot of the issues have been sorted out. Perhaps we'll see it in a QS fork, or perhaps even in QS itself...
I wonder how much of the pushback against it is because it's supported by DP and no one wants to be on the same side of an issue as DP ;p
#83 posted by mh on 2017/12/28 15:43:37
...one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes...
I'd love to see that. I brought it up during RMQ development but it was shot down at the time. The idea I had was that you could have 2 or 3 layers of skyboxes and blend between them, so you might have a rotating "clouds" layer and a static "scenery" layer, or whatever.
 MDL Support
#85 posted by Qmaster on 2017/12/28 17:14:21
If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.
.MDL (Source Engine)
====================
Pros:
Skeletal anims
Morph anims
Higher precision
Multi-skin support
Uses qc (wierd am-I-right?)
Cons:
Difficult to create
Pipeline is horrible
Creation is not streamlined (okay so that's really only 1 con)
FBX:
======
Pros:
Skeletal anims
Higher precision
VERY common, de facto Standard
Cons:
Proprietary so there is limited support in some tools (still avail. in Blender)
No morph anim support
 Lit Liqs
#86 posted by Qmaster on 2017/12/28 17:16:11
Need engine support in the trinity of Quake engines: Quakespasm, FTE, and Mark V.
+1
 QTWID
#87 posted by venderant on 2017/12/28 17:32:27
- Quake the Way id Did
- optional PS1-style vertex jitter
- +1 for gameplay mods
#88 posted by mankrip on 2017/12/28 17:49:09
#77
See #75.
#31 Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though.
Super8, Engoo and MarkV already supports alphamasked models, and Quakespasm likely does too.
Glowing eyes and flowing lava can be faked by using fullbright colors and animated skingroups. Animated skingroups are part of the original Quake MDL specs but were never used in the main game, so most people aren't aware it exists.
IIRC, support for animated skingroups was broken in GLQuake, but custom hardware-accelerated engines fixed this ages ago.
What I don't remember is if animated skingroups supports custom timing, like animated framegroups does.
Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...
Lit liquids with luma textures can break the tiling. But again, lit liquids aren't going to happen, and I don't know if MarkV and Quakespasm supports luma textures.
I second more advance water volumes that accept lighting and foam.
Foam could be faked by using "negative dirtmapping" on lit liquids. Dirtmapping makes surfaces darker at the edges, but if it suddenly cranked up the lighting at the edges all the way to fully white instead, it could look pretty close to foam.
Even without negative dirtmapping (which could also be called "foam lightmapping") in the light compiler, this could be faked by manually placing lots of tiny lights on the liquids.
The other sensible way would be to implement texture crossfading, which I'm going to do in the future (at the moment I'm faking it through soft depth), but I don't know if any of the other engines supports it. Also, each engine (Q3A, etc.) does texture crossfading in a diferent way, and getting some consensus on standards for such things is near impossible given how different each Quake engine is today.
 Simple Quake Launcher By MaxEd.
I'd like to see it included with new releases of source ports. It would lower the barrier of entry massively for newcomers who don't know how to, or even want to, create shortcuts and BAT files.
A simple front-end for loading maps should be a no-brainer in this day and age. :)
 #85
#90 posted by mh on 2017/12/28 18:50:42
If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.
I suggest neither. Any additional complexity is a barrier to implementation. What most people really want is just MDL but without the vertex dance. Better texturing comes second.
#91 posted by Kinn on 2017/12/28 19:38:43
What most people really want is just MDL but without the vertex dance.
Exactly. Cuts to the chase.
 Models
#92 posted by Spike on 2017/12/28 20:33:01
either md3, iqm, or its a waste of time - the tools are much more important than the format itself, and bsp2 meant the same tools could be used (or at least the user-visible ones).
mdl tools pretty much universally suck, worse - the main one that people seem to use is closed source.
md3 already works in qss(r8), fte, dp, ezquake, and _multiple_ others. And there's been at least one software-rendered engine that supported it.
iqm works in fte, dp, and rmqe... and oh noes! quats! flee in terror!
So yeah, md3. Trying to push some other format is pretty much pointless now, especially as there's ALREADY two 16bit q1mdl-derived formats (that noone uses). q1mdl just isn't worth it, imho, especially when the various incompatibilities will persist regardless.
 Wait, What
#93 posted by Kinn on 2017/12/28 21:01:05
I didn't know QSS already supported md3.
That hugely increases the chances of it being implemented in other similar engines then. Just need some md3 content, and I'm sure increased support will follow.
#94 posted by Kinn on 2017/12/28 21:02:36
Maybe the lovely chaps behind the AD monsters could export some md3 versions of them?
 Md3
#95 posted by killpixel on 2017/12/28 21:05:08
a couple exporters exist for blender that are still maintained and there's enough literature to get you rolling quickly. tags are nice, too.
 Spiked
#96 posted by Kinn on 2017/12/28 21:15:54
I'll admit I haven't looked at QS-Spiked (or really anything quake) for the better part of a year - does QSS support crunchy pixel filtering on the fancy particle system yet?
 @Kinn
#97 posted by Spike on 2017/12/28 21:30:52
yes, 'nearest_texture foo.tga' instead of 'texture foo.tga', though I think it requires ALL foo.tgas to use the same type, which is a bit annoying - I didn't tweak QS's texture manager code that much.
 Cool Beans
#98 posted by Kinn on 2017/12/28 21:45:05
 Shambler Is MD3...
#99 posted by Skiffy on 2017/12/29 02:12:54
My shambler model is exported to MD3 and then converted to MDL in my pipeline... sooo I will have to give it a try in QSS... did not know it supported it ha. I just want bones support to have nicer arching clawing animations. Animating at 10fps with vertex interpolation makes for some wonky sweeping movements. :P
 Lit Liquids Will Happen Despite Mankrip's Best Efforts
#100 posted by PRITCHARD on 2017/12/29 02:45:15
(At least I hope so)
#101 posted by mankrip on 2017/12/29 02:46:23
#49 It has technically been done for years, it's just that the community didn't really want it. Also, mods like Hellsmash definitely had custom GUIs. So does Brood Hunter. So did Scout's Journey when it still ran on the Quake engine. It had a friggin' drag and drop inventory (other mods did as well). Various mods by gnounc were all about custom HUDs. It's been possible for years, it has just been stifled by being "uncool".
I'm of the simple opinion that it's about workflow.
CSQC is incredibly complex, because it was made to interoperate with Quake's client/server architecture and stuff like physics and AI. People who just want to do simple stuff like making the Ranger face animate in the HUD feel overwhelmed by all of the extra complexity that they don't need.
Custom HUD and GUI coding needs to be as simple as possible. There's no need to create a whole dynamic programming language for it when the user just want to do some tweaks. A static definition format, like a simplified CSS, would be enough.
The power of CSQC lies in massively reducing network traffic, and allowing the creation of really complex works. Its learning curve is too steep for simple cosmetic tasks like "display that icon at position xy if this bitfield is set".
#81 one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense.
What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.
#90 What most people really want is just MDL but without the vertex dance.
And a big part of the vertex wobbling happens because the animations are not skeletal. Animating models without skeletal animation is a living hell, because anything that rotates gets distorted while interpolating. Swords gets shorter, tubes gets crushed, etc.
As Spike said, the tools are much more important than the format itself, and bsp2 meant the same tools could be used. People create Quake maps because the tools are good and they have fun doing that. But creating Quake MDLs is a pain.
 MDL Is Easy Enough
#102 posted by Skiffy on 2017/12/29 02:57:02
Odd way of saying it... Making monsters is simple for me compared to making a map. But you do end up using tools like 3dsmax, Maya or Blender for modeling and animating. I myself use 3dsmax. I do all my painting using 3dcoat which makes the task of painting the texture in 3d a breeze. Again not a free tool. Blender does have a very good 3d painter as well.
As for converted to MDL, I just export every frame from 3dsmax as a new mesh and then use Inferno's MD3 compiler to make the model. Then I convert the MD3 to MDL and inject the correct textures I want.
Everyone has their tools chain they need to run through. Making monsters or enemies does require a lot of other knowledge that has nothing to do with the tools change. Good mesh construction and unwraps, a sense of form and anatomy, good color and design. Making your own animation rig that is easy to use and deforms well. Good animation! Sense of weight and timing for those attacks and run animations which are seen most of the time by the player... Just different interests is all.
I should just make a video showing my workflow to get a model in game I guess. Tons of resources on making maps for quake but very little when it comes to making MDLs.
2018 is the year I want to properly learn 3d model making for quake. Any tutorials would help a huge amount
 Fifth
#104 posted by killpixel on 2017/12/29 03:52:45
This was posted last year sometime by the author. It's a solid tut that I found very useful (if you're out there, thank you).
Are you looking for quake-specifc modeling tutorials or just modeling in general?
 What I Want
#105 posted by mankrip on 2017/12/29 05:08:12
... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.
Mark V has an option to enable it, but it doesn't work properly on viewsizes higher than 100 (WQ didn't keep it consistent either, but imho this should be fixed, and I've fixed it in Makaqu).
Seriously, this is my main problem with most Quake engines. This is what makes most engines feel wrong for me, because the weapon is displayed the whole time and I can't avoid noticing that its not where I expect it to be.
Also, I like how the on-camera position of the weapon changes when looking up and down in WinQuake's viewsize 100. This happens because the weapon is higher in world space, not in screen space, but I remember that there's an engine that uses screen space instead of world space in its higher weapon position option.
 Ok Then
#106 posted by Qmaster on 2017/12/29 05:11:47
QSS to be merged into master.
 Hardware Accelerated Vis Replacement
#107 posted by mh on 2017/12/29 05:23:18
This is an idea I had some time ago.
Draw the entire world. Pick a leaf to be the viewleaf. Using occlusion queries determine which other leafs are visible from it, from all 6 directions. Read back the results, that's the PVS for the viewleaf. Pick the next viewleaf, repeat until done.
Vis time should become linear, with no more weird extreme cases.
Vis time should no longer be a function of geometry complexity.
PVS should be tighter and nonsense like geometry half way around the map being included should go away.
 @mh
#108 posted by Qmaster on 2017/12/29 06:27:46
Occlusion queries?:
•Raycasts? 6? Would be woefully insufficient. In a room with 4 world columns in a square in the middle, the 4 corner leafs wouldn't get drawn when you stamd inside the center leaf in the square space between the columns.
•6 Renders - ortho? Possibly if each leaf is assigned a different color.
 #108
#109 posted by mh on 2017/12/29 10:41:26
Nope; nothing to do with raycasting; using the GPU for rendering to a small enough viewport - 256x256 should be sufficient - do 6 standard renders with 90 degree horizontal and vertical FOV for each. For each, run a bunch of hardware occlusion queries to determine samples passed for each leaf. Any leaf with 1 or more samples passed is visible.
This is nothing to do with raycasts and nothing to do with any software-based approach; it's pure hardware using standard rasterization techniques (that have been available since OpenGL 1.5) based on similar thinking to that used for shadow mapping. Because if you think about it, shadow mapping is just an occlusion/visibility problem so the same thinking should be able to apply to the more general case of determining actual occlusion/visibility.
#110 posted by Kinn on 2017/12/29 10:55:38
That sounds like it could massively improve vis quality in big outdoor Tronyn-style facemelters.
 Not Sure If This Realistically
#111 posted by spy on 2017/12/29 12:14:33
but i'm still waiting for a something new from Kinn
@Kinn , there's a TF discord channel, if you're willing to join to https://discord.gg/P56HXr
#112 posted by mh on 2017/12/29 13:16:35
... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.
Mark V has an option to enable it...
Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.
It'll probably never happen in DP because Religious Reasons.
 Episode 1 Remake With AD Bells And Whistles.
I'd love to see the top tier mappers start a project expanding on the shareware episode maps the AD's extra beastiary and projectile weapons.
I want to play E1M1 with the Widow-maker, dammit!
 #101
#114 posted by Spud on 2017/12/29 16:11:50
What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.
Hey, that's pretty neat. At risk of sounding like a complete moron, what exactly causes it to be a pain in the ass? I'm sure it's somewhat difficult to make it look good, but honestly, any sort of happy medium between the standard tiling two-layer skies and the static but six-sided skybox textures supported by newer engines would be fantastic. The extra detail given by the skybox is great but given how lively some Quake maps tend to look within the play area itself, the completely stationary skies and backgrounds can sometimes stick out like a nailed thumb.
 #114
#115 posted by mh on 2017/12/29 16:15:48
...what exactly causes it to be a pain in the ass?
I assume that's specific to the software renderer. In hardware it's just some cubemaps and some texture matrices.
#116 posted by mankrip on 2017/12/29 17:04:06
#112 Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.
Thanks, I've found it now. There's no menu option for it in QuakeSpasm, and I usually don't bother searching through cvars in game engines anymore, so I didn't notice it was implemented.
After enabling it, paying in QuakeSpasm got 200% better for me now!
#114 what exactly causes it to be a pain in the ass?
The zero-overdraw architecture of Quake's software renderer is incredibly monolithic and gets in the way.
In my implementation, each side of the skybox is vertically cropped twice, one time for the fully opaque section of the image, and another for the section that contains some transparent texels, while the fully transparent vertical area of each side if fully cut out. The fully opaque section gets drawn as an opaque surface, and the rest is drawn as an alphamasked surface.
Also, the background layer's sides are cropped from the bottom of the alphamasked portion of the foreground, to the absolute height of the skybox.
Dynamically resizing surfaces like this, specially when all of them are shared by the same cube, causes complete chaos in Quake's monolithic BSP architecture.
The hybrid skybox implementation in previous versions of Retroquad was far simpler, resorting to much more overdraw, which is much slower.
 Spawnflags For All
#117 posted by Cocerello on 2017/12/29 23:13:13
I noticed that some universal flags like Not in ... don't work for all entities, even though they work for entities that aren't documented as having them in .fgd and .def files.
How hard would it be to do this without mods so i can use an existing mod that i have no source for? Or is it better to leave that to mods just in case someone used those flags on theirs?
 MH:
#118 posted by metlslime on 2017/12/29 23:23:56
Unless I misunderstand, it seems like there are two issues with that idea. First, there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts but never eliminated. Second, leaf PVS has to be valid for all points within a leaf, while any raycast-based system will be treating the leaf as a single point (or a small number of points)
#119 posted by mh on 2017/12/30 01:23:08
...there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts...
I really don't understand this part, and it's second time around.
Why the fixation on raycasts?
I'm not talking about raycasts.
Forget about raycasts.
There are no raycasts.
#120 posted by metlslime on 2017/12/30 02:15:50
isnt a "sample" in a hardware occlusion query effectively a raycast? I admit to not knowing the tech behind it.
 How Do You Know What To Render In Your 6 Renders?
#121 posted by Qmaster on 2017/12/30 05:15:01
Unless you raycast for each pixel or something?
#122 posted by Qmaster on 2017/12/30 05:16:45
If, however, you assign a unique color to each leaf and render flatscale color into a buffer, then parse each render to see what colors are visible...
#123 posted by mh on 2017/12/30 07:52:50
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_occlusion_query.txt
Occlusion queries use the depth buffer. Raycasts are absolutely nothing to do with it.
#124 posted by anonymous user on 2017/12/30 09:53:50
In full HD, surfaces smaller than 7*4 pixels would be invisible.
 I Want To See More Infighting With Tarbabies.
#125 posted by Shambler on 2017/12/30 10:36:25
And raycasts, lots of raycasts. Whatever the fuck they are.
 HUD, Scripting, Water
#126 posted by adib on 2017/12/30 12:02:16
+1 for new scripting system
+1 for flexible HUD
Movable liquid volumes. Like turning a water brush into a func_door I could lift to flood an area. I understand that it envolves translating a volume where special physics and render takes place in runtime, but how hard it is to do?
 Oh And +1 For Lit Water In QS
#127 posted by Kinn on 2017/12/30 12:23:46
spy, cheers I might visit that discord place as long as it's not full of weird porn like the irc channel was.
 A Proper
#128 posted by Text_Fish on 2017/12/30 13:09:16
comprehensive co-op mod, with a selection of purpose-built maps by the community and an easy way to play online with friends who aren't really bright enough to play anything that's not on Steam.
 Unrealistic Request
#129 posted by Kinn on 2017/12/30 13:51:38
This basically requires all engine authors to agree on a feature so hahahaha, but anyway one thing that has always peeved me is how mod folders all have to be a child folder of a main quake (engine) folder.
When you have hundreds of mods, taking up gigagbytes, you only really want a single instance of your mod collection to exist on your hard drive.
This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.
Yes, of course you can create a separate Quake folder for each engine, and duplicate all your mods across each of these, but as I said earlier, that rather sucks, can take up too much space, and it soon becomes a synchronisation nightmare.
I guess what I am saying is it would be great if you could tell any engine to reference a mod folder that's ANYWHERE on your drive, so you can just keep your mods centralised and separate to the engine installs.
#130 posted by Kinn on 2017/12/30 13:55:43
This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.
Sorry I should have clarified a bit more - this sucks arse mainly because it becomes nearly impossible to then later remove a particular engine when they are all dumped in the same folder because all the dlls for each engine and other secondary files are all just mixed up together in one massive unorganised clutter, and you don't have a clue what can be deleted.
 @Kinn
#131 posted by Spike on 2017/12/30 15:35:08
Any decent engine will still respond to the -basedir argument (otherwise the vanilla behaviour is to use the working directory).
You can then install your (decent) engine inside some subdir and then tell it to use the parent dir for content.
Note that this won't help when it comes to the numerous config.cfg file conflicts. You'll need homedirs or alt-config hacks (eg: fte.cfg) for that, which is still ugly.
There's probably still a few other conflicts too (like console input history), though I don't think I've seen any such issues more serious than config.cfg conflicts.
Unfortunately a few engines are buggy and force the basedir to where the exe is (regardless of working directory), and in doing so ignore the -basedir argument.
You can create symlinks as a workaround (or reparse points on windows), but as this is per-mod-per-engine then its just annoying to do unless you want to spend a while creating some kind of fancy script to maintain them for you.
Tbh though, if a dll isn't backwards compatible (and didn't get renamed) then that library just sucks, or whoever built it does.
And then there's a few engines where all the important stuff is statically linked so that it works even with no messy dlls at all!
 Spike
#132 posted by Kinn on 2017/12/30 16:53:38
Thanks, I now feel like a right knob that I typed all that out without knowing about -basedir.
#133 posted by ericw on 2017/12/30 21:33:59
afaik, metl's concerns in #118 are still applicable to rasterization / occlusion queries. The visdata is supposed to be valid for all locations within a leaf's volume and all camera angles, so if you generate it by sampling a few camera positions (or just the center) and a few angles, and rasterizing, false negatives will be possible (homs/grey flash).
I still think it's a cool idea worth trying, the question is just how many views (camera positions/angle combinations) you have to render to make the false negatives a non-issue. I don't have any sense of how fast it is to render these 256x256 (say) views and doing the occlusion queries. If you budget 1ms per leaf, that would give 64 second vis time for a 64k leaf bsp. I wonder how many FPS for rendering these views would be expected on a decent graphics card.
e.g. this would allow vising ORL's latest pack which has unvised maps.
PS the "showing the other side of the map" bug is fixed as of v0.15.10 of my compile tools, as far as I know the only cause of that symptom was the way func_detail was added to qbsp.
 @Kinn
Was just lurking and spotted this. If there are issues using -basedir as Spike alluded to, you could always use Symbolic links, not sure what OS you're on but they're fairly easy to setup.
 Kinn.
#135 posted by Shambler on 2017/12/30 22:53:50
I've saved some especially for you, there's a secret sub-channel specifically for that stuff :)
 Ericw
#136 posted by Qmaster on 2017/12/31 01:23:58
How many camera positions does vis compute anyhow? Or does it figure out how many positions to account for and only compute those??
 Also
#137 posted by Qmaster on 2017/12/31 01:24:53
It's funny how a lot of people's requests are already possible or exist. We need this sort of thread more often to help spread the word.
 Hey Kinn, Who The Fudge Said Engines Need DLLS?
#138 posted by Baker on 2017/12/31 08:24:11
Who the fuck says an engine needs DLLs?
WinQuake doesn't need DLLs.
FitzQuake 0.85 doesn't need DLLs.
FTE doesn't need DLLs.
Mark V doesn't need DLLs.
The idea of needing DLLs is a shitty LINUX concept.
LordHavoc was a Linux user when he made DarkPlaces. The original Quakespasm authors (not ericw) were Linux users.
Linux ideas like DLLS and OGGS should be rejected and shunned.
NOT normalized, like a dopey person would do.
Don't be a dopey person. I'm just saying. Who the fuck said engines need a folder full of shitty DLLs?
Well -- answer: Linux people who do not use Windows.
In fact, in the compile tool chain for Linux friendly engines there is a static linking option that would eliminate the DLLS.
Demand better! Don't buy into the "need to have shitty DLLs" way of thinking. It's a lie.
/Against my better judgment I click submit!
 +1 For DLL Free QS/QSS
That would make updating so much nicer, as well as having multiple engine/single directory coexistance.
 Kinn
#140 posted by spy on 2017/12/31 10:52:49
I might visit that discord place as long as it's not full of weird porn like the irc channel was.
no worries, the nsfw channel's hidden now
 OH, Another Thing I'd Like To See In 2018
#141 posted by Text_Fish on 2017/12/31 11:42:02
is some sort of new visual thematic. It seems like the past 4 or 5 years have been dominated by mashups or updates of old themes. I'd like a comprehensive new texture-set that stands up on its own and looks just as good in a vanilla engine as it does in one with advanced features.
 @Baker
#142 posted by SavageX on 2017/12/31 12:36:26
DLLs are, of course, a Windows (and OS/2) thing. On Unix and Linux you have .so files. The concept of shared objects and libraries is present in any modern operating system. A vanilla install of WinQuake comes with:
GENVXD.DLL
PMPRO16.DLL
QUAKEUDP.DLL
WDIR32.DLL
GETINFO.DLL
PMPRO32.DLL
WDIR16.DLL
No idea what connection to Linux you see there.
Also, as someone with a Xiph.org connection a few years ago, I hereby kindly request Ogg Vorbis support in all engines ;-) (or, perhaps even better, Opus support - awesome for music, sfx and voip).
 Aye
#143 posted by Kinn on 2017/12/31 12:45:14
Yeah, was gonna say WinQuake also had its fair share of dlls too.
Anybeans, now that I have discovered the sheer wizard magic of -basedir, I'm keeping all my engines quarantined in their own individual folders and the dll thing doesn't bother me now. Others' mileage may vary obviously.
 #42
#144 posted by topher on 2017/12/31 16:52:15
reading the documentation i see that AD already has what i said in #42 about scrags, and possibly demons
the third thing would be level-aware monsters, but in some ways they would start acting like multiplayer bots, so i don't know...
 +1 QS With DLL's Baked Into The Exe
#145 posted by Qmaster on 2017/12/31 17:27:14
 Topher
#146 posted by Cocerello on 2017/12/31 17:33:34
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.
 And
#147 posted by Cocerello on 2017/12/31 17:42:20
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...
#148 posted by Barnak on 2017/12/31 18:08:15
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.
 #144
#149 posted by mankrip on 2017/12/31 18:39:18
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.
#150 posted by Kinn on 2017/12/31 19:08:23
r_softwarebanding from FTE in QS and QSS please please please? :}
 Muk Finish His Honey Map And Medieval Map And Ikwhite1024 Map The Cunt
#151 posted by Shambler on 2017/12/31 20:35:32
 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
#153 posted by Redfield on 2017/12/31 22:18:31
I can dream can't I??
 Baker
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.
 @mankrip
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.
 Dumptruck_ds
#157 posted by mankrip on 2018/01/03 04:49:36
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.
#159 posted by PRITCHARD on 2018/01/03 12:24:47
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.
#163 posted by Text_Fish on 2018/01/03 13:26:43
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.
 AD
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
#165 posted by anonymous user on 2018/01/04 15:55:59
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
#169 posted by Butane on 2018/01/06 21:16:21
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 https://youtu.be/hxcbEliwpxQ
 Don't Play Quoth Or AD
#170 posted by kaffikopp on 2018/01/06 21:36:54
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:
#171 posted by Shambler on 2018/03/02 12:40:00
Posted by Baker [65.60.237.219] on 2018/03/02 11:27:11
Mark V added a ground-breaking mouse driven menu http://celephais.net/board/view_thread.php?id=61375&start=1835
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.
#172 posted by Shambler on 2018/03/02 12:40:15
Not Sure If You're Talking About Engine Stuff Or Whatever.
#1 posted by Shambler [88.111.222.13] 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
#173 posted by Shambler on 2018/03/02 12:40:33
#2 posted by onetruepurple [178.235.146.159] 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?): https://www.youtube.com/watch?v=iooijPc7dbY&
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.
 #171
#175 posted by mankrip on 2018/03/02 13:20:56
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.
 #173
#176 posted by Kinn on 2018/03/02 14:13:49
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.
#178 posted by Kinn on 2018/03/02 19:22:23
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.
#179 posted by mankrip on 2018/03/02 19:53:11
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
 #180
#181 posted by mankrip on 2018/03/02 21:02:38
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.
#182 posted by mankrip on 2018/03/02 21:18:20
Hmm, that would require a dummy entity anyway, as movetogoal is implemented engine-side.
 Vanilla Quake 2 Does That
#183 posted by Kinn on 2018/03/02 21:41:16
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.
#186 posted by Spike on 2018/03/02 22:25:14
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
#187 posted by Qmaster on 2018/03/03 00:37:27
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.
#188 posted by eukara on 2018/03/03 00:48:23
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:
QuakeSpasm
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.
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.
FTE
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...
ezQuake
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.
 Quakespasm
#189 posted by Qmaster on 2018/03/03 03:28:11
Does support colored lights.
I can agree on FTE. Not really sure where it fits in, no offense to Spike or anything.
#190 posted by Tribal on 2018/03/03 11:04:29
@Qmaster
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: https://www.youtube.com/watch?v=WmcXLNzan48
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
 Hrm...
#192 posted by Qmaster on 2018/03/03 13:58:42
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.
 #188
#193 posted by Bumleathers on 2018/03/03 14:37:57
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...
 @Tribal
#194 posted by Shambler on 2018/03/03 19:28:30
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.
 @shambler
#195 posted by Tribal on 2018/03/03 20:08:38
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 ;)
 @Bumleathers
#196 posted by eukara on 2018/03/04 09:44:45
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?
 #196
#198 posted by Kinn on 2018/03/04 11:53:59
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.
 #199
#200 posted by Kinn on 2018/03/04 13:50:36
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.
 Additionally
#201 posted by Kinn on 2018/03/04 13:55:41
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
#203 posted by mankrip on 2018/03/04 14:30:53
What some popular engines doesn't support are special textures like bumpmaps, normalmaps and so on. Regular 24-bit color images are fine.
#204 posted by Spike on 2018/03/04 20:07:00
@#198
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.
@#199
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.
@Kinn
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).
@Qmaster
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.
#205 posted by Tribal on 2018/03/04 21:10:33
@Spike
First, i love your engine.
Second, You sir, are a genius =D
Third, thank you for your awesome work =D
 @Tribal
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.
 Ummm.
#207 posted by Shambler on 2018/03/04 23:41:02
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...
#208 posted by Qmaster on 2018/03/05 01:37:48
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.
#209 posted by ericw on 2018/03/05 06:37:25
Quakespasm inherited per-map external textures from Fitzquake 0.85; they go in /textures/mapname/ (docs: http://celephais.net/fitzquake/files/fitzquake085.txt ).
 @shambler
#210 posted by Baker on 2018/03/05 06:59:00
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!
 @mk
#211 posted by Baker on 2018/03/05 07:17:08
"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. http://celephais.net/board/view_thread.php?id=61375&start=1835
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!
 @shambler
#212 posted by Baker on 2018/03/05 07:26:13
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 ...)
#213 posted by Spud on 2018/03/05 07:28:40
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?'
 @spud
#214 posted by Baker on 2018/03/05 08:23:06
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
#215 posted by Baker on 2018/03/05 09:16:22
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.
 Oh
#217 posted by Spud on 2018/03/05 09:39:10
I wanted to post with just the face but I have to put some words here, I guess.
#218 posted by Baker on 2018/03/05 09:39:39
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?
 @spud
#219 posted by Baker on 2018/03/05 09:43:30
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 ...
 @onetruepurple
#220 posted by Baker on 2018/03/05 09:54:38
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.
 Well.
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.
 Also.
If it is such a revolutionary implementation, it shouldn't be difficult require installing numerous other, allegedly inferior implementations to explain.
 @219 Er, Okay.
#224 posted by Spud on 2018/03/05 10:21:09
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.
#225 posted by Baker on 2018/03/05 10:25:54
@otp
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.
 @spud
#226 posted by Baker on 2018/03/05 10:35:36
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.
 @spud
#227 posted by Baker on 2018/03/05 10:54:02
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.
 @Baker.
#228 posted by Shambler on 2018/03/05 12:04:33
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.
 @shambler
#229 posted by Baker on 2018/03/05 12:14:38
"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
#230 posted by Shambler on 2018/03/05 12:22:56
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.
 Hmmmm
#231 posted by Kinn on 2018/03/05 12:45:12
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.
#232 posted by mankrip on 2018/03/05 12:53:04
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
#233 posted by Kinn on 2018/03/05 12:56:11
- 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.
#234 posted by mankrip on 2018/03/05 12:57:16
*carpal tunnel syndrome, not carp.
 #231
#235 posted by mankrip on 2018/03/05 13:43:12
You're describing "3D skyboxes". AFAIK, the Source and Unreal engines supports that.
 3d Skyboxes
#236 posted by Kinn on 2018/03/05 14:01:11
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.
 Kinn
#237 posted by Bal on 2018/03/05 14:10:17
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).
 #236
#238 posted by mankrip on 2018/03/05 14:45:42
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
#239 posted by mjb on 2018/03/05 14:54:15
But new mappers entering the fray.
With Dumptruck_ds's tutorials I think that's entirely realistic! ;)
#240 posted by eukara on 2018/03/05 16:25:43
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.
#241 posted by eukara on 2018/03/05 16:33:42
The stage in question will look somewhat like this
{
map $cube:gfx/env/mountains
blendfunc blend
tcGen skybox
}
#242 posted by eukara on 2018/03/05 16:47:08
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?
#245 posted by eukara on 2018/03/05 17:11:49
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
#246 posted by anonymous user on 2018/03/05 19:43:35
 People Are Talking About Improvements They'd Like To See In Quake
#247 posted by Shambler on 2018/03/05 20:55:07
#248 posted by mankrip on 2018/03/06 03:07:46
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
#249 posted by mh on 2018/03/06 04:53:23
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.
#250 posted by mankrip on 2018/03/06 06:54:30
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.
#251 posted by mh on 2018/03/06 08:51:24
Yeah, that would work better.
 I Want To See...
#252 posted by Shambler on 2018/03/07 10:00:59
...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.
 Shambler
#253 posted by Kinn on 2018/03/07 10:17:11
Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer.
 Bler
Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment.
 Shambler
#255 posted by Bal on 2018/03/07 11:06:25
TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D )
 Sigh. Quake Ruined.
#256 posted by Shambler on 2018/03/07 11:30:05
[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
#257 posted by Qmaster on 2018/03/07 13:16:49
#258 posted by eukara on 2018/03/07 16:40:15
Texture filtering in Quake was a mistake.
#259 posted by Shambler on 2018/03/07 16:42:41
Your conception was a mistake. Your mom told me as much.
#260 posted by mankrip on 2018/03/07 16:57:41
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
#261 posted by Qmaster on 2018/03/07 18:53:21
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 door...one 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.
#262 posted by mh on 2018/03/07 19:13:47
Unfiltered Quake looks fantastic.
Aside from the sharper edges on things, textures just pop with detail compared to the filtered versions.
Compare:
http://www.quaketastic.com/files/screen_shots/Q1-Unfiltered.jpg
http://www.quaketastic.com/files/screen_shots/Q1-Filtered.jpg
More than just fullbrights and overbrights was lost in the initial SQUEEEEEEE-fest over GLQuake.
 Actually
#263 posted by Bal on 2018/03/07 19:17:46
Good filtering is much more important with high resolution images than it is with low res stuff (where it just makes them blurry).
#264 posted by metlslime on 2018/03/07 20:58:55
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.
 Agreed!
#265 posted by Qmaster on 2018/03/07 22:35:56
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)
#266 posted by Qmaster on 2018/03/07 22:36:28
#267 posted by mh on 2018/03/07 23:47:00
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.
#268 posted by metlslime on 2018/03/08 00:08:24
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.
#269 posted by mh on 2018/03/08 00:15:30
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
#270 posted by Qmaster on 2018/03/08 00:29:45
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!..?
#271 posted by Redfield on 2018/03/08 05:54:48
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.
 #271
#272 posted by mjb on 2018/03/08 06:12:36
Centerprint with constant cheesey rhymes
 Gruntilda Says:
#273 posted by Redfield on 2018/03/08 06:24:02
Ranger will end up slobbering,
after the Shambler gives him a clobbering.
And so forth.
 Volumetric Fog Is Definitely A Good Call...
#274 posted by Shambler on 2018/03/08 11:23:35
...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.
#275 posted by eukara on 2018/03/08 14:38:42
Just adopt Q3 BSP already if you want stuff like volumetric fog. :)
#276 posted by mh on 2018/03/08 17:37:11
Another thing that no current Quake engine does, AFAIK, is gamma-correct mip-mapping: http://filmicworlds.com/blog/gamma-and-mipmapping/
 What?!
#277 posted by killpixel on 2018/03/08 18:47:55
As you should know by now, the value 187 is actually half-way between o and 255.
 192
#278 posted by Qmaster on 2018/03/08 22:33:39
 And The Actual Quote Is Half Between 128 And 255
#279 posted by Qmaster on 2018/03/08 22:34:00
 QMaster
#280 posted by mankrip on 2018/03/09 00:32:21
Wrong. The problem is that that article was very poorly written. Here's the actual equation for gamma-correct gray:
((255^2,2)÷2)^(1÷2,2)=186,083713
Most of the gamma correction articles on the web are poorly written.
 #277
#281 posted by Spike on 2018/03/09 13:49:35
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
#282 posted by Tronyn on 2018/03/09 21:30:14
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
#283 posted by killpixel on 2018/03/10 01:55:30
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
#284 posted by Qmaster on 2018/03/10 02:00:28
+1 editor lighting preview.
#285 posted by metlslime on 2018/03/10 02:10:46
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
#286 posted by Kinn on 2018/03/10 02:31:18
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.
#287 posted by mankrip on 2018/03/10 03:45:32
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.
#288 posted by Qmaster on 2018/03/10 05:08:30
 @qmaster
He's right I've used it in one of the Radiant's before. Would be a great addition to TB.
#290 posted by mankrip on 2018/03/10 21:24:54
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
#291 posted by Qmaster on 2018/03/10 23:07:04
But ya I agree. I use JACK all the time.
 @snug
#292 posted by Baker on 2018/03/13 16:10:26
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.
 @Baker
#293 posted by Shambler on 2018/03/13 16:54:49
No apology needed as it was pretty hilarious. Welcome back after your hangover :)
#294 posted by Baker on 2018/03/13 17:08:22
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!!!!!!!"
 "Snug"?
It's Spud.
#296 posted by Spud on 2018/03/13 21:25:58
In retrospect Snug is a much snazzier sounding handle, though.
@Baker: Don't sweat it.
 Ya Don't Worry About It Baker
#297 posted by Qmaster on 2018/03/13 22:53:11
#298 posted by PRITCHARD on 2018/03/14 05:14:40
In 2018, I want to see at least one map easter egg about drunk Baker.
#299 posted by mh on 2018/03/14 05:19:01
 @spud
#300 posted by Baker on 2018/03/14 18:31:28
@Baker: Don't sweat it.
Thank you.
#301 posted by R00k on 2018/03/16 09:08:25
@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?
#302 posted by R00k on 2018/03/16 09:13:07
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
 @r00k
#303 posted by Baker on 2018/03/16 09:37:47
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 ;-)
#304 posted by Spud on 2018/03/16 09:40:24
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
#305 posted by Baker on 2018/03/16 10:03:02
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 ...
https://www.quaddicted.com/reviews/honey.html
https://www.quaddicted.com/reviews/quoth.html
https://www.quaddicted.com/reviews/ant.html
https://www.quaddicted.com/reviews/sewage.html
https://www.quaddicted.com/reviews/hdn.html
https://www.quaddicted.com/reviews/arwop.html
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
#306 posted by Spud on 2018/03/16 11:02:58
More the size and complexity of the map part, regardless of how many info_player_coops it includes.
 Unnecessary Side Note Double Post
#307 posted by Spud on 2018/03/16 11:03:41
Holy shit Quaddicted works in Waterfox now, neat.
 Coop
#308 posted by Qmaster on 2018/03/16 17:23:07
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.
 @spud
#309 posted by R00k on 2018/03/16 18:13:34
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
#312 posted by PRITCHARD on 2018/07/01 16:43:59
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
#313 posted by Spud on 2018/07/01 17:28:12
(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.
#314 posted by mankrip on 2018/07/01 17:41:12
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...
#315 posted by brassbite on 2018/07/01 19:49:47
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.
#316 posted by topher on 2018/07/01 20:18:09
(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
#318 posted by Qmaster on 2018/07/02 04:39:31
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??
#319 posted by mankrip on 2018/07/02 05:03:48
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
#320 posted by Redfield on 2018/07/02 06:56:49
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
#321 posted by Spud on 2018/07/02 07:48:04
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).
#322 posted by mankrip on 2018/07/02 08:10:43
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.
#323 posted by Baker on 2018/07/02 08:55:32
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.
#324 posted by Tommy on 2018/07/02 11:50:21
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.
 @qmaster
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.
#326 posted by scar3crow on 2018/07/02 20:46:41
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.
 Qmaster
#327 posted by madfox on 2018/07/02 23:13:43
Quark,what good is that for anymore?
I use Quark4.07 for lots of model additions, may be old but gold for me.
#328 posted by mankrip on 2018/07/03 00:14:58
QuArK duplicates all vertices belonging to both front-faced and back-faced triangles.
 I See
#329 posted by Qmaster on 2018/07/03 02:52:09
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
#330 posted by khreathor on 2018/07/03 07:52:30
Quake Web Tools
You should be able to run it by yourself.
 Quark
#331 posted by madfox on 2018/07/03 18:38:35
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.
 Madfox
#332 posted by mankrip on 2018/07/03 19:45:55
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.
 Ah
#333 posted by madfox on 2018/07/04 07:42:40
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.
#334 posted by anonymous user on 2018/07/06 05:46:33
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
#336 posted by A_COC0NUT on 2018/07/10 14:21:32
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
 #336
#337 posted by Kinn on 2018/07/10 14:54:45
Use QuakeSpasm-Spiked then.
 @A_COCONUT
Type host_maxfps 0 in Quakespasm-Spiked console to decouple the framerate. More info at 3.1 here
 @dumptruck
#339 posted by Baker on 2018/07/10 17:09:56
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
#340 posted by Cocerello on 2018/07/10 19:18:30
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.
 Host_maxfps
I set mine to 144 to match my monitor.
#342 posted by Spike on 2018/07/10 20:02:19
@A_COCONUT
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).
@Baker
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.
#343 posted by Baker on 2018/07/10 21:13:12
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.
 #343
#344 posted by mankrip on 2018/07/10 22:26:34
Windows 9x interface will always be the best.
I'm particularly fond of the Windows Me interface, too bad the underlying OS was crippled.
#345 posted by Kinn on 2018/07/10 22:35:49
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.
#346 posted by Baker on 2018/07/10 23:13:14
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.]
#347 posted by Spike on 2018/07/10 23:17:52
@Baker
cl_yieldcpu 1
@Kinn/FifthElephant/Cocerello
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).
#348 posted by Baker on 2018/07/10 23:31:21
Spike --- no difference. Now this is FTE 5020 from April 2018 +/-.
cl_cpuyield 1 -- screenshot
 @spike - Re-review
#349 posted by Baker on 2018/07/11 04:08:41
If I set cl_idlefps to 30 and cl_yieldcpu, the cpu usage when FTE isn't the active app is quite good.
screenshot
But cl_idlefps defaults 0 according to the screenshot. Which was the source of my pain and frustration.
 #285
#350 posted by adib on 2018/07/11 18:48:47
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.
 @adib
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?
 @dumptruck_ds
#352 posted by adib on 2018/07/13 22:59:09
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
#354 posted by A_COC0NUT on 2018/07/14 16:12:55
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.
@dumptruck_ds
Love the mapping tutorials. Keep it up.
@Shamblernaut
I would love to have decals and multiple fogs. It would make maps with multiple distinct atmospheres easier to make.
 @354
#355 posted by PRITCHARD on 2018/07/18 12:29:12
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
#356 posted by Kinn on 2018/07/18 12:46:24
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.
#357 posted by PRITCHARD on 2018/07/18 12:51:16
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...
#358 posted by Kinn on 2018/07/18 13:01:26
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!
#359 posted by PRITCHARD on 2018/07/18 13:06:15
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...
#360 posted by Kinn on 2018/07/18 13:41:48
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.
#361 posted by mankrip on 2018/07/18 16:07:57
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.
 :popcorn:
#362 posted by Kinn on 2018/07/18 16:11:41
#363 posted by metlslime on 2018/07/18 18:27:37
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
#364 posted by Qmaster on 2018/07/18 18:46:57
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.
#366 posted by Poorchop on 2018/07/18 21:25:06
Fog is perhaps the single greatest feature ever added to these source ports. No better way to instantly create a beautiful atmosphere.
https://i.imgur.com/cwakFVt.jpg
#367 posted by Kinn on 2018/07/18 21:25:20
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.
 @kill
The destruction of my config.cfg file is what REALLY turns me off about FTE.
#369 posted by Spike on 2018/07/18 22:23:26
@Kinn
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.
@dumptruck_ds
Destruction?!?
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).
#370 posted by Kinn on 2018/07/18 22:26:58
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.... >:}
 @Spike
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
#372 posted by Spike on 2018/07/18 23:33:02
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).
 @spike
#373 posted by PRITCHARD on 2018/07/19 02:45:21
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.
|