Two sprites dissapearing after collision

[Ronan]

I'm trying to make two sprites collide (bullet and an enemy) and both disappear after the collision. The only problem is that only one disappears while the other remains. I'm using the TestCollisionMask with a parameter method. It's worked fine expect for that issue. It seems that the collisions don't get triggered at the same time, causing only one to disappear.

I'll go into more detail later if more is needed, as I'm busy right now.

Any help or different methods appreciated!

Thank you.

[bluemonkmn]

As soon as one sprite disappears, the collision is no longer occurring, so if you have rules in each sprite to check for collisions, only one will see the collision if the first one is eliminating itself when it sees the collision.  What should be happening is something like this in the rules for the bullet sprite:
TestCollisionMask: Targets=ParentLayer.m_SpriteCategories.Enemies; Output to = TempNum
If TempNum > 0
   SelectTargetSprite: Sprites=ParentLayer.m_SpriteCategories.Enemies; Index=TempNum
   SetTargetParameter: ParameterName = "Hit" (including quotes); Value=1
   Deactivate
End If

If you set up rules like that, make sure that you have a parameter named "Hit" on every sprite in the Enemies category.  Then instead of using TestCollisionMask in the enemy sprite rules, you can just check if the Hit parameter is > 0.  If so, de-activate the enemy.

[Ronan]

Thanks! Worked perfectly. Just a question, why did I have to add the qoutations for hit? Just wondering.

Now I can finally proceed in my game 

[bluemonkmn]

If your question is, "How do I know when to put quotes on a parameter?" then the answer is this: if you look in the online help (look in the index) for "SetTargetParameter" you'll see that the type of the first parameter is "string".  That means you have to provide a quoted value (or a variable that refers to a string, but I don't think there are any of those).

To explain why is a little harder.  Perhaps a series of facts which you can assemble into a sensible answer to your question:

1) All the rules are converted into C# source code when your project is compiled
2) C# is a "strongly typed" language, which means that you can't directly refer to arbitrary objects and properties that are not known at compile time.  For example, I can't refer to the MyObject.x (the x property of MyObject) unless I first force the compiler to see MyObject as a Sprite (and the compiler knows that all objects of type Sprite have property x).
3) Each sprite definition corresponds to a specific "type" of sprite, and the parameters correspond to properties of that type of sprite (that only exist for that sub-type).
4) The environment does not know the specific type of an arbitrary sprite you have found with a function like TestCollisionMask, only that it's some form of sprite.  So it can't directly access any properties except those that are defined for all sprites.
5) I can, however, indirectly refer to such properties if I take the more round-about method of providing the property name as a string (I won't bore you with the details of that).
6) Literal string values must be contained in quotes in C# (and most other languages for that matter).
7) Because parameters provided in the rule editor can represent strings or other values, you must distinguish which parameters are strings by enclosing them in quotes yourself (the IDE can't infer when you want a parameter to be a string).

So to sum it up, the final code will do something like this, in plain English:
"Hey .NET, I have a sprite object, can you give me a tool I can use to access a property named 'Hit' on it for sprites that have a property by that name?  Cool, thanks.  Now use that tool to change the value of that parameter on this sprite I just found to 1."

That's not entirely accurate, but maybe close enough without having to write a semester's worth of object oriented programming theory .

[Jam0864]

So to sum it up, the final code will do something like this, in plain English:
"Hey .NET, I have a sprite object, can you give me a tool I can use to access a property named 'Hit' on it for sprites that have a property by that name?  Cool, thanks.  Now use that tool to change the value of that parameter on this sprite I just found to 1."

wouldnt it be great if u could talk to a computer, as if it were a person, and it did what you said...

[bluemonkmn]

AI has been very slow in developing, but with the pace that technology is advancing today, you can sure expect to see some amazing things in your lifetime, whether it's AI-related or not.  I expect you'll be able to do something similar at some point.  The power of modern programming environments today is amazing compared to what it was 10 years ago.  Programming is almost as fun as playing games, which is why I don't mind developing ERP (Enterprise Resource Planning) software as my day job (even though it seems like a boring kind of software to develop compared to games) ... 'cuz working with .NET is so much fun.  What will programming look like in another decade?  If things continue at the current rate, it's not long (definitely within our lifespan) before man-made computing capacity exceeds that of the human mind.  It'll be interesting to see what happens then.