Another alternative to a function is to use the system condition "pick all". So your event could look like this:

spriteShot: On Colision with spriteEnemy

system: pick all spriteEnemy

---> spriteEnemy Destroy

You know, you'd think I notice something that obvious. If you aren't interested in re-use, that's definitely the most direct method, and less error prone (you can't misspell it) <img src="smileys/smiley1.gif" border="0" align="middle" />

Ah, found the problem.

Here it is fixed, and annotated in the comments

db.tt/FYRfoCZ9

See what was happening was you were setting the player position right before you pinned your animations to the player. But you had your pin set to remember the position relative to the object. This meant that your objects were very far apart, and as the player moved and rotated your player sprite went all over the place.

So I set them to be at the same position, then pinned. Problem solved.

Note that it LOOKS a little funny in the player, because it will look like there are times when your player and animations don't match. However, that is a visual only bug, due to the way you have the bullet. Because you are setting the angle of the bullet, it is setting the angle of the sprite.   If you look, they always have the same position, the player sprite is just rotating around the upperleft corner, causing it to appear out of alignment when walking anything other than right. If you run it through the debugger, you can see they actually are at the same position. Just don't use that player for collision, and you'll be okay.

If you do want to use the player for collision, I would recommend using Lerp and doing an actual linear interpolation (keep track of the move timer yourself and update it every frame, don't feed the position back into the Lerp, that performs asymptotic movement.

Hmmm... good point about families. If you're looking to "depick" you can use the trick I posted on the other topic.

scirra.com/forum/destroy-sprites_topic79122.html

I would use a function. If you have a DestroyAllEnemy routine, you can call it, which will operate without the have a sprite picked.

Then you can just CallFunction from your On Collision event. Plus, it's reusable.

Here, here's a simple example:

db.tt/3pxTNdBM

Just gave it a try.

Turns out, the setting sticks, no need to do it every tick. On object created/layout loaded, etc works just fine!

Cheers and thanks!

~Complete CSS NOOOOB

tumira

If it supports .Net4.0, I would expect it to be based on C# 4.0, and support LINQ.

Yeah, I need LINQ if I'm in C#, I live and breathe Reactive Extensions.

I have to laugh, though. I've used the docking architecture before, and contributed to it somewhat <img src="smileys/smiley1.gif" border="0" align="middle" /> (well, a derivative of it, since WeifenLuo stopped updating it.

Then we moved to WPF and redid the user interface, but hey!

Thanks for the heads up!

*Edit* Something screams out as very wrong when you are better off downloading from the forums than the main page.

The simplist way is to use an image button, instead of a regular button.

scirra.com/forum/plugin-image-button_topic51829.html

However, one other option is the "Set CSS" under appearance, since the text is rendered HTML5. You can use all of the properties here:

w3schools.com/css/css_text.asp

PixelHero why bother to get 2 extension such as playmaker and uScript?

Well, if we're talking about the capabilities of Construct 2, event sheets and visual scripting of actions come to mind. You don't need them in Unity, no, but it at least comes close to some of the main features of Construct 2 (other than the built in 2D, of course). I was trying to convey that you could replicate some of the main features that set Construct 2 apart from other 2D engines for the same price as buying Construct 2.

*shrug* Not trying to recommend or tell people what to buy.

Honestly, I hope they never finish C2 (although they need an additional revenue stream from us, to be honest).

There are some great 3D platforms out there. $100 on the Unity store will get you a great state machine (playmaker) AND a visual scripting platform (UScript) that replicates a lot of what C2 offers, and throws in a state machine on top that is really quite powerful and has built in handling of 3D object actions.

For me personally, I prefer Construct remain 2D. I want to make awesome 2D games. Yeah, some of that comes from my complete failure to ever understand how to texture, bump, specular, diffuse, normal 3D objects that I'm pretty terrible at making anyway.

But that doesn't change that C2 fills a niche, and fills it well, in my opinion. And it just so happens that right now, that niche is what I want to develop towards.

If Construct went 3D, I just feel like it would get drowned out by some of the big names.   There is simplicity in 2D, and Construct aims to make game development simple. Maybe not easy, but simple.    <img src="smileys/smiley1.gif" border="0" align="middle" />

I use C2 because I actually really have a shot of finishing my games.

I don't really get why, but I don't mind it really. I'm a C# developer and there are times where I REALLY miss the multiple interfaces, reactive extensions, object references...

And not one of those that I've worked on with any other platform has progressed beyond " a few things on screen and lots of data classes". I had one in XNA I finished, but that's dead now... I've used Unity, I have lots of assets, but I never really get in more than those first few days where you have a cool idea and work feverishly on it.

I don't really know why, but I find C2 fun to use. So I'm coming from the opposite end. I'm a professional developer, that's worked with platforms like Unity... and I'm going a new direction with C2.

I'm not saying you're wrong, not at all. Every tool has its strengths and there are many things that C2 isn't really good at. But I'm loving C2, and I hope that never changes.   <img src="smileys/smiley1.gif" border="0" align="middle" />

Hmmm...Yeah, I was assuming a return to idle before going in the opposite direction (no button press), but there's not necessarily anything in the code to cause that, and it would be bad to assume.

Wouldn't the same thing happen with yours C-7?

If W is down set animation to north

--subevent: if a, set animation to north,

--if d, north

--if s, south.

...

If S is down set animation to south

--subevent: if a, set animation to south,

--if d, south

--if s, north.

then the animation is the north animation, regardless of which key was pressed first.

I think I'm missing something.   <img src="smileys/smiley1.gif" border="0" align="middle" />

taborgreat, that's probably because of the order of your events. If you reorder them, do you get an issue with a different direction?

If I understand correctly, I would add an instance variable to the player that indicates the player is moving. Then when a button is pressed, check to see if the player is already moving. If they aren't, set your animation going and set the moving variable

On future button presses, they check to see if moving, and the player is already moving so they skip the animation and press on. You character still moves in the correct directions, but you only set the animation to play if no movement key was being held down prior to the button press.

That should prevent animations from overriding each other, which is what I suspect is happening here. What you have described is "undefined" behavior, meaning the exact outcome depends on which order you test the movement keys determines the final, actual, animation.

At least I think. If what I'm saying doesn't make sense, can you post a .capx? We'll be happy to take a look at it (I wouldn't imagine it would be hard to make a new project, copy the player and the movement key events).

Hope it helps!