ah, you're right - sorry for the bad advice! the setup of evaluatePhysics() looks fine to me then.

all I can think of is generic debugging advice.. like, stick a:
printf("inside Particle::evaluatePhysics()\n");
at the first line of evaluatePhysics(). double check the particle object you're calling ->evaluatePhysics() on is not NULL. is it possible Game::FrameTime() is dereferencing a null pointer?

it should be possible to get a debugger to break when a null pointer dereference happens, so you can look at the call stack and ideally see exactly where the problem is. which IDE/environment are you using? 

Here's my very reduced test case

http://ideone.com/u1scWv

I actually put an implementation in my base class but it's easy to check that it works when it's pure virtual. Anyway, it's all got the same syntax and setup as your code above, so there's a detail wrong somewhere.

Have you tried putting a dummy evaluatePhysics function in PhysObject for debugging purposes. Just a quick one-liner that maybe logs a message. It would be a quick way to test if it is the "pure virtual" function which is causing the null pointer dereference. 

Nothing changes when I implement evaluatePhysics in PhysObject, so something else must be going wrong here.

debug on particle object: http://tinypic.com/r/ibctq9/8
There's a __vfptr member at 0xCDCDCDCD?

Here's the entire Particle class:
http://pastebin.com/jmtfPHs3

static void drawParticles() is called each frame which in turn calls this->evaluatePhysics() on any living particle. 

Can anyone explain to me what the limit is on numbers that I can store in self.items, and how it works? I've been having some very odd bugs with my mod. I have 16 different weapons, but for some reason I'm getting wierd errors where certain weapons are already owned, getting ammo gives the weapon, etc. etc. I'm thinking that perhaps there is a limit on how high the number can be for IT_<WEAPON NAME HERE> in the defs.qc. Is 16777216 too high a number to even fit in the float variable self.items?

I understand that certain numbers are assigned in a bitwise fashion for the correct HUD art to display, but I think I'm misunderstanding how it all works. 

cleaned up the code I posted above:
http://pastebin.com/hAXRXryT 

highest number you can use for any number in qc: 8388608 

highest flag you can use, sorry. :( 

Still hammering out (inside joke/pun!) the problems with IT_ numbers (1,2,4,8,16,32,etc.,4096,8192,etc). Apparently there is some engine code to handle the numbers stored in self.items, because otherwise picking up one item with a completely different touch function from another wouldn't still play that item's pickup sound. Apparently the engine is looking for a sum??(help!?) of the items contained?? 

so the way items works is that each IT_ value corresponds to a bit.

in binary,
1 is 0000000000001
2 is 0000000000010
4 is 0000000000100
etc...
storing items this way is a compact way of storing a bunch of yes/no settings in one spot.

if you do items = items | 4 you are essentially setting bit #3 to on. if it was already on, nothing happens.

so if you have multiple items stored on items, if you were to print it, you might see '7'
but actually what it is is: 0000000000111
so it means bits 1, 2 and 3 are 'on', in other words if you had:
IT_GUN1 = 1
IT_GUN2 = 2
IT_GUN3 = 4
it would mean you had all 3 guns in your inventory. 

I think i see the problem, it's cause by allocating memory with malloc, and then copying the particle in.

Here's a reduced test case that segfaults on the line particle->evaluatePhysics();:
http://pastebin.com/WB7iVHP1

I can't find a great explanation of why this is illegal. there is some stuff here: http://www.drdobbs.com/cpp/calling-constructors-with-placement-new/232901023?pgno=1

To fix it, I'd replace this:
Particle* Particle::pool = (Particle*)malloc(sizeof(Particle) * Particle::MAX_PARTICLES);

with an std::vector<Particle> Particle::pool;.
generally, you should avoid malloc in a c++ program and use new/delete, and the STL containers.
hope this helps :) 

That seems to be exactly what the problem was! I had used a static array because I planned to never grow it in size, but didn't know that it had trouble handling polymorphic stuff. Guess I shall stay away from malloc from now on. 

That makes so much sense now! Thank you! So this means that a standard quake integer (read that the float is floored) would initiate to 0000000000000000000000000000000 (32 0's) since it's 32bit, right? So I could have a total of 32 weapons then right? 

Unfortunately not. QC doesn't let you use integers, but floats. A 32 bit float only dedicates 24 bits to "places" in the number, the rest tell you the sign and the "scale" of the number. Basically when the number is large enough a float can't store integers accurately - the largest whole number that can be safely stored without rounding is 16777215. That's why necros gave 8388608 as the maximum size.

It is possible to use the non-place bits in a floating point value for more flags, but it's really incredibly fiddly. Better to just add another field to the entity and store the extra flags there.

re: pickup sounds. These are all specified in items.qc - the sound is based on the classname of the entity you touch. 

http://dev.xonotic.org/projects/3/wiki/Introduction_to_QuakeC
float
This is the basic numeric type in QuakeC. It represents the standard 32bit floating point type as known from C. It has 23 bits of mantissa, 8 bits of exponent, and one sign bit. The numeric range goes from about 1.175e-38 to about 3.403e+38, and the number of significant decimal digits is about six.

As float has 23 bits of mantissa, it can also be used to safely represent integers in the range from -16777216 to 16777216. 16777217 is the first integer float can not represent.
 

So that explains why I've had so many issues with the weapon assigned to the last bit slot of 16777216. Good to know that 8388608 is max. Phew, adding more weapons is gonna be a bit tricky then. 

the way floating point numbers are stored is actually pretty cool. it allows for a huge amount of scaling at the expense of precision. 

BUMP!!

Can we please sticky this thread next to Mapping Help? I come here often to read up on awesome stuff going on in QC Land but I keep having to dig down in All Threads. 

is there a reason why C++ compilers are so unhelpful?

the language is nice and having access to the heap and more control over what goes on the stack is great but tracking down some bugs or even mistyped things can be such a hassle. 

I've not used it myself, but one of the touted features of the clang compiler is superior error message delivery:
http://clang.llvm.org/diagnostics.html

Might be worth a punt... 

The problem with C++ error messages is (nested) templates. This makes the error messages very long and basically unreadable. The Xcode IDE is quite helpful here because it allows you to click on the separate lines of a template error and highlight their occurrence in the source files.

Other than that, I remember reading a trick to simplify the error messages in a C++ book. I can look it up if you're interested.

Preach, maybe clang has better error messages than others, but they're still hard to understand when there are templates involved ;-) 

http://tgceec.tumblr.com/ 

https://pbs.twimg.com/media/BCh-v51CAAA9HuT.jpg 

lol willem, yeah, i feel like that sometimes. :)

as for using another compiler, i have no idea how to change it since i'm using visual studio 2012... i assume i'm just using microsoft compilers of some kind. 

to give an example, at one point i started getting an error saying NULL was an undefined variable. and then suddenly it went away and I have no idea what caused that to happen. 

NULL is a typedef for the literal value 0. It is defined as soon as you import any STL header, such as iostream.