Arrays creating decimal place of a number from an array

Problem Description

When taking a number out of an array and adding a prefix and placing the number into another array the resulting number will receive a decimal point.

The numbers i am working with are a 10 digit number with values representative of an id. the first 2 digits are the item and the following are the information. All the way up to 3699999999 works without issue and the results are correct. Around 3710100100 the numbers act oddly once they are put from one array to the other while adding the needed "item" prefix.

i have created a Capx with the findings and the steps to recreate the bug.

i am using this bit of code to add the information to the new array

Parameters for new array: Set at XY

X= ItemId

Y=0

Value="Item"&StartArray.At(ItemId)

some help on this would be fantastic as this is the final available item and i would like to not cut it from the game.

Attach a Capx

https://www.dropbox.com/s/9zple3tgc8wm5 ... .capx?dl=0

Description of Capx

This Capx is a recreation of the bug i have come across while working with arrays in a larger game.

All of the ItemIds work correctly except for the numbers in 3710100101 range.

The results and findings can be found and replicated in the capx file.

Steps to Reproduce Bug

• Step 1 Run the project in debug mode. (To make the arrays more visible and easily accessible press the eye button to watch the array data for each array and then use the watch Tab.)
• Step 2 Press either the "1" or the "2" button on the keyboard. ("1" will load the starting array with numbers that are problematic) ("2" Will load the starting array with numbers that work with no problems.
• Step 2 Press the "t" button on the keyboard to activate the function that transfers the information to the new array.
• Step 3 Check the values in the arrays and see the difference in the numbers. ("Start array" is the original values, "new array" is the ones with the "item" prefix)
• Step 4 The values can be changed in the Event sheet to test further if need be.

Observed Result

The numbers recieve deciamls

e.g.

3610100101 becomes "item3610100101" Which is correct

3710100100 becomes "item3710100099.9999995" which is incorrect

3710100101 becomes "item3710100101.0000005" incorrect

interestingly with the same string using the same code these numbers work fine;

3710100102,

3710100103,

3710100104,

3710100105,

3710100106,

but these following ones will also become decimals again.

3710100107 becomes "item3710100106.9999995" which is incorrect

3710100108 becomes "item3710100108.0000005" which is incorrect

3710100109 becomes "item3710100109.0000005" which is incorrect

Expected Result

All the numbers should directly transfer without adding mystery decimals.

3710100101 becomes "item3710100101"

3710100102 becomes "item3710100102"

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (not tested)

Operating System and Service Pack

Windows 10 Pro

Construct 2 Version ID

R239 (64bit)

Perhaps the system expression round(x) would be of help in this situation at least until the bug (if it is a bug) is fixed?

Thanks for the idea Burvey, but unfortunately I have tried with the system expressions like this, "Item"&floor(StartArray.At(ItemId)), "Item"&ceil(StartArray.At(ItemId)), and "Item"&round(StartArray.At(ItemId)). (Im assuming these are correct.)

Which i would have thought would eliminate the odd decimals that are occurring which it what leads me to believe this could be a bug

Try it like this:

"Item"&StartArray.At(round(ItemId))

Thank you again but alas im afraid still no luck the decimals are still coming through even with "Item"&StartArray.At(round(ItemId))

I just ran your capx with the "Item"&StartArray.At(round(ItemId)) added and it looks like it fixed 3710100102 through 3710100106, but the others are still unfixed. Quite curious.

Yeah its really bizarre that 3710100102 through 3710100106 are working correctly but the 0-1 and 7-9 acquire the decimal places

Sorry I can't verify this but maybe try:

"Item"&str(StartArray.At(ItemId))

str() converts a number to text differently than just using & as I recall. The reason was str(), which uses the js method to convert a number to text would often show long decimals like: 0.0999999999. So the default behavior with & would cause it to be prettier like 0.1. Anyways that's my rough reasoning.

I just tested R0J0hound method and it works in your test capx! Try it in your real project and let us know how it goes.

"Item"&str(StartArray.At(ItemId))

Fantastic!!! I have had a look in the test Capx also and success!!!

I will add it into the code for my full project, Fingers Crossed.

il keep you up to date

Hurray!!!!!!

We have done it!!! The code has worked in my full project and fixed the problem.

Thank you very much for your help Burvey and R0J0hound

R0J0hound your "Item"&str(Inventory.At(ItemId)) line of code has worked a treat.

Cheers All!!

I'm glad you got it sorted. I'm still curious about what is causing the issue in the first place (Why the lower numbers work as expected and the higher ones don't).

I can confirm this bug. Here are my findings:

If I access 2 array datums in the same action (i. e. set text to Array.At(0, 0) & newline & Array.At(0, 1) & newline), then I get this error. If I access them one by one, however, and add some text at the end, then it works normally (according to comments here, I guess it's because then it converts it into a string).

Here's the number I'm having problems with, but I see that some (not all) other numbers cause problems as well: 1909769338

capx: http://www.filedropper.com/c2arraybug

By the way, round() expression doesn't work here.

This bug is problematic, as if you request a post with id 1909769338, it is ok, but if you request 1909769337.999998, you obviously get an error.

The bug is with the & operator when it converts a number to text. It's the rounding feature that was added to make decimal numbers print nicer that is causing the issue. It's not unique to array values, something like a variable can be used to cause it too.