An issue here, for example, is the need to alter the timing on a frame by frame basis. I could, say, make a string variable for each animation that stores the right information and then play it off.I know I can do it, but it'd be nice if I didn't have to make all these alternatives to features already in construct.

I don't mean to sound flamey here, and I definitely don't mean any disrespect... but if you can do it, then why don't you? Ashley has stated his case for why Construct is made the way it is. You're asking for a rather fundamental change to Construct's engine, and all for a problem that's very specific to what you need done (and no one else).

The level of precision that you're seeking is something that I think only God and a handful of fighting game enthusiasts who can think between animation frames would appreciate. The kind of players like my ex-roommate Karl who own their own fighting game stick and carry it with them on the bus to the arcade to practice for tournaments. Not that there's anything wrong with that... he was really friggin good.

Anyway, my point is this: If one is seeking a change to the way Construct works, and one is in the minority of users who need this change, and this change can be accomplished with events, then the logical answer is to just make it with events.

Such is the burden of specialization. It takes more work, and fewer people appreciate it.

No prob. By the way, the project is looking pretty sweet. I can't wait to play it

If you're really that hard set on tick-based animation, there's nothing stopping you from doing it.

Set your animations to no loop, and 0 frames per second. That way they won't auto-play on their own.

Then make a custom tick-based animation routine of your own, manually setting the animation frame when you need it. I can't imagine this would take more than a handful of events.

Update:

Oh I get it. Writing float from Layout editor is impossible on my machine, but passing float numbers in Events works fine. Thanks Deadeye ^^.

Well I guess that's good news and bad news, you should be able to enter decimal values in the layout editor as well. I wonder what's causing that to not work on your machine At least it works in events.

Yep, as I thought, it was a Trigger Once issue. I ran into the exact same problem when I did my animation routines. Here's the fix:

<img src="http://i38.tinypic.com/2jg494i.png">

Works fine this way, without having to set the jump animation to loop.

Not a bad demo, and I agree it is faster. Looks pretty slick. There seems to be some zsorting issues for some of the sides here and there (bottoms showing up above sides) but I'm sure that can be tweaked.

But this:

-> more control of depth (3dBox don't accept float numbers for depth)

Is just plain wrong. I'm able to put any decimal number I want into the depth, either in the IDE or at runtime.

To clarify. Whenever I use an animation that does not have looping and that animation has played through, all the other looping animations only play the 1st frame of their animation.

Ah, I see. I myself am unable to recreate this problem so I suspect it's an issue with your code. If you'd like to post the .cap I can take a look at it.

I've read and re-read your post and I'm afraid I still don't understand it. It's worded a little confusingly.

Are you saying that when you jump, your animations stop looping/playing?

The only thing I can think of off the top of my head without a better explanation is you might be setting your animations to frame 1 every cycle. Add a "Trigger once while true" condition to your set animation frame/play animation actions.

If that has nothing to do with your problem, could you explain what's happening in better detail?

Nice engine. Runs pretty smooth. I hate pressing up to jump though, but it's an easy enough fix.

Might I suggest a running attack? One that won't stop your momentum.

Also, I get tearing on your background tiles with a fixed frame rate. When I turn V-Sync on it looks much nicer.

I don't understand what you mean by "normal."

Try this method:

http://www.mediafire.com/download.php?vbx5byvuptd

It draws the boxes just fine, and they fall just fine. Buuuuut... there seems to be a problem with the collision mask in the physics object setting properly when the object is created, so the collision is wrong. It's a bug, needs to be addressed.

Edit:

Also, there doesn't seem to be any way of setting the hotspot of the box object, so I'd suggest using sprites, and set the hotspot in the corner so drawing looks normal. Otherwise, the point of the mouse cursor isn't lined up with the corner of the box during drawing.

Edit 2:

Also, if you draw "backwards" (that is, from right to left instead of left to right) then the box glitches out. You might want to add some events that keep the box from being drawn if the user is trying to draw right to left. A simple mousex compare should do the trick.

Edit 3:

Hmm, seems that the box also glitches out when trying to draw down to up as well, so a mousey restraint should also be put into place. Basically you'd want people to only be able to draw from the top left corner to the bottom right corner.

Alternately, I suppose you could just figure out some way of rotating the physics box when it's created so that it lines up with the drawing box. That way the player could draw it any which way they wanted.

World domination implies that there will be some sort of profit. Not that you'll see any of it when the new world order is established... You'll just be another slave in the sprite mines. Or if you're lucky, an event code harvester. At least then you get to see the sun.