Great, I fail to do the timer settings, because all the tanks rotate at the same time. I know it has something to do with the "Turn" Private variable. The link to the cap is still the same.

Your event is picking all of the Tank instances. If you want each on it's own timer, then you should give each it's own timer.

Make a "myTimer" private variable. On start of layout, do "For Each tank -> Set 'myTimer' to random(however long)."

Then in the main movement loop do "For Each tank -> subract from 'myTimer' whatever amount." Then when the tank's timer is less or equal to zero, give the turn command and generate a new random amount for their timer.

Game art as it relates to Construct (such as how to import and best optimization practices, etc.) or art in general?

It would help if we knew the method you're using to move your enemies. Perhaps you could post a .cap?

It's not "wrong" if you want the last sound to finish before stopping

And if you do want it to finish immediately upon releasing the mouse button, then just take the condition out entirely. Like I said before.

Show Object Tree is an unfinished feature.

As for getting the object window back... yeah there should be a button or menu item for that

Yes, for important sounds that you want more control over it's a good idea to load them in a channel. And it's also a good idea to reserve that channel so no other autoplayed sounds will choose it and interrupt your stuff.

Fiddling with the picture editor to align frames and hitboxes is a pain as is (you can't see the hitbox during the runtime etc.)

Ah, another good point . Didn't even think of that.

This will loop your sound while you hold down the mouse button:

<img src="http://i46.tinypic.com/4uuf13.png">

The "NOT Channel 1 is playing" condition in event 3 will stop playing the channel after the current sound is finished. If you want it to stop immediately upon releasing the mouse button, you can just take that condition out.

This looks really nice and I'm very tempted to try helping out. But I don't really have much faith in my isometric coding abilities I'm afraid . I wish you luck though. And with awesome artwork like that I'm sure you'll find someone to help with the coding pretty easily.

You could do all that with ... spawning invisible collision sprites and such.

Hmmm......

[quote:1e6o0ltj]Now, to get that accurate, you have to use an image point or create a sprite for each part of his body or an invisible collision sprite for each part of his body. All of these things feel like work-arounds to me.

It's not really a workaround but yes I can see how juggling many collision boxes could be a lot of work.

Let's just look at the alternatives for a moment. If multiple collision masks were introduced as a feature, how would they be implemented? You would still have to draw the box, if not a full-on mask. You would have to make sure they were aligned properly on each frame somehow. If you look at the current state of sprite collision masks this can be a bit of a chore as it is! Let alone the fact that moving a sprite's mask away from the hotspot causes misaligned collisions.

But let's just say you could move a mask around wherever you wanted. You would have to go through frame by frame in your animation and line each mask up in it's proper spot. Either that or set hotspots and tell Construct to line them up at runtime. So... it's not going to really be a whole lot different to set up than the methods you would currently use, the only difference is that the hitboxes are built in to the sprite instead of being separate objects.

It seems to me like a feature that not very many people would be using all that often. Sure, some people would find it useful on occasion, but for the most part people really only need one hitbox for their sprites. I don't see that changing the fundamental way that sprites and other objects collide and coding in extra editors and whatnot into the IDE would be justified by just a few people needing it on rare occasions.

Of course, in this day and age of plentiful plugins, someone might be able to make a Hitbox Object that you can attach to another object, that manages however many collision boxes you need all in one package. I think that would probably be the best solution, if you can find someone to code such a plugin for you. Otherwise using invisible detectors isn't really a bad thing. It's something that's done a lot in gaming.

Done. Looks like it was a blanket ban for 64.131.*.*

There were no notes on the ban so I hope removing it doesn't mean we're looking at a spambot invasion

If you're swinging a sword in an arc, how about you make a pie-shaped detector like so:

<img src="http://i46.tinypic.com/hvrxmv.png">

Leave it there for the duration of the sword swing animation and check collision against that.