Touching sprite works with self

[griffpatch]

Expected behavior

Expected touch 'self' to always trigger... like in Scratch 2

Actual behavior

I was pleasantly surprised that with multiple clones, the touching 'self' only triggers if the clone is touching another copy of itself. This is by far the better solution, but I just wanted to flag it up as a difference. If you keep this functionality (and I really hope you do) then please add in an option to select the current sprite from the list of available sprite collisions). In Scratch 2 all clones are red all the time, and it runs VERY slowly. I'd also like to say well done for making the collision detection so much quicker in scratch 3 (even if general script processing is far slower at present - Do you expect the general script speed to get better as the engine is progressed? or is this going to be a balancing act?).

Steps to reproduce

Load up this project '138856666'. Run the project and see that sprites that are not colliding other clones are not coloured red.

Operating system and browser

PC, Chrome

[CosmicWebServices]

I would like this implemented but maybe for cross-compatibility self can be like it was and then there can be self-clone or something like that

-@icycoder on scratch

[griffpatch]

When I say self, I mean the name of the current sprite (that can only at present be selected by adding a block into a separate sprite, choosing the name of the sprite from the drop down in the touching block and then dragging back to the original sprite. Since at present this is a completely unusable use-case in scratch 2, and would be unusable in scratch 3 (if touching non-cloned self triggered it), it would seem illogical to add two modes to cover both cases...?

…

On 12 January 2017 at 11:41, Cosmic Web Services ***@***.***> wrote: I would like this implemented but maybe for cross-compatibility self can be like it was and then there can be self-clone or something like that ***@***.*** <https://github.com/Icycoder> on scratch — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#377 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGbNvtZ6O9uG0WuQMkKnyFpCQpvK55tjks5rRhF1gaJpZM4LhmJS> .

[SillyInventor]

This stems from the line
if (testID === drawableID) return false;
in _filterCandidatesTouching in renderer

Changing isTouchingSprite to parse self at the beginning as follows:

if (spriteName == this.sprite.name) return true;
else if (spriteName.contains(''-clone")) spriteName = spriteName.split('-')[0];

will result in the compatibility / functionality suggested.

Though I prefer it as is.

[griffpatch]

Me too... Please keep as is!

…

On 1 Feb 2017 8:38 p.m., "Silly Inventor" ***@***.***> wrote: This stems from the line if (testID === drawableID) return false; in _filterCandidatesTouching in renderer Changing isTouchingSprite to parse self at the beginning as follows: if (spriteName == this.sprite.name) return true; else if (spriteName.contains(''-clone")) spriteName = spriteName.split('-')[0]; will result in the compatibility / functionality suggested. Though I prefer it as is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#377 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGbNvuKTNaBWTb0z9XDLMjrmaW6sAumlks5rYO1bgaJpZM4LhmJS> .

[griffpatch]

Maybe we should re-label this one as I don't think it should be flagged as a bug. It may be different behaviour from scratch 2.0, but the behaviour in scratch 2 causes this feature to be unuseable in this configuration anyhow as it always resolves to touching... Therefore it will never be used like that and is safe to be released to work in this new configuration for scratch 3... the way it should always have worked anyhow. I'm worried that by leaving it as help wanted and bug it will get fixed! ;)

[thisandagain]

I agree. I'm happy to keep it this way and just add a note to our compatibility wiki:
https://github.com/LLK/scratch-vm/wiki/Compatibility