Pretty cool, Davio.

I'm working on the serialization portion of a plugin I'm working on and I need to serialize some pointers to CRunObjects. I've stumbled across this plugin, but I'm not sure how to use it correctly. My thought at the moment is something along these lines:

CRunObject* obj;
CRunObject* tempObj;
...
void ExtObject::Serialize(bin& ar)
{
	if (ar.loading)
        {
                pRuntime->SerializeObjectPtr(tempObj, ar);
                obj = tempObj;
        }
        else
        {
                pRuntime->SerializeObjectPtr(obj, ar);
        }
}
[/code:31ikoddk]
Unfortunately, this doesn't seem to work quite right.  

[i]I have an expression that returns the X coordinate of "obj".  If I do a quicksave and then a quickload, the returned X coordinate is equal to what it was before the load, but if I move around the object that's being pointed to, the returned X coordinate no longer changes.[/i]

Scratch the stuff in italics, the SerializeObjectPtr() function doesn't seem to be returning anything when I call it in the load portion of serialization.  My pointers remain NULL.

Using IsFamily and GetFamilyTypes doesn't seem to work either. I have the same problem using them as usual.

Maybe I could prod David into releasing the source for the pairer plugin. The "For each pair" condition would probably cover what I'm trying to do.

That is correct, yes, but this formula is actually a little simpler:

X = Sprite.X + cos(Sprite.Angle - 90) * 30

Y = Sprite.Y + sin(Sprite.Angle - 90) * 30

The only change for the Y coordinate is that "cos" is changed to "sin". Everything else stays the same.

Well, I managed to come up with a method for bypassing the problem, but I'm having actual picking problems now. I can specify a family as the type and the correct objects will be picked, but only if you're acting upon a specific member type inside the family. For example, if my condition and action setup was like this:

+Pick BlueFamily in vector
-Destroy Blue 
[/code:38xv5g5e]
All instances of blue would be destroyed.  If I do this, however, specifying a member type of the family but still picking a family:
[code:38xv5g5e]
+Pick BlueFamily in vector
-Destroy Sprite
[/code:38xv5g5e]
The correct objects are picked and destroyed.  Here's the code with the changes applied:

[code:38xv5g5e]
vector<CRunObject*> objects;
...

// The type of the object specified in Construct
CRunObjType* objType = params[0].GetObjectParam(pRuntime);
CRunObject** typeInstances;
int count;

pRuntime->GetTypeInstances(objType, typeInstances, count);
CRunObject** end = typeInstances + count;

// Iterate through the vector and find objects of like type
vector<CRunObject*>::iterator i = objects.begin();

for ( ; i != objects.end(); i++)
{
      CRunObject** begin = typeInstances;
      for ( ; begin != end; begin++)
      {
            if ((*i) == begin)
            {
                  pRuntime->SelectAll((*i)->pType);
                  pRuntime->SelectF((*i), (*i)->pType);
            }
      }
}
[/code:38xv5g5e]
This checks to see if the object currently pointed to by my CRunObject* vector iterator is equal to one of the instances that belongs to the specified family type.  Anything I'm doing wrong here?

specify two points, then specify two objects as arm1 and arm2. the arms would then form into an ik chain starting from point one, and attempt to reach point two. Maybe just specify arm1 as the root, then another point as the goal.

My IK plugin already does this.

I'm currently having problems with a plugin I'm working on regarding family picking -- or rather, family type comparison. The setup is like this:

I have a CRunObject* vector which I can add objects to through an action. With a condition I've set up, the user can specify an object type. The plugin iterates through the vector to see if any of the objects inside it match the type specified and then picks them. Here's how the code is laid out(non-bracket or comment lines are numbered for easier reference):

1. vector<CRunObject*> objects;
...

// The type of the object specified in Construct
2. CRunObjType* objType = params[0].GetObjectParam(pRuntime);

// Iterate through the vector and find objects of like type
3. vector<CRunObject*>::iterator i = objects.begin();

4. for ( ; i != objects.end(); i++)
   {
5.       if ((*i)->pType == objType)
         {     
6.            pRuntime->SelectAll((*i)->pType);
7.            pRuntime->SelectF((*i), (*i)->pType);
         }
   }
[/code:35a49waq]

If the given object type -- objType -- is a specific object, everything works fine.  However, if you substitute the specific object for a family, the type check in line 5 always returns false, resulting in no objects being picked.

Is this a problem in the way I'm comparing the types of the two objects?

You can download the redistributable version from HERE, which should work fine.

It would probably be better to leave it as one big image. Splitting it up, as far as I'm aware, wouldn't speed up loading times.

ODE is a 3D phsyics engine, so I don't think it would run nearly as well as Box2D. That was one of the reason why they switched to Box2D from Newton.

What particular features does ODE have that Box2D doesn't?

I don't think a whole lot can be done about it. Construct doesn't know what will be colliding with an object or where it will collide at, so it has to check for a collision with each possible object. Collision checking is already one of the most expensive processes, and doing it 5000+ times every frame is going to take a lot of CPU power.

It looks to be the collision checking for the "Ground" objects. If you turn off the solid attribute, the framerate jumps up to where it should be. I'd suggest placing stretched invisible dummy objects over the tiles to handle collisions. That or use the TiledBackground object for repeating chunks of ground. You have 5895 ground objects.