Read up on the bullet behavior. It has a "Set Angle" property that causes it to sync the bullet angle with the sprite angle.

Also, you might want to have a look at Kyatric's HOW DO I FAQ, which is stickied at the top of this forum. It discusses how to set conditions to detect distance.

It sounds like perhaps these obects are on layers with different layer parallax? I know that in my inventory system, Items move between my UI layer and my Game layer, and I have to keep adding and subtracting the viewport coordinates for every transition.

I would also be interested in multiple frames on a 9patch, even if its not as efficient as changing frames on a sprite. Sorry for necromancy, but I thought it might be better than making a new thread.

I recently had a problem with a tileable fog I made in gimp at 1024x1024. Theres no need for HD fog, so I scaled it down after importing it. It took me a couple of tries to realize that the odd bar wasn't coming from the spritesheet, it was coming from the scaling that was used. I went back and scaled it down in GIMP and it was fine.

Problem Description

When I have global sprites on a global layer, travelling between layouts duplicates the sprites and destroys any information they contain.

Description of Capx

There are 4 global square sprites on the top layer. You can click on them to make them change color and increment their instance variable. There is a button on the main layer that takes you to the other layout. Note that when the button is pressed, the layout changes, but the squares

Steps to Reproduce Bug

• Start the project in debug mode.
• Click the little squares to make them change color.
• Click the button to change layouts Observed Result
• Notice that all the squares, which are global, have reverted to thier initial state of being green.
• Notice that the Instance variable, which has been counting clicks, has reverted to 0
• Notice that there are now 8 squares instead of 4, and that each pair has duplicate UID

Expected Result

I am expecting each UI element to be created if it doesn't already exist. If it does already exist, I expect it to keep it's state and instance data.

I was expecting each of the 4 little squares to retain it's color and instance variable as the layout changes.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Windows 7, SP1

Construct 2 Version ID

Release 198, 64 bit.

1. omg I can't believe I missed that.....

2. That's what I was doing. I'm kinda tempted to create a custom behavior that uses runtime.testOverlapSolid(), but I'll leave it for now, unless it becomes a serious pain.

I have an "Attack" object that represents a sword swing, and I spawn it and use it to detect when you hit something with your weapon. I figured every melee weapon is more or less the same, so they all use the same object. Each weapon should look different, so that sprite has like a dozen animations. I've been using the animation: OnFinished trigger to destroy the attack, but it seems to require the name of the animation, and I have bunch of animations that all do the same thing. Can I perhaps use a wildcard?

My other question was about collisions. I was wondering if there is a way to detect collisions with solid objects, even without picking the collided object? There are the overlapping and overlapping at offset conditions, but they require a specific object or family. Can I use these conditions with "any solid"?

An artistic suggestion rather than a technical one: Give the individual asteroids on a layer a small proper motion relative to the layer, that way it makes it harder for the human visual cortex to see the individual layer moving as a unit.

Have you tried turning off collisions?

omg you have as much useful stuff as native C2.

Was it efficient to have 15 different layers? I imagine it was more efficient than individual asteroids, and 15 layers is the method I would try. For each asteroid, you want to generate an x, a y and a z from 1 to 15. You can give the layers numbered names so that you can pick them easily. It seems you are up against the limits of the engine and your hardware. I would suggest taking a step back, and looking at other ways to create the same impression for the player. It is only the background after all.

If you switch to using the Physics behavior, it will allow you to set the collision mask to a circle. Also consider that Physics may give you more control and make your bouncing balls more interesting.

Seems like we ought to be able to get collision points using a trigger condition, instead of crazy workarounds. It also seems like we should have some kind of raycasting collision testing. It can't be that much harder to test a ray against a polygon than it is to test two polygons.

Maybe it's time for someone to read the source and add a line to the physics behavior so that it triggers a condition when it computes a collision, then stores coordinates of the collision.