This Strip is Not Safe For Work!

I found a hack that will allow the removing of excess frames from an animation! That's half the battle for adding and removing frames. If you set an animation to be a Friends Only game so you gain access to the Mod button, you can hide the panels you want to be rid of. This isn't perfect but can be very helpful for a carefully planned animation, letting you work with excess frames for safety's sake and then hide any which are unneeded.

Brilliant discovery, TFD! Do the hidden frames count still towards the final animation? For instance, animation with 100 final frames, with 40 hidden frames, is the total count 140 or 100 frames?

unfortunately they do -- it was only meant for moderating after all I sort of have an idea on how to solve this.. I think the problem is that I was thinking of solving this the hard way so instead of changing the panel order and renaming files and so on I'm thinking of adding a new animation category for big animations and the idea is that the frames and panels would be fully independent of each other for those so something where you could reuse panels multiple times (and no doubt something like this was probably suggested before and I forgot -- and probably how I should have done it in the first place) anyway this would solve my problem with editing and new panels and would not break backwards compatibility either.. I'm still not sure what is the best way to store the frame data for this -- it's still in the planning stages

`Painovoima` However, remember you can also hack the animation to have 999 frames! Even at a full cinematic 24 frames per second that would be 36 seconds of animation so I doubt anyone's ever going to push that. Also since the display time can be changed on a frame by frame basis, it means if you need to hold on a frame for an extended time, you can, so I'd say if someone isn't getting everything speed-and-time wise they need from the animation feature the problem might exist in their method since there's plenty of frames and plenty of timing tools. `Peyo` I'm hesitant to suggest things coding wise because I don't want to insult your intelligence, but if you'll take all my suggestions as just honest attempts to help and forgive me if I say something nonsensical from your viewpoint, I have some thoughts. In doing some planning (for fun) of a Panel Jam like alternative one idea I came up which solved a lot of problems was to store every "frame" (each picture with its attendant layers) as a database asset independent of everything else, and then make "strips" (any assembly of those frames) as lists that refer to those frames by database number. This breaks the pictures themselves loose from strips for purposes or ordering them, and if any frame can be invoked easily at any location it opens up a lot of options for things like being able to re-use an earlier panel multiple times. So I would highly recommend making each panel its own independent object first, and then make the use of those panels open ended so they can be shuffled and repeated easily. It would also be good to be able to "delete" a frame from a given strip or animation without actually losing the frame, which would be possible if they were assets that were referenced, since once the asset was stored, how it was referenced and where wouldn't impact the asset itself. One way to determine whether a frame has been altered or not would be if you can access its size in bytes and use a match with whatever the...

... starting byte size is for a blank frame to simply check if it's been altered. If it has been altered it could simply be treated as non-existent and left out or just marked as "insert blank layer here" for next time it is invoked. I think another thing to remember is a lot of these tools are going to be subject to VERY rare use, so a lot of these approaches aren't something to worry about on a "but what if everyone starts doing it" level because all I can say is... A world where the majority of people learned and took advantage of high-level creation tools? I wish! These tools are generally going to be used by a very small group of users, much like the project circle idea. So I'd say some extravagance can probably be afforded. Excellent optimization is great and becomes more important as the number of times a feature is called grows. But I don't think you'll see an explosion of people cranking down hardcore on the animation features. It's probably going to result in a very modest number of very rewarding projects!

Also, additional thing to consider if you do go the route of treating panels as assets. The possibility of inserting animated panels into otherwise static comics is a good one since it could allow the depicting of an action panel or a special effect if someone so wished.

`TeeEffDee` no worries, it seems we are thinking about the same thing so right now the tables look something like this: STRIP IMAGE and it would be STRIP IMAGE FRAME (not exact names) the real hard part will be making the editor in javascript for it