2D has certainly the priority, but actually the possibility of just having a 3D sprite with simple 2D collisions would be AWESOME.

I agree this would be pretty sweet if Construct had the ability to do this somewhere down the line.

If I could ever make something like this with Construct, my head would probably explode:

Not necessarily... array paste needs info entered into a dialog. Flood fill would work on a single click. Also, array paste is limited to rectilinear areas. If implemented properly flood fill would fill an irregular area of grid spaces.

It might not be totally necessary to have a flood fill, but would be a little different.

Flood fill would be nice too. Actually, the more tools the better, but Paint Brush and flood fill is probably the most needed. Being able to resize the brush would be nice too.

Are we still talking about a tile-editor interface? Because I was under the impression that it would simply be a "click in or drag across gridspace to place tiles" type of thing, so brush size wouldn't really matter...

Flood fill makes sense, though.

Okay, okay. Sorry, Ashley. It's just... well, I did have this long and detailed explanation on the implementation and benefits of using surrogate collision detectors, outlining the whys and wherefores thereof, and I... um...

It all boiled down to this one image:

<img src="http://xs223.xs.to/xs223/08036/wtf118.jpg">

*sigh* <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

I hope it's not Chris's blood...

Is this... blood?

As my game grows, so does the clutter in the event sheet editor dialogs. I have to sift through dozens of useless Tiled Background objects that I don't need to perform actions on because they're just decorative. I'd like to request a way to exclude them from the dialog so that I just see the objects I'm concerned with. Would it be possible to add a new property to each object's Common properties to take care of this? Something like "Include in events" with the default being a checkmark or a "Yes." Something toggle-able, in case I want to go back later and include that object for event editing.

Note that I don't want to make them hide in events already created, just the object picker.

A tile editor doesn't have the same global use as other tools in Construct. Since many people are making non-tiled games, having a tile editor wouldn't be justified 100% of the time, especially considering the amount of work that would go into it.

I agree that a "Tile Blitter" object like the one nobuyuki described is a better idea, but there's just one problem... which tile map format would you choose to work with? As soon as you decide on this, you'd have people screaming at your for that or the other.

Currently in the klik community people who have need of tile editors write their own custom ones for their games. I suppose it would be possible to make a generic one that would work in conjunction with a Tile Blitter object, but it would take a lot of work to get enough features into it to satisfy people using it. Perhaps some enterprising samaritan would be interested in tackling that...?

There was a POST here. It's gone now.

Yep, I thought that was coming next.

You will need detectors. Make a plain sprite a few pixels tall, and as wide as your sprite. Set it just underneath your sprite, like so:

<img src="http://xs223.xs.to/xs223/08036/detector600.png">

Now make your detector invisible, and update it's position to your player's feet each cycle. That way you have a new condition you can work with:

"footDetector overlaps groundSprite" and

"NOT footDetector overlaps groundSprite"

I'm sure you can see the usefulness of this <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink" />

Heya, Casho my boy. I feel sorry for ya, kid. Nobody seems to want to help you out. Well, me and Johnny.jpg got yer back.

Check it, yo:

<img src="http://xs223.xs.to/xs223/08035/johnnyrunning929.gif">

How To Run, starring Johnny.jpg:

http://www.mediafire.com/?bhexmhksmxh

See Johnny. See Johnny run. Run, Johnny, run! But how does Johnny run? We put the default Platform movement on him, but it's not enough. He just sorta slides back and forth. So we make a new animation for him called "Running" and fill it with some running frames. Check it out in the Animator Bar.

But there's a problem... he doesn't know how to move his feet when he runs! Johnny's not too bright. We have to tell him when to move his feet, like so:

<img src="http://xs123.xs.to/xs123/08035/howtorun1158.jpg">

Event 1 triggers when you have the right key down. It tells Johnny to which angle to face, and to switch to his Running animation. But we don't want any interference from the left control key, so we put in an inverted trigger for "Move Left is down." We also only want Johnny to face the angle and switch to his animation only once when we push right, so we add the System trigger "Trigger once." This keeps him from setting his animation to Running every cycle (which means you would only ever see the first frame of the animation).

Next, we set it up so that when there are no movement controls pressed, Johnny goes back to standing still:

<img src="http://xs223.xs.to/xs223/08035/howtorun2129.jpg">

Easy enough. At this point though, you may be wondering why we're using "Control is down" and "Trigger once" instead of just "On control pressed." Basically, it's because game players are sloppy! They mash the keys around when they're playing, so sometimes both left and right is pressed at the same time. This causes problems, like having poor Johnny go moonwalking around the screen. To compensate for this we put in the inverted controls to keep actions from happening on sloppy key presses, like so:

RIGHT DOWN, LEFT NOT DOWN - Run right

LEFT DOWN, RIGHT NOT DOWN - Run left

RIGHT NOT DOWN, LEFT NOT DOWN - Stop running

But there's one key combo left that we have to compensate for to refine our controls:

RIGHT DOWN, LEFT DOWN - Stop running

But the way the default Platform movement is set up, it's a bit tricky to do this. When you have both keys down, Johnny still wants to run in whatever direction you pressed last. You could conceivably do this:

<img src="http://xs123.xs.to/xs123/08035/howtorun3763.jpg">

BUT this leads to problems. The Platform -> Stop action stops all movement, including jumping, and even falling! Yikes! We need something that will make a smooth transition from pressing left and right that won't make Johnny grind to a halt every time the player mashes both control keys. A better way would be like so:

<img src="http://xs123.xs.to/xs123/08035/howtorun4632.jpg">

Now, this might seem a little weird at first, but trust me... it works pretty well. We want Johnny to ease to a stop (or into a quick turnaround) with momentum instead of grinding to an immediate halt. So we set the Platform movement to ignore user input when both left and right are pressed. Since this only happens very briefly when someone is playing a game, the transition from right to left movement is pretty seamless.

So, what's the event right above that for? Well, if you tell Construct to start ignoring user input, then whenever someone presses both keys down Johnny will become unresponsive. We add that event to bring input back each cycle. We're using two events to serve one purpose.

So, why don't we just set up an Else event right after checking for both keys down, instead of putting the "johnnySprite -> Platform -> Is moving" event in? Well, I tried that and it didn't work, that's why. He slid around like he was on ice when I did it that way. I don't know why. All I know is that this way it works, and the Else event didn't.

Also, this isn't necessarily the best way to do this. This method of restricting controls could be a little buggy down the line if you wanted to add more complex controls. It's just to give you an idea of how you can customize the default Platform movement to suit your needs. Once you get this down I'm sure you can come up with your own method of doing things.

Anyway, I hope this helps.

P.S. -

Don't steal my tiles, or Johnny will bust your ass.

Short answer: Yes, you can rotate it.

Long answer: If you want to do isometric stuff, the 3D Box isn't going to help you. The 3D Box will always be in perspective relative to the viewport regardless of it's rotation. This means that you can change the yaw of the box to 45 degrees, but you will still be able to see under it if it scrolls towards the top of the screen, or the left side of it if it scrolls to the right side of the screen. Also, the box itself doesn't collide with the faces of the render, but rather a 2D mask created by the back face texture that is always oriented toward the viewport.

Still, you can rotate the box however you like. In the Event Sheet editor, select one of the following actions:

New Action -> 3DBox -> Set yaw

New Action -> 3DBox -> Set pitch

New Action -> 3DBox -> Set roll

Each of the settings takes a positive or negative floating-point value in degrees.

The 3D Box object isn't so much a feature as it is a proof-of-concept. It does have it's uses, but they are rather limited. Mainly it's there just to show that it is possible to integrate 3D into Construct. If I remember correctly, there are plans to eventually add more 3D support for Construct, but not until after v1.0.