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.