Runaway loops

[Spike]

when in doubt, decompile it and see what you get.

[golden_boy]

Be that as it may, I still went and changed all my i++ to i+=1, because that's what I actually meant to do every single time (I checked each case.)

[PrimalLove]

Be that as it may, I still went and changed all my i++ to i+=1, because that's what I actually meant to do every single time (I checked each case.)

Roger that!

@Spike

Roger Dodger! (EDIT)

[slackhead]

I get a lot of warnings about variable declarations with no references. Not quite sure that that means, but if I initialise them with a value it solves the problem. This is lengthy though. Is there an easier way?

[golden_boy]

EDIT2: Which version fteqcc you use?

SVN revision 4745 from today.

svn co http://svn.code.sf.net/p/fteqw/code/trunk fte/

cd fte/engine/qclib

make

I get a lot of warnings about variable declarations with no references. Not quite sure that that means, but if I initialise them with a value it solves the problem. This is lengthy though. Is there an easier way?

Adding

#pragma warning disable Q302

to progs.src.

FTEQCC FAQ - FTE

[slackhead]

Oh sorry I'm an idiot. It means that a variable has been declared and not used.

[PrimalLove]

Oh sorry I'm an idiot. It means that a variable has been declared and not used.

ROFL! Yeah they are just kinda there. You'll get like 140 or so references like that. They are perfectly fine but if you want you can simply comment them out or in most cases just completely get rid of them to clean up the code. They are more or less placeholders for something that either no long is in the code or like a just in case we want to use it here thing. ID has pretty sloppy code. I'm guessing frikqcc just ignores them.

[PrimalLove]

For a funny example of left over code check this out in ai.qc:

/*
=============
ai_walk

The monster is walking it's beat
=============
*/
void(float dist) ai_walk =
{
	[COLOR="Red"]local vector		mtemp;
	
	movedist = dist;[/COLOR]
	
	[COLOR="Red"]if (self.classname == "monster_dragon")
	{
		movetogoal (dist);
		return;[/COLOR]
	}
	// check for noticing a player
	if (FindTarget ())
		return;

	movetogoal (dist);
};

What is monster_dragon you ask? No dragon in Quake! Well unless you have mission pack 2 And the local vector? Da Fuq?

This is left over code from earlier versions of Quake. This is sloppy code so you can clean it up if you want with this:

/*
=============
ai_walk

The monster is looking for an collecting items.
=============
*/
void(float dist) ai_walk =
{
	
	// check for noticing a player
	if (FindTarget ())
		return;

	movetogoal(dist);

};

That cleans it right up.

[slackhead]

I'll just remove the bits that get warnings in the compiler for now.

Anyone got a way of fixing this mismatch?:

in function PutClientInServer (line 77),
client.qc:433: warning F307: type mismatch: void() to void(entity attacker, float damage) entity
.th_pain

Got a few of those.

[golden_boy]

I'll just remove the bits that get warnings in the compiler for now.

Anyone got a way of fixing this mismatch?:

in function PutClientInServer (line 77),
client.qc:433: warning F307: type mismatch: void() to void(entity attacker, float damage) entity
.th_pain

Got a few of those.

This means that the code has a function expecting two arguments (attacker, damage) but the actual function doesn't use those. Or the other way around.

[slackhead]

Yes, but how fix those? My C is a little shakey.

[golden_boy]

Yes, but how fix those? My C is a little shakey.

Pastebin.com the code please, I really can't remember what this looks like in vanilla QC.

[slackhead]

Pasted code - client.qc

Line 433

compiling client.qc
in function PutClientInServer (line 77),
client.qc:433: warning F307: type mismatch: void() to void(entity attacker, float damage) entity
.th_pain

[Spike]

*cough*
*cough* *cough*
#pragma warning disable F307
*cough*

add the extra arguments to the function in question. you don't have to use them.

alternatively self.th_pain = (void(entity, float)) Player_Pain;
or whatever the function is.

[PrimalLove]

Yes, but how fix those? My C is a little shakey.

In that particular case you can't fix it. Otherwise you would competely have to change the way the code works. As is, it allows for the player to go into pain animations based on being hurt. But if you place the additional parameters the routine will become specific and you'd have to come up with some code to compensate. Off the top of my head I can't think of a fix that wouldn't just lead to more bloat so why bother? PutClientInServer() basically resets the player with all the beginning params he needs when spawning in. Changing this would require prediction of information that isn't stored anymore I think. So it just isn't going to work. The good news here is this is a one way exchange. So it doesn't need the additional params. If any of that makes sense?

Let me explain why it catches this as an error. Functions not matching field types quickly leads to functions being called with the wrong number of parameters. You can imagine such a thing very quickly leading to a debugging nightmare especially the more complex your code gets. That is why this compiler throws up warnings about this issue. It's really to protect you from writing functions that simply can't possibly work or using the wrong parameters leading to bugs and crashes.

In short, it depends on the circumstance. In some cases you could define the additional params and its all good. But in this case you would seriously muck up the code and would do more damage than good. It's one of those errors you should ignore.

@Spike

Ah yes you can do that too! I like to keep mine on for debugging. But yeah most might find it annoying having all those warnings.