linkman2004's Forum Posts

  • I meant to have this out back in June(I've been working on this forever), but since nobody knew about this plugin until now, that's okay. So, I now introduce to everybody the:

    Advanced Camera Plugin - v0.93b

    Download Now(with example) - 150KB

    To install, extract the contents of the ZIP file into your Construct folder.

    What this plugin does is allows you to have an unlimited amount of named cameras which you can easily switch between, set to follow objects, etc. Here's a list of the main features:

    Features:

    • Create unlimited, named cameras
    • Switch between cameras, either smoothly or instantaneously
    • Follow objects with advanced options like lag and offset
    • Follow at a point between two objects
    • Smoothly transition between different locations, zooms, and angles
    • Cubic interpolation used so there are no sudden starts or stops
    • Camera shake action with magnitude, duration, dropoff, and smoothness settings
    • Easy to setup Mega Man style grid scrolling

    The download comes with an example showing off the big features and should give people a good understanding of how to use it, but if you have any other questions, be sure to ask, I'll be glad to help.

    If you find any bugs, please be sure to mention them and give specific information on what you were doing. Also, if there are any features you'd like to see, let me know and I'll see what I can do.

    Well, that's it. Download away and be sure to let me know what you think. Enjoy!

    NOTE: The example is made in .99.5. Sorry for anybody using an earlier version. I wasn't taking this into account when making the example.

  • Is it possible we could get the option to disable layer rotation on specific layers? For example, you can stop a layer from scrolling and you can stop it's zoom from changing when using "Set zoom", but you can't keep it from rotating when using "Set display angle". This really throws a wrench in things when you have a HUD and you don't want it to rotate with everything else.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It works for me, althought I had to download and install Python 2.6 from the Python website before it would stop crashing. That might fix your problem.

  • 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.