What kind of device are you using?: (Also include iOS version, and Hopscotch version) iPhone 8, Hopscotch 3.48.3, player 2.0.0, and also on 3.49.0 on my mac
The “characters between” block has in the past always returned a string even if the value could be converted to a number. This is a very useful feature that makes many things much easier. However, in the newest webplayer, this is no longer the case. Instead, it will convert it to a number.
The expected result is that the object would set text to “0000009b” but it removes the leading 0s since it converts to a number (and back, which is probably not very good for performance) in between the characters between block and the concatenation, which has never happened before.
Is this intentional? If it is I think that it is very important that we get a way to use strings consisting of only digits as strings very soon.
Yeah this is not intentional — ‘characters between’ should get those characters in the string from the positions that you specified. We’ve added it to our list to fix.
Basically whenever I change the “3” to any number higher than 1, it will keep returning 9. I suspect that the input string is converted to 9, and thus characters between 0 and any number will just keep returning 9.
Edit: now I remember the original example in the post has “a” — I’ll just edit a screenshot so the steps are clear.
we all hope as soon as possible- it’s still possible to work with string, however it’s pretty counter-intuitive and not easy to work with
personally, i think “character at index”, “character between” and “length” [1] should by default consider any number as string in their first input (just like the new update where any inputs in non-addition operators only allows numbers, not text)
Yes, that too. It would also be helpful to split the + block into + and a concatenation block, instead of having it be the same block, though that one would not be as good. And of course text blocks should always return text, unless it doesn’t make sense (length)
If I treat it like a string, it will return a length of 14.
I’ve been investigating a bit. Currently the player seems to convert to a number whenever possible (like when setting the value of a variable, when getting the parameters for blocks, etc.) So it is a bit involved.
We can probably do it in a minor version update (as in bumping from 2.1 to 2.2, for example), since it might cause some unexpected behaviour with existing projects, where people have relied on the current existing behaviour.
I agree it is not ideal — it should convert to a number only if the block needs it, like @Tri-Angle mentioned with the blocks in the app
There was a bug where “characters between” and other text operators convert their input to a number, meaning that leading zeroes are lost. There’s a fix for this in the works, coming out for player 2.2.0
the text operators will keep their input as strings
now variables will also stay as strings. They’ll only be converted to numbers when used as input for mathematical operators
note: the Set Text block will still simplify numbers when displaying, e.g. removing leading zeroes even though a variable may contain leading zeroes.
However, you can use the ‘length’ block or loop through ‘character at index’, to confirm that a variable does have the leading zeroes & correct result from Chars between
‘Join’ block feature
For the case of joining 00000 and a, this is probably best suited for a separate “join” block — to concatenate/join numeric strings that have leading 0s.
the + operator will preference treating its input as numbers
the ‘join’ operator will preference treating its input as strings
We do have a ‘join’ block on our feature request list.
I know it might have worked before with the + operator, but it would be better to have reliable behaviour in the long-term — so a ‘join’ block would be better for this.
u might want to wait on your mon game main system untill this is fixed unless you want to use a seperate variable for everything or if you would like to make each stat max out at 9 sadly this would make it were the id for them would be limited to 9 types unless you did 9 categories and 9 per categorie or in other words 81 max mons
so in other words because of this the limits for stats would be 0-9 and the max mons is either 9 or 99 depending on how much effort your willing to put
Thanks for the notice, I will take that into account now hopefully this gets fixed soon.
I think the limit shouldn’t be 0-9 though, as numbers like 50 would still work I think and numbers like 51, 52, etc. I think if I kept stats at least two digits it should be easy to implement
