Last 7 days

• Dec 24, 2009

  issue 14 (the projects slowdown after 10-20 seconds) commented on by AmiBlit   -   In the render loop i clear the graphics. Now is much more fast. One question: it's possible to use the angle to detect the direction or part that colleded? I.E: the object collided on his top or bottom. Think about a bouncing ball: if i hitting the ground i can jump, otherwise i can't. Could you put an example of this? Thank you

  In the render loop i clear the graphics. Now is much more fast. One question: it's possible to use the angle to detect the direction or part that colleded? I.E: the object collided on his top or bottom. Think about a bouncing ball: if i hitting the ground i can jump, otherwise i can't. Could you put an example of this? Thank you

Last 30 days

• Dec 21, 2009

  issue 14 (the projects slowdown after 10-20 seconds) reported by AmiBlit   -   i used the code for the terrain collision. i use one large object for as the terrain. The game starts ok, but after few seconds begin to slow down dramatically. i use the 1.5 version on windows xp system is P4 at 2,8 ghz. Could be something related to the creation of the objects? Maybe something must be clear or erased in the render loop? Don't know. Please, continue with the development of your code: is really great!!! Thank you very much. Best regards Davide

  i used the code for the terrain collision. i use one large object for as the terrain. The game starts ok, but after few seconds begin to slow down dramatically. i use the 1.5 version on windows xp system is P4 at 2,8 ghz. Could be something related to the creation of the objects? Maybe something must be clear or erased in the render loop? Don't know. Please, continue with the development of your code: is really great!!! Thank you very much. Best regards Davide

Earlier this year

• Nov 26, 2009

  issue 13 (Ignore same object) reported by Kremnari   -   It would be nice to prevent the return of collisions between the same object types. Example: Right now I'm designing a basic shootemup game in flash. I'm checking for collisions between bullets and enemies. Since some of these enemies can over lap, they are being returned as a collision. Also, there may be times when bullets overlap. I would like to prevent checkCollisions from returning these cases. I would think this could just be done with a property; then a simple if statement to compare the two objects before we actually collision test them. I'm looking to see if I can implement this myself, but perhaps others would like this as well?

  It would be nice to prevent the return of collisions between the same object types. Example: Right now I'm designing a basic shootemup game in flash. I'm checking for collisions between bullets and enemies. Since some of these enemies can over lap, they are being returned as a collision. Also, there may be times when bullets overlap. I would like to prevent checkCollisions from returning these cases. I would think this could just be done with a property; then a simple if statement to compare the two objects before we actually collision test them. I'm looking to see if I can implement this myself, but perhaps others would like this as well?
• Oct 23, 2009

  issue 9 (Need way to specify whether to include overlapping array) commented on by indyaner.de   -   A Flag would be pretty much appreciated. Is there a rough Releasedate vor this fix? I'm not sure If I can escape the nesseary lines by myself, so I will bett wait.

  A Flag would be pretty much appreciated. Is there a rough Releasedate vor this fix? I'm not sure If I can escape the nesseary lines by myself, so I will bett wait.
• Jul 01, 2009

  issue 12 (Need way to define a 'Region of Interest' within which colli...) commented on by effortless.complexity   -   I don't see how people are getting good performance from this. I would find it very valuable if there was a wiki page outlining performance: expected, and how to get better performance. Thanks.

  I don't see how people are getting good performance from this. I would find it very valuable if there was a wiki page outlining performance: expected, and how to get better performance. Thanks.
• Jul 01, 2009

  issue 12 (Need way to define a 'Region of Interest' within which colli...) commented on by effortless.complexity   -   Sorry, I didn't mean to classify it as a defect.

  Sorry, I didn't mean to classify it as a defect.
• Jul 01, 2009

  issue 12 (Need way to define a 'Region of Interest' within which colli...) reported by effortless.complexity   -   What steps will reproduce the problem? 1. In code, populate a container sprite with object from x = -5000 to 5000 2. Add these ojects to the collisionList. 3. Query collisions every frame What is the expected output? What do you see instead? Starts at 30fps. Goes down to 10fps when colliding. Maybe because stage.width is so large. I move this container across the stage, so I only care about objects I can see, aka stage.stageWidth. So would be great if I could define a 'Region of Interest' rectangle (= to the stage, or actually even smaller) so that collision detection is only done in that area. What version of the product are you using? On what operating system? 1.5, Flash CS4, XP Pro. Please provide any additional information below. Maybe there is another reason for slow performance. I tried the following variables (glow means alpha at edges. solid means non alpha'ed jpg): /* Speed tests (With panning background 7708x2056 unless otherwisw stated): // With single half XGA, Reticule.alpha = 0.5, placeholder glow, goes down to 11fps at max intersection. // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 10fps at max intersection. Even if 'add' drills down to hotspots[] -> placeholder -> loader // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 11fps at max intersection. With panning background only 2048x1536 // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 10fps at max intersection. // With single XGA screen, Reticule.alpha = 1, placeholder glow, goes down to 11fps at max intersection. // With single XGA screen, Reticule.alpha = 1, placeholder solid, goes down to 11fps at max intersection. // With single XGA screen, Reticule solid square, placeholder solid, goes down to 8fps at max intersection. // With single XGA screen, Reticule stroke circle, placeholder solid, goes down to 13fps at max intersection. // With single XGA screen, Reticule 4 sml squares, placeholder solid, goes down to 13fps at max intersection. // With single XGA screen, Reticule 4 pixels, placeholder solid, goes down to 14fps at max intersection. // With single XGA screen, Reticule 3 pixels, placeholder solid, goes down to 14fps at max intersection. // With single XGA screen, Reticule 2 pixels, placeholder solid, goes down to 30fps at max intersection. // With single XGA screen, Reticule 1 pixels, placeholder solid, goes down to 30fps at max intersection. // With single XGA screen, Reticule plchldr solid, placeholder solid, goes down to 3fps at same intersection. // With single XGA screen, Reticule ph solid jpg, ph solid jpg, goes down to 3fps at same intersection. // Traces make no difference. */

  What steps will reproduce the problem? 1. In code, populate a container sprite with object from x = -5000 to 5000 2. Add these ojects to the collisionList. 3. Query collisions every frame What is the expected output? What do you see instead? Starts at 30fps. Goes down to 10fps when colliding. Maybe because stage.width is so large. I move this container across the stage, so I only care about objects I can see, aka stage.stageWidth. So would be great if I could define a 'Region of Interest' rectangle (= to the stage, or actually even smaller) so that collision detection is only done in that area. What version of the product are you using? On what operating system? 1.5, Flash CS4, XP Pro. Please provide any additional information below. Maybe there is another reason for slow performance. I tried the following variables (glow means alpha at edges. solid means non alpha'ed jpg): /* Speed tests (With panning background 7708x2056 unless otherwisw stated): // With single half XGA, Reticule.alpha = 0.5, placeholder glow, goes down to 11fps at max intersection. // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 10fps at max intersection. Even if 'add' drills down to hotspots[] -> placeholder -> loader // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 11fps at max intersection. With panning background only 2048x1536 // With single XGA screen, Reticule.alpha = 0.5, placeholder glow, goes down to 10fps at max intersection. // With single XGA screen, Reticule.alpha = 1, placeholder glow, goes down to 11fps at max intersection. // With single XGA screen, Reticule.alpha = 1, placeholder solid, goes down to 11fps at max intersection. // With single XGA screen, Reticule solid square, placeholder solid, goes down to 8fps at max intersection. // With single XGA screen, Reticule stroke circle, placeholder solid, goes down to 13fps at max intersection. // With single XGA screen, Reticule 4 sml squares, placeholder solid, goes down to 13fps at max intersection. // With single XGA screen, Reticule 4 pixels, placeholder solid, goes down to 14fps at max intersection. // With single XGA screen, Reticule 3 pixels, placeholder solid, goes down to 14fps at max intersection. // With single XGA screen, Reticule 2 pixels, placeholder solid, goes down to 30fps at max intersection. // With single XGA screen, Reticule 1 pixels, placeholder solid, goes down to 30fps at max intersection. // With single XGA screen, Reticule plchldr solid, placeholder solid, goes down to 3fps at same intersection. // With single XGA screen, Reticule ph solid jpg, ph solid jpg, goes down to 3fps at same intersection. // Traces make no difference. */
• Jun 23, 2009

  issue 11 (Call dispose() on BitmapData objects when done) commented on by e.verdonk   -   When the collision detection is fully done, can you also null the properties bmd1 and bmd2 in the CDK class? Or better, null everything that is not needed anymore to free up memory.

  When the collision detection is fully done, can you also null the properties bmd1 and bmd2 in the CDK class? Or better, null everything that is not needed anymore to free up memory.
• Jun 23, 2009

  issue 7 (checkCollisions should return strongly typed Object) commented on by e.verdonk   -   There are lots of more places in your code where strong typing is pleased. Start subversioning :-P.

  There are lots of more places in your code where strong typing is pleased. Start subversioning :-P.
• Jun 23, 2009

  issue 8 (Need way to determine target in checkCollisions) commented on by e.verdonk   -   I can live with the option you described in comment #2. However I do much prefer the target/collisionItem option Mike described. I do not see a scenario where I would first choose to use CollisionGroup and later swap it for CollisionList. When you have a clear goal on what you're building you choose either one and never swap. Often clear and easy code outweighs flexibility.

  I can live with the option you described in comment #2. However I do much prefer the target/collisionItem option Mike described. I do not see a scenario where I would first choose to use CollisionGroup and later swap it for CollisionList. When you have a clear goal on what you're building you choose either one and never swap. Often clear and easy code outweighs flexibility.
• Jun 22, 2009

  issue 8 (Need way to determine target in checkCollisions) commented on by lessthanthree   -   How about this: In the case of CollisionGroup, object1 will always be the smaller of the two objects (as it is now) In the case of CollisionList, object1 will always be the target. This way we can have a Collision object being returned (re: your issue for typed objects from checkCollision()) that is the same structure for both CollisionGroup and CollisionList, making it painless to swap between the two. Shoot, I can have a "target" property in the class anyways and just use it in the case of CollisionList if you think it's worth it.

  How about this: In the case of CollisionGroup, object1 will always be the smaller of the two objects (as it is now) In the case of CollisionList, object1 will always be the target. This way we can have a Collision object being returned (re: your issue for typed objects from checkCollision()) that is the same structure for both CollisionGroup and CollisionList, making it painless to swap between the two. Shoot, I can have a "target" property in the class anyways and just use it in the case of CollisionList if you think it's worth it.
• Jun 22, 2009

  issue 11 (Call dispose() on BitmapData objects when done) Labels changed by lessthanthree   -   Couldn't hurt! I didn't see a need since the three BitmapData objects in use are reinstantiated each time a collision is checked, but like you said, it's probably a good idea if just for piece of mind. I'll have it in the next release.

  Labels: Type-Enhancement −Type-Defect

  Couldn't hurt! I didn't see a need since the three BitmapData objects in use are reinstantiated each time a collision is checked, but like you said, it's probably a good idea if just for piece of mind. I'll have it in the next release.

  Labels: Type-Enhancement −Type-Defect
• Jun 22, 2009

  issue 10 (Need way to specify whether to include overlapping array) Status changed by lessthanthree   -   This is already available via the returnAngle property. It's a Boolean that determines whether or not the CDK finds the angle of collision. If you set it to false, then the angle returned in the checkCollisions() objects will always be 0. It can be seen here in the docs: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#returnAngle ...though the documentation is incorrect in that it says the default is false. The default for returnAngle as of version 1.5 is true.

  Status: Invalid

  This is already available via the returnAngle property. It's a Boolean that determines whether or not the CDK finds the angle of collision. If you set it to false, then the angle returned in the checkCollisions() objects will always be 0. It can be seen here in the docs: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#returnAngle ...though the documentation is incorrect in that it says the default is false. The default for returnAngle as of version 1.5 is true.

  Status: Invalid
• Jun 22, 2009

  issue 9 (Need way to specify whether to include overlapping array) Labels changed by lessthanthree   -   Agreed. The previous version of the CDK only returned the number of overlapping pixels (information I already had on hand without further computation), so when it was updated to include location having a condition for it wasn't considered. I'll put a flag in for it in the next release.

  Labels: Type-Enhancement Priority-High −Type-Defect −Priority-Medium

  Agreed. The previous version of the CDK only returned the number of overlapping pixels (information I already had on hand without further computation), so when it was updated to include location having a condition for it wasn't considered. I'll put a flag in for it in the next release.

  Labels: Type-Enhancement Priority-High −Type-Defect −Priority-Medium
• Jun 22, 2009

  issue 7 (checkCollisions should return strongly typed Object) Labels changed by lessthanthree   -   Agreed. This is a change I would have liked rolling into the last update but was overlooked. Will be done for next release. You keep this up, Mike, and I'm going to have to start subversioning. ;P

  Labels: Type-Enhancement Priority-High −Type-Defect −Priority-Medium

  Agreed. This is a change I would have liked rolling into the last update but was overlooked. Will be done for next release. You keep this up, Mike, and I'm going to have to start subversioning. ;P

  Labels: Type-Enhancement Priority-High −Type-Defect −Priority-Medium
• Jun 22, 2009

  issue 8 (Need way to determine target in checkCollisions) Labels changed by lessthanthree   -   I'll mull this one over. The main reason I have it as object1/object2 is so that you could swap out CollisionGroup and CollisionList without having to rewrite any of the code handling the collision. If I specify target for CollisionList, but still have object1/object2 for CollisionGroup, then implementation changes between the two. However, I agree that specifying the target in CollisionList would improve performance by eliminating checks, so I'll think it over. I should note that you get a wee bit of help in discerning between object1 and object2 in that object1 is always the smallest of the two involved in the collision. So in situations where your target is always smaller or larger than your other items in the list, you always know if it's object1 or object2.

  Labels: Type-Enhancement −Type-Defect

  I'll mull this one over. The main reason I have it as object1/object2 is so that you could swap out CollisionGroup and CollisionList without having to rewrite any of the code handling the collision. If I specify target for CollisionList, but still have object1/object2 for CollisionGroup, then implementation changes between the two. However, I agree that specifying the target in CollisionList would improve performance by eliminating checks, so I'll think it over. I should note that you get a wee bit of help in discerning between object1 and object2 in that object1 is always the smallest of the two involved in the collision. So in situations where your target is always smaller or larger than your other items in the list, you always know if it's object1 or object2.

  Labels: Type-Enhancement −Type-Defect
• Jun 21, 2009

  issue 11 (Call dispose() on BitmapData objects when done) reported by mikechambers   -   Its probably a good idea to call BitmapData.dispose() on BitmapData instances we the code is done with them, to ensure that the memory for them is reclaimed.

  Its probably a good idea to call BitmapData.dispose() on BitmapData instances we the code is done with them, to ensure that the memory for them is reclaimed.
• Jun 21, 2009

  issue 10 (Need way to specify whether to include overlapping array) commented on by mikechambers   -   This title is wrong. It should be: Need way to specify whether to include Angle data

  This title is wrong. It should be: Need way to specify whether to include Angle data
• Jun 21, 2009

  issue 10 (Need way to specify whether to include overlapping array) reported by mikechambers   -   This is related to: http://code.google.com/p/collisiondetectionkit/issues/detail?id=9 checkCollisions should include an option to not look up collision angles. The code in findAngle can be processor intensive, and this would provide a way to not take the CPU hit when the angle data is not needed. checkCollisions(includeAngle:Boolean = true):Array

  This is related to: http://code.google.com/p/collisiondetectionkit/issues/detail?id=9 checkCollisions should include an option to not look up collision angles. The code in findAngle can be processor intensive, and this would provide a way to not take the CPU hit when the angle data is not needed. checkCollisions(includeAngle:Boolean = true):Array
• Jun 21, 2009

  issue 9 (Need way to specify whether to include overlapping array) commented on by mikechambers   -   I just did a quick test on this, and commented out the code that generates the points. In my case, where I have a lot of items, it gave me a 33% performance improvement.

  I just did a quick test on this, and commented out the code that generates the points. In my case, where I have a lot of items, it gave me a 33% performance improvement.
• Jun 21, 2009

  issue 9 (Need way to specify whether to include overlapping array) reported by mikechambers   -   When calling checkCollisions you are returned an object that contains an Array of Points where the objects are overlapping. I suggest that we provide an api to make this optional: checkCollisions(includeOverlapData:Boolean = true):Array The main reason is performance. In a lot of cases, this data is not needed (just whether there is a collision). However, the overlapping array can contain a LOT of Point instances. In flash content where collisions are being detected among many items, frequently (maybe in onEnterFrame), this can lead to a LOT of Point objects being instantiated which may not be needed by the user. This can have a significant impact on performance.

  When calling checkCollisions you are returned an object that contains an Array of Points where the objects are overlapping. I suggest that we provide an api to make this optional: checkCollisions(includeOverlapData:Boolean = true):Array The main reason is performance. In a lot of cases, this data is not needed (just whether there is a collision). However, the overlapping array can contain a LOT of Point instances. In flash content where collisions are being detected among many items, frequently (maybe in onEnterFrame), this can lead to a LOT of Point objects being instantiated which may not be needed by the user. This can have a significant impact on performance.
• Jun 21, 2009

  issue 8 (Need way to determine target in checkCollisions) reported by mikechambers   -   When calling checkCollisions, you are giving an untyped argument with two properties: object1 object2 There is currently no way to know which object was the target passed to CollisionList. In fact, it seems to be random, and can sometimes be object1 or object2. I suggest that we rename these to something like: target collisionItem and ensure that target always contains the target. This will make it clearer and easier to use, as well as improve performance (since the developer will not have to check which one is the target).

  When calling checkCollisions, you are giving an untyped argument with two properties: object1 object2 There is currently no way to know which object was the target passed to CollisionList. In fact, it seems to be random, and can sometimes be object1 or object2. I suggest that we rename these to something like: target collisionItem and ensure that target always contains the target. This will make it clearer and easier to use, as well as improve performance (since the developer will not have to check which one is the target).
• Jun 21, 2009

  issue 7 (checkCollisions should return strongly typed Object) reported by mikechambers   -   Couple of suggestions for the array returned from checkCollisions. Right now, when you call checkCollisions() you get an Array of objects returned to you for each collision. These objects should be Strongly typed. This will be faster for the player, and will make it easier to work with. Maybe something like: public class Collision { public var targetObject:DisplayObject; // the target public var collisionObject; //the item the target is colliding with public var overlapping:Array; (over Vector.<Point>; }

  Couple of suggestions for the array returned from checkCollisions. Right now, when you call checkCollisions() you get an Array of objects returned to you for each collision. These objects should be Strongly typed. This will be faster for the player, and will make it easier to work with. Maybe something like: public class Collision { public var targetObject:DisplayObject; // the target public var collisionObject; //the item the target is colliding with public var overlapping:Array; (over Vector.<Point>; }
• Jun 18, 2009

  issue 6 (Add ability to change target in CollisionList) commented on by mikechambers   -   Awesome. That is exactly what I was looking for. mike chambers mesh@adobe.com

  Awesome. That is exactly what I was looking for. mike chambers mesh@adobe.com
• Jun 17, 2009

  issue 6 (Add ability to change target in CollisionList) Status changed by lessthanthree   -   I'm happy to report that this ability already exists. You can change the target using the CollisionList's swapTarget() method. Pass it the new target you want and it's done! You can read about it in the documentation here: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#swapTarget By the by, I'm a big fan Mike. :D If there are any open seats at Adobe for the Flash team, drop me a line? Pretty please?? ;)

  Status: Invalid

  I'm happy to report that this ability already exists. You can change the target using the CollisionList's swapTarget() method. Pass it the new target you want and it's done! You can read about it in the documentation here: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#swapTarget By the by, I'm a big fan Mike. :D If there are any open seats at Adobe for the Flash team, drop me a line? Pretty please?? ;)

  Status: Invalid
• Jun 17, 2009

  issue 6 (Add ability to change target in CollisionList) reported by mikechambers   -   Right now, you can only specify the target for a CollisionList in the constructor. It would be helpful to be able to change the target of a CollisionList after the instance has been created. Please add a target property to CollisionList. This would be useful when you need to do multiple 1 to many collision checks, where the many are the same for each check (although the 1 is different). This would allow you to reuse the same CollisionList instance across multiple one to many checks. You could possibly use CollisionGroup for this, but that is not always as efficient: 1. it may do unnecessary checks, if you dont care that some items hit others. 2. the same items may appear in the collisions array, making it more difficult to work with them (i.e. removing colliding items from the display list).

  Right now, you can only specify the target for a CollisionList in the constructor. It would be helpful to be able to change the target of a CollisionList after the instance has been created. Please add a target property to CollisionList. This would be useful when you need to do multiple 1 to many collision checks, where the many are the same for each check (although the 1 is different). This would allow you to reuse the same CollisionList instance across multiple one to many checks. You could possibly use CollisionGroup for this, but that is not always as efficient: 1. it may do unnecessary checks, if you dont care that some items hit others. 2. the same items may appear in the collisions array, making it more difficult to work with them (i.e. removing colliding items from the display list).
• Jun 16, 2009

  CDK Examples_v15.zip (Collision Detection Kit v1.5.0 - Examples (Source Files)) file uploaded by lessthanthree   -  

  Labels: Featured Type-Archive

  Labels: Featured Type-Archive
• Jun 06, 2009

  issue 4 (Collision will not work correctly when having objects in a c...) Status changed by lessthanthree   -   This problem has been addressed in the latest release, version 1.5 You can now do whatever you see fit to parent containers without issue. Download and enjoy! :D

  Status: Done

  This problem has been addressed in the latest release, version 1.5 You can now do whatever you see fit to parent containers without issue. Download and enjoy! :D

  Status: Done
• Jun 06, 2009

  CDK Documentation v15.zip (Collision Detection Kit v1.5.0 - Documentation) file uploaded by lessthanthree   -  

  Labels: Type-Docs Featured

  Labels: Type-Docs Featured
• Jun 06, 2009

  CollisionDetectionKit_v15.zip (Collision Detection Kit version 1.5.0) file uploaded by lessthanthree   -  

  Labels: Type-Source Featured

  Labels: Type-Source Featured
• Jun 03, 2009

  issue 5 (get collisions) commented on by AlexWHB   -   how do i convert the angle object in the array returned from checkColisions to a number var?

  how do i convert the angle object in the array returned from checkColisions to a number var?
• May 15, 2009

  issue 5 (get collisions) changed by lessthanthree   -   You can check for collisions by calling the checkCollisions() method. If any collisions are occuring while you do the check, then it will return an array containing each collision (or an empty array if there are no collisions). Each array item is an Object which contains information about the collision (the two objects that collided, the amount of overlap, and the angle of the collision if you're set up to calculate it). All of this is covered in the documentation, which can be found here: http://www.coreyoneil.com/Flash/CDK/documentation/ Some simple examples of checking for collisions and retrieving information about the collisions can be found in the docs here: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#Examples

  Status: Invalid

  Labels: Type-Other −Type-Defect

  You can check for collisions by calling the checkCollisions() method. If any collisions are occuring while you do the check, then it will return an array containing each collision (or an empty array if there are no collisions). Each array item is an Object which contains information about the collision (the two objects that collided, the amount of overlap, and the angle of the collision if you're set up to calculate it). All of this is covered in the documentation, which can be found here: http://www.coreyoneil.com/Flash/CDK/documentation/ Some simple examples of checking for collisions and retrieving information about the collisions can be found in the docs here: http://www.coreyoneil.com/Flash/CDK/documentation/CollisionList.html#Examples

  Status: Invalid

  Labels: Type-Other −Type-Defect
• May 09, 2009

  issue 5 (get collisions) reported by arkzai1   -   hello first of all great job with collision kit i love i really do. but i ran in some problems i cant figure out what objects collide. i trying to know when a collision happens and with what MovieClips. so the collided MovieClips will do something. basically how do know when a collision happens and what get collided. thanks u

  hello first of all great job with collision kit i love i really do. but i ran in some problems i cant figure out what objects collide. i trying to know when a collision happens and with what MovieClips. so the collided MovieClips will do something. basically how do know when a collision happens and what get collided. thanks u
• Mar 31, 2009

  issue 4 (Collision will not work correctly when having objects in a c...) Labels changed by lessthanthree   -   Yup, it doesn't account for transformations made to parents. When I get around to pushing out an update to the CDK, I'll be sure to include a routine to run through any/all parents and include their transformations prior to snagging the display objects for collision detection.

  Labels: Type-Enhancement −Type-Defect

  Yup, it doesn't account for transformations made to parents. When I get around to pushing out an update to the CDK, I'll be sure to include a routine to run through any/all parents and include their transformations prior to snagging the display objects for collision detection.

  Labels: Type-Enhancement −Type-Defect
• Mar 31, 2009

  issue 4 (Collision will not work correctly when having objects in a c...) reported by jorgen.bang   -   What steps will reproduce the problem? 1. Put your display objects in a container object. 2. Increase the scale (or size) of the container object. 3. Do collision detection on the objects in the container. What is the expected output? What do you see instead? The expected output is to see that the collision detection adapts to the rescaled sizes. Instead the collision works only on the checked objects original sizes, before rescaling. What version of the product are you using? On what operating system? Please provide any additional information below. attaching a sample file that shows how this behavior occurs. Grab any circle in the sample to rescale the container. Make them collide and observe that as they grow collision is not detected in the outer parts of the circle.

  What steps will reproduce the problem? 1. Put your display objects in a container object. 2. Increase the scale (or size) of the container object. 3. Do collision detection on the objects in the container. What is the expected output? What do you see instead? The expected output is to see that the collision detection adapts to the rescaled sizes. Instead the collision works only on the checked objects original sizes, before rescaling. What version of the product are you using? On what operating system? Please provide any additional information below. attaching a sample file that shows how this behavior occurs. Grab any circle in the sample to rescale the container. Make them collide and observe that as they grow collision is not detected in the outer parts of the circle.
• Mar 20, 2009

  issue 3 (Having a small issue with putting your test code in a Packag...) commented on by p...@pkhome.us   -   Ahhh yeah, very good explanation, thank you! I knew it was those 2 declarations, took a guess with the array... Thanks for the great code, works perfecty now!

  Ahhh yeah, very good explanation, thank you! I knew it was those 2 declarations, took a guess with the array... Thanks for the great code, works perfecty now!
• Mar 20, 2009

  issue 1 (Collision with Animations) changed by lessthanthree   -   Closing issue as it does not require a code change. If you'd like assistance with integrating the CDK in your project, just let me know!

  Status: Done

  Labels: Type-Task −Type-Defect

  Closing issue as it does not require a code change. If you'd like assistance with integrating the CDK in your project, just let me know!

  Status: Done

  Labels: Type-Task −Type-Defect
• Mar 20, 2009

  issue 2 (What if I use the collisionGroup into a Class that is loaded...) changed by lessthanthree   -   If you'd like assistance integrating the CDK into your project, just let me know. Closing this issue since it doesn't require a code change.

  Status: Done

  Labels: Type-Task −Type-Defect

  If you'd like assistance integrating the CDK into your project, just let me know. Closing this issue since it doesn't require a code change.

  Status: Done

  Labels: Type-Task −Type-Defect
• Mar 20, 2009

  issue 3 (Having a small issue with putting your test code in a Packag...) changed by lessthanthree   -   Yeah, it was just something small you were missing. The main issue you were having was properly scoping your variables. Both your messageBox and collisionGroup variables were being cast as Arrays on the class level (messageBox is a TextField, and collisionGroup is the class CollisionGroup). Properly casting them fixes part of the problem. The next issue was that you were declaring collisionGroup inside the constructor as a local variable (though doing it as CollisionGroup this time). Here's how the compiler sees all of that: - I have a variable called collisionGroup that's accessible throughout the class. It's an array. - I have a variable called collisionGroup that's a CollisionGroup. It's only accessible in the constructor. So when you run checkCollisions() in your mouse event handler, the only collisionGroup varaible it sees is the empty array you declared at the top. And since checkCollisions() is not a method of Array, you received that error. Here's an updated version of your file with the necessary corrections. Runs great now! :)

  Status: Done

  Labels: Type-Task −Type-Defect

  Yeah, it was just something small you were missing. The main issue you were having was properly scoping your variables. Both your messageBox and collisionGroup variables were being cast as Arrays on the class level (messageBox is a TextField, and collisionGroup is the class CollisionGroup). Properly casting them fixes part of the problem. The next issue was that you were declaring collisionGroup inside the constructor as a local variable (though doing it as CollisionGroup this time). Here's how the compiler sees all of that: - I have a variable called collisionGroup that's accessible throughout the class. It's an array. - I have a variable called collisionGroup that's a CollisionGroup. It's only accessible in the constructor. So when you run checkCollisions() in your mouse event handler, the only collisionGroup varaible it sees is the empty array you declared at the top. And since checkCollisions() is not a method of Array, you received that error. Here's an updated version of your file with the necessary corrections. Runs great now! :)

  Status: Done

  Labels: Type-Task −Type-Defect
• Mar 19, 2009

  issue 3 (Having a small issue with putting your test code in a Packag...) reported by p...@pkhome.us   -   What steps will reproduce the problem? 1. Put any of your test codes inside a package (CollisionList or CollisionGroup) and i get: TypeError: Error #1006: checkCollisions is not a function. at Main/checkForCollision() 2. If i declare the public var collisionGroup=new Array(); as public var collisionGroup:*; I get: TypeError: Error #1010: A term is undefined and has no properties. at Main/checkForCollision() so iam thinking that =new Array(); is correctly defined..or is it? 3. Code is attached hope you can help, iam hoping its me missing something small, BTW I did get it to work fine in timeline, and it's fantastic, used it in conjuction with FlintParticles and it detected each Pixel... NICE Hope i get it to work inside the package shortly... What am i missing here? If anything maybe you can supply a test file thats already in a package...

  What steps will reproduce the problem? 1. Put any of your test codes inside a package (CollisionList or CollisionGroup) and i get: TypeError: Error #1006: checkCollisions is not a function. at Main/checkForCollision() 2. If i declare the public var collisionGroup=new Array(); as public var collisionGroup:*; I get: TypeError: Error #1010: A term is undefined and has no properties. at Main/checkForCollision() so iam thinking that =new Array(); is correctly defined..or is it? 3. Code is attached hope you can help, iam hoping its me missing something small, BTW I did get it to work fine in timeline, and it's fantastic, used it in conjuction with FlintParticles and it detected each Pixel... NICE Hope i get it to work inside the package shortly... What am i missing here? If anything maybe you can supply a test file thats already in a package...
• Mar 16, 2009

  issue 2 (What if I use the collisionGroup into a Class that is loaded...) commented on by lessthanthree   -   As the error indicates, any items you add for collision detection have to be on the display list first; meaning you'd have to addChild() to the stage (or to some display object already on the stage) before you addItem() to your collision group.

  As the error indicates, any items you add for collision detection have to be on the display list first; meaning you'd have to addChild() to the stage (or to some display object already on the stage) before you addItem() to your collision group.
• Mar 15, 2009

  issue 2 (What if I use the collisionGroup into a Class that is loaded...) reported by office.romedia   -   What steps will reproduce the problem? I have a small game that is composed of : 1. first frame :preloader 2. second frame : a "var game:Game = new Game(); this.addChild(game);" code. And a game.as Class which extends Sprite. Inside the Class, I have a collisionGroup instance that should detect simple interaction. What is the expected output? What do you see instead? Once I want to add a sprite to the "collisionGroup", I get the following error : "Error: Cannot add item: [object HitMV] - Items added for collision detection must be on the display list. at coreyoneil.collision::CDK/addItem() at Game() at banner_fla::MainTimeline/frame2() " Basically, the "root" for my object is Null, instead of Main_Timeline. What should I do ? What version of the product are you using? On what operating system? Please provide any additional information below.

  What steps will reproduce the problem? I have a small game that is composed of : 1. first frame :preloader 2. second frame : a "var game:Game = new Game(); this.addChild(game);" code. And a game.as Class which extends Sprite. Inside the Class, I have a collisionGroup instance that should detect simple interaction. What is the expected output? What do you see instead? Once I want to add a sprite to the "collisionGroup", I get the following error : "Error: Cannot add item: [object HitMV] - Items added for collision detection must be on the display list. at coreyoneil.collision::CDK/addItem() at Game() at banner_fla::MainTimeline/frame2() " Basically, the "root" for my object is Null, instead of Main_Timeline. What should I do ? What version of the product are you using? On what operating system? Please provide any additional information below.
• Mar 13, 2009

  issue 1 (Collision with Animations) commented on by lessthanthree   -   Hard to say what's causing your problem without looking at your code. Since your body MC is able to detect collisions, I'd assume there's an issue with how you're accessing your head MC. I'd be happy to take a look at it for you if you can upload the FLA and any additional assets for it. Alternatively, you can e-mail me the file(s) to lessthanthree[at]gmail.com

  Hard to say what's causing your problem without looking at your code. Since your body MC is able to detect collisions, I'd assume there's an issue with how you're accessing your head MC. I'd be happy to take a look at it for you if you can upload the FLA and any additional assets for it. Alternatively, you can e-mail me the file(s) to lessthanthree[at]gmail.com