For messed up textures, do you use AutoAtlas for these affected textures?
Cool, I’ll implement it in the next version.
Hi, MikeFromMars.
Did you mean can’t save animation in editor?
I just fixed an issue, but don’t know if it’s your issue.
@pandamicro Thanks though in the code fragment the property that should be used is id, not url (which I found after lots of debugging) this worked for loading the image 
@nantas2 My textures are exported from TexturePacker in .png and .plist files and I don’t use anything else. I just import the textures in the project and start using them. Strange that the project compiles with the correct textures in beta.1 but in beta.4 it seems to use only 1 texture from each atlas (even though there are more other textures in it that should be used)
Hi jyinkailej,
saving works fine, but the wrapModes have no effect. I need Loop, but it plays just normal without looping.
Cheers
Mike
Awesome!!! Thanks! 
beta.5 updated on 12.22
3 Likes
@nantas2 I can confirm this works great! Now I have been able to open the editor. I’m doing some tests with a small project and compiling iOS version. So far so good. Thanks!
1 Like
Awesome! Thank you for your feedback!
Hi jyinkailej,
thank you, now in beta 5 looping works again here.
Take care
Michael
This will greatly improve loading time of my project. Thanks ! 
Thanks for the fix 
I’ve noticed a few other unexpected behaviors that could be looked into:
When using slicing for sprites, if the original texture is bigger than the target size of the node, instead of using slicing, the texture is just downsized and stretched. What I think that should be done is downsize the texture along with the coordinates for slicing and use slicing on the resulting texture and coordinates to create the node. The reason I bring this up is that if I use smaller textures, so that the bug doesn’t occur, there will be much upscaling for my highest target resolutions and everything will be blurry. Here are 2 images showing the problem:
Wrong - downsizing and stretching
What should be - downsizing and slicing
My second concern is with the scrollbars in the ScrollView. If I try to make the scrollbar shorter than the ScrollView, the scrollbar behaves very strangely and exceeds it’s limits when scrolling. This is probably because its maximum size is calculated from the ScrollView instead of the scrollbar. Also another thing that bothers me is that no matter what I do, the bar node always gets stretched to full width/height of its parent node (depending on horizontal or vertical scroll) and I can’t have a bar that is narrower than its parent. For example in the ProgressBar control you set the position of the filling bar and set its maximum length and it only resizes it in the direction of which the bar goes (actually the 2 upper images are from a ProgressBar ). Here are images to illustrate the problem:
Narrower bar (set in editor)
Bar is stretched when running the scene
Bar exceeds the scrollbar’s limits when the scrollbar is smaller than the ScrollView
On a side note, do you plan to have a different sprite in the PageViewIndicator control, as currently all of them use the same sprite and a color is applied to the indicators that aren’t for the current page? Maybe have something like the transition property of buttons and be available to select from color, sprite and scale, instead of being hardcoded to color only.
Edit: I found another bug after trying to mask component, so I’ll add it to this post as an edit instead of writing a new one. If you use the mask component with a sprite and then add a sprite node as a child to it, the image gets the shape of the mask. So far so good, but when put inside the container of a ScrollView, if the image is outside the view (due to scrolling), it is rendered fully (without the mask) when it should be clipped (not rendered at all) because of the view. Maybe both the view and the mask use the same logic and they cancel each other somehow and this should be fixed.
beta.6 updated on 12.26
could you provide a test sample to me, I will check the issue.
As stated in my previous comment, beta.5 fixed the issue for me
In beta.6 nothing has changed for the issues described in my comment from 3 days ago, but I guess that in the next release they will be looked into.
Edit: Actually in beta.6 it seems that the id parameter from cc.loader.load is changed to url which is fine (as you probably meant for it to be url from the beginning). But there is a problem with the callback. It returns a null texture and null error on it’s first call for each url, so my interface ends up with empty spriteFrames unless I call it again or query the textureCache for the url after some time has passed. Could you look into that as well ?
How are you using cc.loader.load exactly ？
Actually the id parameter is deprecated because we need to define it internally, if you pass an id and find it being modified after load, it would be annoying, so we decide to not permit id parameter. You can use url or uuid instead.
beta.7 updated on 12.29
I’m using it the same way as I did in beta.5 - with the exception that in beta.5 it didn’t work with url and required id instead and now in beta.6 it is the other way around.
cc.loader.load( {url: this.imageUrl, type: 'jpg'}, function (error, texture) {
// handle loaded texture
cc.log(error, texture);
self.imageLoaded(texture);
});
imageLoaded: function (texture) {
if (!texture) {
cc.log('no texture');
return;
}
this.image.spriteFrame = new cc.SpriteFrame( texture, this.image.spriteFrame.getRect() );
this.image.spriteFrame.setRect(cc.rect(0, 0, texture.width, texture.height));
},
In the web browser log I see:
null, null
no texture
for each picture that I try to load. They are https, but they worked fine in beta.5 so I don’t know what is broken in beta.6 except that which I already explained - I get null texture and null error, but if I try to use the texture by its url from the textureCache it works, so the load callback for the cc.loader is somehow messed up in beta.6.
I’m currently downloading beta.7 to see if the issue is fixed, but from the looks of the changelog neither this, nor the things described in my other post have been looked at.
Edit: Yup all the issues are present in beta.7 as well.
Thanks for the details, I’m looking into it
Can you give me one url that triggers the problem here ?
I tried one https url but got the correct response, we do modified a little bit the logic for https image urls, here is the steps:
- we will try to fetch https urls with
img.crossOrigin = 'anonymous'setting, if the server accept, then everything will be ok, texture will be created - If the server doesn’t accept, then we will continue as if an error occurred, because even if we succeed to load the image without crossOrigin setting, the image will failed at
texImage2Dcall after loaded
Sure, here are a couple: