adamcreator

How do you use the "On sound volume change triggered" condition? I Googled it but there was a missing image in Lucid's response that I need to figure it out. Scml | On sound volume change triggered || Audio Set "Tag" volume to -20*1-Scml.soundVolume("")???

I think my issue is technically a bug with the self-drawing/sprite sheet method. But should I make a new thread for it? Edit: Are the settings in this screencap correct? Or could something throw off or not save origin point data or positions in the final sprite sheet or saved scon? Edit2: I just realized that all the origin points are simply being reset to the default; the upper left corners. Any way around this?

I'd still like help with this if possible. If it's not a bug and I should start a new thread in the help section I can do that too. If it has anything to do with the issue, I use tiny red 5x5pixel PNGs that act as placeholders for character map character creation equipment that I was wondering if the self-drawing spritesheet method might somehow be swallowing up, such as with the 1 pixel buffer set in its options. There are also between 500-1,000 total images, with saved origin points, in the scml/scon, so maybe Spriter is somehow quitting before it saves everything, and that's why it doesn't load up every origin point in C2? Granted these are all just speculations. I don't actually know what's going on. I'd just prefer to be able to use the new self-drawing method because C2 often wants to just freeze up when I try to load all those images using the original method. Thanks!

Sure thing! Pixel rounding is off. It sounds like it isn't already a known issue, then. In the screenshot, left is Spriter and right is C2. Her head and waist and hand are off in this case, but it happens to many other pieces too. The sprite sheet image itself is a large 8112x8112 pixels, 70,940kb, the scon that was made with the sheet is 1,435kb. I tried to compare the origin point data in the scon using Wordpad to a scon with working origin points, but I don't know enough about what origin point data I would copy to make it work. Thanks!

In case my post was missed because of the newer post. (By the way, Dropbox is great to use for version control. You get a new version every time you save. You just have to move your project to the Dropbox folder, which is worth it.) Edit: I confirmed that the problem indeed only happens (at least in my case) with the new self-drawing method. The origin points are correct when using the original method. I would still be interested in knowing anything you could tell me about the incorrect origin points when using the self-drawing method, as I like how the new method counts as only 1 C2 object instead of, in my case, almost 1k images, as C2 doesn't like a lot of objects. But no rush. I'll use the old method for now. Thanks!

I don't know if this is specifically an R9 issue or bug, but when I use the self-drawing method by importing my sprite sheet and scon into C2 according to the instructions in this post, then for whatever reason it appears as though some sprite origin points are off when running animations in C2 preview. Is this a known issue with a known fix that you could help me with? Thanks

My best answer around this is to scale the entire animation via a copy of it by 2.0 or even 3.0. This makes the bones nice and fat. Then when you're done animating, simply remember to include a final step to shrink everything back appropriately, such as by 0.5.

An incomplete answer I have to this is that you have to develop tricks and ways to work with Spriter's Z-order issues. Some stuff I learned so far is that sometimes when you copy and paste something into somewhere, it may screw up the Z order of that key, or even other keys when doing the 'super-paste' as I call it, with Ctrl+Shift+V to paste an element to all frames. Sometimes you have to decide which you'd rather have: the paste or the Z order left in tact. Another trick is that if the Z order remains stable on one keyframe such as key 1, you can always use that frame to copy the Z order to other frames as a sort of Z order backup. However when Z order changes like crazy like in your case, it's best not to do anything that screws up the Z order, which may mean a bit more tedious animating and less pasting or whatever else you notice screws with the Z order.

It's best to scale the images beforehand to the max resolution you actually need, to save on download size.

No reason you can't use Spriter for this. It's all about Z order. Even if the bones would seem more cluttered because of the perspective, you would get more savvy with it as you get used to working with it.

You have to right-click the wav to insert it into the timeline, if that's what the issue was.

That is awesome, thank you SO much! I'm going to get to everything at the start of my next work day. It may take me time to find out why my PNGs and JPGs are saved in an unusual way, as all my image work and saving is simply done through "Adobe Photoshop CC (64 Bit)", but I'm just so glad to finally know what the cause(s) are. Thanks so much!

Update: I'm going to work with the original HD images version of the scml until the sound bug is figured out, due to the importance of sound in my work. (And the original HD project folder is the only one that allows sound to play.) Instead I'm going to split my scenes up into hopefully only a maximum of two halves from now on, into two different scml's, as soon as it begins to show signs of freezing. It would be great if a future update would allow us to simply merge in animations between different scml's that actually exist in the same project folder. (Construct2 makes a whole duplicate of even the same exact image file when the file is used in a different Entity, even within the same scml, so it's vital that if this idea is ever done in a future update, that it allows us to simply transfer animations, at least after the fact, between scml's in the same project folder--not only different--with no issues.) As of now I'm simply going to go completely down the path of doing whatever it takes to allow myself to continue doing my work, which means allowing the final download size to take a hit. Besides, future updates, or Spriter2, may include great needed features that allow me to decrease the download size again later on. And smaller-screen devices can simply have a 25% or 50% res version with barely any quality loss, while larger-screen devices can probably afford to take a big download size. The only other issue I remember that I could report now is that when a scene has a camera truck-in/zoom-in that utilizes the Easing Curve Editor, such as for a nice smooth slow start as well as slow end, all images simply disappear in C2 until the next keyframe. (In fact maybe this is even the cause of my main issue of that one scene not showing up in Spriter? Use of the Easing Curve Editor is hiding all the images, making it appear as though the Spriter object itself simply isn't playing at all? However by my experience this only happens between keys that use the curve editor, and I only use it sometimes when I want to add an extra flair or for camera truck-ins or outs. I also want to repeat that I do in fact have the latest version of the Spriter C2 plug-in installed, as long as the link that I used was updated correctly after r5.) As for the original issue of that one scene not playing in C2, I look forward to Edgar hopefully finding the cause eventually, as the scene is already fully animated. However, there's no rush. Thanks!

Another issue that could potentially make that downsized tactic a last-resort strategy instead of first--but something that could also probably be improved in a future update or version of Spriter, is that it isn't just an image resize: It's a bone resize. So, unfortunately, due to the size-decrease, the bones become needle-thin. Even with just a 0.5 downsize instead of 0.25. So there's difficulty in attempting to move or rotate bones, even when very zoomed in. EDIT: Oh, nevermind, that bone thing's not an issue: I just have to resize the animation I'm working on to a bigger size, then shrink it back down to normal again after I'm done animating it. Silly me.

Oh, another fact that may help: Even left-clicking on audio files in the upper-right Project Folder view, which normally plays the audio file upon clicking, doesn't play in the downsized version of the scml. So it's not just the audio's used in the timeline.

Thanks!

I even just now got done testing if it works if I overwrite the resized version's sounds with the original sound files, and restarted Spriter, but unfortunately it doesn't make a difference. So that's a stumper. Also tried the reload button, but doesn't make sounds audible.

Yes, they're there. Sometimes audio files will just be displayed as a gray key frame located at the point that the wav begins, but the audio isn't playing whether it's the key version or the normal version that displays the full wavelength--which is there too--and even though I noticed this issue in every resized version before, I also know that the sounds do, however, successfully play with the scene in C2, even from the resized scml. I just now need to figure out how to make the sounds work in Spriter, however, since I'll now be working in the downsized version. It sounds like that will be hard though, since this is not in fact a known bug.

My only issue so far, which I noticed with previous scml resizes, is that the sounds don't play in the resized scml in Spriter--despite that the sounds do in fact exist in the appropriate subfolders of the resized version of the project folder. If you know of this issue, what might the fix be?

Wow it works! Haha! Yes this is how I'll work from now on. Yes I'll be careful and organized so as to not overwrite anything with anything I don't mean to, and I have all my Spriter folders in my Dropbox folder for that version control. Awesome!

But what would the work process be like for that? For example, begin by putting all HD images I plan to use for a scene into the scene, then resize out at 0.5, then animate the 0.5 scml version of that scene, then when the scene is fully animated, resize them back out again at 2.0, and then overwrite those resized 2.0 image files with the original HD images? I could test that, but I was guessing that would just cause the images to be blown up over the bones they're attached to, as opposed to perfectly scaling up the entire animation? I'll test it now, though.

Even though I've collected dozens of suggestions and errors in a document over the past several months of my having worked with Spriter fulltime, one that I'd especially like to recommend now is a feature Adobe After Effects has, which is an option to view the images in the work frame at a lower resolution, in which the images appear fuzzier and more pixelated, such as 25%, so that it's much faster and doesn't freeze and force you to end the process and use a very tight autosave (I'm down to having it autosave every 5min) in order to minimize loss of work. This way, the end result of the scene can still be HD res, without actually having had worked on it in full res. I wouldn't mind working with fuzzier versions of what I know are actually the full-HD images. (My only other idea, but something I haven't given enough thought to yet, is whether or not there's a stable trick for working, for example, at 0.25 or 0.50 resized images thru Spriter, but then, whether or not there's a way to then, afterwards, resize those images by 2.0, and then replace the images that are used by the original full-res images, since they're now the same size. Problem is, I think that would simply end up blowing up every object x2 around its own orbit, as opposed to the entire project simply being scaled uniformly x2.) Anyway, just a suggestion. EDIT: Another idea is to come up with a way, in a future update of Spriter and/or of the actual C2 plugin, for it to actually recognize when the same exact image file is being used in more than Spriter object in the C2 project. Instead of having a different copy of the PNG per different scml. This would be awesome because it would allow us to split complicated scenes up into as many scml files as we want to, without resulting in a nuts download size. (I also notice that when Spriter is freezing--always after I hit the 4 key, 'play'--it causes my CPU in Task Manager to hit 100%, even though my computer is decent--Intel Core i5-3450 CPU, 3.10GHz, 16GB DDR3 RAM, 1333MHz, 166GB free of 1TB HDD--and runs high-end programs smoothly, including 3dsmax and After Effects.)

I don't think I have it turned off, as I still get the message sometimes, like today when I think it ran out of graphics power again, at which point it will cause any given background image(s)--which were JPGs in my case--to turn into the red 'missing image' box, but only until I restart the program, maybe to make the RAM/processing power come back. I'm also able to see the images themselves, even upon a fresh restart of the program and opening of the scml. Thanks!

Thanks for the quickness! Hmm, I didn't have the missing-images problem with the test-scml I included in the zip file I sent, I didn't think/know that was one of the issues, unless it means something, but on my end it didn't show missing images in that particular file that I set up for you. I'm fuzzy on what texture issues means. I use Photoshop to create the PNGs, but I know there are 4 options every time you save a PNG in Photoshop. I wonder if there are there any rules with those. The images included in the test zip were also 50% reduced through Spriter's feature to do that, in case Spriter has any hand in changing the nature of the PNGs or JPGs when it outputs/saves them at 50% size. Hmm, just like the missing-images issue you received on your end, I also actually have no issue importing my wav files in C2. For me, they end up converting to both formats. I save them using Adobe Audition using the rules C2 gave me. I don't suppose there were any issues with the files being compressed in that zipx format I used when preparing the file to be sent your way, as opposed to simply becoming completely uncompressed again upon unzipping them? Yes, using JPG images even in Spriter is actually something I do, in an attempt to save space whenever there's no alpha, such as in flat rectangle backgrounds in my cut-scenes that I animate in Spriter. But I definitely won't use them anymore since you said JPGs shouldn't be used in Spriter. I'm curious why that is, but I'll stick with PNGs from now on in Spriter, even when they're just backgrounds with no alpha. Yes, I'd love if Edgar could take a crack at it sometime. I'll definitely work on improving in the areas you mentioned that could be potential problems, since for all we know one or more of them could actually be bad enough to actually be causing the ultimate issue of C2 not playing the animation. I hope that Edgar is able to pinpoint the exact cause(s), which will certainly prove to be a valuable learning experience for me going forward, and hopefully can also help you to teach others what to avoid that I failed to, since, as it stands, there's certainly something we don't know of yet that certainly keeps an animation from being played in C2. I appreciate all the help!

Thanks! No rush at all.