If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : You can now close your own issues and reopen them later if needed. You can also comment closed issues.
List of issues#2707 Add the ability to export XML separately with scripts
Author: 
demnd
demndDate created:
Type: feature
Visibility: Everybody
Assigned to:
State: upgraded 
Hi! I had an idea: add an option to export XML with scripts separately. And in the XML,
instead of actionBytes, specify the relative path to the script. Something like this
structure, it is not perfect and may contain errors:
MyWidgetProject/
│
├── widget.xml # Main XML file
│
└── scripts/ # Root folder scripts
│
├── classes/ # Classes (DoInitActionTag)
| | BarterMenu.as
│ ├── Shared/
│ │ └── GlobalFunc.as # __Packages.Shared.GlobalFunc
│ └── skyui/
│ ├── components/
│ │ ├── list/
│ │ │ ├── BasicList.as
│ │ │ └── ScrollingList.as
│ │ └── SearchWidget.as
│ ├── defines/
│ │ └── Input.as
│ ├── filter/
│ │ └── ItemTypeFilter.as
│ └── util/
│ └── ConfigManager.as
│
├── main_timeline/ # Code from main scene (_root)
│ ├── frame_1.as # Code from Menu_mc.InitExtensions();
│ └── frame_10.as
│
└── sprites/ # Code in DefineSpriteTag
├── sprite_4_itemCardFadeHolder/
│ ├── frame_1_fadedIn.as
│ ├── frame_4_fadeOut.as
│ └── frame_11_fadeIn.as
│
└── sprite_8_BarterMenuObj/
└── frame_1.as
<item type="DefineSpriteTag" spriteId="4">
<subTags>
<item type="DoActionTag" scriptPath="scripts/sprites/sprite_4/frame_1.as"/>
It would be great to have this. It would eliminate the need for huge actionBytes blocks in
XML. And the project would require less build logic; for example, we could omit the CMake
logic with the script import step. JPEXS would directly take the XML and dependent scripts
and package them into bytes.
bartermenu.xml (472 KiB)Perhaps a similar approach could be taken with images. Specify the PNG and SVG import
path. Currently, JPEXS allows you to import SVG as a replacement for another image. That
would be convenient. And if the SVG contains attributes unsupported by JPEXS, a warning
could be displayed in the CLI log when running xml2swf.
Yes, I know there's swfmill, but it seems seriously outdated and generates a huge
100,000-line XML file.
By comparison, JPEXS only generates 4,400 (example for inventorylists.xml).
This would be great for collaboration. It would eliminate the need to first compile
xml2swf and then launch the second task, import scripts, images, and so on.
In other words, simply running xml2swf would be enough.
Perhaps, for this function, JPEXS could first:
1) run xml2swf, inserting placeholders for tags that specify the path to an .svg or .as
asset (for example, an empty script tag, Inventory.as, with 00 bytes).
2) create an swf in JPEXS memory with empty placeholder tags.
3) Then simply import assets into the swf file from the specified paths.
It might not make sense to export AS Linkage scripts to a separate file. You can directly
create an attribute in the tag that explicitly specifies:
Object.registerClass("ScrollBar_thumb",gfx.controls.Button);
instead of actionBytes, so you can track the link directly in the XML.
This request is most likely for a separate XML export type. And if there were a VS Code
extension with Language Server for this type of XML, that would be great. We could edit
some things directly in the XML (yes, I'm drawing the XAML analogy again).
Maybe I could come up with a XAML structure that would encompass all of this, tie it all
together so that all assets would be outside of the XML. JPEXS could simply take this XML,
iterate through it, and create empty tags in the SWF, and then simply fill these empty
tags by importing assets.
a XML* structure
Please try nightly 3513.
You can now (optionally) export XML with external AS1/2 scripts, images and/or
defineSounds.
CLI -swf2xml takes optional argument -external <formats>
It sets which items will be available externally:
Values for <formats>: Use comma separated list of following:
as12script:as
as12script (same as "as12script:as")
image:png_gif_jpeg
image:png_gif_jpeg_alpha
image (same as "image:png_gif_jpeg_alpha")
definesound:mp3_wav_flv
definesound (same as "definesound:mp3_wav_flv")
all (same as "as12script,image,definesound")
The assets directory structure is based on already existing structures mapping in FFDec.
Hiding Object.registerClass calls would require separating some parts of the code from its
actionBytes and I don't think that is a good idea.
Also we only export AS1/2 scripts, as these are standalone - each script does not need the
others to compile.
That's not true for AS3. Our AS3 compiler currently assumes the needed classes for current
script are already present in the SWF. So you cannot take let's say 10 classes which have
dependencies on itself and compile them.
That would probably not work.
But it seems that you only needed AS1/2, so that may be enough for you.
State: new→upgraded