Characters between block no longer always returns a string

Use this template to make awesome bug reports:

Your username: Petrichor.

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.

13 Likes

Yes!! This is happening to me too!

it is very important that we get a way to use strings consisting of only digits as strings very soon.

Absolutely!!

7 Likes

-1/10 would be very nice to see

7 Likes

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.

4 Likes

Will this be fixed in time for the next spring competition deadline?

4 Likes

Unfortunately it probably won’t, I have added it to our list though.

1 Like

Ok it looks like Characters Between is actually converting the string to a number, or cutting off leading 0s, before slicing it.

For this code:

I expect “000” but it displays “9”

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.

4 Likes

Please fix this bug it brakes complex projects.
Also do you have a dew date?

2 Likes

Any idea when this will be fixed?

2 Likes

@t1_hopscotch ^^^

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)


  1. so basically the three text operators ↩︎

3 Likes

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)

2 Likes

Yeah that would be the expected behaviour. Unfortunately it currently converts the first parameter to number for all of them

This returns a length of 1:

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

4 Likes

So there’s two parts to this:

Text operators bug

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.

2 Likes

@Poison this might be why… (see OP)

1 Like

ahh that would explain things @StarlightStudios

read this starlight

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

2 Likes

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

2 Likes

sure correct ypu coudld also do that and do 3 digit to make the limit 999 like most mobile games

2 Likes