Sprite overlaps block question

Arcade
1

I have encountered a problem, from last night the on sprite overlaps otherSprite block does not work.

Follow is my sample:

unnamed
unnamed3840×1857 323 KB

The sample’s link is: https://makecode.com/_gCw1Lp0CYHbd

When Player sprite overlaps Enemy sprite, the score doesn’t change.

I coded it in arcade.makecode.com, my web browser is Chrome version 80.0.3987.116 (64-bit).

2

Hm, somehow you have the old form of sprite kinds in there (as an enum, instead of as constants) - if you go to typescript you’ll see that the overlap event has the new constants (SpriteKind.Player, etc), but the sprites themselves are using the old style (SpriteKindLegacy.Player). The two things have the same names, but are not the same value - sort of like how there’s a sprites.create and an images.create

Is this an old project you have, or copied from somewhere? Not sure how that would show up otherwise (and it should have upgraded itself in the first place, though I suppose this might have upgraded then been added on to.)

3

I have saw that the sprites are using the old style (SpriteKindLegacy.Player) in typescript.
After testing, I have found that if I select Simplified Chinese language, when I create a sprite in Blocks, it will use the old style (SpriteKindLegacy.Player) in TypeScript. But if I select the other languages, it’s OK.

4

微信截图_20200221100116
微信截图_20200221100116724×467 31.7 KB

mySprite was created in English.
mySprite2 was created in Simplified Chinese.

5

Ahhh, that’s an issue with the translation…

The translation had overridden the type of the spritekind, which broke the block as you showed. This has been broken / mismatched for 7 (!!!) months: https://crowdin.com/translate/kindscript/2958/en-zhcn#q=spritetype … started to change them but doing so will potentially cause inconsistencies (e.g. the blocks won’t work together as upgrade rules won’t necessarily be applied) so will see about it in the morning.

Thank you for letting us know, will have to think of a way to to proactively catch this in the future. (@peli maybe something along the lines of a cron job gh action that pulls all target translations and compares the parameter names / shadow blocks
/ etc to make sure api’s have the right shape after translations? even with the .shadow format it’s still very easy for translation mistakes to break blocks without us noticing)

(issue filed here)

7

The client does validation of translations when loading them (and ignores the ones that look broken). Not enough apparently.