If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#2070 SWF not repackaging from XML properly
Author: 
ShortFuse
ShortFuseDate created:
Type: bug
Visibility: Everybody
Assigned to:
Labels: XML
State: closed 
> What steps will reproduce the problem?
Take some SWF/GFX files. Export to XML. Change nothing. Import back from XML. Save
> What is the expected output? What do you see instead?
The file outputs should match.
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
The last nightly build. Windows and Linux.
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
I'm using SWF/GFX from Starfield and doing some small edits to colors over XML. Even
without many any changes to the XML when repackaging, I can see things are missing like
DefineSceneAndFrameLabelData => tagLength. What's worse is Starfield will crash with the
repackaged files.
I added one file to show as an example.
intro.swf (32 KiB)fonts_en.swf (209 KiB)
1) when opening in FFDec, make sure you do NOT import linked assets (see attached
screenshot - press no in that dialog). If you press yes, and then export XML, the XML
might contain also imported assets which will result in wrong SWF. This is unwanted bug
:-(.
2) The SWF tag length is stored in the SWF file in two different variants. SWF compiler
can decide whether to use long format or short format. XML export/import does not maintain
original length variant, thus FFDec writes it own variant.
3) The standard flash playing component does not differentiate whether the length is
written in short or long format, it should play both without problems.
4) Are you sure this is a XML problem? Did you try to make the changes manually in the
FFDec GUI, and then save them standard way?
The starfield may crash for other reasons, for example it may check the file size, its
hash or something...
importassets_ask.png (8 KiB)I'm doing it over the CLI to make sure it wasn't related to something I'm doing. Importing
over the GUI will work, but we're talking about 4000 colors in some files, so I need
something automated.
Just doing -swf2xml and then -xml2swf with no modifications has some differences. I
noticed the long/short length and was able to modify `forceWriteAsLong` on some tags to
keep things to match. Right now I'm noticing a difference with FILLSTYLEARRAY where the
original file will use 0x40 and the re-exported file uses 0x00. I'm going to keep going to
see what other difference I find.
There are so non-crash related differences. For example, the game is uses a $ before some
strings, and that doens't appear on the original, untouched file, but only the re-imported
file.
Also thanks for taking a look at this!
*Correction: "the $ doesn't appear in-game", though I can see the $ in the actual
untouched swf file in the hex-editor.
I was able to realign everything to track the issue. I made some changes to persist the
value of forceWriteAsLong into the XML and read it back. I also persist the moveBits
instead of letting the exporter flatten it (0 byte values).
I narrowed down the issue to DoABC2Tag.
I then exported both versions as is and did a folder compare. It seems it's a XML issue
where \t (tab) gets removed from scripts. Also \n is being removed, in .text tags
Thank you for the investigation.
Please try nightly 2547,
now tabs and newlines (and few more characters) are escaped using backslash.
I also made forceWriteAsLong attribute public so it's editable in FFDec and also exported
to XML.
(see changelog)
This should solve this issue. Let me know...
State: new→upgraded
State: upgraded→closed