Copy link to clipboard
Copied
How can i load swc files dynamically using as3? ( without relying on Flash IDE).
The SWF can be used the same way as the SWC, meaning you do not need to visually "show" anything when it is loaded. Your code can utilize classes and assets embedded in the SWF, just like a SWC. Therefore if anyone just loaded the SWF to see what was in it they wouldn't see anything. They could however programmatically access anything inside it just like you, if they went to that level. But it would not be as easy as just running that SWF to see what is inside.
Hopefully just packing several sep
...Copy link to clipboard
Copied
Skipping the obligatory "why are you making this hard on yourself" and "you're not supposed to", legend has it that you can perhaps get a .zip extraction library and get at the inner SWF contained in the SWC and load that. You're going to have some issues getting the domains to match, internal classes to be visible, etc etc.
So am I allowed to ask why you're not just making a SWF with all your classes/assets instead of a SWC? It's very easy to bundle the classes in that SWF and use them, as well as assets.
Copy link to clipboard
Copied
I have a menu that reads several games swfs into folders, but it is very heavy on the machines that my client has, therefore, in order to read a foreign swc library for each game, loading only what is me care at the right time, in a MovieClip inside the menu. So, I would avoid open two SWFs simultaneously (Menu and Game), and also using a SWC for each game, I would avoid that the client could find SWFs inside the folders where you installed the menu and play each game separately from menu.
Sorry for my bad English.
Any suggestions?
Copy link to clipboard
Copied
A SWC is just a zipped up SWF with a few more assets. It's no more protected than SWF at all. I think what you're looking for is a way to prevent people from doing exactly what you want to do yourself, read code from a file while protecting it at the same time. If someone really wants it, they'll get it. The best thing you can do is provide server-side assets as much as possible. By protecting the SWF from being downloaded in the first place is the best you can do. Otherwise there's little to nothing you can do besides hard coding the domain you expect the SWF to be loaded from. There's largely no way to protect a decompile of a SWF (which means a SWC as well).
Copy link to clipboard
Copied
Do not work with the server. It is a local application . My client are children curious though , do not try to open a swc to zip to see what 's inside ...
I went through other avenues . As you had recommended , I'm loading a SWF with Stage empty , and only bringing the screen, which is important to me direct this external swf library . Thus , if the child can find the swfs loose , nothing will occur to run them . I just worry a bit about the process of it all : a whole load external swf ... Despite being a local application , believe me, the machines are really rotten . The original intention of using the swc , was to test which method would be most effective in terms of processing and memory load RAM ...
Finally , i choose the swf , the ease at work, yet I am faced with two issues : The weight of the processing , and the use of GPU , because my client machines , have only a generic driver for the video card ... I tried to use the starling , but its resources are only accepted from the AIR 3.1, but that's another story ... Thanks for All.
Copy link to clipboard
Copied
The SWF can be used the same way as the SWC, meaning you do not need to visually "show" anything when it is loaded. Your code can utilize classes and assets embedded in the SWF, just like a SWC. Therefore if anyone just loaded the SWF to see what was in it they wouldn't see anything. They could however programmatically access anything inside it just like you, if they went to that level. But it would not be as easy as just running that SWF to see what is inside.
Hopefully just packing several separate SWFs will let you load and unload only what you need to keep RAM usage as low as possible with minimal SWF overhead.
If you're all set please mark any helpful/correct so we can filter unanswered. You're welcome and good luck!
Find more inspiration, events, and resources on the new Adobe Community
Explore Now