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. 

It clarifies things for my non-coder mind.

Apples and oranges - got it :)

I'm compiling with fteqcc.

I've got it working now doing the direct comparisons - they've done the trick since I'm looking at a static object placed by the mapper.

A range would be more elegant, but the primitive nature of the mapobjects involved means they should only be rotated 90 degrees anyway - they usually have one or more surfaces that can should be flush to a wall.

And a 45 degree rotation would make baby jesus be shot full of nails ie. cry. 

Spike: while you're hear sharing all kinds of wisdom about hacky things involving ints, I've got a question about them.

Is it possible to have a non-constant jump instruction in QC? If that were possible you could create a proper c++ style vtable - have a function which takes a parameter, pass specially designed integer constants for that parameter, and use them to jump to a function call for the "virtual" function the parameter designates. I tried messing around with the asm stuff but the compiler interpreted the variable as a goto label instead. Is this a compiler limitation or something completely impossible in QC? 

there's no such thing as jumptables in QC.
op_if_i, op_ifnot_i, op_goto all take constants only, the offset is directly encoded into the instruction.
on the other hand, op_call* takes a function variable (an index/int).

if you pass a function as an argument, you can theoretically add_f to it to move it on to the next function body defined in the source code, but that's evil.
yeah, a proper c++ style vtable could theoretically be achieved by storing the first function and add_fing an offset to get an indexed function by name... but frankly, I'd just go with fields for them, less hacky then. fteqcc's class stuff already does that, of course. 

op_if_i, op_ifnot_i, op_goto all take constants only, the offset is directly encoded into the instruction.

Yeah, this is what scuppers my plan. I basically just wanted a "switch" statement where each "case" calls a virtual function then returns. I think the easiest way to do it now is just use fteqcc arrays, have an array of function pointers, and select/execute the function using an index - which is a bit slower but doesn't need any integer tricks. By having multiple arrays with the same layout for corresponding functions it should be possible to switch between sets. 

struct
{
float(float a) func1;
vector() func2;
float() func3;
} vtable[] =
{
{
class1_func1,
class1_func2,
class1_func3
},
{etc2}, {etc3}, {etc4},
{
class5_func1,
class5_func2,
class5_func3
}
};

idx = bound(0, idx, sizeof(vtable)/sizeof(vtable[0]));
vtable[idx].func1(3);

can do different args that way. all functions from a single class form part of a single struct. 

Hi - Didnt know where else to post this here on the site, but was wondering does any one have an old key or registration for the original Quakespy? Not Gamespy, but just Quakespy. I have asked Gamespy if they would release the old src to the public but never got an answer.... 

It was nice to get so much positive feedback for the ogre article, I'll try and do more like it in the future. I think it was helped by being reasonably timely about an interesting open problem - so keep generating those kinds of ideas for me to tackle :-p

Today I'm polishing up an article I started in October, and it's on the maths-heavy side. In UK secondary schools you typically take one of two routes when studying Maths to age 18. Some students take on modules in Mechanics, and they would be well placed to tackle the grenade article from last time. The other route is Statistics, and so here's an article for them instead!

http://tomeofpreach.wordpress.com/2014/01/23/removing-busy-random-polling/

I've tried to push the heavy maths parts onto links again, but I do spend some time in the middle justifying the core idea. It's an older article and I spent too long on the graphs to delete them, so just feel free to skip that chunk. Also if you get the feeling at the start that this is unnecessary optimisation, make sure you catch the better reasons to do it near the end! 

I am not really sure how I can use this for anything, I don't have any functions that do what you are optimizing. Sorry, this article feels too abstract and more for you than anyone else.

If you want ideas for future code articles what about, creating ladders, tracking missiles (quoth rocket guy), vertical movement code (quoth bob), or improving the fiend jumping mechanic. 

That are set up with proper pathing? Like in unreal?