seems to compile without errors. 

if it doesn't crash, then its a feature! 

Thanks for all that info! Very useful to know.

I wonder how the guys behind the Quake specs figured it all out before the QuakeC source etc. was officially released by id. Must have taken a lot of trial and error. 

Spirit: Yeah, I was looking at the Quake Wiki the other day and thinking it looks a bit sad and needs some love. Perhaps we should get as much info from the Quake Specs about file formats as possible on the wiki, and finish off the level and monsters guide.

Part of the problem I had before is that there's just too much information per thing and it's annoying to have to basically write an entire article just about a level in a game that was released in 1996, even if that game happens to be one's favourite game. It might be worth looking at how the pages are formatted and thinking how to divide it up within the article so that more of the information is optional. 

Okay.

I want to hide the crosshair during centerprints and other special events. This is easy.

I also want to remember the user's crosshair preference, because the only way to hide the crosshair is set the cvar to 0 .

It was easy when I was just assuming that the user's preference was "use the crosshair, always" because what kind of lunatic wouldn't? I forget who or where, but someone recently posted somewhere on func that they hate playing Quake with the crosshair on because it makes their aim worse or something. Fine, whatever, I'll try and support it.

If I save the value in a float in the progs somewhere, the crosshair doesn't come back if I restart the level or load a new map while it's hidden. If I save it in a safe cvar (like 'temp1' or setting a high bit in the value of 'registered'), the crosshair doesn't come back if I quit the game while it's hidden and restart later, because those cvars get reset.

Is there any other cvar I can use? Are the 'saved1-4' cvars safe to faff with? 

you should consider using a nosave var which will cause the progs to re-evaluate the state of the crosshair visibility after a map load. 

this isn't an answer, nor likely helpful.

...but is it worth going to all the trouble to fix that bug (crosshair setting doesn't return if user quits during a centerprint)? I understand the desire to fix it, but on the other hand... you're making a mod not a AAA title that needs to get certified. It doesn't seem like it would be that common an issue, nor one that most users couldn't fix themselves by turning the crosshair back on if it was off when they loaded a save. 

I didn't need a crosshair when quake came out and I certainly don't need one after 17 years of playing the game.

The hitboxes for the enemies are bloody huge, it's not needed! 

no crosshair. No one plays with that;) 

I don't use a crosshair. Shots go into the middle of the screen. It's not THAT hard to predict. :P 

you should consider using a nosave var

that's not going to help. when I hide the crosshair, "crosshair 0" gets written to the config. no amount of qc-only shenanigans will restore it because quake itself has forgotten what it was.

but is it worth going to all the trouble to fix that bug

it annoys the hell out of me, so yes :)

everyone else and your no crosshairs

you fucking people


Apparently the cvars saved1-saved4 were added in SoA and never used, for anything, by anyone. I'm going to go with using one as a backup crosshair cvar, because it's persistent across game starts. The only problem with this is that if someone is a crosshair user and decides halfway through lunsp2 to join you fucking people the crosshair will keep coming back unless he sets 'saved1' to 0 also. I can live with this. 

nosave float isCrosshairCheckDone;
float crosshairVal = -1;
float isMessageDisplayed

displayMessage()
{
crosshairVal = getCvar(crosshair) //or whatever the method is
isMessageDisplayed = true;
isCrosshairCheckDone = false;
}

messageDone()
{
isMessageDisplayed = false;
isCrosshairCheckDone = false;
}

and then in player prethink or something:
if (!isCrosshairCheckDone)
{
if (!isMessageDisplayed && crosshairVal != -1)
setCvar(crosshair, crosshairVal); //or whatever way it works
else
setCvar(crosshair, 0);

isCrosshairCheckDone = true;
}

probably buggy but you get the general idea. 

yup bug:

if (!isCrosshairCheckDone)
{
if (!isMessageDisplayed && crosshairVal != -1)
setCvar(crosshair, crosshairVal); //or whatever way it works
else if (isMessageDisplayed)
setCvar(crosshair, 0);

isCrosshairCheckDone = true;
} 

did you try just adding some blank lines to the centerprint so that it gets shifted upwards? 

this problem of centerprints and crosshairs has never occurred to me before recently, since I always play without a crosshair. (I can only do this in classic FPS games with centered gun models, though.) 

only thing with adding newlines on centerprints is that there is somewhat inconsistent behaviour across engines. darkplaces, for example, places centerprints higher up the screen, so adding the newlines in that case puts them even higher.

it's not so bad it breaks, but it needs to be tested. 

crosshairVal = getCvar(crosshair)

If the crosshair was hidden the last time I quickloaded/died/quit, that cvar was set to 0 at the time and got saved that way. getCvar returns 0 because it no longer represents my actual crosshair preference. 

ok, then just do some clean up and reset the var to -1 and then check in the display method. 

http://derp.co.uk/a214c.jpg 

You seem pretty non-thrilled about the crosshair thing.

And it looks like you making and wasting time worrying about this.

I'll produce a FitzQuake 0.85 and a Mark V with an option "gl_crosshair_hide_on_centerprint" (or whatever) that will always hide the crosshair with centerprint on the screen and a simple tutorial to implement.

Far better for you to be making a map than messing with awkward QuakeC solutions.

It would suck to see a quality single player release poisoned with awkward QuakeC and screwing with your cvars. 

Can you at least fix non power of two rendering? 

Better solution than an engine hack. 

But csqc is much more involved, small tweaks are a gateway drug!
the crosshair/centerprint thing is a general engine issue, so should probably be implemented anyway.
Besides, I doubt baker has the time to add csqc support to two engines...

@baker, markv with bsp2? I'm just curious mostly. 

I do have a "fitzquake_mark_v_bsp2.exe" in my Quake folder... 

I see where it came from, now.