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. 

yeah that's what i mean. it should just be there regardless but something i wrote in my own code was stopping it from being defined or at least, made it look that way to the compiler.

i'm sure if i knew more about it it wouldn't be that strange but for a noob like me, it's just befuddling. 

So I haven't posted much on the old blog this year - putting together the Quoth release took up most of my Quaking time. So now that it's out the door, here's a return to posting stuff. Today we develop a bit of a hack to create an EndFrame function.

http://tomeofpreach.wordpress.com/2014/05/11/creating-the-endframe-function/

There are a bunch of extra hacky things this makes possible, but the article is tightly focused, maybe I can follow up with some of the options... 

Does this mean there's a way to reorder the entity edicts list? Is that what .chain and head are doing? Care to explain how those work, please?

I have a really cool entity that requires any linked entities to be right next to each other (or very nearly) in the edict list in order to avoid any mid-frame lag between eachother. I haven't released the entity as a standalone .qc file yet since I haven't found a workaround for telling people to "Yeah, just select the entities in the editor, copy them, delete them, then paste them to bring them back, then compile. That way the linked entities are always last on the edicts list since they are last in the map file. That way you avoid any mid-frame lag from having to calculate too many physics calls in between entities within the same frame." (DEATH to 0.100 second delays when arriving at path_corners!)

Is there a way to always make sure these entities are near each other in the edicts list so that they're physics are called together? 

.chain is set when you run findradius. the engine simply sets this on all entities in the radius so you can iterate through them.

relying on the entity spawn order for your code is dangerous and impractical. it would be better to create a new .entity field and then build your list of entities with the new field at map start once. then you can iterate smoothly without having to rely on the map playing nice. 

@Qmaster: try using copyentity to copy the slave entity towards the end of the list. combine with the entnum builtin/intrinsic/nextent so you know the order is okay. do it inside the master's spawn function if the slave already exists and you should be okay with respect to targetname stuff on other entities. 

Now, from the context clues in your post, I'm guessing you're trying to create some kind of escalator or conveyor belt contraption out of a set of func_train entities. Ensuring that all of the trains are next to each other in the entity list will not save you here. One way they can still go out of sync is if a player blocks one of the trains, but the others are free to move.

What I'd recommend is getting a copy of the "custents" mod, and looking at their func_train_sync entity, which is designed to fix this specific issue. I can't remember if the fix was complex - like ensuring all the movement shuts down when one entity is blocked, or the simpler solution of having individual entities wait at each corner until all the trains have reached their next stop. 

Incidentally I'm running into a bug now with the tutorial I posted, so hold on using it until I figure out what's causing it. It's the kind of bug that creates a substring out of a QC string, so something's really having a party on the entity... 

Ok, so it turns out that the compiler optimisations I was using with FTEQCC have an obscure bug that got exposed by the spawn() function wrapper in the previous tutorial. This was corrupting the entities, and it also managed to corrupt the linked list in CreateBackstop to obscure the fact that it should loop infinitely.

The full skinny on what form the bug takes, how to work around it, and how to fix the bugs it masked in my own code is now up on the blog:

http://tomeofpreach.wordpress.com/2014/05/20/fixing-the-endframe-function/ 

Preach, in all seriousness, get an updated version. That's an order!