[Tutorial] CSQC Progress Bar

[gnounc]

Link the csqc source you're using. I havent looked at it, so i havent read the readme.
Maybe they intercepted intermission. I wouldnt be surprised, smc covers quite a bit of ground. especially for a mod with the word "small" in it.

[gnounc]

Ok, I've read through the csqc in the link you gave me.
I've read the readme.

My best guess is the code they gave is a fix for a standard quake bug. But I dont remember the game well enough to say for sure.
I't looks like perhaps intermission was being stomped on or something.

Either way, I dont see anywhere where they do anything with intermission themselves that would require that change.
And the only thing the change did, was delay the intermission writeByte. That is it. LIterally. it adds a think to delay calling it.

so as for anything else being broken. I have no idea. I dont see any reason anything would be borked that was not borked before.
You might want to ask nahuel and seven why that delay is put in there. And when you get an answer, please post a reply here.

[Cobalt]

Hmm, you got me thinking that it might be a Darkplaces only bug now. I will swing it to LH for some feedback.

Why would the ent obey all other assignments in the intermission except fixangle?

I do remember playing with this same src years ago on quakeone, and I supplied them with the informaiton on intermission_running float, because
at that point the players view didnt chenge position from where they last were during the intermission. They fixed that, and I am led to believe the "intermsiion" float in the csqc src is taking care of that, but there has to be more to it.

Ok, I've read through the csqc in the link you gave me.
I've read the readme.

My best guess is the code they gave is a fix for a standard quake bug. But I dont remember the game well enough to say for sure.
I't looks like perhaps intermission was being stomped on or something.

Either way, I dont see anywhere where they do anything with intermission themselves that would require that change.
And the only thing the change did, was delay the intermission writeByte. That is it. LIterally. it adds a think to delay calling it.

so as for anything else being broken. I have no idea. I dont see any reason anything would be borked that was not borked before.
You might want to ask nahuel and seven why that delay is put in there. And when you get an answer, please post a reply here.

[Cobalt]

Ok, it appears I got it resolved. LH says fixangle is always set to zero every frame.

Execute_Changelevel () walks through all the players once and sets their fixangle to 1, then PlayerPreThink () is hijacked when the intermission is running which I guess prevents the engine from completing another full frame and setting fixangle back to zero.

Apparently csqc is allowing "independent thought " so to speak in this special case, so I tried enforcing fixangle in the intermisisonthink () :

Code: Select all

void () IntermissionThink =
{
              self.fixangle = 1;

]

This seems to have solved the issue.....

Another strange thing I observed is that even if we dont do:

other.fixangle = TRUE;

...in the code that walks through all the players, somehow fixangle is being set and enforced. I can only guess its done at the engine level at this point.

[Spike]

intermission normally blocks client angle changes.
you could always put some if(intermission && (inputevent==IE_MOUSEDELTA||inputevent==IE_MOUSEABS)) return TRUE; inside your CSQC_InputEvent function, which should block the engine from handling the event as a viewangle change.

edit: wait, I think that's one of the bugs. bugger it.
you'll have to just keep spamming calls to setviewprop(VF_CL_VIEWANGLES, 'some fixed angle'); although knowing what value its meant to be will be annoying, so yeah... spamming .fixangle angle changes every single network frame will have to do the job instead... yay...

[Cobalt]

Ok, neat. Starting to get a grasp on this a little.

How about we take this tut one step further, and now make the progress bar reflect our o2 level while submerged in water?

Lets make the bar pop up only when self.waterlevel > 2 && pointcontents (self.origin) == CONTENT_WATER. Dont bring it up if in slime or lava.
We probably will need to make use of self.air_finished float while doing this.

Id be interested to see how we carry over these floats to ssqc for the experiment. Im guessing everything in ssqc "can" be bought over for the most part?

Another interesting problem would be the biosuit....we could double up on this bar to reflect biosuit remaining time, and when thats done , its reflecting your air. I think Nahuel was helping me work on something like this a while back, but I lost track.

[gnounc]

http://forums.inside3d.com/viewtopic.php?f=16&t=5194

READ THAT.

It should clear up 99% of everyones csqc questions.

also this.
http://quakeone.com/forums/quake-mod-re ... ars-3.html
I'ts what you were looking for.

edited for: unwarranted hostility,

[gnounc]

That said, an 02 sensor bar would be a good expansion on the tutorial. I look forward to your additions.

[Cobalt]

Ok agreed.

So I started doing some experiments localy. My first test was to determine how a .float can be detected in csqc. I noticed that (float intermission)
seems to make us detect an intermission, and in Nahuals "experminetalbar" src, he seems ot be able to detect .items and .items2 by merely floating them the same way.

So as an experiment with the compass draw function I tried: if (intermission) return; ..... which no longer shows the compass during intermission.
However, I added if (intermission || observer) return; ....the intent was to see if the .float observer would be passed so that when we are observing, dont draw the compass, but its failing.

Whats the trick to passing .floats or other (.) specific fields relative to the player entity? We will need to use .air_finished for the o2 bar.

Update, I did start to read that link and it seems we have to register these floats, however, I cant fint the clientstat built in in my DP Qc files. I may have too old a version...?

That said, an 02 sensor bar would be a good expansion on the tutorial. I look forward to your additions.

[gnounc]

you need to look in dpextensions.qc which you may or may not have.
It contains engine builtin extensions, and if I'm not mistaken, is included with every darkplaces download on lh's icculus site.
If its not there, it's probably in dpmod.

ALSO Iirc dpextensions.qc calls it addstat...so theres that.

Otherwise ask around, theres no telling how many people here have a copy of dpextensions.qc

FTE users are looking for csplat, and/or fteextensions.qc

[Cobalt]

Ok, got it.

Registering the .air_finished float we will need to do the 02 bar:

in world.qc (sscq)

Code: Select all

addstat (37, AS_FLOAT_TRUNCATED, air_finished); 

and in constants.qc (ssqc)

Code: Select all

const float STAT_AIR_FINISHED = 37;

...also had to add the AS_FLOAT_TRUNCATED and other 2 floats in ssqc as you specified in the other link.


Next quesiton, is - do we need to always float again for the new registered float, or can we call it directly? IE:

Code: Select all

if ((getstatf(STAT_AIR_FINISHED)) < 1 ) 

I tried this with another float as a test, and it didnt seem to work, and I had to "localy" float it, and used the local float, and it worked. Or can we merely put something in defs like:

Code: Select all

float oxygen = getstatf(STAT_AIR_FINISHED ); 

...or do we always need to "refresh" / update the value each time we want to work with it?

Oh, and one other oddity I noticed. The src I am working with now has:

Code: Select all

const float STAT_MYSTR = 32; // for the experimental bar Nahuel used

and hes using

Code: Select all

getstatf(STAT_MYSTR );

In his code to detect that we either have the biosuit, and or are in water? There was no float registering at ssqc to declare #32 or in fact there are none at all registered at ssqc except for what I did today, yet his code dows bring up the custom images for the biosuit and vertical progressbar.... ?

[gnounc]

Update any variables containing getstats every frame, before those stats are used.
I do it in a function called updateStats() which i call under renderscene() in CSQC_UpdateView() located in view.qc.

As for how nahuel did it without registering the stat.. the first 31 stats are already registered. I show the first 21 in
my tutorial. He uses 32 according to your post, so I imagine he DID register it somewhere.

But,

Code: Select all

#define STAT_ITEMS 15 

probably would work just as well. No need to register it, just call getstat with STAT_ITEMS, or 15 if you prefer it to be unreadable, and save that in a variable.

[Spike]

if you register a string, make certain that you use only getstats to read that string, and never any of the other getstatX functions.
In DP, string stats are horribly limited, and while getstatf can be used to test against an empty string (in DP), doing so will break things if DP does ever support more versatile string stats.

To explain:
DP still packs strings within 4 consecutive stats, giving a limited string length to 15 chars and consuming multiple stat slots for each string.
FTE does remove the length limits on string stats by using a seperate namespace for strings. using getstatf on such a stat will always return 0 (unless, of course, if you depend on the separate namespaces feature by using the same stat number for both a string and a numeric stat. more stats, woo).

as gnounc says, stat 32 will always read as 0, unless the ssqc actually registers something to use that slot.

you can't define random new variables and expect the engine to understand what you mean by that. it doesn't have a clue. if you want it to be available then its either a legacy feature (like intermission, which is set via a special-case svc_intermission packet), or you'll need to modify the ssqc to make that information available somehow.

any stats that you store in some global must be refreshed each frame in order to prevent them from becoming stale. qc doesn't constantly reevaluate every variable based upon how it got its value like prologue might, because that's basically insanely inefficient. thus you'll need to re-read the stats at least once a frame.

[Cobalt]

Nope, it looks like hes pulling it out of thin air without a need to register. Its not the float for IT_SUIT like I had first thought, that float is defined already, and when IT_SUIT is detected he calls this code:

Code: Select all

void () drawwer
{
local float transparencia;
        local float stat_data;
	
      stat_data = getstatf(STAT_MYSTR ); // we pass our hard coded index to getstats (getstats if (stat_data > 15)
{transparencia = 1;}
if (stat_data <= 15)
{transparencia = stat_data * 0.066666 + 0.3 ;}
	local vector color;
local float r;
local float v;
v = stat_data * 0.03333333333333;
r = 1 - v;
color_x = r;	
color_y = v;	
color_z = 0;	
Sbar_DrawPic('-321 398 0', "gfx/fondo", 0.8, 0.77);

	Sbar_DrawBar ('-300 110 0', "gfx/verde", color, transparencia, 0.4, stat_data);
Sbar_DrawPic('-321 398 0', "gfx/aire", ALPHA_FULL, 0.77);	
}

As for how nahuel did it without registering the stat.. the first 31 stats are already registered. I show the first 21 in
my tutorial. He uses 32 according to your post, so I imagine he DID register it somewhere.

??

No clue where the > 15 part comes from....the only thing I can suspect is that its the air_finished float? His code comes already compiled, so if you drop a precompiled progs in your folder, the code works without a need to register anything in sscqc. Maybe thats a real bug, and is the reason why the bar does not fill up...its really a non finished experiment. But still, the graphic will come up when you appear to have a waterlevel of 2 or more + the suit.

[Cobalt]

Thanks for clearing up those details. I had no idea how the intermission float was derived. I was expecting to see intermission_running somewhere, as to match the ssqc label....making it easier to identify.

you can't define random new variables and expect the engine to understand what you mean by that. it doesn't have a clue. if you want it to be available then its either a legacy feature (like intermission, which is set via a special-case svc_intermission packet), or you'll need to modify the ssqc to make that information available somehow.