A problem that DarkPlaces can have -- but neither Quakespasm nor Mark V can ever have that problem.

The Quakespasm content protection system prevents .ent files or .lit files from upstream directories being used on models in downstream directories.

id1 (start.ent) -> arcane dimensions (start.bsp)
^^ NO, that start.ent cannot know about model in gamedir

Once I urged LordHavoc to add that system (I call it the "Quakespasm content protection system") to DarkPlaces. He didn't think that was a good idea.

So DarkPlaces suffers greatly from that problem even today. 

mh, What specific issue are you talking about that I want to change from Quake's default behavior only because it suits me? That centerprint thing we were just discussing is a case where I WANT Quake's default behavior ;) And in that case it was you who was disagreeing when you thought it would be a change from Quake's default behavior, heh... soooo... aren't you doing the thing you accused me of?

What's ironic is that when people thought I was asking for a change to Quake's default, they seemed against it (ONLY for the reason that it was a "change"), but it turns out it was Quake's default all along (I only knew it was in ProQuake, which does stay pretty faithful to original Quake), and someone had changed it....

I'll quote Mugwump above, who said, "The point is the Fitz family of engines is more geared towards conservative Quakers. Therefore, changing things too much might not be a good idea."

That nails the point PRECISELY, and that's the position I approach from.

That doesn't mean NOTHING should be changed (certainly bugs should be fixed) -- and something like a more optimal positioning of centerprint is such an insignificant thing, and yeah, I would have advocated for that regardless of whether or not it was Quake's default. But I would NEVER push for something like, "centerprints should be in bright yellow text because I like it that way and it's more noticeable."

Do you see the difference there? One thing is just a minor optimization of text position which doesn't change the look or behavior of Quake, while the other thing is a major change from Quake's default look based on my own preference.

MINOR improvements and Behind-the-scenes-changes and options which CAN be enabled are great. FORCED changes from Quake's default, expected behavior are bad, especially when they cannot be disabled.

It's as simple as that.


And yeah, if you make a 4-sentence, pretty baseless attack on me, you get a multi-paragraph response fully describing my actual position ;)

By the way, what is your position on the centerprint thing now? It should use Quake's nice default instead of, as you said, "ugly hacks," right? :D


Come on people, don't be so serious. Then again, we're Quakers, and sometimes we just need to fire rocket launchers at each other ;) 

I just fire rockets...

@Baker We should petition LH to implement that protection system into DP. Let's show him how unnecessary it is! 

I get that the engine is geared toward single-player maps, but this feature is not good toward that end, except in limited situations. Yes, mappers use weird names, but if it's an actual "mod has its own directory" then there will already be a progs to send you to the right map. If that's not the case, there's no guarantee the intended map will be correctly named for this to find it.

"Weird map names" is a reason this function will often fail to do as intended.

I'm not speaking hypothetically -- this is happening to me. I have the IIKKA and Terra map packs. They aren't "mods," just maps, so I have them all in the same folder, without their start maps (unneeded). I also have a modified DM6.

So when I go to start a Single Player game I get put on DM6 because that's first by alphabet. There is seriously no reason this should ever happen when I try to start a single player game...

Ok, so I don't have the IKstart or TerraStart maps, but even if I did, there would still be a problem -- I would always go to IKstart regardless of what I want, because it's first alphabetically and contains the word "start." I will never begin on the terra or orl start maps if I have those in there too, or any other map.

How does this help me if I want to play single-player map episodes other than IIKKA? How does it ever help me if I want to play a selection of standalone maps? It would only work if I put one map at a time into my maps folder, otherwise I'm always starting on the same map.

Seems most of the time this function is not helpful, unless you're using a lot of separate folders, and it even becomes a hindrance in some situations.
Sure, it will work as intended if you only have one map, or only one map pack, assuming their is an auspiciously-named start map included. But that's the end of it -- if you add other maps, it breaks down and you gain nothing.

What is the solution? It's already there! An excellent Map Browser! Now THAT is nice. I may have seen that before, but forgot about it.... But since we have that, and we can easily select whichever single map or starting map we actually want to play, why then do we even need an automatic forcing of a potentially unwanted map, especially if we are expecting a single-player game (of a mod) to put us on the standard Start map?

So yeah, Map Browser: Beautiful, non-intrusive, allowing full player control.

Forced Alphabetical Staring Map: Drastic change from Quake default behavior which is not controllable by the player.

Options in order of preference:

1. Remove it! Heh, It just seems more negative than positive, and the user-controlled (important!) Map Browser is the IDEAL way to do this. Seriously. Love that.

2. Disable it by default, as it is far removed from Quake's default behavior. Allow it to be turned on if someone really wants it...

3. Even if it's left on as the default (*shudder*), give me a setting to disable it. Then you won't hear me mention it again, because it will stop annoying me, heh.

4. Have it be more selective and ONLY function if there IS a map that contains the word "start." TerraStart, IIKKAstart, ORLstart, whatever. At least you KNOW those are actually meant as starting maps. This wouldn't fix the problems I mentioned above (with many maps in the same folder you'd still be starting on the same map every time, regardless of what you want), but it would stop it from happening for those who don't want it by allowing some user control -- just make sure to remove maps with "start" in the name from the maps folder, and it stops sending you to some map (like DM6!) just based on alphabet.


Heck, ya know what might be more useful than allowing the whims of the alphabet to select your starting map? Allow the user to select any map as the default starting map from within the map browser. "Press 'D' to set this as the default starting map."

Throw me a bone and give me SOMETHING to allow me to make it stop happening! :D



Don't get discouraged, Baker, heh. Even though I hate this feature, I still love the engine as a whole. But just because you CAN do something, and just because someone asks for it (... who asked for it anyway? was the idea really well-thought-out?) that doesn't necessarily mean it SHOULD be done. There should always be someone asking if there are truly good reasons to make changes, and pointing out the negative issues that can happen if those changes are implemented.

Yeah, that includes any changes I might ask for. But I support my suggestions with solid reasoning, with consequences fully considered, and you'll never see me asking for anything that changes the look, feel, or function of Quake in a drastic way.

It's the job of us modders to do that, not the engine coders ;)


I'm just happy that you're actually making some updates now instead of later in 2017 :D 

loc file support -- is this not a separate issue from the macro format? I mean, it's not as if your hands are tied when you import something from another engine (just checked -- original Fitzquake didn't have this). Sure, maybe ProQuake chose to use %c as the macro, but you could choose to make it something like %c% instead (I mean, you changed "apropos" to "find" ;) ) It's just a matter of the user formatting their binds for the engine to access the loc files. But I guess all the other custom engines are using the %c format, so that's what players expect.... And anyway, this is a very minor thing, as I mentioned, which I don't care all that much about. But there's no reason to not talk about ways it might be improved.... 

No no no no no.

The centerprint positioning you want is not more optimal in the general case.

It's more optimal for your mod. It's more optimal for what you want to do. And that's leading you to downplay the importance of it's actual intended purpose.

A useful rule of thumb in cases like this is to ask yourself "what if two mods did this?"

So please, try to look beyond your own requirement and think about what would happen if two mods had different centerprint positioning needs.

That's why we have defaults and that's why defaults sometimes don't suit individual mods.

There is a useful dialog to be had about making centerprint positioning more flexible - maybe keep the default but stuff some control characters to the start of the string to override. But right now you're being just as inflexible about it yourself. 

Next version: Coop players spawn partially transparent, get less transparent each second.

While transparent, they may walk through each other/cannot be telefragged.

Maps without coop spawn points will be drastically less annoying for coop. Pure engine modification. 

Also in next version, Nehahra support is perfected and polished.

Includes fog support (yhe1, I think kept bringing it up) via non-standard commands that Nehahra uses and full fmod support.

Mark V starts up fmod if you activate Nehahra, shuts it back down if you change the gamedir back to id1. Also during the fmod startup, it adds the Nehahra special commands in and then removes them on shutdown.

/It has been discussed before that Nehahra tries hard and heavy to screw with your settings (fov, wateralpha, crosshair, viewsize, and on and on and on ... sheesh). The engine lies to Nehahra, pretending those things happened. 

Next version: The built-in install single player releases from Quaddicted via typing "install" in the console has been enhanced some.

The install command will autocompete 538 Quaddicted single player releases. It can install the ones that don't auto-complete, but I didn't want the lower rated releases to autocomplete.

And this subset is searchable similar to the "find" command, but I haven't been able to figure out a good name for it.

Misc stuff: the OpenGL build may be able to work for, say, Gunter or Jonathan with touchy OpenGL drivers. Added -nomultisample (<-- I think this is the villain) and -nostencil command line params, hopefully one of those will solve the issue, particular for Gunter who can run Quakespasm ok with r_oldwater 0. Also bind 3 three keys in menu in customize controls.

Shooting for a couple more things (and intentionally keeping something rather unusual a surprise) ... I've been wanting to get this engine completely polished up for over 2 years now.

Probably will have international keyboard support. I've procrastinated on that because of more serious issues, but modern ProQuake has had international keyboard support for ages and ages (I worked with Vegetous and rudl as beta testers back at the time.). Also want it to be able to be turned off on a whim, like ProQuake does. 

I'm a bit confused about this centerprint argument right now. Gunter wants it to be returned to how the original engines and some custom ones do it, mostly because it serves his needs better (the argument can be made that it's also good to be more like the "real deal" anyway...), but mh doesn't want that because it's considered worse for a lot of other mods/use cases.

If i've summed it up well enough, I can't see where this discussion can go from here. And I mean, it hasn't really been going anywhere regardless. 

There are two elements to it.

Part one is that the original engine suppressed centerprints when the menus were up. Some engines changed this behaviour to retain centerprints. This should be reverted.

Part one is not in dispute.

Part two is that the default positioning of centerprints should be changed to suit Gunter's mod and that the original intended purpose of centerprints is not as important as Gunter's mod.

Part two, and only part two, is in dispute. 

Now I don't know whether to use Mark V or QSS. I know it's too much to ask to make them a joint effort. This engine has x awesome feature and that engine has y awesome feature. And poor player doesn't know whether to get the camaro or the mustang, especially not when yall keep turbocharging them and adding cool features. To think I used my old beater WinQuake for so many years up until a couple years ago. Had to ditch DP since it didn't twist water right, plus it leaked oil all over my config file.

I'm tempted to compile a comparison chart so people can better pick the best engine. It'd be hard to keep up though. 

You have it right, Pritchard. mh is confused.... Maybe he didn't fully digest the post I made where I showed that the positioning I want is actually the default positioning of original Quake.

See for yourself. Start a single-player game in original Quake, GL, or Proquake (which uses the same positioning). As you walk through a hall you will get the one-line message about "this hall selects whatever skill." Note the position above your crosshair. Now enter the first episode area, and you get the 4-line message about the dimension of the doomed. Note that it still starts at the same place, but is still fully above your crosshair position (assuming you aren't in a tiny resolution). All good. Now enter the second episode area where there is a FIVE-line message about the realm of black magic... but look where it is positioned! It's way up near the top (again, resolution dependent)! Why? Probably for the same reasons I talk about: so that it doesn't actually start to extend to the crosshair area and block that important area of your view, when instead you can move it upward because you have all that extra screen space where it could go instead.

This is NOT a case where I want to change the positioning JUST to suit my mod -- this positioning would be better for ANY mod that uses centerprints, and even for original Quake. So yeah, it IS more optimal for the general case.

id, in all their wisdom, chose this positioning for good reasons. I, in all my wisdom, wanted this positioning too, for good reasons, before I actually realized it was the original positioning, haha. I didn't know at first that this positioning was from original Quake (I've been away from Quake for a couple years :p ) -- I just knew that it had changed from what I was used to in ProQuake, and the change had made things less optimal, and it ended up obscuring my view in an unpleasant way.


So it turns out you actually agree with me, right mh? You think the default Quake behavior should be used, correct? Good, glad we have that settled.


Or are you focusing too much on the idea that I am wanting to change the PURPOSE of centerprint messages, from when I said, "But I think at this point they are no longer 'always important,' sooo.... they don't really need to be inconveniently in the middle of your view anymore :D"

Much like id's original statement, I was not being completely serious. id's original statement was a small joke (I thought it was funny anyway) -- it's simply not true that every centerprint in Quake is 'always important,' and they aren't even always inconveniently in the middle of your view, as I demonstrated above.


Sure, I did talk about even changing it a bit beyond the original positioning, but that's the kind of ideas that should get thrown around in threads lie this. After some testing, I have found that I actually have a great deal of control with id's original centerprint positioning.


If I want it to appear closer to the center of the view, I just make it 4 lines or fewer (that is the actual limit, now that I've checked for sure).

If I want it to appear near the top (it's "7 lines" from the top), I just make sure to pad it with extra lines ("one line\\n\\n\\n\\n" will appear at the top).

I can even move it below the crosshair area if I stuff in a bunch of extra lines above what I want to print....


I have lost this level of control in Mark V, so yeah, I would like it reverted to Quake's default behavior.

And apparently you agree with me, right mh? You seem to pretty strongly advocate for using "defaults..." So we are in total agreement here!



Now let me consider some of these other juicy changes Baker is adding in.... 

Yeah that's difficult since a lot of stuff is not well-documented, plus there's an avalanche of little things that someone may or may not care about.

One could try to do a chart comparing engine support for widescreen, rendering API, palettized rendering output, texture filtering, QW multiplayer, QW listen server, singleplayer, colored lighting, soundtrack music files (and in what formats), bsp2, map texture replacement, model texture replacement, alpha-masked textures, various fog behaviors, .ent files, .loc files, QC extensions, clientside QC, XInput controllers ... you could really keep going and going and even then never get to things like "centerprint behavior" :-) or corrected weapon-viewmodel-height or whether the demos play on startup. Which some folks really care about!

It might be a good thing to try to set up as a shared Google-docs spreadsheet that a few engine experts/aficionados would be interested in keeping up-to-date. I dunno. There's a chance it would just get dozens of feature-columns added for minor things which only apply to one specific Quake engine. 

was replying to Qmaster there 

"Coop players spawn partially transparent ... cannot be telefragged"

Brilliant! We do have that problem in FvF! Unfortunately, I don't think this is going to help me, heh. That would be a server thing, right? Polarite runs some linux proquake for the server.... Further, FvF doesn't actually run in coop mode -- it runs in a special deathmatch mode (coop 0, deathmatch 3), so all the doors are already open and we don't have to go around collecting keys and things most of the time. We just get to killing the monsters.

But this certainly give me the idea to try this change in the mod, instead of the standard 3-second spawn protection pent (which prevents telefragging, but causes people to sometimes be pushed into the floor). Hm, but what happens if the players are standing on top of each other when they became fully opaque?


I'm hopeful about the gl issue workarounds.... 

That is pretty weird behaviour in WINQUAKE.EXE: set the res to 1024x768, walk up to the episode 2 entrance in start.bsp, and the 5-line message is near the top of the screen. The episode 4 message (4 lines) is just above the crosshair.

This feels like something where the code is fudged in a way that looks good at 320x240. (another is the weird left-aligned deathmatch hud) 

The episode ending messages use WriteString, not centerprint and that is why they are at the upper portion of the screen.

@Johnny Law: Might do...sounds tedious but I do like that sort of thing. 

Last night I was using chase_active 1 too look at some splashing water effect I'm trying, and I thought it would be nice if the crosshair was still accurate even in chase cam.

I used the autocomplete and found the chase_active setting which I had forgotten about, and toggled it on, and found that my crosshair was accurate in chase mode! Ok, that's nice.

However, chase_mode does not act in an intuitive manner -- I reported this as a bug in the past because I did not know what was happening. It seems that chase_mode cycles through 8 different modes (and most all of them are going to be completely non-useful, I think) without letting you know it's doing that. I did find that I can do "chase_mode 1" to specify I want that first mode with the accurate crosshair.

Perhaps the cycling of chase_mode should be followed by a notification, like "chase_mode is 4" or whatever.

And I guess this would throw everything off with crosshair accuracy, but it would really be nice if I could re-position the chase cam so that it was like right above my shoulder, as in many 3rd person shooter games (chase_right just doesn't work in chase_mode 1, etc).

Maybe one of the default chase_modes could be a view like that....

I can't tell what the difference is between chase_mode 1 and chase_mode 2. Chase_mode 3 and higher are rather crazy.

Quake has had chase cam for a long time; it's just never been that useful. Having an accurate crosshair even in chase mode is a big improvement. I just need to be able to move the cam to the right a bit so my guy isn't blocking my aim.... 

Chase_mode is a "for fun" feature.

Gives different camera perspectives, possibly for making a "movie"/.avi/Youtube video.

Games with sophisticated camera control have massive C++ libraries created by paid game professionals, sometimes involving camera hint entities and such in the maps.

Like shadows, chase_active 1 is just a hack. I gave some extra flexibility for making a Quake vid and ...

... gave it an MH tune up where MH made the chase camera collide with the wall far more accurately. Used to be something mh and I talked about a ton, haha.

But once I saw the massive C++ camera code in commericial class engines, yeah ... sadly it's a lost cause.

Won't be altering chase_mode for the foreseable future. Have more important issues.

I'm just one person. 

I'll probably be making at least some light documentation since it looks like the engine will finally be out of beta testing stage -- a place its been living due a lack of time. 

I don't know how fixable this would be, but I'll mention it.

I have an altered gamma profile on my netbook, to brighten the screen a bit -- the default is too dark. It loads up automatically in windows once I set it in the graphics properties.

Mark V uses hardware gamma, as you have mentioned, and it looks good in the game.

If I run Mark V in a window, I can see that my other windows are even brighter than usual, but when I switch away from Mark V (or when I exit Mark V) it returns my netbook to the default setting instead of my altered gamma profile (switching back to Mark V changes it again to the gamma settings I made in Mark V -- of course, this all still applies when I run in fullscreen too; it's just easier to notice when I run in a window).


It's not a huge problem, since I have a taskbar icon I can use to set my gamma profile, but ideally it would return my gamma profile to what was selected before I started Mark V, rather than the default (which is "no adjustment"). 

You can do vid_hardwaregamma 0 in Mark V and only get contrast correction (no gamma). Only other option. 

Next version: Marcher is fully coopable; engine overrides bad keys behaviors in coop. 

I might add a texture gamma option into the (it won't be very flexible though) next one. I want to see what texture gamma would look like (it might look nice, it might look "wrong" -- only one way to find out).

Mark V already can apply gamma/contrast, it does it to screenshots when hardware gamma is used so the screenshots look like what you see on the screen -- I just don't have it setup to do that when loading textures.