compatibility ishue

[Ty-Jack]

in penguinmod if you have a undefined boolen from a custom block it will return false but in scratch and turbowarp it'll return 0 and because you can put boolens in the in the spots were you put variables you can have a game that works perfectly fine on turbowarp and be broken on penguin mod their is a few ways to fix this problem

1 tell the people on pinguin mod about this inconstancy
pros: games that are allready on pingwan mod that use this niece technique wont have to alter their project
cons: people porting projects over will have to pain stakingly have to look througe the code to make sure its compatable

2 (better then method 1) you change it so it will return 0 in pinguinMod and tell the people on pinguinmod about this change
pros: fixes the isue without having to make the people to do more work
cons: might brake a project that worked before on PinguinMod (thouge there is a chance that no one has done that on pinguin mod yet)

3(best option) make it so old undefined boolens return false and the new ones return 0
pros: dont have to bug your users about this over sight and fix the isue
cons: a lot more time is required to fix it this way and might start a little bit of confusion

example of this isue
https://scratch.mit.edu/projects/1287988195

conclution
its better to fix this ishu now before its to late and too many people are using pinguin mod

[Steve0Greatness]

Hey! Could you explain how this breaks games being ported over? Doing operations on booleans should work exactly like a 1 (for true) or 0 (for false).

Just to demonstrate this, here's the expected values for all boolean arithmetic when A = True and B = False. FYI, the operation here is assumed to be the value to the left applied to the value on the right; so the 2nd table column A row B is A - B = 1.

+	A	B
A	2	1
B	1	0

-	A	B
A	0	-1
B	1	0

*	A	B
A	1	0
B	0	0

/	A	B
A	1	0
B	∞	NaN

Even in cases of equality checking, A = 1 and B = 0 are both true, as well as A > B, etc. This kind of boolean arithmetic is actually used a lot in Scratch and PenguinMod games, as it allows for simpler character controllers.

[RedMan13]

the only case by which i can see this being a problem, is in equals comparison, since "false" != 0, even though "false" == false and false == 0. though the boolean argument reporter returns an actual boolean so not even that is necessarily the problem

[Steve0Greatness]

the only case by which i can see this being a problem, is in equals comparison, since "false" != 0, even though "false" == false and false == 0. though the boolean argument reporter returns an actual boolean so not even that is necessarily the problem

That would only matter if it were returning the string "false." But given this works, I'd say that's not what's happening:

[Steve0Greatness]

The only other place I can think of is string casting. In Scratch and TurboWarp casting that to a string would yield a single character and in PenguinMod would yield 5, so that could be a possible issue. Although I'm unsure where an undefined boolean would be used in cases of string casting, or even, like, at all, aside from the block used for detecting if the project is running in TurboWarp, which I don't think would be used outside an if statement, usually.