Construct supports alpha transparency automatically. You don't have to define a color as the transparent color for your sprite... just create your sprites with alpha to begin with.

Or go through the image editor and delete the background to all of your frames.

The sprite image importer seems to have a feature that handles the color mask for you, but I don't believe it's been implemented yet. Either that or is just isn't working.

Yum yummy, I love Alien Artichokes.

There are problems with both offset and invisible detectors in this case... using offset would require several conditions to check all sides of the ball, which means extra code.

And using an offset in that manner, as well as using a detector sprite, would mean that the detection area could overlap more than one brick at once, thus destroying two bricks with one hit, which would look strange.

I agree that each movement-type behavior that interacts with solids should have some sort of collision condition built into it that you could use instead of the regular "On collision" condition. Either that, or be able to utilize the regular "On collision" somehow.

The method I posted before doesn't seem to work the way I thought it would.

This, on the other hand, works like a charm:

<img src="http://i40.tinypic.com/2gy366s.png">

And it's the simplest method I could come up with. Setting it to fall when Jump is pressed won't mess things up when you're jumping without holding down because it processes the jump before the fall, it seems.

By the way, David... the Yes and No seem to be reversed in the "Fall through platforms" dropdown (which means that in event 3 you're actually telling Construct to fall, and in event 2 you're telling it not to)

I think that's just an optical illusion caused by the change in direction. His rate of movement along the X axis stays constant. As a test, focus instead on the background parallax layer and you will see that it scrolls along at a steady rate.

You could alter his speed in the Slopes event sheet if you wanted to slow him down on on the slopes though.

I still use Photoshop 7, so I got the scripting plugin off the Adobe site:

http://www.adobe.com/support/downloads/ ... ftpID=1536

And here's where I got my layers-to-png script:

http://www.kirupa.com/motiongraphics/scripting6_2.htm

And I think scripting is in CS by default... not sure though.

You can already do a batch import. Under the "Import Frames" dialog, just select all of your frames and hit open. It will automatically import all of them as seperate frames to add.

...what? <img src="http://www.b3tards.com/u/2951c544e5d930f23b20/emot-doh.gif">

That's my second "Doh!" moment today. I'm on a roll.

> off topic, but how did you manage to put an expression into the 'set color filter' action? it defaults to a colorpicker ...

>

After you've chosen "Set colour filter" as the action, right click where it says "Filter", and you can choose to use an expression from the menu that appears.

Right click? <img src="http://www.b3tards.com/u/2951c544e5d930f23b20/emot-doh.gif">

So that's how you do it. I was having trouble with that the other day.

You could lay your sprites out evenly on a single sheet, and use the importer to automatically cut them into separate frames.

Also, if it's exporting layers to files that you're worried about, I know Photoshop has scripts available that do that. I have one that exports each layer to a .png, numbers them, and sticks them all in a new folder. I'd go crazy without it.

But I think some sort of "batch import" for Construct would be handy... like if your files are numbered in sequence, you could select them and tick an "import sequence to frames" box or something. That would be quite useful, at least for me.

If the bricks and bat are set to Solid, then the ball won't be able to overlap them. They're solid, so it can't move into the same space as them to cause an overlap. That's just how the Ball behavior works... it's doing it's own collision routines before your events run.

"On collision" sounds like it should work, logically speaking, but actually a collision is basically the same as "Is overlapping + Trigger once." (Though I seem to recall something a while back about some behavior or another having a fix for that so "On collision" worked... I thought it was Ball, maybe it was something else)

You might want to check out Midnight's Busta Ball example on the wiki to see how he did it. I haven't looked at the .cap myself.

http://apps.sourceforge.net/mediawiki/c ... =Tutorials

What if I just set the player's jump strength to 0 while ducking? I think that just might work. I'll try it out.

I'm not on my Construct computer right now, so I can't test it out, but if that doesn't work, you could try something like:

(at the top of your control events)
+Always
  ->playerSprite[Platform]: Don't ignore input

+On control "Jump" pressed
+Control "Move down" is down
+playerSprite is overlapping Platform at offset (0,2)
  ->playerSprite[Platform]: Ignore input
  ->playerSprite[Platform]: Fall through platform
[/code:239o6kfp]

That way it will ignore the controls for a single tick so you won't jump, then reactivate the controls at the start of the next tick.  I did something similar for the fall-through platforms in Little Hitler in Toyland, but I can't remember the exact method.  I'll look it up as soon as I can get at Construct.