I decided to start posting some technical blog posts from time to time, this being the first.

While I do have respect for Adobe (Flash is where my money comes from after all) , and I am also in gratitude for a 2600$ worth prize (won a CS5 Master Collection in a lottery at the latests Global Game Jam event), they do know how to annoy me. I will begin with something I encountered yesterday:  AS3′s Math.atan2 function. A very common function, especially in game development. I had to use it in order to point graphical arrows to various locations. When I tested the result, all the angels were wrong. Obviously the first thing I did was checking if I inserted the right parameters. And I did.

The documentation in Flash Builder 4 shows the ‘x’ parameter before the ‘y’ one. Seeing the above tooltip, I automatically wrote the parameters as I was told to. I had used atan2 in the past, and in the cold depths of my head I knew that someone was wrong (used it countless of times in the past, before I started using FB4), but who would argue with formal documentation? After 30 minutes of trying to figure what the hell went wrong, I checked the AS3 API on the web, and saw the following:

Adobe = FAIL

The function’s parameters are actually in the opposite order (!). Needless to say that I reversed their order in my code and got the desired result.

—–

Unfortunately, the resolution for the second issue is not so simple as the above: It seems the classical MovieClip’s gotoAndStop() method isn’t 100% consistent when using frame labels as parameters (which I do quite often when working on Gladelings). gotoAndStop() receives 2 parameters:

1. An Object object which can be either a number (for a frame number) or a string (for a frame label name).
2. A scene name, in case your MovieClip has more than one scene and you want to switch between them. This parameter has a default value of null.

I know that sometimes using gotoAndStop() with frame labels names doesn’t change the currentFrame property of the MovieClip immediately, which causes all sort of problems (Adobe claims this is a feature, not a bug [...]). In order to fix this problem when it happens, I search for the desired frame label name in the MovieClip’s currentLabels, and then use gotoAndStop() with the found frame label number instead. Today, I noticed a new, very odd, behavior:

After returning from a gotoAndStop() call with a frame label name as parameter, the currentFrame doesn’t change. The thing that does change against all common logic is the currentScene property! Instead of jumping to the desired frame, Flash overrides the existing Scene object, and replaces it with what seems to be a cloned copy of the original scene (it has the same length and same labels, but you can see it’s an entirely new object in debug mode). As usual, I tried overriding the problem by calling gotoAndStop() with a frame number, but the same thing happened again – the scene was modified and the MovieClip stayed at frame 1.

I have absolutely no idea why this happens. I thought it’s a good idea to share this since I couldn’t find any reference to this behavior in the web. Maybe others encountered it and can elaborate.

—–

Next week I’ll return to update about my undergoing projects and spew some information about a future Star Relic 2.