: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means waiting times in the issue tracker are very long and mostly depend on community. Sorry for the inconvenience.
State: upgraded new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
> What steps will reproduce the problem?
just opening the program.
> What is the expected output? What do you see instead?
when i click advance settings i see parallel is set to 2....not 20 by default
> What version of the product are you using? Is it "nighlty build"? Which operating system
do you have?
> 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 know alot of people who use this program. I literally talked to 18 people about it.
Every single person had a low setting for the parallel setting. Every single person who
changed it to the default 20 say the program is much faster now and they love it. Its like
night and day. So why does it set it to a low number? how to keep the default setting of
Thanks for the quick response....I love what you guys do here. Im going to go ahead and
try the new version now and will let others know that the newest update addresses the
Will let you know how it goes after a day or two.
I have read your "If you are using jpex free flash decompiler then read" post on the fh
and saw people complaining about us fixing one bug while introducing another. It makes me
sad a bit :-(.
I know we create new bugs while implementing new features. We have unit tests for some
basic stuff like AS decompilation and direct editation so this part is relatively safe.
But unfortunately we cannot write tests for GUI. These problems must be "tested" manually.
It would be better if more of FFDec features had unit tests, but everything which depends
on GUI is very hard to test.
If you have any idea how we can improve the release/testing system then please tell us!
I don't like people using old versions of FFDec, because we do our best to improve our
product and fix all bugs and we spend a lot of time with it (and nobody pays us) and if
people then do not use it I feel like I wasted my time :-(.
We have nightly builds which are compiled right from our repository and then at some point
we release "stable" version. When we find critical bugs in stable, we released fixed
stable as soon as possible.
Then we continue with nightly builds.
Do you know any better system? If yes, then do not hesitate and tell us. I would like
people to use more up-to-date versions, not to be stuck with "v1.7.4 or 4.1.1". But I
know... you need just edit the SWF, not to experiment with FFDec versions which one would