To tie in to the save-game shenanigans from Sunday, here's a blog post describing how to use Preach's black magic for good instead of evil:

Debugging and Save Games 

OK, so it took long enough to debug and make correct that the discussion died down, but here's a post on making ogres play fair and aim vertically:

Proper Ogre Aiming

Hopefully I'm hitting the right balance of maths and code here today, but please tell me if it was too cut-down to comprehend, or waffled too long on the whys and the sums. 

...

But I can't wait for someone to compile this so I can get smashed by ogres. 

And I just updated their qc in RRP X) 

Hopefully I'm hitting the right balance of maths and code here today
Thank you, thank you, thank you! I really can't get my head around all the maths without a good example in QC. This is just perfect for me because I can tweak it and try out different things. 

There are a few places where I made myself leave things out from the QC code as posted, even where the changes are natural and not that hard. This was to maintain the focus on the new idea. Getting gravity correct and moving the launch point of the grenades forward are two such changes that would have distracted; I wouldn't release a mod without them.

The one that I'll share here is how to do the tan function correctly, as you might use it in a maths library. The flaw as I see it is that it changes global state, purely as a side effect, by calling makevectors and overwriting v_forward. It's not hard to imagine how this could break code if users were not aware. Here is the fixed version of tan, which was cut for space:

float(float theta) tan =
{
� local vector ang; //temporary used to calculate trig values
� local vector v_forward_temp, v_right_temp, v_up_temp;

� //save off global state
� v_forward_temp = v_forward;
� v_right_temp = v_right;
� v_up_temp = v_up;

� ang = '0 0 0';
� ang_y = theta; //assign theta to the yaw to simplify reasoning
� makevectors(ang);
� theta = v_forward_y / v_forward_x;

� //restore the globals
� v_forward = v_forward_temp;
� v_right = v_right_temp;
� v_up = v_up_temp;

� return theta;
} 

@Preach, I finally got around to merging your code into my ITS QC base and it works like a charm! Thank you :D

You got a spelling mistake in your tan2 function:
"and = '0 0 0';" should be "ang = '0 0 0';"

Also I highly recommend you prefix your tan/tan2 functions with "mathlib_" otherwise they conflict with the DP extension QC file.

I personally prefer (self.enemy.origin + '0 0 24') otherwise the grenades have a habit of falling short most of the time and especially if the ogre is below the player and close to a ledge. 

Need to get this replacing my dodgy code.

I like your approach, it's the more difficult way of doing it, but intrinsically better. 

Limit the player's movement speed to walk velocity without changing any cfg values? 

you can manually modify .velocity of the player when fl_onground is set. It's not going to be perfect though as there's no way to do this without changing cl_forward/back/side settings. 

Ok. My first thought was to just force always run to off, but I know there exist people who don't have that on by default.

But considering what I want to use it for (crippled state) maybe that won't be an issue. 

I would modify cl_*speed. Obviously *some* people may actually play with modified move speeds, but I think in your own mod, you have to be able to make some assumptions or decide not to cater to extremes. 

Ok, so I'm writing a tool that reads and writes quake wad files and was wondering if someone knows why some wads include the palette and some don't. Is the palette in the wad used anywhere? 

gfx.wad probably had the palette in it at one time, before it became a .lmp file instead. Perhaps that is where the palette-in-a-wad came from. 

so i should assume the palette in the wad is not used and therefore optional. 

So, what does 'Implicit Conversion' mean? I assume it means the result of the IF I'm trying is a constant, but I don't know why this:

if ((self.angles == 90) || (self.angles == 270))

Produces it. Basically if it's been rotated to face north/south as opposed to east/west do X instead of Y. Both of which are bounding box definitions.

Little help? How do I write that IF statement so it's not an Implicit Conversion? 

angles expecting a '0 0 0' value type? 

 

if ((self.angles_y == 90) || (self.angles_y == 270))

Should work? 

if ((self.angles == '0 90 0') || (self.angles == '0 270 0'))

or

if ((self.angles_y == 90) || (self.angles_y == 270)) 

Thanks guys.

I've been pussy footing around that issue for weeks, if not months now. 

Implicit conversion means the compiler is converting a value from one data type to another automatically because you used an assignment operator (=).

Contrast this to explicit conversion where you are telling the compiling exactly what data type you want a value to be. (Note: this isn't possible in QC)

ex:
int x = 10; //32bit integer
long y = 5; //64bit integer

y = x //this is allowed and implicitly converts '10' from a 32bit to a 64bit integer because there is no loss of precision (the number will still be the same).

However, you could not do:
x = y; //because you are trying to move from a 64bit to a 32bit (smaller container) data type. You would have to specifically say you are converting it:
x = (int)y;

What this means in regards to your code is that the compiler was probably implicitly converting '90' into the vector '90 0 0' because going from a float (1x32bit data type) to a vector (3x32bit data types) was not a loss in precision.

Let me know if this is incorrect as it's just my reading of the situation. 

sorry, to be specific, it's not just assignment operators, but also comparators ( ==, !=, <, > ). Can't compare apples to oranges! 

Although I've got done any careful checking, the bug with the mangle key on...
http://tomeofpreach.wordpress.com/quoth/tutorial/mapobject_custom/
...suggests that it's more common for a compiler to truncate a vector to a float - specifically the first component of the vector. 

bad implicit conversions are 'allowed' mostly due to decompilers not being able to determine types properly, and just writing out vec_x as vec instead. such ocde is of course buggy, but should run fine once its recompiled.

c-style casts exist in fteqcc, but are dependant upon opcode extensions or builtins to do the work where the fundamental types are made of different fundamental primitives (ie: floats+vectors are floats, everything else is an int).

qccx-style casts can be achieved with: asm mul_f yoursourcefloat, 1i, yourdestint;
which will rescale your source float and write it as some denormalised float which just happens to match the float's value as an int - so long as its smaller than 1<<23 or whatever it was.
fteqcc does not directly accept (float*1i) because it will convert the int to a float first resulting in no operation, instead of pretending that the int is a float.

note that asm add_f someconststring, 1i, someresult; will return a string omitting the first byte, etc.
hurrah for evil hacks.

ijed, when dealing with angles, I'd be surprised if you could actually get away with comparing exact numbers like that. such things typically need a range tolerance.