Mike at BrashMonkey

Hi bwwd, There's no way reporting bugs, especially in a clear and concise manner can come off as offensive. Screen recorded bug reports are something we greatly value and apreciate. Please keep in mind though that you're using a pre-release beta and focussing on a still early and experimental feature which wev'e said repeatedly is likely to change. We very much appreciate your helping to find the issues with any and all features, but to attempt to create a lot of production work that you care about keeping and using with this still experimental feature in this pre-release beta build is NOT something I would recommend. We'll report back once we're able to watch your bug reports and will let you know when we have a new build to test. again, thanks a lot for helping to find the bugs. cheers, Mike at BrashMonkey

morintari, Thanks for the kind words. We're very glad to help. And please do not feel like an idiot, because that would make me one too. I never read manuals unless absolutely forced to. ;) Edgar and I feel that a good tool should be as intuitive and easy to learn as possible, and soon we'll be able to address this exact concern. Once all of Spriter's remaining 1.0 features are in, Spriter development will be all about increasing ease of use, stability, flexiblity etc, and one of the first steps in this direction will be all the necessary pop-ups or mouse-over messages to explain what each tool does, what's happening at the moment etc. cheers, Mike at BrashMonkey

Hi everyone, Trumgottist hit the nail on the head. lighting methods like those used in Sprite Lamp could work very well with Spriter based animations... the light information images would be created per body part image, NOT per entire specific frame or keyframe...so the additional workload per animation is really not too great, and for people who want/like the effect, it could well be worth it. It could definately be used to creat effects that the vast majority of people would find beautiful...it's really up to the art direction and visual style of any particular game in general... Obviously we can't promise when support for such lighting effects might show up, per Spriter implimentation (game engine-side) or somehow within Spriter itself, but its definately something we'll eventually pursue after the critical features are rock solid, general workflow is really fun, fast, and flexible, and Spriter's full 1.0 feature set is supported acorss all major authoring systems. cheers everyone, Mike at BrashMonkey

@ KFII and Mediadi, A few questions: 1) Are you running Spriter as administrator? 2) Are you on a network of some kind? 3) What kind of anti malwar/virus protection are you using, and are there any signs of the Spriter activation file being deleted or quaranteened by it? Thanks very much for reporting the issue. I hope we can resolve it for you quickly...there's got to be a common link for you two which could explain why it doesnt happen on Edgar's system, my own, or most other users systems... cheers, Mike at BrashMonkey

Hi KFII, Spriter does not yet support reordering animations or moving them from one entity to another...it will, of course at some point in the not too distant future, but this is why it's crashing for you...those features are not yet implimented and why the "change" is not saving. To merge spriter projects, no matter what they must start from totally seperate folder sets, EVEN IF they use the same exact images, folder structure etc. (this limitation will likely change in the future). In other words, if you create a copy of the entire main folder of the spriter files you're trying to merge, and merge from the copy to the original, the merge will work fine...but trying to merge from one .scml into another that's already in the same folder will do nothing. Sorry, I know that's confusing... we'll address this when we can.. but just know, you can continue to merge by creating temporary coppies of the entire project to use as the source files for the merge. As for the C2 related stuff, I'll review it with Edgar and he'll reply here when he can to let you know what kin of progress he's making to resolve any of these issues. cheers, Mike at BrashMonkey

Great question sonder! Not yet but very soon Spriter will support variables that can be set per frame which could be used for anything like triggering specific pixel shaders, triggering vertical or horizontal velocity, causing the spawing of other objects etc in the game. The limit is pretty much your immagination. ;) cheers, Mike at BrashMonkey

Great work, bsowers. Thanks for helping out. Have you seen this resource for detailed explaination of the data format? Edgar should be updating it fairly soon to cover the new features. http://www.brashmonkey.com/ScmlDocs/ScmlReference.html cheers, Mike at BrashMonkey

Thanks so much for the concise report of the issue, isj'. Edgar will look into improving and optimizing onion-skinning in the relative near future, after some much needed and long awaited feature additions to improve work-flow in general. cheers, Mike at BrashMonkey I've tested it both with some of my own files as well as with tombmonkey's Mantis-girl and Plant-girl (to make sure it wasn't something in my workflow that caused it). I've re-downloaded his project-files to make sure everything was exactly as it originally was, and have only loaded in the projects (from a freshly started Spriter); the only action I did in spriter was setting the onion-skinning distance (to make sure that it would contain a couple of frames). Below I've added the timeline from the Mantis-girl 'stand' animation, and indicated the length of my onion-skinning distance (i've copied the red line and brightened it a bit to make it a little clearer). The decrease in performance is across the board as far as I can tell; although it is of course more obvious when more frames are drawn and when these frames are more complex. I've emailed you two short avi-movies to show the difference in performance on my system.

Hi mediadi, No one else seems to be having this issue...It sounds to me like you have Spriter installed in multple places, and not all your installed Spriters are activated. Try loading this new Spriter build directly, and THEN load the .scml files from Spriter itself. When you double click on an .scml file it loads the first Spriter you installed, not the latest (if they are installed spearately from each other). does this make sense? cheers, Mike at BrashMonkey

Hi Misj', Thanks for reporting this. Is onion-skinning performance slower across the board, even when not using the new feartures like the "skin" objects ("bendy sprites" ;) )? cheers, Mike at BrashMonkey

Hi Valerien, I would think the curve data would need to be reset when changing the mode, as the math is completely different per curve type...Spriter could be made to temporarily store what the curve was set to per curve type in case you want to switch back...but such specialized featres additions would definatlely have to wait intil all more important features are perfected...so, this isn't a bug as much as a feature request. You are quite right and we agree with you completely about core workflow... By necessity we need to get all major features implimented first, and then, go back and improve workflow once all features are in...This is so people can use and create Spriter support as early as possible... but that said, don't worry, we are very excited and eager to be able to drastically improve general workflow and add the numerous small features which will make a massive difference to how quickly and easily you can make, perfect, and tweak animations in general. Thanks for the great feadback and the kind words. cheers, Mike at BrashMonkey

Very cool. Congrats! cheers, Mike at BrashMonkey

Sound triggers are more than half-implimented. But we didnit want to make the community wait longer, and postpone community wide testing any longer. Sound will certianly appear in the official release of b6 or following quick update worst case scenario. cheers, Mike at BrashMonkey

Hi bwwd... tweening (speed) curves effects the timing of things...easing in and out etc. It sounds like what you want is to designate motion paths. This is definately possible in the future, but very likely wont be coming any time soon, as there are more critical features yet to be added. It's definatley a good suggestion though and one we're very likely to do something about in the future. About Spriter crashing...Spriter never crashes on me and I used it extensively to finish the Art Packs, so it's really important for people to get crashes to try and figure out the fastest way to reproduce the crash and report it to Edgar so he can find the cause and fix it. A bug we don't know about, or can't reproduce is unlikely to get fixed. :( The ideal situation if you get a crah is to start screen-recording, restart Spriter and redo the exact thing that happened to see if it crashes again.. If it does crash again, that screen recording is like a gold brick of bug-fixing treasure. ;) cheers, Mike at BrashMonkey

Great question tombmonkey. Don't worry...the new features add stuff, but shouldn't break anything IF you avoid using the new features OR if the plug-in (Spriter implimentation) you are using is programmed carefully as to ignore data it can't use. cheers, Mike at BrashMonkey

Hi YellowDuck, Please keep in mind Spriter is still in beta and for that reason no game authoring system currently has complete support for Spriter. That said, due to the developers working hand in hand with Edgar (Spriter's programmer and lead designer), Construct2 by http://www.scirra.com is very likely going to be the first game authoring system to have complete and stable Spriter support. In fact, a functional but infinished beta of it's Spriter plug-in is already availible for use and testing. I recently made a tutorial video in fact showing how to use it, which you can find here: https://www.scirra.com/tutorials/699/im ... tion-files Please keep in mind, while the C2 plug will likely be the first, likely not by a long stretch of time, and definately not the last. Once this upcoming Spriter build is released, it should help generate greater incentive for the other developers to finish Spriter support in other popular authoring systems, also, once we've released Spriter Pro 1.0, Edgar will switch poriorities to helping the developers and communities of all major game authoring systems to finish Spriter support ASAP. Cheers, Mike at BrashMonkey

Hi everyone, We're in final internal testing now, but there are still several important bugs to fix before we can release it for community wide testing. Best guess is 3 days for community release for testing (likely Windows only at frist), then however long it takes to fix any bugs you all find before we replace b5 as the official latest version. Sorry this build has taken so long, but it represents the addition of all "major" remaining features for the initial release of 1.0. All subsequent releases will be drastically more frequent, and focussed on workflow improvement and overall stability. cheers, Mike at BrashMonkey

Hey Drew, One feature thats highly likely to come soon after this b6 release is the ability to export a scaled version of an entire project (including the image files used). What you could do is create all image files and the animations at 2x the final size needed, and then reduce the entire project when you are ready to use it in the game. This would alow you to work much easier in Spriter, work faster and sloppier on the image files (because reduction automatically cleans up imperfections), and means you'd have 2x or 4x versions of all art/animations to use for marketting graphics, Flash banners etc. This might be your best solution ATM, to hold you over until the Pixel art friendly mode is availible. cheers, Mike at BrashMonkey

Keep these great feature requests coming everyone. We're listening. Our goal after the official release of b6 is to start getting general work-flow and eas of use improved as throughly and quickly as possible.... when were ready for this phase we'll review these suggestion threads and let you all know what's being worked on. cheers, Mike at BrashMonkey

Hi Drew, Sorry you are having a rough time with Spriter. Thanks for the feedback, and for making it concise and numbered. This makes it really easy to address the issues one at a time and make sure I don't miss anything. But before I address the specific issues, I'd like to point out a few things. Please do keep in mind, Spriter is still in beta, there are still bugs that will appear as we coninue to add the remaining features we have planned. We fix them as soon as possible once they are discovered by us or the community, but there's bound to be the occasional one they you will run into before its reported and/or fixed...this is why we offer the eartly adopter sale discount. This is even more true with the Construct2 plug-in...its not done, doens't support all of Spriters features and is is bound to still have bugs. The free version of Spriter is there so people can make sure it Spriter will satisfy their specific needs. Potential paying customers can take all the time they need to test it out with the free version, and only buy the Pro version if not only the free version meets their specific needs and expectations, and if they want to further support its development and take advantage of the pro features. Now for your specific issues: 1. I created some pixel art in photoshop and saved each body part to a separate file. I don't know any easier way to do this. I found some scripts that were supposed to help with PSD files into Spriter, but they did not work. So, I had to save 20 images (left leg, right foot, etc.) and then drag them out one at a time in Spriter. The key word here is pixel-art... While we plan on implimenting a specific pixel-art friendly mode some time after the initial release of Spriter 1.0, we canit guarantee how soon that will happen. So, for now, the smaller resolution the images you use, the tougher it will be to work with them. (The mixel art friendly mode will rectify all of these issues.) As for the script, I can't say why they didn't work for you, but we didn't make them and I suggest you contact the people who did and help troubleshoot what the issue is. Another important point, I've never used a script to quickly export all the body part images etc and get them into Spriter. I alays have done so manually, for the Art Packs and for my professional work for clients. While it is no the fun or fast part of animating, the overall animating process is still drastically faster..especially once you finish this initial set-up task. 2. To makes things worse, the image was extremely blurry when zoomed, so it was impossible for me to align anything. Any zoom at all produces extreme blurriness. Photoshop on the other hand can zoom and retain the pixels so I can see what I'm doing. So, I don't know what the issue is. Maybe it's anti-aliasing? If I can't see each pixel with hard edges, I can't line up the art assets. The image was small, maybe 100 pixels tall. That's how pixel art is supposed to be. If it gets much larger, we start dealing with more pixels and it looks different. I was going to resize the image in Construct 2, which I've done before and it works fine. Right, this again goes to the pixel art issue.. the smaller and lower-res you work, the more this will be an issue...this will be a non-issue once the pixel art friendly mode is introduced into Spriter. I'm a pixel artist myself, I love low-res low-color pixel art and making it... Spriter is NOT yet a comfortable tool for working with low-res pixel art. It will be, but we really can't say how soon. 3. It was extremely hard to assign bones. Maybe the hit box on the bones is too big, but I could not for the life of me click a bone, hold B, and assign an object to it. It would not click anything. I had to do a lengthy walkaround. I had to lock the bone, drag the object away, unlock the bone, click the bone, hold B, click the object, lock the bone again, drag the object back where it should be, and unlock the bone again. Add my number 2 point above to this, and it gets very frustrating. If I had just been allowed to click a bone, hold B, and click an object from the menu, all of this would have been solved... I think this issue as well is due to the resolution you're working at more than anything else. However, in an upcoming build of Spriter, the click detection for bones is no longer based on a box, but on the sctual shape of the bones...which will help in these situations as well. You're suggesting for an easy solution (being able to click the sprites to assign in the x-order palette instead of just in the canvas) is spot on. I'll make sure Edgar hears about this iand its highly likely this will appear in a build before 1.0 is released. 4. Maybe I am just not very good at the program, but I had trouble getting the program to behave. I would make sure there are no key frames or whatever they are called, go back to the first point, and delete a bone to try something different. Like say to delete a foot bone and use the lower leg bone to control the foot. Well, I did that and it kept not wanting to keep it assigned. The foot would go back to not being assigned to the lower leg bone. I don't know why it's so picky. I deleted everything in the animation window at the bottom, and tried again with no success. Maybe there is something I'm not doing. It's definaly more that Spriter is NOT currently easy to use to do what you need to do..IE, work with very low-res images. We'll fix this as soon as we can, but Edgar's plate is very full atm. about the bone isses, I'm really not sure what you mean. Did you know each keyframe has seperate data for what is keyed to what bone etc...this is so you can dynamically change bone structure, z-orders etc etc at any point in the animation. perhaps you ran into an actual bug here, but I can't tell without more info. 5. Then, I duplicated the animation. I then tried tried to delete the first animation, but it wouldn't let me. I could rename the first animation, but not delete it. I have no idea why. This is a known bug and will be fixed as soon as Edgar can get to it. 6. Okay, so I manage to create a very crude animation. For the reasons above, I did not try to get fancy. I just wanted to import it into Construct 2 and test it. Well, it didn't work. I have imported the demo guy into Construct 2, so I know I can do it. But I imported "my" animation into Construct 2, and it looks okay. I set the starting animation to "idle." I run the test to see what it looks like. Well, it plays an animation that doesn't exist. The guy's foot rotates and flies away while getting bigger and distorted. I thought, okay I messed up something in Spriter. So, I go back to Spriter, and that animation does not exist. I can not play it back or see it. My real "idle" animation just had a little movement in it. This was something, I don't know what. I tried saving and bringing it back into Construct 2 clean, but it did the same thing... If the animation looks one way in Spriter and different in C2, this is almost certianly a bug in the C2 plug-in. Please email Edgar your file and when he can, he'll find the issue and fix the plug-in. his direct email address is lucid@brashmonkey.com Again, really sorry your first attempt to make actual work with Spriter was so difficult. I hope I adequately explained why and hope we can address these issues within the next several Spriter (and C2 plug-in) updates. cheers, Mike at BrashMonkey

Hi ursuletzu, Thanks for reporting the issue. I've also noticed in the current build you can't delete the first animation in an "entity". Is this the problem you are experiencing as well? In other words, I can delete the second, third animation etc, but never the first animation. Can you verify this is the same issue you are experiencing? cheers, Mike at BrashMonkey

Hi morintari, I don't think you're presenting enough information for us to figure out if its something you're doing specifically or some kind of bug. Obviously the vast majority of people currently using Spriter are not having such an issue, so if it is a bug, we'd love to know exactly what is causing it for you. Did you watch the tutorial videos and read the built in manual? Are you properly setting up a project folder with sub-folders for your images before you begin animating in Spriter? Are you moving image files out of the folder they were in when you created the animations? Spriter just references to image files, which need to be kept in the same folder structure/location relative to the .scml file. If you move the images after creating your animation, when you reload the file in Spriter, Spriter can no longer find the images. Is this what's causing your problem? I've never experienced or seen a Spriter project folder dissappear on a user due to a bug. Are you saying a folder you create is literally being moved or deleted on its own? The best course of action might be to make a screen-recording of this issue, to show us exactly what's happening. thanks, Mike at BrashMonkey

Inspired clearly by one of my all time favorite games... looks like its gonna be fun! Best of luck with it. cheers, Mike at BrashMonkey

Hey Everyone, I finally got around to making a thorough tutorial for controling the Spriter object in C2. Here's where to find the video: viewtopic.php?f=9&t=12866

Hi everyone, Here, finally is a step by step tutorial for importing and controlling a Spriter object (swapping out animations etc) In Construct2 You can try the actual demo I made here (Chrome highly recommended): https://dl.dropboxusercontent.com/u/617 ... index.html cheers, Mike at BrashMonkey