I’ve been experiencing this issue for a while and always found a way to work around it, but am finally taking the time to dive in more to find out why this issue occurs.
I have a function that creates duplicate enemies and scatters them throughout my map. The same function can replicate multiple enemies of the same sprite “kind” but with different names. In the game when my sprites projectile overlaps the enemy the enemy is destroyed, but the reward differs depending on the enemy name. But, this is easier described than coded. In the example below the blue sprite can only destroy one of the red or orange sprites and not all. Why?
If I use the arcade sprite data extension I can create a field called “id” and compare the “othersprite’s” id in the overlap and achieve the desired result.
Is there a way to accomplish what I want without using the arcade sprite data extension? Why can’t I compare duplicate sprites names against “othersprite”? My guess is behind the scenes the sprite variable name has some number or data appended which I don’t directly see in the blocks. In debug mode the sprites have different IDs so I’m guessing the duplicate named sprites are probably named orange.1 or orange.9.
This is my guess too. But why don’t you want to use the sprite data extension?
Seems like there is an issue with my original “duplicateOverlapWithID” link. Here’s a corrected one:
I don’t mind using the extension, but if there is another way to accomplish the same thing without the extension then I’d be curious to know what it is.
The ‘sprite’ of kind player is always going to overlap ‘otherSprite’ if all the kinds are of same type Enemy. If you don’t want to use the sprite data extension, just create new kinds.
This does mean that you need to create multiple overlap events for each kind. Otherwise, if you don’t want to do that, then what you are doing now is fine. When using this extension I prefer to define the ‘data’ identifiers in variables, that way I don’t have repeat the identifier in multiple locations.
There is another extension that allows you to build up multiple properties, and store more types than what the sprite data extension offers, and then assign that to a sprite; it is called ‘settings-blocks’.
I was mistaken, the extension I was referring to is not an official extension (but user created), and it is found here: https://github.com/microsoft/arcade-block-objects
@UnsignedArduino kindly created another GitHub repository detailing various useful extensions and tools. You can find it here: https://github.com/UnsignedArduino/Awesome-Arcade-Extensions
I think you misunderstood my post. It’s not the overlap in question, it’s the evaluation of ‘othersprite’ against the variable name. The duplicative sprites have the same variable name, but when you run a simple if-else statement comparing othersprite against the variable name it does not evaluate to True.
My suspicion is that the variable name actually has some appended qualifier behind the scenes that isn’t viewable at the block level.
If I knew how it was modified then I could take that into consideration when evaluating the condition.
It sounds like you’re thinking of variable names as a property of the sprite, though, which isn’t correct; a variable only ever refers to one thing at a time. I like to describe variables as sticky notes that are stuck on top of values / objects (if we’re personifying it, then maybe it’s stuck on the back of the variable like a ‘kick me’ sign from any of a million tv shows – the sprite doesn’t ‘know’ that it’s a referenced by the variable ‘red’) – the objects themselves do not contain the name of the variable they are assigned to, the variable is just currently referring to them. When you assign some other value to the variable (e.g. do another
set red to), the connection between the two is gone - the sticky note is removed from the first object and placed on top of the second one.