Sorry for the delay in replying everyone. I've been quite busy on several fronts, but I wanted to check in and at least give a status report.
@lucid Sent on July 9th, 2:22 PM Pacific Time from Wemail@example.com
, will send again now
Sethmaster wrote:Sent you an e-mail lucid.
Thank you. I will be getting back to you as soon as I get a chance to look into it. Thanks for your patience.
mudmask wrote:@Sethmaster and @lucid, regarding the seams issue - this might solve it, and might not, but I was having an issue with sprites lagging and jumping around, and so I made the spriter object set it's x and y to int(object.x) and int(object.y) (where object in this case would be your placeholder sprite) as opposed just object.x and object.y. I guess the issue was that it was trying to align sprites based on coordinates that weren't necessarily whole numbers, so it would round up or down. seems to work well for me, hopefully that helps for you guys. I haven't exported to nwjs, and I'm only guessing on what I think you're referring to with that issue, so maybe this is completely irrelevant.
Thanks for the info.
DiVeR wrote:Hi there @lucid , thank you for the hard work and support provided for the C2 community! I was wondering if the procedure for importing AND updating scml objects in C2 had changed since the performance update? I read what you said recently about being able to just reimport the files if not too many changes occurred within spriter in the meantime (new images, sounds etc) but do we still have to rename the scml file association to scon and then rename to scml in C2 before each update? I may have missed the info somewhere but are there other new things to know like that or is it strictly the same as before the performance update? All my searches point me to the official tut made years ago.
Also I use a lot of container sprites as you recommend in one of your videos in order to apply behaviors and I wished there was a way to not to suppress the container object when it gets updated by drag n dropping the scml file into the c2 project. Right now I have to unbind all my containers manually before any file update, which gets time consuming, maybe a feature to think of later on or again, something I missed? This was actually the reason why I was looking at alternate ways to update the files without breaking the containers every time.
Thank you again for your hard work and support, spriter is an amazing tool!
Aside from the way you import in performance mode, the procedure hasn't changed. The most up to date instructions are here
(also linked in my signature). You shouldn't have to rename any files. In performance mode you just need to save the scon (using the performance mode import method
), and in the classic mode, you need both the scon and the scml to import. There's an option now in File|Other File Actions...|Custom Save Options... to automatically also save an scml file every time you save a scon to save you a little trouble if you plan to be using the classic import method. You shouldn't have to unbind the containers. Was it causing an issue if you didn't do that?
chadorireborn wrote:@lucid . I got another object which has a different size. I don't know the exact size but I know that it has a portrait size with the width of 96 pixels. So the problem again is the same with my previous post but now it becomes invisible when 75% of it's size is not seen on screen.
Maybe it is getting some problem finding out if the scml object is still on-screen. I can provide you the scml & scon file if needed via email. Thanks again.
I'm aware of this issue, and the solution requires an update to Spriter, which I won't be able to get to just yet, but there is a workaround. Manually drag the rectangle representing to the scml object in the layout to a size large enough to accommodate the character in all animations. Since you're doing this with no visual feedback and no control of the pivot point, you will probably have to drag it larger than whatever box size seems intuitively appropriate. At start of layout and when any scml objects are spawned immediately set their scale to 1. The problem is that it's using that small default box size to decide whether or not to draw the entire character. The plugin only used the box size to set the initial scale in previous versions, so if you set it larger in the layout, it won't get resized back, and it 'fixes' the issue.
Btw, if anyone missed the announcement in open topic, we're having an animation contest
! Take a look: