Uh-huh, except in this particular case we were talking about a very specific conversation where people actually managed to make sound arguments when they weren't too busy throwing insults around. 

My discussion with Gunter wasn't a philosophical one. It's an aesthetic one. When I was looking to solve the centerprint issue, I experimented with several different ways and loaded up about every engine including DarkPlaces to assess options.

Centerprint in the ProQuake position makes it so ...

1) it looks really silly when you go to the menu and have white text sitting above the menu.
2) looks silly when you press TAB to see the multiplayer scoreboard and have white center print above the scoreboard.

So to avoid that I'd have to move ...
1) The menu
2) The scoreboard
3) Other stuff

And it would no longer look like FitzQuake. 

I am sympathetic to the issue of centerprinting positioning, by the way.

I've worked on mods that have used centerprinting (RQuake, xCTF, Team DM) and centerprinting positioning has always been a thorny thing.

And there are some classic single player mods that use a lot of centerprinting (see Quake Terminus mod list or Frika's Q-Pacman).

I went out of my way to get Mark V to handle centerprinting consistently and tested a lot of different stuff to make sure it looked great, even with mods that have centerprint menus.

But the ProQuake position for a FitzQuake engine is a case where the cure is worse than the disease.

/Maybe at some point some sort idea for a viable solution will emerge. 

Couldn't you solve the overlap issues by hiding centerprints when one of the conflicting menus is visible? They do show up in the console as well if I'm not mistaken so if a player missed one it wouldn't be the end of the world. 

Stock GLQuake doesn't draw centerprints if the menus are visible; look in SCR_CheckDrawCenterString for a check for (key_dest != key_game); engines that change this are also changing the behaviour from stock GLQuake.

So overlap issues are actually not something that occurs unless someone has explicitly modified the engine code to make them occur. 

Ah, so it's the other engines (rather than original GLquake) that do it differently in regard to hiding centerprints when menus are open. I'm mostly fine with that functionality; my only concern was that a centerprint may go unnoticed if someone is staring at the scoreboard. But still, I don't hate that behavior.

My main concern is the positioning of centerprint on the screen. So to address things people said in regard to that (assuming that's what they're talking about):

"What you're basically doing is taking a default feature of Quake, using it for a purpose for which it's not intended, "

What? The purpose of centerprint is to deliver information to the player. That's it. And that's what all Quake mods use it for.... Maybe the information is above and beyond what id originally thought of (like an underwater air meter, for example), but it's still just delivering information to the player. Indeed, centerprint is heavily used in every Quake mod I can think of to deliver information to the players (it's pretty much THE tool we have to do so -- console prints are very quickly swallowed up if a lot of things are happening). But it can have negative issues, as I've mentioned.

Yes, the original resolution of Quake was tiny, so there really was practically no choice but to have centerprints right in the middle of the screen, but now we can run Quake in all kinds of resolutions, and we have MUCH more screen space available, so there is no reason it still needs to be in an area that blocks potentially important areas of the view.

It's not as if text popping up closer the top of the screen is going to go unnoticed by noobs -- UNLESS they are in the middle of a battle, in which case, again, it it detrimental to have text blocking their view when they are trying to aim!

This has nothing to do with muscle memory (I guess you didn't mean that literally...), and it doesn't make any radical changes like a new HUD or particle system -- it's just more optimal positioning of text in the available screen space. Yes, if you make changes that cause things to "not look like Quake" then people will complain. However, I wager NOT A SINGLE PERSON has ever complained about ProQuake's better (IMO) centerprint positioning, and ProQuake was "the standard" for many years....


Perhaps the most ideal solution would be a setting that would control centerprint positioning -- placing it either centered in the screen, or just sticking it about 4 lines from the top of the screen. But I really doubt anyone would prefer to potentially have it blocking their aiming rather than up near the top, out of the way....


Again, I'm not sure everyone is talking about the same issue (hiding centerprints when the scoreboard is up is fine) -- I'm only referring to the vertical positioning of the centerprint text on the screen. This really does not reach the same level of new HUDs or particle systems that alter the look and feel of Quake substantially.

Of course, I do like "rounded" particles rather than the giant square pixels in old software Quake, heh. 

Hahaha... ok... REVELATIONS.

I decided to go and look for myself in the original (that's DOS Quake.exe 1.08 and original GlQuake whatever version it was) executables to see for myself....

So you can basically forget all my well-thought-out and valid arguments for why ProQuake's centerprint positioning should be used. My new argument is:

"You've changed Quake's default behavior!! I don't like it!! Change it back right now!! Too many changes are a bad thing!!!!!1"

Yep, that's right, original Quake's centerprint positioning is IDENTICAL to ProQuake's!

...as you can see in this screenshot of original DOS Quake in all its pixely glory at maximum resolution of 800x600:

http://imgur.com/a/Ps11o


It's also identical in that if the centerprint is 3 lines or fewer, it starts more toward the center of the screen, but if it's more lines than that, it appears up near the top of the screen.

Also, you can see that the scoreboard is stuck up near the top of the screen, just like those ProQuake screenshots I provided earlier (and the centerprint text is still visible when scoreboard is up, but not when the Menu is up -- is that what people were talking about?)


Actually, again, I don't hate that centerprints are hidden when the scoreboard is up, but I don't love it either....

And don't actually forget all my previous arguments, heh; they are still completely valid! I still would prefer ALL centerprints, even those of 3 lines or fewer, to be positioned closer to the top of the screen... But I think I can perhaps force that to happen by padding the bottom with empty lines... hm, I'll have to test that.

But yeah, scoreboard and centerprint positions should be just like in ProQuake, which is just like in original Quake, because:

1. It is more optimal for all the reasons I have mentioned about obscuring the important part of the view,

and:

2. OMG, you changed Quake's default behavir and I don't like it and youneed to fix it right nao!!!1!!


:D 

Has Gunter won the centerprint wars?
Tune in later to find out! 

A new version is going to be out in the 24-48 hours. 15 changes. Includes DarkPlaces/FTE-like "apropos" ability, which every engine should have.

/Wish had time to fix NightFright's Malice "knockback effect" issue, since he did so much mod compatability testing/bug resolution verification. AAA+++ beta tester.

/So is Gunter/Fifth/Spy/OTP/Pulsar and so many others. Gunter may argue too hard at times, but he sure tests stuff great ;-) 

I argue hard, I bug-test hard!


Nice! New update.

...

What is "apropos" stuff?


Here's a quickie "bug" I just encountered. I was trying to type "%complete" and it came out as "100omplete" because apparently %c is a macro for my remaining Cells.... And I guess there are many more such macros. There should be a much more rare macro indicator, like %% instead of just %, perhaps.

I'm preparing a 50-page powerpoint presentation to support my position on this.... I'll post it later! 

is a console command that lists all cvars containing xxxxx.

ex: apropos particles 

Malice is fixed too. 

As some of you may know, I'm French and "� propos" means "about" in french. Why not have settled on an About command instead? I mean usually, all command names are in english... 

Hahaha, you're on to me. You are ruining everything!

http://quakeone.com/proquake/media/find.gif 

But seriously, it was a genuine question. Was someone French on the team of the first engine that implemented this command or something? 

I think Apropos is just one of those words that the Folks Across The Channel nicked off with a while back and started using for themselves.

Interestingly, Google's dictionary functionality suggests that Apropos doesn't really mean "About", at least not in English. It says "with reference to; concerning.", which is still appropriate to some degree but perhaps not the best choice of words. 

Ah, "find" looks like it could be useful.

Uh, it does appear that centerprints are being shown when the Menu is active. Standard Quake doesn't do that (and it does look bad).

Also, I think maybe %c% would be a better format for the macros. That ensures that they only occur when someone intentionally wants them to.


Bug. Try this: take any map, rename it dm6.bsp and put it in like quake\test\maps\dm6.bsp

Now run Mark V -game test

Go to start a new single player game through the menus.

It will dump you onto that "dm6" map instead of the Start map. I saw this happen with another test map too, which was named like fvf_hallo.bsp

Actually, I'm not sure the name of the map is important. It seems to do this no matter what the name.... I've seen (and mentioned) this happening before, but I haven't give it a thorough testing. But it should be reproducible.

But perhaps this may have something to do with the "autocomplete" feature that looks for map names automatically? 

Loc support -- Mark V has nothing to do with it nor how it works. Load up DarkPlaces, ProQuake, Qrack, FTE or ezQuake type "say %h" in the console and see what happens. As I understand it, id Software wrote the spec.

Automatic start map support -- if you use -game and that gamedir has maps, Mark V is going start those instead if you are using a gamedir when you do single player new game. Mark V is oriented towards single player releases. So if you have a gamedir and it has maps named ruinsstart.bsp, ruins1, ruin2 it is going to load ruinsstart.bsp. If it only finds 1 map, it will load that one. 

It's worth noting that this was discussed around the community some years ago, and the described behaviour was a community consensus decision. 

Hm, I see.

Well, "the community" was WRONG about this :D

Where did this discussion take place? Got a link? I'd like to read over it and see how this "consensus" was arrived at....

This is bad behavior, altered from standard Quake, and uncontrollable by the user (specifically, I don't WANT to go to a custom map when I go to start a new single-player game -- and if I do want to, I will change to the specific map myself). If I have several maps in my mod folder, it just picks one seemingly at random? Or does it work by alphabetical order? I don't know, but you can almost guarantee that it's not going to pick the specific custom map I might want to play, meaning that I'll have to change it manually anyway. In a folder full of maps, it's not likely to select the correct starting map for a custom episode either.

Testing that.... Yep. Looks like it's just grabbing the first map in alphabetical order... that is, unless there is any map that contains the word "start" in the name, in which case it prefers that. If you have 2 or more maps that contain the word "start" then it favors the one that's first alphabetically....

Of course, if there is a custom map named "start.bsp" for a custom episode (like with DOPA), then that will start automatically anyway.... that's standard Quake behavior.

All that this functionality does is ensure that one single map -- whichever has the preferred name in your folder full of maps -- will the the one that starts up every time you go to start a new single-player game. So unless the end user is wanting to play the same map every time, there is no benefit, because he'll still have to change maps manually after starting up.

The standard Start map is the starting map for various reasons, such as being small, without a lot of entities, so it loads up fast. This functionality could result in a larger map being selected as your single-player start map, which could take longer to load (ok, probably a barely noticeable delay in most cases, but still undesirable behavior).

If I'm going to have to rename maps so that the the one I want will load up, that's no different than the standard behavior of having a custom "start.bsp" in your maps folder.

Well, this isn't exactly a CRITICAL issue, but I will say that I absolutely hate it :D

And this isn't just "in theory" --

It has been happening to me for a while, every time I want to do some testing, when I start up a single-player game, and I had no idea why it was happening, and it forced me to have to manually switch back to the Start map....

Now let's hear from all the people who are actually making use of this feature often, without any issues of having to change maps manually anyway, because it selects the correct map they want to play every time :D

All I would really ask is an option to ENABLE this feature for those who might want it. Of course, I feel it should be DISABLED by default -- this is a pretty drastic change from standard Quake behavior. And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default.

And it further seems unneeded, because I see that you have added the really NICE functionality of the console command "maps" to see a list of your custom maps, and "map XXX[tab]" to auto-complete a map name. Now that's some fine, elegant, helpful, non-intrusive functionality right there. Love stuff like that. ;)


I suppose the ideal thing might be a map browser of some kind where you could scroll up and down the list and select the one you want.



And quickly checking my old Quake.exe... nope, no macros in original Quake or GlQuake (they print literally "%c" instead of your cells value), but it is in Proquake. So it's just one of those things someone came up with, and everyone imitated. But it could be more optimal in various ways.

Eh, not a major issue, but I don't care for it, since I don't use it. And the rare situation arises where it interferes with something I try to say. 

I find this particularly ironic.

You want a change from default Quake behaviour when that change suits you.

You hate a change from default Quake behaviour when that change doesn't suit you.

At this stage it's looking like you just want what suits you and to hell with anything else. 

loc support - How it works and how it was defined has nothing to do with me; is not subject to my whims. You used ProQuake for 10 years, it was always there. Nothing to discuss, move along ...

single player default map - This engine is oriented towards playing single player custom map releases just like func_msgboard! And it will be tomorrow and every day after that.

map browser - Actually already has one. single player --> levels. Voila! 

And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default.

Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp, even though their mod has its own directory.

This feature is for players, not developers. It allows to launch such weird map packs without using the console. If you like to test on start.bsp - you're probably knowledgeable enough to organize it without using the new game menu. 

Yeah, Gunter please read dwere's comment. It is a real problem in single player. 

Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp
Naming your start map "startsomething.bsp" is useful to avoid problems when you have a custom start.ent in \id1\maps. Otherwise you have to manually save the .ent file of the mod whose start map is simply named start.bsp