Good morning everyone!
I am developing a project in Unity where I use .CSV files to collect the data to be used in the project. Important fact is that I am developing the project with the region of the operating system (OS) in Spanish (Spain, international).
I use this .CSV to list a series of actions that I want my characters to perform within the game, such as moving from the point where they are to point A or waiting for the current position for X seconds. In the .CSV I save the data as a string, but when entering it in the project I need it as a float:
- MOVE: float Velocity, float Position.x, float Position.y, float Position.z
- WAIT: float Time
Any of these actions is bound to an object that receives this action and executes perfectly.
The problem arose when I sent a build to Steam to validate the project and they notified me that they had not been able to advance because the characters did not move (the game worked, but nothing moved).
After many tests, I found the problem. It turns out that if the OS where the project build is run is in a region other than Spanish (Spain, international), such as English (United Kingdom), the game runs but nothing moves at the times originally I programmed.
This problem is given because each region has a different decimal system, for example, in Spain dots are used to indicate units and commas to indicate decimals ("1,234.24") and in England it is the opposite ("1,234.24 "), so if I declare my character to wait (WAIT) for "0.2" seconds (Spain), in an OS with English (United Kingdom) region, it will be "20" seconds, because it interprets commas as unit separator. The same goes for MOVE actions.
To avoid having to change my OS region, I changed the commas to periods in the .CSV to translate the problem to my region and do the necessary tests. With what I could test the direct that if I put "3.00" (which would be 3 seconds) my OS interprets it as 3 minutes.
My question is how can I fix this so that it works at the times I want regardless of the region of the OS it's running on?
I tried to do a manual parse from string to float by changing the dot to a comma, but I realized that even if it fixed the error in my region, it would carry over to another region.
Is there a way to configure the project to always use a particular number system independent of the OS? That is, interpret the comma as a decimal and use it for that purpose regardless of the region.
I tried with System.Globalization.CultureInfo
, but I didn't get anything (or I didn't finish understanding it).
Is there a way to create a manual parse that works in any region?
Thank you very much in advance.
The solution to my question was quite simple, I just didn't quite understand the logical use of
System.Globalization.CultureInfo
, since the solution was there.What I needed was to be able to convert a string to a float and have a number system that every OS could understand. To do this, what he was trying to do was convert the data input in a specific system, for example, a string "1.25" into a float and that in the parse it would be in charge of changing the comma to the point using the encoding
"en-US"
.As you can see, my logic was failing as it
System.Globalization.CultureInfo
doesn't make this change. Its function is simple, it is used when you want to force the project to understand the data input in a specific encoding. If you are using an "en-US" system you could not pass a .CSV with commas for the decimals (1,234.56) because it would not understand it, you had to pass the commas changed to periods directly in the .CSV.Even so, I understood that using .CSV to store numerical data is not the best option and in future projects I will look for other more effective systems.
I leave this explanation as an informative note in case someone stumbles upon this error, so that they can easily understand and solve it.
The process I carried out is to use a parse with a default culture:
The
CultureInfo.InvariantCulture
is used to format the culture of the program in the most used culture, in this case, useCultureInfo.InvariantCulture
would be the same as useCultureInfo("en-US", false)
, so all data that we try to convert must enter the numerical system of"en-US"
, that is, with commas to separate the units and points for decimals (1,234.56).If, like me, you are using a .CSV to save the data, you will simply have to access the excel options and change the "system separators":
File > Options > Advanced > Use system separators
So when you save to .CSV the units/thousands will be in a format that your project can understand on whatever OS it runs on.
I have to thank English Stackoverflow user Andrew Morton for giving me the tools to fix the problem. If it is not clear to you from my explanation, you can go to the answer he gave me and solve it by yourself.
Thank you very much to all.
You can set the culture this way and not have to do it every parse, because it leaves it at the level of the process to change.