News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.

FitzQuake Mark V Download:

http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.

It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.

Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme).
First | Previous | Next | Last
 
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! 
Apropos Xxxxx 
is a console command that lists all cvars containing xxxxx.

ex: apropos particles 
I Lied 
Malice is fixed too. 
Apropos Apropos 
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 
Hyar Hyar Hyar!! 
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. 
Automatic Start Map Support 
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. 
Gunter 
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. 
Dwere +5 
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 
 
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 
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 ;) 
You Fire Rocket Launchers? 
I just fire rockets...

@Baker We should petition LH to implement that protection system into DP. Let's show him how unnecessary it is! 
Baker 
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.... 
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.