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. 

Yeah, me. Hence why my curiosity. :P 

 

Uh? What is an example? Do you mean textures that don't comply to the Quake standards listed in http://www.celephais.net/stuff/texturefaq.htm ? Or are you talking external textures or what?

Or do you mean something else?

[I have been thinking about a revision of Mark V to tidy up some of the things pointed out in the thread.] 

Quick comment on this:

> Apparently the cvars saved1-saved4 were added in SoA and never used, for anything, by anyone.

FYI frikbots use saved1. 

I can't give an example now because im in work. But some textures go blurry if they are a weird size. Best exanple I know right now is the large metal panel texturre on ziggurat vertigo 

@baker, markv with bsp2?

Not sure if I understand the question. But yeah if I do any kind of clean-up release of Mark V I will incorporate the bsp2 code you donated to the project.

[I'm kinda of preoccupied with trying to port Mark V to Android combing using FTEDroid and Q14A for ideas/pointers. Looking at FTEDroid source has been immensely helpful and is a bit shocking the extent of your implementation.] 

just use https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt
or in other words, if that's supported, ignore the fact that its an npot texture and upload it regardless.
This avoids various columns/rows getting ignored/duped to resize it. Resizing is evil, mmkay?
iirc, vanilla glquake's code was fine with the npot check disabled - so long as the drivers support it. 

Sorry it took so long for me to post examples.

Here's what the blurriness looks like in fitzquake -

https://www.dropbox.com/s/s2w8it70khmvrrx/1.jpg
https://www.dropbox.com/s/syr2vgpsj6bl0r6/2.jpg

And here's the same textures in directq -

https://www.dropbox.com/s/j6pgvqxos4s45mv/1a.jpg
https://www.dropbox.com/s/507l4a3f93tslzg/2a.jpg