When I compile the same project with ant many times it gives a different sizes for each compilation
I added the rsl and more option to mxml it works fine ,but the size is still changed
Please any idea to unify the size
This is not really possible, unless you do some, quite involved post-processing. Below is the list of things I know to change the size between compiles, but it may not be exhaustive:
When you compile pure AS3 project or a project that uses framework:
Resources you embed on variables have their class names generated using the current date in the name.
Flex compiler generates a tag of obscure purpose (can be removed manually, but persists in release builds), which seem to contain a GUID and a compilation time or something similar. It is usually found at the very beginning of the SWF file, somewhere after the rectangle of the SWF dimensions.
In a project that uses framework:
All code generation is suspect to generating inconsistent names, particularly, all bindings will certainly produce different assembly upon each compile. Styles and some other rarely used metadata will cause this too.
Specifically for spark skins, which come as sources rather then compiled libraries - some of them embed resources in a bad way, so you would probably need to compile them into a library and plug it into a project, removing the sources from the source path.
All in all, if you are using pure AS3 project, your task is difficult, but doable (will require following certain conventions and some post-build script that unzips the SWF, purges the compiler-added extra tag and zips the SWF back. But if it is a SWF based on the framework - I'd say the effort isn't worth it, just accept it cannot be done.
Related
Is there a way to de-obfuscate AS3? With de-obfuscation I mean making it compilable again. At this moment I lost some source code and only have the Flash file left. The problem I now face is that the compiler is not able to compile it as the class names contain illegal characters.
I could start manually naming all classes again however I'm not even certain if the de-compiler worked.
To compile the SWF again I use flash develop and the FlashSDK.
Regards.
This depends on how the code was obfuscated to begin with. If it was simply obfuscated by changing class/variable/function names, then you could use an IDE such as FlashDevelop which allows you to Refactor->Rename by right clicking the instance name which would rename it across the entire project. Or just do a simple find/replace using a text editor.
Knowing how the code was obfuscated is the most important thing though. Whichever program you used to obfuscate is probably going to provide you with the most information.
I would suggest, however, doing the bare minimum by removing all illegal characters first to see if it will compile.
is there a way to trace the compiler command for flash builder? I mean, I want to know the parameters and files that is compiling internally when I click "build" on FB.
Basically I moved a project to Flash Builder, and everything works fine but I have some runtime issues, and looks like the compiler is doing something wrong with some files (like using old files instead of using the one im changing, this occur only for a particular file, the rest works fine or I think that works fine). Also is different the way to embed some file, that's another reason to check what's doing internally.
I ran the game with mxmlc before, and probably I can compare what's the difference if I get the command executed by FB.
Also, I want to know how to do it if I need to research something in future.
Thanks for any help,
Regards
Flash Builder only recompiles if there has been a change to the code. So if you are changing an asset (image), for example, you won't recompile unless you also make a change to the project.
There are a few ways around this:
Easiest way is to just go into a file and press the space bar at the end of a line. It will add an extra byte to your file, but not to the project (compiler is "smart" and gets rid of unused files, classes, and characters). Since this is not a common thing, it shouldn't be an issue
Project->Clean.... That will force your workspace to rebuild and, in most cases, will also recompile your project
If #2 is failing, first delete bin-debug or whatever you are using as your debug folder, then run Project->Clean...
It's a tad bit annoying (especially when editing external libraries), but it allows for quicker re-launches of the debugger, which is the ultimate goal of that behavior.
This is an architecture question that I hope solves some of the issues that are popping up with a large-ish UI problem I'm working on.
Background: I'm building an in-game UI in Flash (using Flash CC) for use with Scaleform. I'm somewhere between nood and moderately knowledgeable; probably enough of the latter to be dangerous.
My current architecture is:
Parent: This will manage and create all instances of the UI. It has its own FLA/SWF file.
Component 1: This is one of the components of the parent, with its own FLA/SWF file
Component 2: This is another component of the parent, with its own FLA/SWF file
Shared HUD Assets: This contains common elements between all elements (its own FLA/SWF file); it exports all of its symbols, and these are imported into the libraries of the appropriate component
Shared Assets: This is common across all UI (buttons, background, etc.) It also exports/imports like the HUD assets
The intent here is to allow multiple types of components to be stored in each component file, with the HUD choosing which one to use and "assembling" the HUD. Artists would be able to work in the component and asset files without touching the larger HUD file and having to muck around in code.
Initially, I tried storing all of the assets in the main parent, but Flash is... a bit of a pain with managing imported symbols for multiple layouts. I'd end up with duplicate fonts, links that broke, etc.
Next, I tried creating instances using pure AS, i.e. "component = new component()" from imported AS files, but it appears I've run into issues with layouts created in the Flash IDE (and not done exclusively in AS) not being accessible to the parent. (I'm assuming this is an issue; it's possible I'm misreading some people experiencing similar issues on this site and others.)
Now, I'm decided loading the SWF files should address that issue, but I'm running into a number of "TypeError: Error #1009" in these loaded SWF files; specifically, a button (AnimatedToggleButton) that's referenced by another Scaleform component (ButtonBar). Both it and the ButtonBar are imported to the HUD component from Shared Assets, but AnimatedToggleButton is unused anywhere else. It's properly exporting and importing, and works from when compiled in the component SWF, but it comes up as a missing class/null in the parent when the SWF is loaded. I'm tried all of the usual tricks, waiting for the stage, etc.
Is this the right architecture for this sort of thing? And if it is, what's the deal with imported symbols? Do they not exist unless used?
Do you have "Export in Frame 1" checked in the Symbol Properties?
If not, then yes, only symbols that appear on the stage will be exported and accessible to the parent SWF.
I am very new to Alchemy and not an expert in using swc to store code(Although I am well aware that it worked for me so far). I want to make sure I understand if Alchemy is the right tool for me in this situation.
I want to make a simple script in Alchemy to help make certain 'heavy lifting' in the code lighter and less time consuming and ooze out more performance. The trick is that my colleagues will likely be daunted by the installation process(even though there is a guide). So my question is, if I do take the time to work with Alchemey, can I make my code available to other people that do not use it, for our project?
Hope that makes sense, my instincts (gut feeling) says yes. I simply want to make sure.
Yes, this is exactly what SWCs are for, you can compile your C++ code with FlasCC and expose a simple AS3 API that other people can use by linking your SWC into their project. Download the FlasCC beta and check out the tutorials it comes with that explain this in more detail: http://gaming.adobe.com/technologies/flascc/
Shortly, the answer is yes.
The point is you can't recompile the SWC into an SWF if you don't use alchemy. What you can do, is download at runtime (using Loader.load with ApplicationDomain.currentDomain) the SWF contained into the SWF (SWC is a simple zip, extract it).
Then, you can freely use the class that's inside, using ApplicationDomain.getDefinition("OneOfYourClass).
More about application domain
Since it's at runtime, you won't have to compile Alchemy, thus it should work fine for anyone.
[Edit: Short version - how do you properly handle namespace collisions in SWC files if one SWC has fewer classes from that namespace than another?]
I have a rather large Flash application which I'm building in Flash Builder (because coding/debugging in the Flash IDE is... not good) and I've got a ton of external SWC files which I'm linking in to my application. This has worked well so far - the file size is on the large side, but it's a lot simpler than loading in SWFs, especially since I am extending most of the classes in each SWC and adding custom code that way (it's a very design-heavy app.) The problem I'm having is when I have Flash Components, like ComboBox or TextInput, in more than one SWC. Whichever SWC was compiled last will work fine, but the others will fail with errors like the following:
TypeError: Error #1034: Type Coercion failed: cannot convert flash.display::MovieClip#1f21adc1 to fl.controls.TextInput.
at flash.display::Sprite/constructChildren()
at flash.display::Sprite()
at flash.display::MovieClip()
at com.company.design.login::LoginForm()
at com.company.view::Login()[/Users/ken/Workspace/src/com/company/view/Login.as:22]
at com.company.view::Main/showLogin()[/Users/ken/Workspace/src/com/company/view/Main.as:209]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at com.company.view::Navigation/handleUIClick()[/Users/ken/Workspace/src/com/company/view/Navigation.as:88]
I've been researching components, ComponentShim, etc. but I'm running up against a brick wall. I thought it might be the fact that some of the components had their skins modified in the source FLA, so I tried replacing them with the default skins, but that didn't seem to help. How can I ensure that I have the components imported and available to all my classes, yet still be able to skin them and include them in my various FLAs? (I am never creating new instances of them, they are all laid out by my designer.)
I dunno if this will help you, but I had a similar problem with an asset in a SWC library that was the visual representation for a class in my main project. What I ended up doing was having the visual asset be a Flash-created class that extended the class in my project rather than having the same name.
For example, my asset and the class were both com.blah.TitleBackground. To fix the issue I made the visual asset have teh class of com.blah.TitleBackgroundAsset and set the base class for the component to com.blah.TitleBackground. That fixed this particular issue for me. I still have more to wade through, but your post sparked the idea for the solution to get around the name conflicts.
I can't find the detailed fix (apparently, the work email I used at the time was trashing older messages without my knowledge!) but the short answer is to create one FLA that has all the components you want to use in it, set those components (and the ComponentShim) to 'Export for Runtime Sharing'. Then, in your other FLAs, whenever you want a component, drag it from the components FLA library (it should show up in your main library with 'Import for Runtime Sharing' turned on.) Make sure you don't have a ComponentShim in your main library. You'll need the compiled component SWF file in the same folder as your FLAs.
What this does is keep all the component code, including skins, in one central place, so when you compile (be it as a SWF or a SWC, though this problem mainly crops up when using SWCs) there are no conflicts.