Crap... Swf Encrypt dosn't work with UZA's global class...

[DesignerMichael]

http://www.uza.lt/codex/as3-global-object

Anyone got any ideas? The encrypted swf throws this error...

VerifyError: Error #1053: Illegal override of Global in uza.utils.Global.
at global$init()
at battleTanks$iinit()

I tried renaming everything in his class to "myGlobal"... Nope, amayeta swf encrypt still doesn't create a proper file... I just purchased the latest version too.

[duncanhall]

That looks like a pretty hideous implementation.

If you really want something like this, just looks up the Singleton pattern and write your own class in about 30 seconds. The basic idea is to have a class that can only ever have one instance, and keeps reference to that instance.

The basic idea (sans enforcing private constructors, which you can read about elsewhere:


package
{
public class Singleton
{

private static var instance:Singleton;

public function Singleton () {}

public static function getInstance () : Singleton
{
if (instance == null) instance = new Singleton();
return instance;
}

public function accessAnywhere () : String
{
return "look, this can be accessed anywhere";
}

}
}




var singletonString:String = Singleton.getInstance().accessAnywhere()

[sekasi]

Top 5 Actionscript wishlist;

1. Abstract keyword
2. Private constructors
3. Union types
4. object.removeAllEventListeners() (without any params!)
5. object.destroy (removes everything that might obstruct garbage collection)

Whine.

Seriously though listen to duncan.

And give us the abstract keyword plz.

[DesignerMichael]

The UZA classes do everything, and so far they have been rock solid stable.

You can make functions global, the stage global, everything... Without coding it yourself.

The only reason I need globals is because I'm developing a SmartFoxServer game, and I would like to be able to add/remove listeners to the SmartFoxServer class from anywhere.

It's not possible to add listeners like...

MovieClip(parent).smartFox.addEventListener(SFSEve nt.onUserEnterRoom, onUserEnterRoom);

//I have tried stuff like...
MovieClip(parent).Class(smartFox).addEventListener (SFSEvent.onUserEnterRoom, onUserEnterRoom);
//It's not possible?
Instead I have to use a custom global class...

global.smartFox.addEventListener(SFSEvent.onUserEn terRoom, onUserEnterRoom);My other main global is my global.debugTrace() function. I could use MovieClip(parent).debugTrace(), but after a while it becomes...

MovieClip(parent).parent.parent.parent.debugTrace( )... And it's just rediculous...

[DesignerMichael]

I wish this would just work... -.- Then no hassles with globals...



MovieClip(parent).SmartFoxClient(smartFox).addEven tListener(SFSEvent.onUserEnterRoom, onUserEnterRoom);
Can I somehow create a reference to the parent class?


public var smartFox:SmartFoxClient = MovieClip(parent).SmartFoxClient(smartFox);

[sekasi]

This is breaking OOP code practices in so many ways I lost count! :P

Encapsulation is a word you want to research a bit. If you at some point need to do something in a parent class, never call it directly because that breaks the whole point of class based programming. Dispatch an event.

the parent can listen for the event and react accordingly.

[DesignerMichael]

The parent is really just handles the connection/login, then all listeners are removed and all communication is handed over to the the game.

In order to keep things stable from game to game the entire game class needs to be destroyed and re-initialized. Without the annoyance of refreshing the browser.

[DesignerMichael]

Pure OOP is pretty, however it lacks practicality. What takes 10 minutes procedural can take hours in OOP.

Productivity and speed is the bottom line that brings in the $$.

If breaking a dozen OOP rules brings a 2x more stable product to the customer 10x faster, its better. :) Nobody cares how it works, just that it works well.

[sekasi]

Pure OOP is pretty, however it lacks practicality. What takes 10 minutes procedural can take hours in OOP.

Productivity and speed is the bottom line that brings in the $$.

Unless you don't suck at coding.

I'd like you to show me something that you can do in 10 minutes procedural that would take me hours in OOP.

Above that, procedural lacks in maintainability and scalability. Once you complete your 1000 line on the first keyframe procedural project and 2 month later you're charged with greatly expanding and updating it, that's when it hits you. Oh ****, procedural programming sucks!

[DesignerMichael]

Yea, I'm quite happy that its just 20 lines of procedural and 2000 lines of private functions.

Its rather nice to own and direct your own projects with outside funding and doing partnerships.

Working for others is kinda lame. Least I ever worked for was 100$ an hour, and it sucks...


Unless you don't suck at coding.

I'd like you to show me something that you can do in 10 minutes procedural that would take me hours in OOP.

Above that, procedural lacks in maintainability and scalability. Once you complete your 1000 line on the first keyframe procedural project and 2 month later you're charged with greatly expanding and updating it, that's when it hits you. Oh ****, procedural programming sucks!

[sekasi]

Yea, I'm quite happy that its just 20 lines of procedural and 2000 lines of private functions.

Its rather nice to own and direct your own projects with outside funding and doing partnerships.

Working for others is kinda lame. Least I ever worked for was 100$ an hour, and it sucks...

I'm not going to deny that procedural programming has its uses.. web banners and such. But if you look at the general progression of actionscript you'll soon come to find that almost every single high end actionscripter uses object oriented programming. And it IS for a reason. You can talk smack about how much money you make all you want, it's not going to take anything away from the fact that you are using an outdated coding method and you're trying to justify it with nonsense. Looking at your last couple of posts at the forum the majority is asking questions on code, so I fail to see how you can be so adamant about you being 'the stuff' and not take advice from people that might just have a bit more experience than you.

OOP has more overhead, sure, but it's hardly that timeconsuming. When expanding the projects or adding new sections you save all that time x 25.

You're fighting a losing battle here, I'm sorry to say. I bet the next thing you'll say is having all your code in frame 1 in a FLA is the way to go :lol:

[duncanhall]

Also, since OOP is rubbish, and far too time consuming, you may as well stop using UZA's Class and make a procedural method of having global variables.

[JonnyR]

DesignerMichael,

If you feel strongly against OOP, then why have you made the move to ActionScript 3, which is itself, far more geared towards Object Orientated Programming - I mean, just look at all the added overhead provided by event handlers!

[DesignerMichael]

Honestly... I came here just asking why this global class might screw over Amayeta and everybody goes off topic and it pissed me off. I honestly do 100% OOP except for in multiplayer stuff... There isn't anything in my Fla except graphic assets and a link to my Document Class.

Nobody seems interested in my actual question, they just seem to be interested in being little OOP religious fanatics... Sometimes OOP can't do everything, and rules have to be broken!

After a decompiling the encyrpted swf... I notice there is a bracket missing after an if (... after some rather interesting code in UZA's main class... That might have something to do with the VerifyError... Grrr... I wonder if Amayeta tech support will ever get back to me.
I'm not going to deny that procedural programming has its uses.. web banners and such. But if you look at the general progression of actionscript you'll soon come to find that almost every single high end actionscripter uses object oriented programming. And it IS for a reason. You can talk smack about how much money you make all you want, it's not going to take anything away from the fact that you are using an outdated coding method and you're trying to justify it with nonsense. Looking at your last couple of posts at the forum the majority is asking questions on code, so I fail to see how you can be so adamant about you being 'the stuff' and not take advice from people that might just have a bit more experience than you.

OOP has more overhead, sure, but it's hardly that timeconsuming. When expanding the projects or adding new sections you save all that time x 25.

You're fighting a losing battle here, I'm sorry to say. I bet the next thing you'll say is having all your code in frame 1 in a FLA is the way to go :lol:

[duncanhall]

Nobody seems interested in my actual question, they just seem to be interested in being little OOP religious fanatics...


Rubbish, you completely ignored my first post. The singleton pattern IS what that UZA junk is using. So I thought I'd show you how it works so you could implement your own version, therefore making bugs a lot easier to nail down/fix. But you obviously didnt want to.

Also, I've done extensive SmartFox development, and never felt the need to devolve into the world of procedural.

[DesignerMichael]

UZA's stuff does not have bugs. It works perfectly There is something in the code that is choking up Amayeta's obfuscation alogarithm.

I don't even have time to bother with this. I'm pushing thousands of users to my game a day, and the new client must go up without Amayeta! Amayeta is surprisingly not that great... After testing with sothink's decompiler...

[duncanhall]

Personally, I wouldn't bother with obfuscation at all (and never have done). If someone wants your code, they will have it, and there shouldnt be anything worth hiding that much in your code anyway. Plus, it's clearly proven itself to be more hassle than it's worth.

[DesignerMichael]

I'm not obfuscating for that reason. I just wanted to make it a little harder to find the positions of variables in memory and stuff like that to help with cheating problems... However, I should just intensify serverside logging of user actions. Tracking skill level changes and etc...

[duncanhall]

Or, as you should most likely be doing anyway (especially with SmartFox), move all your vars/game logic onto the server.

[DesignerMichael]

Yes, all game logic is on the server. Except for a few things like player movement which are easy for users to report if anybody hacks.

For efficiency reasons I'm moving those to the string datatype, so they will soon be loggable too.

Things like users packet sniffing/trying to send multiple projectiles will be super easy to detect.

[DesignerMichael]

Woot, they finally got back to me an uploaded a new build and everything works perfect! Sweet!