Mike at BrashMonkey

at MPRart, Are you sure you are keeping the .scml file in the exact folder structure allong with your images as when you first created your project? If so, could you do a quick screen-record video for us of your problem..Ideally making an scml file from scratch, adding sprites(images) to an animation, saving, then reloading with the images being no longer there. thanks, Mike at BrashMonkey

Hi tombmonkey, Thanks very much for testing and for the feedback. Please keep in mind, this is a pre-release specifically for help in finding and squashing bugs and stability issues quickly with the communities help. While I completely agree under ideal sicrumstances several large features all at once is not the best rout when the specific goal is to deliver a stable incrimental update as quickly as pissible, this was not our goal for this release... please let me explain: We have many things to consider as we approace the release of Spriter 1.0. One of course is getting Spriter itself feature complete and very stable in a timely manner... but another important concern is getting the remaining features implimented, even if NOT in a stable manner specifically to prove the structure of the data for those features and to facilitate full Spriter support in game authoring systems asap. We decided that it would be best to offer the pre-release for testing, b5 for production use (for just a little longer), and to release the next serious of builds in quick sucession, foccussing primariliy on stability, bug fixes, and as we tackle all known bugs, the remaining features, which at this point are relatively small and simple. The vast majority of code related to each new feature is quite separate from the rest...therefore despite several large features being added at once, finding specific bugs related to each should be straightforward with the help of the community testing one feature at a time, and reporting assues as they arrise. We're confident that with the community's help b6 will be more stable and drastically more fit than b5 for production work in the not too distant future. cheers, Mike at BrashMonkey

Hi Everyone, I moved these posts to a new thread specifically for b6 pre-release bugs. Sorry for any inconvenience. cheers, Mike at BrashMonkey

Hi lessthantwo, Can you please be more specific? What version of Spriter were these "older" projects made with? Do you mean made with b5 or made with a considderably older version of Spriter? Can you please send us these spriter projects (images and scml in their main folders) that won't load or cause issues in C2? Please email them to Lucid@brashmonkey.com Thanks, Mike at BrashMonkey

Welcome, MPRart. Sounds like you're saving or moving your .scml or .scon file to a different location after creating your animation. Spriter does NOT save the images into its data files, you must keep the .scml file in the same position relative to the folders with the images it uses...otherwise Spriter has no idea where to find the images. A typical Spriter project folder structure is as follows: 1) main folder, with .scml or .scon 2) sub folders for the images your .scml or .scon file is using. You can copy the main folder and all of its content to any usb drive or other computer and it will load again into Spriter just fine, but if you spearate the images from the .scml files or vice-versa, then they can't find each other. I hope this makes sesne. cheers, Mike at BrashMonkey

Great job hunting down clues as to the causes of the issues, bwwd. I'm sure this sort of info will help Edgar get to the bottom of it. cheers, 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