Forum ‹ C# ‹ EmbeddedResource getting different results dev vs live

[GMulligan]

I have a bunch of strings on single lines in an embedded resource text file. Tinkering around I found I could read them into a string array like this.

Code: Select all

      Byte[] myBytes= EmbeddedResource.GetBytes(myPath);
      string allStrings = System.Text.Encoding.ASCII.GetString(myBytes);
      allStrings = allStrings .Replace("\r", "");
      string[] stringArray = allStrings .Split('\n');


Similarly I found I could get a bunch of decimals between 0 and 1 with one on each line in an embedded resource text file using this.

Code: Select all

        const int numDecimals = 30; // I know count for decimals. Not for strings.
        decimal[] decimalArray = new decimal[numDecimals];
        Byte[] myBytes= EmbeddedResource.GetBytes(myPath);
        string allDecimals = System.Text.Encoding.ASCII.GetString(myBytes);
        allDecimals = allDecimals .Replace("\r", "");
        string[] stringArray = allDecimals .Split('\n');
        for (int i = 0; i < numDecimals ; i++)
            decimalArray[i] = Double.Parse(stringArray [i]);


The strings I read in the first example appear to be the same on both dev and live. However, the decimal example only works when I'm running the server locally. Posting the .dll on player io appears to cause my decimal array to ignore the decimal. So a number like 0.325235 read correctly locally will be read as 325235 on player io.

Anyone know what could be causing this? Is there a better way I should be putting the decimals/strings into arrays?

[Cyclone103]

Well obviously the development server handles your code differently from the actual player.io server.


I have no idea why your specific issue is occurring, but it appears to be a single shift. Couldn't you just shift it back over?

[GMulligan]

Sorry, but I don't understand enough about this to know what it's obvious to expect text files to get processed differently locally and on the actual server. Either way I don't want to do a fix like adding in a shift every time I compile for production without understanding why I'm doing it. I'd rather know what I'm doing wrong.

I added in Broadcasts to the code like this and then traced the broadcasts in flash

Code: Select all

for (int i = 0; i < numDouble ; i++)
{
            Broadcast("stringvalue",stringArray [i]);
            Broadcast("doublevalue",Double.Parse(stringArray [i]));
            doubleArray[i] = Double.Parse(stringArray [i]);
}


The results were stuff like:
string: 0.325235
double value: 325235

Looks like somehow on the server I'm losing the decimal point inside the Double.Parse although I'm not sure why.

[Benjaminsen]

Your problem is that our servers are using another locale - and thus - number formatting than your local computer. More specifically some of our servers are using a Danish locale and therefore expect , as the decimal point delimiter.

The problem only arises because you are storing and retrieving the data as strings. The proper way would be to use a serializer that also stores type information such as BinaryFormatter. Here is an article on the subject:
http://www.switchonthecode.com/tutorial ... -to-a-file

If you really insist on storing the data as strings you can parse an instance of CultureInfo to Double.Parse to force the locale.

[Oliver]

I'll see if we can get the servers to standardize on one culture: en-us.

[Oliver]

Good news; we were able to implement a fix for this.

From the next release, both servers (the ones in our cluster and the development server) will use en-US as the locale, in order to ensure that code will run exactly the same locally as it does live.

We think the release will go out on Monday.

- Oliver

[Oliver]

Just a quick note to let you know that the release is out.

[GMulligan]

Sounds like I should change code to follow the example in Benjaminsen's example, but thanks again for the quick response. It is processing my code the same way on development and playerio now.

[Oliver]

Text files are great for a simple reason: They're easy to read and write.

If you start binary serializing, you can't easily edit the data once it's serialized.

Unless it's anything complicated, my personal recommendation would be to just stick with text files.