yep

(me using more pure lime mostly,,, and also long time not swf-assets from old flash-8 by macromedia ;)

is it same error: "max_string_size reached" ? for " /usr/lib/haxe/std/haxe/io/Bytes.hx line 457" ?

(into your case)

it could be by "unicode"-missmatching maybe also into -> filename

My stack is this: >>> Called from ? line 1 Called from CommandLineTools.hx line 1904 Called from CommandLineTools.hx line 22 Called from a C function Called from CommandLineTools.hx line 125 Called from CommandLineTools.hx line 640 Called from lime/tools/PlatformTarget.hx line 98 Called from AIRPlatform.hx line 257 Called from lime/tools/FlashHelper.hx line 880 Called from lime/tools/FlashHelper.hx line 714 Called from format/swf/Writer.hx line 60 Called from format/swf/Writer.hx line 1450 Called from /Users/runner/hostedtoolcache/haxe/4.2.5/x64/std/haxe/io/BytesOutput.hx line 143 Called from /Users/runner/hostedtoolcache/haxe/4.2.5/x64/std/haxe/io/BytesBuffer.hx line 204 Uncaught exception - alloc.c(177) : max_string_size reached >>>

(at point it is using new haxe "zip")

so maybe it is a bit different? But with same result

oh.. interesting (but seems little bit different)

Where does CommandLineTools.hx come from?

" format/swf/Writer.hx" this time

oh nice, so still Lime

it is preparing your assets i am think

maybe its a know bug, you could search the lime-issues on github also for

something into "compressing" (is your wave-asset filenames all pure alphanumeric-chars ?)

yeah, they are all pretty normal filenames

mhm, than maybe something into neko-tools what is still buggy

and like I said. If I just delete a few of them, everything starts working

(have also some things that not work into neko and async file-loading since lime 8)

so its the pure "amount" of files into asset-lib ?

it seems to be

(ist that some magic number ?)

I can check for sure

Or maybe it is also about filename lengths

or only one corrupt file into ;)

not sure

(^_^)

oh

could be a corrupt file I guess