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.
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).