compiling rogue devkit

Discuss programming in the QuakeC language.
Post Reply
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

compiling rogue devkit

Post by Seven »

Hello,

I have a big problem in compiling the rogue qc files.

What I have is the following:
- Rogue QC_minidevkit (from quakeone.com/navigator/)
- several compiling programs:
-- frikqcc27
-- winfrik26
-- fqcc101
-- advqcc
-- fteqcc_v100

I did not touch the original rogue qc files and simply try to compile them.
All compilers compile without errors, BUT:
I have with all created prog.dat´s the same failure in game:
In R1M7, when pushing the first elevator button, the elevator doesnt move upwards.
It does move upwards with original "progs.dat", that comes with the mission pack 2 of course.

With some compilers (like fteqcc) the game even goes crazy, after touching the elevator button (like squeeking sounds start, and ammo for weapons drop to 0, etc.).

----

The ONLY compiler that has NO issue with original rogue qc files is:
fqcc101
The compiled "progs.dat" with this compiler works fine.

But my task is to compile my "small mod compilation" (which uses dpextensions.qc).
And fqcc101 aborts compilation with the "small mod compilation" because of hundreds of errors in dpextension.qc.


Now my question:
1.) Is it a known issue to compile original rogue qc files ?
2.) Maybe the devkit from quakeone has an error in the qc files.
2.) a) Is there maybe another rogue qc pack ?

I dont know how to proceed.
Thank you very much for your effort and help.

Regards,
Seven
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

some qc behaviour is undefined (aka: unsafe/buggy).
if frikqcc gives you a warning, fix it, or we'll just blame the QC. :)

unsafe behaviour permitting assignments to 'constants' is not something you want compilers to replicate.
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Post by Seven »

Hello Spike,

Thank you for your reply.

What I dont understand is, that even when compiling the original qc, the elevator in R1M7 doesnt work with all recent/new compilers (except with the "fqcc101" compiler from 1997. But this one can abolutely not handle "dpextensions.qc").
I am of course a totally noob in compiling procedure. But why does the original games "progs.dat" work then ?

Can you give me a hint, where to search for the elevator trigger bug ?
Is it a trigger, so I should clean/search for the issue in "triggers.qc" ?
This qc is totally new for me (never worked with).
How can I find out which trigger the 1st elevator in R1M7 uses ?
Via the maps .ent file maybe ? What command must I search for in the .ent file, when knowing the elevator buttons world coordinate (I dont know what else I should search for in the .ent file) ?

I think, I cannot solve this issue... :(
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

some fun for you:

Code: Select all

float blob = 6228;
float() borked =
{
blob = 0;
return 6228 - (3114 * 2);
};
'borked' returns what?

Yup, it returns -6228. Because... well.. because qc code is fscked.
Modified compilers will attempt to do what they think is best, and generate a warning in the process. The authentic behaviour here is to say 'blob, well that's assigned to, like a function, so it must be constant. oh, this 6228 number looks nice oh hey, it has the same value as blob. I might as well use the same bit of memory for both of them'. Which is so increadibly wrong when you do actually assign to 'blob'.

fastqcc prides itself on its behavioural authenticity. other qccs try to make behaviour more predictable and sane.
A qcc can either a) not overlap immediates with defs (which fixes one set of bugs), b) overlap constants and immediates fully (with warnings when you assign to a constant, probably with a 'var' keyword), or c) let people change the values of constants *and* immediates defined afterwards without any warnings (which is the original undesirable suboptimal behaviour).
seriously though, check/fix warnings. They're caused by behaviour that the qcc thinks unsafe or broken.

dpextensions.qc is meant to be standard QC that is meant to compile with any qcc. LH and friends don't read every topic.

regarding the ent file, a lift is usually named func_plat. it just moves up and down.
however, its also possible that lifts are actually func_door. which is just weird.
if it moves sideways following waypoints, its a func_train.
probably you'll need to extract the .ent from the bsp in the first place (or just open the bsp with a decent text editor, and by decent, I mean not notepad).
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Post by Seven »

Hello Spike,

I followed your suggestion and looked deeper into:
- compiling warnings
- .ent file of the map


The elevator button is called in the ent file:
"classname" "func_elvtr_button"


The warnings in your fteqcc and frikqcc direct me to this:

Code: Select all

compiling newplats.qc
in function elvtr_use (line 163),
newplats.qc:172: warning: Result of comparison is constant
newplats.qc:199: warning: Result of comparison is constant
newplats.qc:207: warning: Result of comparison is constant
compiling newmisc.qc
compiling elevatr.qc
in function elvtr_button_wait (line 7),
elevatr.qc:12: warning: Assignment to constant ELV_BUTN_DIR
newplats.qc:14:    ELV_BUTN_DIR  is defined here
elevatr.qc:14: warning: Assignment to constant ELV_BUTN_DIR
newplats.qc:14:    ELV_BUTN_DIR  is defined here
elevatr.qc:16: warning: Assignment to constant ELV_BUTN_DIR
newplats.qc:14:    ELV_BUTN_DIR  is defined here

So in the end, it seems to be the problem with this little constant/param:
ELV_BUTN_DIR

It is first declared in newplats.qc (line 14), as described in your fteqcc warning:

Code: Select all

float ELV_BUTN_DIR	= 0;
Then later in newplats (line 172):

Code: Select all

	if (ELV_BUTN_DIR == 0)
		return;
Then in newplats (line 199+207):

Code: Select all

	if (ELV_BUTN_DIR == -1)
	{	
		if(self.elevatorOnFloor > 0)
		{
			self.elevatorToFloor = self.elevatorOnFloor - 1;
			elvtr_go ();
		}
	}
	else if(ELV_BUTN_DIR == 1)
	{
		if(self.elevatorOnFloor < (self.cnt - 1))
		{
			self.elevatorToFloor = self.elevatorOnFloor + 1;
			elvtr_go ();
		}
	}

Then this "constant" ELV_BUTN_DIR is used in "elevatr.qc" again (lines 12, 14, 16):

Code: Select all

void() elvtr_button_wait =
{
	ELV_BUTN_DIR = 0;
	if (self.spawnflags & ELVTR_DOWN)
		ELV_BUTN_DIR = -1;
	else
		ELV_BUTN_DIR = 1;
		
	self.state = STATE_TOP;
	self.nextthink = self.ltime + self.wait;
	self.think = elvtr_button_return;
	activator = self.enemy;
	SUB_UseTargets();
	self.frame = 1;			// use alternate textures
};

My QC skills are very limited, but could this be the rootcause of the issue ?
I think it is like the example you gave with 'borked', isnt it ?


I have no idea how to correct this QC code.
Can you give me a helping hand ? Or someone else ?
I gues we have to change the ELV_BUTN_DIR code/usage ?

Thank you very much for your time and effort.

Best wishes,
Seven
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

then the fix is:
float ELV_BUTN_DIR;
aye, just remove the =0 part.

side note:
if you wanted to initialize it to something other than 0, you could do this:
var float ELV_BUTN_DIR = 7;
(the 'var' keyword is present in frikqcc and fteqcc, but not in earlier compilers).
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Post by Seven »

Hello Spike,

what shall I say ?
The elevator bug is gone in R1M7 ! :D

Thank you very much for your help in this issue.

I guess not only I am happy now. Everybody else, who want to edit the rogue QC would have stumbled and fall over this "bug".


I didnt test the other maps/elevators, if we introduced a new "bug" now, but I guess not.

So this is how the beginning of "newplats.qc" looks now:

Code: Select all

// newplats.qc
// pmack
// september 1996

// TYPES

float DN_N_WAIT 	= 1;
float PLT_TOGGLE 	= 2;
float ELEVATOR		= 4;
float START_AT_TOP  = 8;
float PLAT2			= 16;
float PLAT2_BOTTOM  = 32;

float ELV_BUTN_DIR;

Regarding your side note:
As you know, my small mod compilation uses the autocvar function a lot.
And exactly this made it impossible to use fastqcc as the compiler.
fastqcc compiles the original rogue qc without issues/bugs (just as you explained it above), but cannot be used with all "dpextensions.qc" functions.


Thank you again Spike for your patience and kind help everytime.

Regards,
Seven
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re:

Post by Cobalt »

Hmm, just stumbled on this post. To me at first seemed to be ok that it returned -6228 , but I guess the reason here is that you are messing around with a global float inside an actual float type return function? Is it safe to say DO NOT change globals of any type within a float () or entity () call, where its returning an actual ent or value to be used in another function?

Spike wrote:some fun for you:

Code: Select all

float blob = 6228;
float() borked =
{
blob = 0;
return 6228 - (3114 * 2);
};
'borked' returns what?

Yup, it returns -6228. Because... well.. because qc code is fscked.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: compiling rogue devkit

Post by Spike »

cobalt, in that example, blob is a constant.

changing the value of constants is not supported. that's what makes them constants. doing it anyway WILL result in 'undefined' behaviour. and by undefined, I mean 'predictable but horribly horribly buggy behaviour that can differ from one qcc to the next'.
DO NOT WRITE TO CONSTANTS.
add the var keyword if you want it to not be a constant.
any good qcc will warn about this.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: compiling rogue devkit

Post by Cobalt »

Sounds good. I pasted this fun into my mod...Im running FTEqcc, I think the latest version , and its NOT saying a warning or stopping the compile with any errors... ?

Oops my mistake , it is warning:

Code: Select all

in function borked (line 4184),
bot/utils.qc:4186: warning: Assignment to constant blob
bot/utils.qc:4183:    blob  is defined here

Warnings are nice, but should this really be an error that stops compiling?
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: compiling rogue devkit

Post by Spike »

yes, it should be an error rather than a warning.
but then nothing would compile any more because QC coders are morons that give up as soon as they get the first error.

#pragma warning error Q106
should turn such warnings into errors.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: compiling rogue devkit

Post by Cobalt »

As a QC coder, I take offense at that ! But like Groege Carlin says - no one gives a shit anyway.... ! :)

But seriously, I guess its not a big deal because it wont crash the engine or anything...
Spike wrote:yes, it should be an error rather than a warning.
but then nothing would compile any more because QC coders are morons that give up as soon as they get the first error.

#pragma warning error Q106
should turn such warnings into errors.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re:

Post by Cobalt »

Yep - ran into this glitch today again, soaked up most the day trying to determine why a float was changing when it ought not to.

Also lets say you pass an entity to a function, then alter it in any way , it actually modifies the entity while in that funct as if its the real entity - not a local (x) in this case.

Code: Select all

void (entity x) Check blah =
{
if (x.origin != world.origin)
x.origin = world.origin

}
So this would actually move the entity x to world origin if not already there. I was thinking its localy floating the x for non destructive purposes....


Spike wrote:some fun for you:

Code: Select all

float blob = 6228;
float() borked =
{
blob = 0;
return 6228 - (3114 * 2);
};
'borked' returns what?
Post Reply