Is QC performance ever a real concern these days to where an extra instruction here or there makes the difference between smooth and choppy gameplay? I don't know, I'm seriously asking. 

Thanks for the answers.

Willem, I doubt it. I just don't want to pick any bad habits if I can avoid it. Besides, I was curious. 

No. But very rarely yes.

A lot of code gets run once per frame or once every animation frame (typically 10 times a second). This kind of code can be messy without impacting performance on even a semi-modern machine.

The times where it can matter are when you are doing things in a loop during the same frame. For example, pathfinding, or searching for new enemy targets. 

dwere

Sure, I understand that. Tinkering with something like Quake is fun because you get to understand every nook and cranny after awhile. It's stable and unchanging and there's something comfortable about that. 

And something a little disheartening as a programmer. As you're figuring out more and more about how things work and what does what, you realize that Carmack came up with and wrote most of this from scratch 18+ years ago. Damn him... 

self.function = (void(float))funcWithFloatArg;

results in:
type mismatch for = (pointer and __variant)

What version of FTEQCC do I need to make that work? 

http://triptohell.info/moodles/fteqcc/ does all of that, as well as adding a bunch of warning for NOT doing it. 

Thanks! Shame that's buried on some hidden server. :( 

Is there any documentation for this?
All I could find was this: http://www.fteqw.com/wiki/index.php?title=FTEQCC_FAQ

For example, is it possible to have an array that is an entity member? 

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.