jho3k

Hi Jack, I am continually astounded at the usefulness of LoaderMax and its superiority over the alternatives... I noticed whilst using the resume function that it seems to call the LoaderEvent.COMPLETE event even if the loader is complete already, this caused a stack overflow in my project which was resolved by removing the listener when it was no longer needed (probably something you should do anyway) but I was thinking for simplicity's sake perhaps there could be a progress check or something? I may have got this totally wrong but thought I'd post just in case.. Thanks

brilliant, you've thought of everything

Hi, I was wondering why this is happening in Safari? It doesn't appear to be slowing down load time but it's quite alarming to see the error counter shoot up like that! Is there some kind of timeout on connections or something?? It happens in another loading class I've used but only when using prioritisation... James

Hi Jack, I found that whilst testing the existence of a loader LoaderMax.getLoader("name") was causing a problem the first time so i modified the static function like so: public static function getLoader(nameOrURL:String):LoaderCore { if (_globalRootLoader != null) { return _globalRootLoader.getLoader(nameOrURL); } else { return null; } } Cheers

Hi Jack, Great work on LoaderMax, it feels really solid. This might be too late but this is something I've noticed that differs from how I'm used to using another popular loading class... A way to access LoaderMax instances by name 'globally'. It'd be great to be able to do this - //in document class: public var mainLoader:LoaderMax = new LoaderMax({name:"theMainLoader"}); //in some kind of sub class: var imageLoader:ImageLoader = new ImageLoader("url", {props}); LoaderMax.getLoader("theMainLoader").append(imageLoader); This way it'd be possible to prioritise/pause/etc the loading of all items within the swf from other classes - at the moment i'm using a workaround that is specifying the document class and then accessing the mainLoader that way which works fine but would be great if it was built in..

Hi, I'm having some trouble getting smooth tweens in a project which uses a number of bitmaps scrolling horizontally across the stage. You can see it here : http://dev.yesphoto.org/ (I've also added a launch page to help with testing, its not quite finished but feel free to try out - http://dev.yesphoto.org/launch.php The project uses a combination of the bulkloader class here - http://code.google.com/p/bulk-loader/, and TweenMax. The problem seems to be related to the stress on the cpu of the multiple easing functions and large(ish) bitmaps. The desired effect is a slow, smooth, languid tween. Does anyone have any idea what the problem is? Is it a straight forward cpu performance limitation? Or is there something I can do to solve this?? Any help is much appreciated. ps I've said this many a time, but TweenMax is MEGA and yea.. I'm green!