pschraut/UnityAddressablesBuildLayoutExplorer

BuildLayout Explorer displays "Unknown" size

pschraut opened this issue · 1 comments

The "size" column sometimes displays "Unknown", rather than the actual size.

Some regions don't use the period symbol . as decimal separator, but a comma ,. The generated buildlayout.txt file uses comma as string delimiter, but the size uses a comma as decimal separator too in some regions/locales. BuildLayout Explorer is unable to properly parse it in this case.

Archive localization-assets-shared_assets_all_5f730b3baa8e25759a6eaa66cd80e6fb.bundle (Size: 21,9KB, Compression: Lz4HC, Asset Bundle Object Size: 1,14KB)
	Bundle Dependencies: defaultlocalgroup_monoscripts_27491efc4f8c5cd1c6bed6b18f652f2b.bundle
	Expanded Bundle Dependencies: 
	Explicit Assets
		Assets/localization/texts_shared_data.asset (Total Size: 13,91KB, Size from Objects: 13,91KB, Size from Streamed Data: 0B, File Index: 0, Addressable Name: texts_shared_data)

The problem is this text (Size: 21,9KB, Compression: Lz4HC for example. 21,9KB uses a comma and that's why parsing this comma-delimited string list fails.

I'm aware that the German locale uses a comma as decimal separator and thus displays "Unknown". I don't know about other locales. English does work.

image

zsoi commented

Can be easily fixed in a custom branch of addressables by modifying BuildLayoutPrinter.cs:

Index: BuildLayoutPrinter.cs
===================================================================
--- BuildLayoutPrinter.cs    (revision 30946)
+++ BuildLayoutPrinter.cs    (revision 30947)
@@ -1,6 +1,7 @@
 using System;
 using System.Collections;
 using System.Collections.Generic;
+using System.Globalization;
 using System.IO;
 using System.Linq;
 using UnityEngine;
@@ -23,7 +24,7 @@
 
             double byteSizeFloat = (double)byteSize + (double)prevOrderRemainder / 1024;
 
-            string result = String.Format("{0:0.##}{1}", byteSizeFloat, sizes[order]);
+            string result = String.Format(CultureInfo.InvariantCulture, "{0:0.##}{1}", byteSizeFloat, sizes[order]);
             return result;
         }

Also the build layout parser of the explorer needs to be modified to always parse floats in the invariant culture, as otherwise an editor running with german locale will spit out wrong numbers as well (e.g. 18.28kb parses as 1828kb).