 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
|
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!
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! :) 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. 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. - 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 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. 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. 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. 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. I am really liking those ideas. Seeing the new Shambler model shows the potential for actually getting it right....
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. 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!! Spike FX fully integrated in official QS.
Also a new vore model with puffy tits and a dripping bloody snatch with teeth. 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. 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. An option to emulate the 8-bit colour look of software quake (with its crunchy banded lighting etc.) in Quakespasm.
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. 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.
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. 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. 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. 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. 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 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. 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. 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.
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 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. 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.) 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. 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. 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. 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) To be clear, I want more FANCY EFFECTS, but only introduced carefully and subtly as many of the current good ones have been.
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 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. 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. 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?
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.
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".
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). @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). 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? - A digs map.
- Release one or two maps myself. - Halo Forerunner-themed mapjam - Silent Hill Otherworld-themed mapjam - uhhhh.... 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. 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. 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. Yea for me this is why MD3 would be a good one or IQM which has bone support! As for some new format be careful because that can get tricky with supporting proper exporters for various art authoring tools. Something that can convert an FBX file to this new format would be a good middleground since tons of software can export to FBX.
#24 Retroquad 1.0
Definitely not happening in 2018. #26 Lightmaps on liquids I've tried encouraging other engine coders to implement this in their engines, I've showed how to properly detect if a map was compiled with lit liquids, EricW coded full support for lit liquids in his compilers, but other engine coders were against it. Mappers were also against it, by shutting down my suggestion of enabling lit liquids by default in EricW's compilers because not all engines supports it, despite there being no side effects in engines that doesn't support it. Interestingly, not all engines supports translucent water either, but nobody complains about translucent water being enabled by default. Darkplaces does support it, and FTEQW probably does too. What's funny is, even if someone maps for DP, they'll never casually find out that DP does support lit liquids, because the map compilers won't lit the liquids by default. If lit liquids were enabled by default, we'd have dozens of new maps using it already, and people would start to figure out how to take advantage of it in their maps. So, it's not going to happen. People are against it. Yes, that's what I'm thinking too. Easy change to the engines. Easy change to the mdl exporters. Just mdl with better precision.
Engine stuff:
I guess weather supported across the engines. An implementation where you can just stick a weather entity in a map and tell it to either rain or snow! QSS works really well of course! Another vote for fog brushes. Maps: I'd also like to see less huge hub-like maps and more dense and original designs. Small episodes or just plain ole medium sized individual maps would be a fun change of pace. I also agree with some people saying about more focused jams with strong themes vs texture usage or one gimmick. Themes: Hmm I don't know, the fun part about that is mappers constantly come out with crazy cool ideas. So I suppose let's just keep doing that! I know I would like to release at least one episode myself personally. The Episode Jam will be a nice early year treat I hope! ;O I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both.
Not exactly 3d skyboxes but one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense. There's always a stick in the mud somewhere, especially when it comes to engine or mod coding, it seems.
I hope we do get to see lit water in 2018, especially since on paper a lot of the issues have been sorted out. Perhaps we'll see it in a QS fork, or perhaps even in QS itself... I wonder how much of the pushback against it is because it's supported by DP and no one wants to be on the same side of an issue as DP ;p ...one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes...
I'd love to see that. I brought it up during RMQ development but it was shot down at the time. The idea I had was that you could have 2 or 3 layers of skyboxes and blend between them, so you might have a rotating "clouds" layer and a static "scenery" layer, or whatever. If a new model format is considered, I recommend either
==================== 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 #77
See #75. #31 Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though. Super8, Engoo and MarkV already supports alphamasked models, and Quakespasm likely does too. Glowing eyes and flowing lava can be faked by using fullbright colors and animated skingroups. Animated skingroups are part of the original Quake MDL specs but were never used in the main game, so most people aren't aware it exists. IIRC, support for animated skingroups was broken in GLQuake, but custom hardware-accelerated engines fixed this ages ago. What I don't remember is if animated skingroups supports custom timing, like animated framegroups does. Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer... Lit liquids with luma textures can break the tiling. But again, lit liquids aren't going to happen, and I don't know if MarkV and Quakespasm supports luma textures. I second more advance water volumes that accept lighting and foam. Foam could be faked by using "negative dirtmapping" on lit liquids. Dirtmapping makes surfaces darker at the edges, but if it suddenly cranked up the lighting at the edges all the way to fully white instead, it could look pretty close to foam. Even without negative dirtmapping (which could also be called "foam lightmapping") in the light compiler, this could be faked by manually placing lots of tiny lights on the liquids. The other sensible way would be to implement texture crossfading, which I'm going to do in the future (at the moment I'm faking it through soft depth), but I don't know if any of the other engines supports it. Also, each engine (Q3A, etc.) does texture crossfading in a diferent way, and getting some consensus on standards for such things is near impossible given how different each Quake engine is today. I'd like to see it included with new releases of source ports. It would lower the barrier of entry massively for newcomers who don't know how to, or even want to, create shortcuts and BAT files.
A simple front-end for loading maps should be a no-brainer in this day and age. :) If a new model format is considered, I recommend either
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. either md3, iqm, or its a waste of time - the tools are much more important than the format itself, and bsp2 meant the same tools could be used (or at least the user-visible ones).
mdl tools pretty much universally suck, worse - the main one that people seem to use is closed source. md3 already works in qss(r8), fte, dp, ezquake, and _multiple_ others. And there's been at least one software-rendered engine that supported it. iqm works in fte, dp, and rmqe... and oh noes! quats! flee in terror! So yeah, md3. Trying to push some other format is pretty much pointless now, especially as there's ALREADY two 16bit q1mdl-derived formats (that noone uses). q1mdl just isn't worth it, imho, especially when the various incompatibilities will persist regardless. I didn't know QSS already supported md3.
That hugely increases the chances of it being implemented in other similar engines then. Just need some md3 content, and I'm sure increased support will follow. a couple exporters exist for blender that are still maintained and there's enough literature to get you rolling quickly. tags are nice, too.
I'll admit I haven't looked at QS-Spiked (or really anything quake) for the better part of a year - does QSS support crunchy pixel filtering on the fancy particle system yet?
yes, 'nearest_texture foo.tga' instead of 'texture foo.tga', though I think it requires ALL foo.tgas to use the same type, which is a bit annoying - I didn't tweak QS's texture manager code that much.
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
#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. 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
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? ... 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. 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. 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. 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. 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 ... 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. 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! 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. ...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. #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. I noticed that some universal flags like Not in
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? 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)
...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. isnt a "sample" in a hardware occlusion query effectively a raycast? I admit to not knowing the tech behind it.
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...
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. And raycasts, lots of raycasts. Whatever the fuck they are.
+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? spy, cheers I might visit that discord place as long as it's not full of weird porn like the irc channel was.
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.
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. 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. 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! Thanks, I now feel like a right knob that I typed all that out without knowing about -basedir.
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. 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.
I've saved some especially for you, there's a secret sub-channel specifically for that stuff :)
How many camera positions does vis compute anyhow? Or does it figure out how many positions to account for and only compute those??
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.
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! That would make updating so much nicer, as well as having multiple engine/single directory coexistance.
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 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.
DLLs are, of course, a Windows (and OS/2) thing. On Unix and Linux you have
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). 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. 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... If you are asking for enemies that are aware of the player since spawn, that exists already. Just trigger them with a trigger_once on the player's spawn.
If you want proper pathing enemies, necros ne_dynamic mod does that, plus some more things. Scrags that don't move on z axis with clip brushes. And the player will never notice if he can't reach that height.
Smarter daemons: slopes instead of stairs, abundant use of clip brushes, no low ceilings, complement on axis walls with 45º ones, and a lot less doors or make them as wide as the rooms they connect. Monsters that jump without monster_jumps can be achieved by making them land on brushes too small for them. This can be repeated with the brushes below them and to the infinite. Currently, the Quoth/AD wizards, flying daemons and minotors have a poor resolution mesh. They don't look as good as all the other monsters (especially the default models).
I think they need some love. AD has vertically-aware ogres that can aim grenades at anywhere.
Oh, you mean path-aware, not height-aware. I second the notion that they'd become bots. It could be interesting to have area-specific waypoints to help monsters battle around their intended place without hunting the player through the whole map. When you leave the area, they'd stay back waiting for you. The concept of territorialist monsters is cool indeed. 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. :)
I'm a filthy linux user. Is the argument for external libs not an argument for ease of upgradability?
If my SDL libs are statically linked into the executable, and I want to upgrade to a newer version of SDL, I need to recompile my whole game. Also on my wishlist for this year is for Baker to incorporate my IRC mod into QS master... Oh wait... Realistic, that's not going to happen with my coding skills XD If my SDL libs are statically linked into the executable, and I want to upgrade to a newer version of SDL, I need to recompile my whole game.
I think that's the promise, yes. The reality is that never happens in real life settings. It could be interesting to have area-specific waypoints to help monsters battle around their intended place without hunting the player through the whole map. When you leave the area, they'd stay back waiting for you. The concept of territorialist monsters is cool indeed.
AD has this functionality, although I have not tested it. It's a "tethering" system. Don't have the entity info handle but Simon mentioned it was used in ad_tfuma I believe. It sounded pretty handy. That depends on whether this tethering system works as waypoints (chained paths) to also help the monster navigate the area. Vanilla Quake already had waypoint-style paths for patrolling, so that may be the case.
I've always wanted to do a Quake mod that was basically Left 4 Dead, in that there was a director written in QuakeC that just spawned monsters as needed. I don't know that it would be all that hard
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. I think it's weird now because AD is the defacto version of Quake we play
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. Quoth is still my Quake mod of choice. AD has tried too hard to harmonise (for lack of a better term) Quake's thematic in a fantasy direction, and in doing so has lost what I always really loved about Quake, which is the thematic dissonance. Easy example: I like seeing sci-fi health boxes in a medieval castle.
I have played some AD and it's very well made, but to me it will never be Quake, because unlike Quoth it changed Quake rather than simply adding to it. Anyway, back on topic, Warren I have also dreamed of a Quake/L4D mashup for a long time. I envisage the director choosing between some pre-crafted encounters (and scaling them) in response to the players actions. You would also need to add a few new enemies, such as fast grunts with melee weapons and mini-bosses that have to be attacked from multple directions, etc. Was never meant as a replacement or even an upgrade. AD is it’s own thing, there will still be new maps for quoth and other mods.
AD is definitely the most polished mod though, I’m proud to have been a part of the team 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.
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.
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 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. 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!!! 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 :) #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 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. Mark V added a ground-breaking mouse driven menu [...].
Whether or not daft people notice today, it is going to have a major long term impact. I want to mention this first because user-interface matters. Wrong. There were mouse-driven GUIs for Quake engines before, and most of them never inspired other engines to follow suit. Even Makaqu has a mouse-driven GUI with a minimalistic approach, which uses the mouse wheel and buttons instead of a pointer and is therefore faster in most situations when we get used to it. Another usability improvement implemented in Makaqu to make menu navigation faster is that the same command used to open a menu can also be used to close it. Press F8 to open the keys menu, and press F8 again to close it. No more pressing Esc multiple times to get back to the game. Has this ever been implemented in another engine? No. When it comes to trends in engine coding, user interface doesn't matter. Technology matters. Engine coders enjoys to implement challenging technology, and this is why we've got multiple engines with CSQC and MenuQC support, which requires users to learn programming in order to modify the menus. Meanwhile, the Makaqu engine has menus that are completely customizable through just 2 (menu_keys_clear, menu_keys_addcmd) or 3 (menu_clearmaps, menu_addepisode, menu_addmap) console commands, which any braindead user could do in a simple autoexec.cfg file. For over ten years, this never inspired anyone else to follow a similar approach to Quake UI customization. Usability generally favors minimalism, but it's hard to not get ambitious when doing engine coding. Unambitious approaches doesn't sell. Anyway, I've never implemented a maplist command and some of the other usability improvements that other engines have. I've stopped implementing usability improvements after noticing that most people don't care about them. When usability is good, people don't notice it. And there's no demand for what goes unnoticed. This is why Quake engine usability tends to follow a reactive design-by-committee approach, fixing issues while ignoring improvements. Real question: Am I alone in wanting Quake to be more than it is today? You're not alone, but it's difficult to come up with a consensus about what "more" means. Most of what the community at large agrees upon seems to have been done already. Further efforts rarely achieve consensus and are most often considered to detract from what the authentic experience should be. Which is why I don't even try to promote Retroquad as a Quake engine anymore, and instead am developing it towards indie game development. Or maybe I'm just drowning in my own negativity, who knows. In Quake you can enter a room, shit yourself, and back out of the room to re-evaluate your strategy in the knowledge that a big conga line of monsters is not going to just perfectly chase you down all through the map.
Any enhanced pathfinding AI needs to appreciate that this sort of soft "tethering" of monsters to an area may be just a quirk of crap pathfinding at the moment, but monster area-limiting would certainly need to be a feature available to the designer in any future AI rewrite. But it can't be rigid, because you'd still want to be able to "pull" a monster to anywhere you want as well. He's spot on. AI needs a refresh. I'm sure there's some way it could be offloaded to the compiling stage like Q3A. So the mapper adds some entities to help with dumb monster behavior and then an external solution takes that data and bakes it into the map. Engines devs would then have the option of supporting the new AI feature or not.
Would this be feasible? I appreciate the convenience of a mouse driven menu but frankly I have a high DPI mouse that always runs too fast in these types of UI. It's certainly welcome and I am all for making things more usable for noobs. I think it's important to remember that communities have to grow to succeed in the long run. We want Quake as appealing and accessible as ever. I still think it's possible to create a set of standard that can be voted/agreed upon and then collaborated on by the brightest minds in our coding community. So the mapper adds some entities to help with dumb monster behavior and then an external solution takes that data and bakes it into the map.
Q3 looks at the connectivity of the BSP leaves to generate the AAS graph right? Something like that sounds like a possible approach, rather than the designer having to add loads of nodes everywhere. Of course, once you have perfect pathfinding, it's then up to the designer/modder to write a load of QC code to do all the extra AI logic that stops the whole level playing out like a Benny Hill sketch. Honestly, advanced AI belongs to "what do you want to see in a mod", not "what do you want to see in Quake". AD is the perfect candidate to such a thing, and it already has tethered waypoints AFAIK.
I think my breadcrumb solution is reasonably "ok"... it would mean if you were properly keen on running away you should still be able to do so.
the idea would be: every 5 seconds or so the player spawns a short lived invisible entity (breadcrumb), if the monster can't see the player, it searches for that breadcrumb, and travels to its location if the breadcrumb has line of sight to the player. If the breadcrumb doesn't have line of sight, the monster just continues on its usual dumb pathfinding. this way the monster is likely to get an extra corner or so of pathfinding before losing the player Something along those lines could work. Not an invisible entity, but just a
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. I'd love to see certain enemies use others as meatshields... chunkier enemies up front and center while the smaller ones try and flank the player
I'd also love to see ogres figure out how to lob grenades over other enemies heads at the player rather than the designer having to add loads of nodes everywhere.
I'd rather have control over it though - as no matter how good the implementation is there will be issues. what I'd like to see would be engines to FINALLY start supporting tracebox, so that this stuff can actually be implemented...
without that, good luck with this ai stuff... you'll need it... but yeah, without this being some map-specific thing, you're going to drastically change the balance of various maps. 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. 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 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. Does support colored lights.
I can agree on FTE. Not really sure where it fits in, no offense to Spike or anything. @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 Well...I would have a leg to stand on by arguing that Quake needs point lights sprinkled throughout a space as fill lights, but...
ericw already made this method of lighting obsolete with his bounce lighting. With too many point lights comes dozens of overlapoing shadows = ugly and distracting and poor performance...on older maps that are much more evenly lit. Something I'd like to see is an engine which focuses on a modern tool-chain with modern formats. No one is considering Quake engines for bigger TC projects because every project also seems to aim for compatibility and misrepresents itself and its capabilities.
So, you want an engine that works with modern asset formats, but you're also knocking points off engines for being compatible with the original Quake. Ummm... maybe just do whatever in UE4 or Unity? Not sure I understand why anyone would even want a Quake engine in this situation... I've noticed just how out-of-place and incongruous real time lighting looks with Quake's old textures and models, especially with pixel mode on, hope that helps.
I think it fits perfectly with them =D
but it's ok, let's agree to disagree ;) i'm not here trying to change anyone's minds, i'm just answering the question of what i would want to see in quake in 2018. But nobody has to agree with me, it's just my two cents ;) These engines run on certain ranges of modern hardware, Unity struggles heavily on integrated chips and even dedicated cards from 5+ years ago, also have all sorts of licensing issues and do not contain the same workflow that everyone is used to in the Quake community.
There is a lot of tech in between QuakeOne-level-tech and something like UE4. When it comes to 3D Gaming engines it's probably as big of a gap as there can be. You never have to take full advantage of such things. I am sure that anyone would welcome a Quake engine where the audio, physics and rendering API was on par with something like the Source engine (because no one has $25000 to pay to Havok and RAD Game Tools) But seeing as only one current Quake 1 engine fork (being FTE) even attempts to take advtantage of things such as a Bullet physics implementation or supporting OpenAL Reverb setups, that's not really happening. So that's what I'm talking about. Of course, what I named above is an example. People love Quake modding, they are familar with it. Everyone here takes advantage of the GPL all the time and are able to build fantastically open things - but all everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts. aal everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts.
Yes, and? For what it's worth, engines probably typically want to react to what the community is actually doing, rather than create a brand new content creation paradigm and then hope that some modders pick it up and start doing something worthwhile with it.
DP, FTE have md3 and Q3 bsp, amongst all manner of other things, and have done for a long time. When we start seeing good projects based around those features, we might start seeing support in other engines. this thread title is like a legal contract - realistically. Its such a relative term :D I'll try.
Realistically I would love quake's palette restrictions lifted. I understand that its all comes down to the fact that old wads and bsps can't store truecolor images, but (correct me if I'm wrong) you're converting them to truecolor anyway when loading into memory? So bsp can store palette.lmp. So what if, upon loading said bsp, engine detects it has palette.lmp and uses it for textures from that bsp, instead of default one? Obviously items and weapons would still use original palette. From my ignorant perspective it sounds very realistic. But then again I have no idea about inner workings of Quake engine, let alone source ports. Point is - using colors from original palette is very limiting. It might be a good thing to keep things coherent and 'in-style', but from what I've seen so far, people would rather create awfully translated to quake's palette textures than adjust their design decisions. The idea of creating a new mod just so I can change color palette is absurd and discouraging. Whoa, you can totally remove all palette restrictions right now by just using external textures! Works in every custom quake engine I know.
You can even keep your new fancy coloured textures looking all limited-palette and pixel arty, but that's an artistic decision now. If you're using external textures, you can still have crappy Q1-paletted versions "baked" into the bsp to allow backwards compatibility for any wierdos somehow not using an external-texture-compatible engine, but if you aren't interested in backwards compatibility, you can even tell ericw's qbsp to strip the Q1 textures out of the
What some popular engines doesn't support are special textures like bumpmaps, normalmaps and so on. Regular 24-bit color images are fine.
@#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. @Spike
First, i love your engine. Second, You sir, are a genius =D Third, thank you for your awesome work =D Where would I find info on how to add real time lights to my map for FTE? I'll be honest I am not a big fan of those BUT I would rather place them myself than have FTE do it automagically.
In this community, 'good' means 'like quake', which in turn means 'low res', which to most people from outside the quake community means 'crap'.
That is the problem. For me, 'good' means 'fitting in with quake via gradual enhancements' which in turn means 'a resolution harmonious with the level of models, typical map brushwork, and general graphical effects'. We are talking about Quake so I can agree with making it fit with Quake's style.
I would like to have a CSQC HUD template that matches the original HUD so that people could use it as a base to tweak or add things rather than reinvent the whole wheel. Heck I might make one myself someday. Quakespasm inherited per-map external textures from Fitzquake 0.85; they go in /textures/mapname/ (docs: http://celephais.net/fitzquake/files/fitzquake085.txt ).
Probably wise a decision merging my thoughts into this thread, but I wanted to avoid the toxic stew of the unrealistic weird crap in this thread.
Too much crazy talk for me in this thread, I was referring to more pedestrian things. That being said Appreciate you, Shambler! "Wrong. There were mouse-driven GUIs for Quake engines before, and most of them never inspired other engines to follow suit. Even Makaqu has a mouse-driven GUI with a minimalistic approach, which uses the mouse wheel and buttons instead of a pointer and is therefore faster in most situations when we get used to it."
Load up Mark V current beta build. 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! May I ask for you try to the mouse driven menu in Mark V build 1050 and share if you if I completely fucking nailed it?
You are a big "stick-in-mud-conservative" which means your opinion is only kind I value. (If you doubt me, ask Mugwump if I think I value your opinion some time I'm sorry if I'm missing something here, but what exactly defines (in this case, at least) if a mouse-driven interface is 'done right' or 'done wrong?'
Proven good taste for classic Quake is self-evident. If you have to ask, you are not the target audience for such a question.
People with appreciation for the taste of classic Quake and conservative credentials are never in doubt. They never ask such a question and are pre-loaded with conviction of their righteousness. 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. My "bad rants" are purely philosophical perspective and conservative prudeness, otp. Your bad rants tend to be personal.
My "bad rants" are impersonally "perspective oriented", even here. 12 beers down and my honest 3rd person critique of a point-of-view is kinder than yours which has many times been euphemistically "quite unkind". Baker + 12 beers > bigger morale compass than otp. I still care and am not looking to offend the person. Life lesson for otp perhaps? So
Try the various mouse driven menus listed above, post your thoughts Don't question your judgment You have already demonstrated you have talents that care for the betterment of Quake. Everyone has seen this.
Why not go with that? You can't spell anti-hero without hero, so quit being such a dick for no reason maybe? I'm just saying We all know you have the capacity for good. I'm well aware of, and actually quite enjoying, my moral compass not being fully functional, so that's hardly a life lesson.(If anything, your bragging sounds like classic compensation, which is fully plausible, considering some of your older, absolutely callous musings in certain threads)
But I'm still capable of doing good, as are you - so I'm hoping once the drunken haxe wears off, you will reflect on what you've done, which is scream profanities at a potential user for asking an unobvious question. I have never used a mouse-based menu in Quake, so out of pure curiosity I would be seconding Spud's question. What's in it for me, as another Quake-conservative player? Or does that question reflect on my tastes and design sensibilities (which have been an asset so far) as well? If it is such a revolutionary implementation, it shouldn't be difficult to explain. And no, thanks, I'll be an actual hero where I think it matters, which is not the Internet.
If it is such a revolutionary implementation, it shouldn't
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. @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. Thanks for the feedback, even though your feedback differs from other feedback I have received and I had reason to question to your judgment from the start, don't think for a second I won't take your feedback into consideration.
I'm hardcore that like where I consider the feedbsck from all. +1 for rising to the occasion. OTP. Let us hear your opinion. Yeah, I am
A sincere thanks for your feedback. I get what you say about the mouse wheel, but I strongly disagree for reasons that are too detailed for me to explain right now (but make perfect sense -- either you honor the mouse position or you don't and in that case you must take the mouse position over the mouse wheel for behavior reasons). I reiterate that I do respect you. You manned up. I always respect anyone who manned up. You did. Case closed, you have my respect. I wanted to convey that. That was an interesting last 20 posts....
I wanted to avoid the toxic stew of the unrealistic weird crap in this thread. Too much crazy talk for me in this thread Oh okay then. My "bad rants" are purely philosophical perspective and conservative prudeness, otp. My "bad rants" are impersonally "perspective oriented", even here. Baker + 12 beers > bigger morale compass than otp. quit being such a dick for no reason maybe? You are a big "stick-in-mud-conservative" I'm not entirely sure about that, given that half the old skool maps I play on stream I comment with "This would be really nice with some subtle fog and coloured lighting and AD-style breakables", and that I have started a thread about modern improvements to Quake. I suppose I am a big "gradual-improvements-and-harmony-with-current-Quake-style conservative", tho. Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for. HTH. "Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for."
Thank you for taking the time to try out the mouse-driven menu, I invested a lot of time and effort in it. I'll take this as a good start for today. Perhaps, tomorrow I hope to win your heart and your soul completely over. I may not have entirely accomplished this today, but I will take that I at least partially won your over. That will have to do for now. I appreciate your feedback and thank you for taking the time to do this, Shambler. Based on me barely having a total of 17 beers-worth of alcohol in the last 2 months.
Mouse-driven menus - never felt a need for it. Improved AI - why not, I wouldn't mind it if it's done well. Not a fan of uber-strafing bobs and nehahra enemies, and z-aware ogres have to be used sparingly, but some better chasing AI could be pretty fun if used well. Like everything, introduce it carefully. Also better tactical negotiations between different enemies could be funny as long as it doesn't override infighting. Real-time lighting / high res textures - both completely out-of-place and jarring with the current level of detail and especially the current Quake models. However these things are constantly improving and if/when all the Quake models are improved and a higher level of design / detail becomes standard (subject to mappers being able to do it easily / comfortable), then both of these more advanced graphical effects would be pretty welcome. I've said it before and I will say it again: Subtle, incremental, careful, and harmonious improvements to Quake's graphics are great There's already been a lot of good stuff added: coloured fog, coloured lighting, breakables, transparencies, cobwebs/vines, particles, the new Shambler model (not perfect but I like it and it does fit in) etc. All of these have been small changes that still fit well with the relatively crude models / texture resolution / detail levels, AND they have often been used really nicely and carefully by mappers to enhance their maps. Hopefully there is more of this to come, and in time bigger graphical leaps like hi-res tex, RT lighting, soft smoke etc, will be able to fit in well too. I'm tempted to add a big laundry list of stuff, but I'll just mention one thing for now.
- Some kind of thing that works as follows: Create a brushmodel, place it in your level in a nice position, and flag it as "always draw". Now, throw sky brushes around to seal all your rooms in a sensible "I understand vis-blocking" way....but...plot twist! Wherever you see sky, you can also potentially see your special "always draw" brushmodel, drawn in front of the sky but otherwise sorted with the rest of your geometry. This would allow the creation of town / city style maps with cool skylines that don't make the engine draw literally the entire level at once. To make it more optimised you could even give the mapper ability to turn it off in places where you don't need it. Keyboard focus should not be tied to mouse focus. I'm not going into the specifics, but there are good reasons why all operational systems' GUI keeps both focuses independent.
All major operational systems have user interface guideline documents describing what makes an interface to be good. From the ones I've read, the Microsoft one was the best, despite their product still having major design flaws. There's also the Apple one, and some others from some Linux distros. Anyway, for Quake itself, in which mouse aiming has become the main control scheme, the purpose of a good mouse-driven interface should be to remove the need for the user to switch his/her right hand from the mouse to the keyboard. Just that. The mouse should enable the user to do anything that the keyboard would require his right hand for, minus typing text. So, the main measure of good mouse-driven interfaces in Quake should be that the less right hand movement needed, the better. Arm injuries such as Carp Tunnel Syndrome are very real and some players have them, so the developers must take this kind of issue in consideration when designing their UIs. User interface design is not a subjective mysterious art. - 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. Do those work with objects that are still very much part of the level though? Say I have a church spire. In one "room" of the map, the church spire is placed as very much a physical part of the room, like any other brushes.... it's just this particular object would get flagged to also be drawn in other "rooms" in front of the sky faces.
No that would not work in Source/Unreal skyboxes, which basically just draw the contents of the sky-room as really big. What you're describing sounds kind of clunky to setup.
Having Unreal type skyboxes would be neat though, that's for sure, and it's purely visible so kind of backwards compatible (engines not supporting it would just have the normal sky or skybox). Hmm, in that case the objects wouldn't be part of the skybox. Getting such a thing to work could be tricky.
We already got visblockers, and your suggestion needs the inverse — a vis unblocker. Also, depending on how the engine handles skies, things can get complicated. But new mappers entering the fray.
With Dumptruck_ds's tutorials I think that's entirely realistic! ;) Q3 BSP supports skyportals (for things such as 3D skyboxes)
For The Wastes I pushed Spike to add support for cubemap layers in FTE's sky shader stages. That way you can have a scrolling cloud layer (or 2 or 3...) in a shader and overlay a skybox on top of it. Like a mountain landscape or something. That will get the Unreal effect. In the end if you want more fidelity like that, pretty much everything is already doable in the Q3BSP/Shader world. The stage in question will look somewhat like this
{ map $cube:gfx/env/mountains blendfunc blend tcGen skybox } Thoughts on mouse-driven menus in Quake:
Retrofitting the qmenu is not the most ideal thing. You can get it to feel somewhat okay, but it will never beat a design that actually is designed around the input method. Simply being able to click on options that were previously able to only be selected with a keyboard does not make the menu usable for mouse driven input. A good mouse driven menu allows you to jump quickly from one place (that was deeply nested into sub-menus before) into another place with just one click, while still retaining a sense of order. In the case of Quake, that would require dumping menu.c into the trash. Unreal used to have a very Quake/Doom ish looking menu, but with Unreal Tournament they realized that people actually wanted to move around the menus fast and have a better overview over all of the options available. This was then carried over to Unreal Gold and that's how most people see it today. It was a drastic change but a needed one. isn't like RtCW had 3d skyboxes? I vaguely remember seeing some kind of screenshot or something showing small scale far-away environment, later rendered before level as if player in the centre of it?
As I've said before, Q3 BSP supports skyportals, aka 3d skyboxes. So yes. RtCW probably used them...
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. You can enumerate paths one time only at startup then only search the paths that actually exist when loading textures. Sort a PAK file directory and binary-search it. Use the native API which has faster calls for determining if a file exists rather than putting everything through stdio.
The point is, you can be a little intelligent about how you approach problems and it doesn't require creating hugely complex code. It's better to do the path enumeration at the beginning of map loading, in case the user alt-tabs to add more assets without closing the engine.
I often add more external textures and reload the map in-game when mapping. ...TB including a GL-filter mode as default so when we're watching streams of people making otherwise awesome looking maps, we don't have to have them ruined by shitty square pixels everywhere when the mapper is zooming around in and out of brushes.
Also I want to see the return of Baker once his hangover finishes. Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer.
Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment.
TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D )
[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 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. 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. 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. Good filtering is much more important with high resolution images than it is with low res stuff (where it just makes them blurry).
One thing i like about filtering is that how smooth it looks in motion, in unfiltered mode is the scene is very noisy/sparkly as you move the camera.
However, filtered mode makes each pixel less vibrant/contrasty, everything gets a little bit more gray and colors shift towards the local average. For example that wall texture in e1m6 has lots of little single pixels of green and blue that pop really nicely in gl_nearest, but in gl_linear they are dulled and dim, and blend into more of an average grey. I feel that's one of the main reasons quake world textures look better unfiltered, it's the pixel art precision of some details that get desaturated and dulled in filtered mode. Ok, since metl mentioned it, the sparkly pixel movement phenomena is temporal aliasing. I want temporal antialiasing in Quake.
GL_NEAREST_MIPMAP_LINEAR is the best compromise IMO. Sparkles are caused more by not using mipmaps than by using nearest filtering, and linear sampling between miplevels eases miplevel transition artefacts. The other improvement is to use screen-space derivitaves from unwarped texcoords when sampling warped textures, otherwise they shift between miplevels as they warp. One of those things you normally don't notice until it's pointed out to you, then you can't stop noticing it.
yeah my settings are GL_NEAREST_MIPMAP_LINEAR + anisotropic set to the max. The thing i don't like about mipmapping in hardware rendering is how floors (and other edge-on polygons) blur into a solid color, and anisotropic reduces that problem quite a bit.
Agreed, anisotropic is essential. Different people are different, so I tend to find anything beyond 4x is not that big a deal, but I won't go below 4x.
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.
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. Ranger will end up slobbering,
after the Shambler gives him a clobbering. And so forth. ...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. Another thing that no current Quake engine does, AFAIK, is gamma-correct mip-mapping: http://filmicworlds.com/blog/gamma-and-mipmapping/
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. 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) 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). 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. 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 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. What editors support region compiling?
In some versions of radiant, you just drag a brush out to define a region to compile and the editor then only sends that small subset of the map to the compiler, automatically boxed in, with an info_player_start added where the camera was. That's a pretty straightforward thing to add to an editor, and would massively help you do quick iterations when mucking around with localised lighting. The best approach would be to edit the light entities in the engine itself, save a diff file containing the modified light entities, and make the engine call the external light utility to recompile the lights.
Upon parsing the diff, the light/BSP compiler would check which lights were removed/added/modified, and relight only the surfaces affected by them. However, Quake's lightmap format still has some annoying limitations that restricts the productivity potential of such an approach. Dirtmaps, sunlights and bounce lighting would likely require the.whole lighting to be recompiled anyway. And the lightmap doesn't keep track of which light entities affected each surface. 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. 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. 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!!!!!!!" @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! I was just thinking about how cool it would be to have a quake/arcane dimensions 8km x 8km map/mod that had a full 200 players per server with little towns to venture to, to fight hordes of monsters or other players with quests etc. hmm maybe like a world of quake-craft but a merge of coop/pvp on a huge map with faithful art assets.
sorry just mumbling over here at 3:13am :D Thanks for checking out the mouse menu, R00k.
Yeah, I'm a stick in the mud conservative that couldn't accept a menu with any changes in the appearance. I was just thinking about how cool it would be to have a quake/arcane dimensions 8km x 8km map/mod that had a full 200 players per server with little towns to venture to" If you look at some of capabilities in Mark V, I am angling in that direction. It has a mod installer built-in, ipv6, some severely enhanced coop features. Combined with some of Spike's work in Quakespasm Spiked, this is almost possible now in theory. That type of thinking is what I ultimately want. The ability to co-operative play easily in an immersive multi-player environment. Makarate once ran a Quakeworld coop server using the Undergate level I made. And obv, my work with RocketGuy on RQuake coop and his then popular coop server. And of course, Gunter who even now runs a Quake co-op server ;-) Given that Ter Shibboleth apparently required some pretty hefty code-monkeying to make happen ("...where [ericw] entirely re-wrote the leak code just so the map would compile"), I don't even want to think about what havoc and even larger map would wreak on editors, compilers, and the engine itself... not to mention the player's framerate.
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 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. More the size and complexity of the map part, regardless of how many info_player_coops it includes.
Needs to be designed for. E.g. a gate closes behind you locking you in to an area, e.g. for an arena fight or a puzzle. Your poor coop buddy gets squished by the gate, resses, runs back only to have to wait for the first player to kill all...crap he died too. Now you have to restart the whole level and cheat yourself back the weapons and ammo you had.
Desigb for coop please. I know it's just dreaming but FTE can handle pretty big maps. This isnt a new idea, years ago people were all talking about taking all the id1 maps and combine them into one huge map! I think that is a doable thing. and imagine 200 people playing across all those maps on 1 server doing their thing.. i think either coop of pvp that would be fun to play. and then imagine its not id1 maps but a whole little quake-world.. :boom: mind blown ! :^D
|
|
|
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |