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#2099 ActionScript decompiler altering numbers in the code
Author: 
3plus4i
3plus4iDate created:
Type: bug
Visibility: Everybody
Assigned to:
Labels: Decompilation
State: closed 
For some reason, the decompiler insists on factorizing some larger numbers. So if I write
code that says
if(this.tick % 300 == 0 || this.tick == 30)
the decompiler turns it into
if(this.tick % 5 * 60 == 0 || this.tick == 30)
instead. Unfortunately it doesn't consider order of execution, completely messing up the
result of the code. I've only seen it happen with numbers divisible by 60 so far.
> What steps will reproduce the problem?
Write any code or decompile existing code that uses larger numbers, like 3600. The
decompiled code will show 60 * 60 instead. I only observed that issue with numbers that
are divisible by 60.
> What is the expected output? What do you see instead?
Keep the numbers as they are in the bytecode or *at least* preserve order of operations.
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
v.19.0.0 DEB package
> 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 can provide files if needed, but it should work with any code
This is fixed in nightly 2651 - parentheses are added around when needed.
Why is it factoring?
This is feature called smart number formatting,
it can be enabled/disabled in Advanced settings on Scripts tab.
Default is disabled so you probably accidentally turned it on.
State: new→upgraded
Oh, I need to check. I suspected that it might try to optimize, but I can't quite imagine
that pushing two byte values on the stack and then performing a multiplication is more
efficient than just pushing a short. Though I might be entirely wrong, I don't really know
anything about that. Also why is it only multiples of 60?
Now I understand. I turned off smart number formatting for color values, to make them
easier to read. And I guess the decompiler interprets everything that's divisible by 60 as
a time. What confuses me though is that I turned off smart number formatting now, but it
still factorizes on decompilation. I also upgraded to v.19.1.1.
I meant that I turned smart number formatting **on** in the second sentence there
I just released 19.1.2,
the decompiler does not factorize the numbers when smart formatting is off now.
Why 60? It is because it tries to factorize as you say - time values. Like when you write
1 day in milliseconds, that would be 24*60*60*1000 and not 86400000.
Yeah, that whole thing hat me so confused. I turned on that option for color formats, I
absolutely didn't expect it to change anything in a way that would affect the compiled
code. With 19.1.2 it respects the option being turned off again, so I regard this as
fixed. Colors in hex would be nice, but I can cope with having them as numbers.
State: upgraded→closed