Philip Bulley

Hey, just wondering if since this post, there is now more of a formalised way to get at this data (other than the two not-so-formal options previously mentioned)?

Totally understand, "regX" and "regY" is certainly sufficient for now. As always, thanks and keep up the amazing work

Thanks Jack. Being new to EaselJS, I wasn't yet aware of regX and regY, that indeed solves my problem Do you think there could still be a benefit in implementing transformOrigin or TransformAroundPoint within the EaselJS plugin? You'd be able to keep your registration point at 0,0 and perform transforms around any co-ordinate without having to compensate when setting x,y position of your DisplayObject.

So I realise that transformOrigin is a CSS property and thus don't expect it to work when tweening scaleX and scaleY of an EaselJS Bitmap, but is there any way I can achieve the same ends? Tweening using a top left origin isn't always ideal. Thanks

I have a tween with a delay of x secs and I want to execute some custom code just before that tween begins. onStart is triggered too late, as that fires just after the tween has started. onInit used to be the solution pre v12, but sadly this seems to have been removed. From http://www.greensock.com/v12/ How can I achieve the same thing with v12? Thanks.

Sure thing. I can see how that might be seen as an advanced/non-crucial feature in the public API Thanks for considering though.

Do you think it could be a good idea to be able to remove all listeners defined in the vars object without the need to dispose of the loader? I have a situation where I have a root LoaderMax instance (which i never want to dispose of) with several child listeners (childComplete, childProgress), during an initial load, nested loaders will have their events dealt with thanks to those child listeners. Later in the project, I want to be able to unload and load those nested loaders (in this case, when the user toggles HD assets on and off), but I don't want the onChild listeners of the root LoaderMax to fire. Yes, I can remove each listener from the root LoaderMax manually in its complete handler, but it'd be nice to have public access to the following code (from LoaderCore._dump): for (var p:String in _listenerTypes) { if (p in this.vars && this.vars[p] is Function) { this.removeEventListener(_listenerTypes[p], this.vars[p]); } } That way, if LoaderCore is ever updated with new listeners, I don't need to potentially add a new manual removeEventListener. What are your thoughts?

I've PM'd you a new test. It's not an FLA, but an extremely distilled version of how I use the VideoLoaders in my project. I notice the gap about 90% of the time in this example (flash of bright green background). You can re-compile the VideoStandaloneTest.as via MXMLC (I'm using FDT with Flex SDK 4.5.1 targeting FP10.2), but please test the SWF in bin first, just to see if you also get the flicker. Thanks!

So the fix works nicely in the test FLAs I sent you, but doesn't in my main project even when "videoLoader.autoDetachNetStream = false" I'm still getting a couple of frames of black before the video starts playback. After tinkering with VideoLoader, I've found that removing the "if (_video.stage != null)" from VideoLoader._applyPendingPause solves my problem. Kind of. I no longer get the gap, but it would seem that I cannot later dispose(true) of the loader. VideoLoader._dump is getting called with a scrubLevel of 3, but the memory never gets released. The flash player will eventually crash with an "out of memory" trace as I later load more VideoLoaders. I can confirm that when the if statement inside VideoLoader._applyPendingPause is present, the memory is released successfully. Does this help? Anything else you'd like me to try?

Looks good to me. I'll keep an eye on this and let you know if it ever breaks again. Thanks for your, as ever, ultra fast response and fix!

I've put together a test FLA. Basically it seems that the erratic behaviour happens when "videoLoader.autoDetachNetStream = false". If you comment out that line, it seems that all netstreams are attached as expected (but with the gap as explained earlier, so not a viable solution). I'll PM you the link to download the test package. Thanks!

Relieved to see this is something intentional and not a random bug! Apologies for wielding the "BUG" headline!! I have a lot of faith in the greensock toolkit So, I'm now setting autoDetachNetStream on all of my VideoLoader objects, but now it looks like some netStreams are not attached to Video, whereas some are successfully attached (it almost alternates sequentially as I go through videos). I suspect this, as on some videos I see black whilst I can hear the audio. Got to leave work now, but I'll do some more in depth testing tomorrow. If you have any pointers or things you'd like me to test, feel free to let me know Cheers!

I'm only using the word bug here as something that works with LoaderCore.version: 1.83 no longer works the same way with LoaderCore.version: 1.87. I have two H.264 video files, the end of the 1st cuts seamlessly to the beginning of the 2nd. When the first video dispatches VIDEO_COMPLETE, I do the following: removeChild( video1.content ); addChild( video2.content ); video2.gotoVideoTime( 0, true ); After swapping versions of greensock.swc, I noticed that 1.87 will display a couple of frames of black whereas the older 1.83 will seamlessly swap between the two videos, so 1.83 works well. If there is any extra info I can give you, please don't hesitate to ask.

I was thinking that maybe the easiest way to do this would be for XMLLoader.parseLoaders to actually add the auto generated name attribute (ie. loader23) to any activated XMLNode (, , , etc). Then I could call: LoaderMax.getLoader( myXML..scene.( @id == 'train' )[0].assetList[0].LoaderMax.( @bandwidth="high" )[0].@name )

Hey Jack, I've found myself in a situation a couple of times now where it'd be great to be able to getLoader by the XMLNode which declared it. What do you think about being able to do something like the following: // AS3 LoaderMax.getLoader( myXML..scene.( @id == 'train' )[0].assetList[0].LoaderMax.( @bandwidth="high" )[0] ) // Here's the XML Here, I'm using simply to group files (so no url present), and would prefer not to give them and subsequently manage name attributes, as in this case they're better identified by being children of scene.( @id == 'train' ). Forgive me if something like this is already possible, but I haven't come across it.

Thanks for your suggestions... this first is a nice idea! For reference, this is roughly what I ended up with: var xmlStr:String = xml.children().toXMLString(); // start looping through tokens var rule:RegExp = new RegExp( '%myToken%', 'g' ); xmlStr = xmlStr.replace( rule, 'myTokenReplacementString' ); // end loop xml.setChildren( XMLList( xmlStr ) ); thanks!

I noticed that in VideoLoader.as, there are several places where _video.attachNetStream() is called. If I've assigned the NetStream to StageVideo (as above) would any of these scenarios perhaps steal back the NetStream from StageVideo? Also, when using StageVideo, it's important to be able to revert back to classic Video if StageVideo becomes unavailable (or even if we desire to draw it's BitmapData), so maybe VideoLoader needs to have _video.attachNetStream exposed as public? Just to note also, it is possible to use StageVideo without importing any of the StageVideo classes (this will compile for previous Flash Player versions). This revolves around using constant strings instead of enumerator classes such as StageVideoAvailability and something similar to the following: public function getStageVideo( index:uint = 0 ):Object { var sv:Object; try { sv = stage.stageVideos[ index ]; } catch(error:Error) { sv = null; } return sv; }

Hey Jack, That's great if you want to edit the same XML object. But in my case, I want to convert the XML object to a String, perform a mass of regular expressions, cast the String back to XML and assign back to XMLLoader.content (I definitely want to assign back, rather than store elsewhere, so I can retain all the awesomeness of XMLLoader later). Converting to a String is much faster than using E4X to traverse the XML object. My process takes: E4X: 3198ms (during which the UI locks up) String: 29ms So I added the following to LoaderCore, which works great for me, but it may we worth adding this feature to the distribution? public function set content( value:* ):void { _content = value; }

Hey jack, I didn't notice your reply here until now. I originally figured that a retry feature would be useful when calling API methods, rather than static files. As an API method can often return a response that isn't adequate (for example, during twitter's rate limiting). But I totally understand and appreciate each of your points, and agree that this functionality is probably so niche that it's best implemented outside of LoaderMax itself. Cheers, Phil

Hi Jack, I have a suggestion (forgive me if there's a way to do this already). In the onRawLoad handler of an XMLLoader, it'd be great if it were possible to: [*:1hhx0adf] Get the loaded XML content [*:1hhx0adf] Convert it to a string ( XML.toXMLString() ) [*:1hhx0adf] Parse that string (for example using String.replace() with regex) [*:1hhx0adf] Finally convert the string back to XML ( XML( myString ) ) and inject back into the event.target (XMLLoader) The only roadblock here is that XMLLoader.content seems to be read-only, and I imagine for good reason. So maybe there could be a method on XMLLoader called injectXML(), initXML() or even replaceXML() which would allow this. The use case is that I could place tokens absolutely anywhere in my XML (not just in the url attributes) and have LoaderMax replace them before XMLLoader.parseLoaders() is executed.

Yep, now I know what's happening under the hood regarding events, makes perfect sense. Thanks Jack, that's solved my problem! Cheers mate! Phil

I had to read that twice, but yes, makes perfect sense! In which case, I'm wondering how I can null the onProgress callback reference once the file load is complete. That way, in theory, once the SWFLoader has completed, the reference to the onProgress callback function will be removed, and subsequently, when that loader is disposed, onProgress will not contain a function reference to invoke. I've attempted this by adding the callbacks to the SWFLoader (instead of LoaderMax as I had done previously), and in the onComplete handler, I'm setting: event.target.vars.onProgress = null; Strangely, if I later call ContentDisplay.dispose(), the original onProgress handler is called. It's as if I had never nulled the callback reference. Here's another FLA demo: LoaderMaxTest 2.zip PS. And thank you, as ever, for providing the speediest and best support around!! (You and the Robotlegs guys are truly in a league of your own when it comes to this!)

When calling dispose() on an instance of ContentDisplay, onProgress is subsequently invoked with a value of 1. Is this intentional? And if so, how can I effectively remove the onProgress callback inside the onComplete callback? Basically, I don't want onProgress to be invoked after calling dispose(). Thanks!! Phil PS. I've uploaded an example .fla of this behaviour (minus greensock.swc which should sit in the same dir as the fla). LoaderMaxTest.zip

I'm not fully up to speed on all of the features of LoaderMax, but it doesn't look like there's any obvious 'retry after failed loader' mechanism. So unless I've missed it, this is a feature request Maybe specifying { retry:3, retryDelay:10 } would tell the loader that in event of failing, the loader would retry up to 3 times before dispatching a fatal error. It would wait 10 seconds between the failed load and trying again. It'd also be good to be able to call something like loader.retry(), for the scenario where the loader has completed, but the data returned fails a custom validation check (for example if an API decides to limit your access and sends you XML containing an error message, but with an HTTP 200 OK response header, in which case you might like to retry after a certain period). I guess if progress events could report all of this too, that'd be good. Any thoughts?

If I started a tween like so: TweenMax.to( mc, 5, {x:100, y:100} ); Is it possible to do something like: TweenMax.killVars( mc, {y:true} ); I'd prefer to do without the hassle of keeping multiple instances of my tweens. Love using the static methods. I'm using using v11.101. Thanks