Warning

In a while, I’m going to release CBEffects Two and One-Half. With this release will come bug squashing, “problem parameter” handling, and more. However, in the course of time, I’ve detected a number of parameters or methods that will have to be changed. These include things that have inconsistent results, odd effects, and that sort of thing. Basically, what I’m saying is change your usage of CBEffects now, so that you don’t have to change it later. Here’s a list of changes that will be there:

relativeToSize:

I’m going to remove this parameter. Start setting it to “false” in your code, so that when it’s removed you won’t need to change anything. I’ve found that the values most affected by this are the gravity values (x and y).

density:

I’m also removing this parameter. Shouldn’t be too much of a problem, as it’s mostly unnoticeable. However, if you are currently using it, change it.

ParticlePhysics Particle Value Access:

For each particle, I’m adding all ParticlePhysics values to a separate table. This means you won’t be able to access particle values like “velX”, “velY”, “xDamping”, and such. Values moved to the separate table:

velX, velY

sizeX, sizeY

xDamping, yDamping

linearDamping, angularDamping

angularVelocity

xbS, ybS, xbL, ybL

rotateToVel

offset

Underscores

I’m adding a lot of underscored ("_") values. You shouldn’t need to access these, I’m just putting them here for anyone who is.

“particle._kill” instead of “particle.kill”

“particle._physicsColor” instead of “particle.physicsColor”

“particle._num” instead of “particle.num” ***DO NOT EDIT ON PAIN OF CRASHES***

DeleteAll

I’ll be removing this; there’s a memory leak that happens when this is used. It might be back when (if?) I fix the leak, but note that it’s return isn’t a sure thing.

That should be it, although if I think of anything else, I’ll add it.

C

New underscored values:

“particle._fadeInTrans” instead of “particle.inTrans”

“particle._fadeOutTrans” instead of “particle.trans”

“pPhysics._objects” instead of “pPhysics.objects”

I’ll also remove “particle._num” - it’s replaced by a value in the private table.

The values from the rotation table (“towardVel” and “offset”) will be merged into the main data table (as “rotateTowardVel” and “towardVelOffset”), so you might make a small edit into the library yourself if you wish, to accomodate that.

This is a  major  update, so be ready - in a good way :) 

Will give more information when I map everything out.

C

New underscored values:

“particle._fadeInTrans” instead of “particle.inTrans”

“particle._fadeOutTrans” instead of “particle.trans”

“pPhysics._objects” instead of “pPhysics.objects”

I’ll also remove “particle._num” - it’s replaced by a value in the private table.

The values from the rotation table (“towardVel” and “offset”) will be merged into the main data table (as “rotateTowardVel” and “towardVelOffset”), so you might make a small edit into the library yourself if you wish, to accomodate that.

This is a  major  update, so be ready - in a good way :) 

Will give more information when I map everything out.

C

Hi Caleb P,

Apologies for highjacking your thread, I wanted to post you regarding your ‘Perspective’ code but I could not find any posting enabled.

Brent Sorrentino posted an answer to my question which is this:

http://forums.coronalabs.com/topic/41136-rotating-an-object-in-a-group-as-a-camera-on-a-larger-than-screen-size-map-fixed-to-x-y-coords/

Could you tell me if this is possible with your code, and how I would go about implementing it?

Hi Caleb P,

Apologies for highjacking your thread, I wanted to post you regarding your ‘Perspective’ code but I could not find any posting enabled.

Brent Sorrentino posted an answer to my question which is this:

http://forums.coronalabs.com/topic/41136-rotating-an-object-in-a-group-as-a-camera-on-a-larger-than-screen-size-map-fixed-to-x-y-coords/

Could you tell me if this is possible with your code, and how I would go about implementing it?