A maximum number of entities that can be searched through with the find function?

I'm using it to search through randomiser entities and it seems to be provoking a crash now, as the map and number of entities has grown in size. 

it's possibly you're hitting the 100,000(?) operations per frame limit.

In a given frame, you can do 100000 operations before the engine thinks you're stuck in an infinite loop. This includes all operations done before you hit your loop and all the operations done after your loop, so you can get through your loop fine only to crash on subsequent operations done after.

the solution to this is to defer the search after n loops to the next frame by saving the last entity and starting from there instead of world. 

Just talking with Sock about it.

I threw in some delays and it certainly seems to be the case. The size of the map is basically breaking this limit.

What I'm doing is randomising monster position, and the code I'm using is searching the entire entity list to do so.

If I chained the entities it'd work much better, but that's a massive amount of work.

Not using randomisation would have the benefit of more precise monster placement and not having to rewrite the code and map.

Just delete a load of entities from the map.

Thanks, seems like the way ahead is clear!

I could rewrite, but it'd take a lot of time. In future projects I can take this limitation into mind and use stuff which has nextthink = time + random(); or similar. 

I'm removing all the randomiser entities and replacing the monsters traditionally.

This'll give me a playable level.

I've got in mind a randomiser system that would be supported by the single thread engines that Quake uses.

Basically it flagging monsters as RANDOMISED (additional to the SPAWN_SILENT, SPAWNED and SPAWN_ANGRY flags).

Each monster would have keys to denote their randomiser grouping. These keys would be rname, rnext and pool.

rname and rnext would copy the door code to produce chain grouping. This would make things much lighter when using the find function. Erroneously configured chains would have a failsafe to make sure they'd always be a loop.

All monsters in the same group would randomise their positions between the others in the group, any monster ending up in another position would also inherit the target of that position (to point at the relevant path_corner or trigger_counter) if a monster didn't have a target then this would clean any target held by the arriving monster. The difficulty flags and targetnames would remain unchanged.

Monsters with pool set to 1 would never add the position etc. to the randomisation group, but could take the place of other monsters. Possibly there'd be other functionality for pool, which is why it should be a key and not a flag.

Basically this means that the monsters not set to pool 1 define the positions used for spawning and how many monsters will be spawned.

Monsters would only be randomised when spawned, so quick loading after dying would re-randomise the monster positions as they would be retriggered.

This would produce a system optimal for the engine and simple for the mapper, even though it involves a flag and three separate keys.

Probably won't do it in this project though. Maybe next time. 

This would make a monster not spawn. The utility would be placing three shamblers for example, but only one appears. 

I mean, pool 2 would make a monster part of the group, but not increase the amount of spawns for that group. 

So apparently you can use "Code::Blocks" as an IDE for QuakeC, with autocomplete and all that shizzle.

Anyone use this? I followed the instructions here: http://ouns.nexuizninjaz.com/dev:programming_introduction#working_with_the_code

But I can't get the pissing thing to work properly - my symbols tab is empty and it can't find any of my functions or do autocomplete or any of the things which would make it better than, you know, notepad.

Has anyone else got it working for QuakeC? 

Gave it a try, but I don't know the first thing to do with codeblocks, so didn't get very far.

Did notice that the lexer_qc.xml file has a bunch of typos in the keywords though, so it's not going to be highlighting .vector, continue or default any time soon... 

I noticed all those typos too. Doesn't fill me with much confidence to be honest. 

more like lol 

Coming from Java, this C++ stuff is confusing to me...

I have this class which is meant to be an Interface:
class PhysObject
{
public:
virtual void evaluatePhysics() = 0;
protected:
Vec2 velocity; //physicalized objects have velocity
PhysObject() :
velocity(Vec2())
{}
};


Then I have this other class that implements PhysObject:

class Particle : public PhysObject
{
public:
Particle(Vec2 pos) :
position(pos),
size(Vec2(4, 4)),
releaseTime(Game::Time() + 1),
PhysObject()
{}

void evaluatePhysics()
{
this->position = this->position + (this->velocity * Game::FrameTime());
}
...
};

But when I call this->evaluatePhysics() on the Particle object, it crashes with access violation 0xCDCDCDCD which the internet tells me is caused by dereferencing a null pointer. So it looks like my evaluatePhysics() implementation in Particle never actually took, and it's still trying to call the Interface's evaluatePhysics() = 0 pointer.

Any hints? 

I think you just need to add 'virtual' before 'void evaluatePhysics()' in Particle.

Also, sounds like there's a new c++11 feature where you can stick the "override" keyword after the function args in Particle, like this:

virtual void evaluatePhysics() override
{

which will make the compiler check that this evaluatePhysics() is actually overriding something from the parent class. 

no dice, neither from adding virtual or override. :(

From what I've read, once you put virtual on a method, everything from that point forward will always be virtual, ie: behave as expected of a polymorphic object and properly call child class methods if held in a base class container. 

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?