`Peyo` I think I brought this up before, but thought I would again since you have things more in hand now. As usual this is not something I consider urgent, but would be really useful. I'd like to request an optional text box that can be placed at the top of a project by the creator of a strip or project, which can be edited or removed freely by the creator, that will be seen before everything else. This would allow creators to give background information (or any information) about the project before people dive in, and not require them to try and fit it into the comment for the first panel and hope people see it.

So what I'd ask is if you do add vector to the site please make it an additional option, and not a replacement for raster work. It's a highly conditional protocol that got a lot of popularity mostly due to mobile devices, but it should never under any circumstances have been viewed as any sort of baseline art creation method. However it's a great option to have if added as an extra, and once something is created in vector, using that vector creation to render raster art is trivial, so the two can work together great! Also, concerning what `Painovoima` brought up about the fuzzy edges, that's just anti-aliasing being applied to the vector work. The same art could be rendered with any edge, fuzzier, fuzz-free, double-lined, whatever, which is one of the strengths of vector, that you can do whatever you want with it at render time. So, my view on it is, vector is great to have as an option but should never be the sole option.

`Peyo` I wanted to comment because this is an area of personal interest for me. Yes, PanelJam (and also Drawception unless they changed it since last I used it) both use vector drawing apps. This is very easy to diagnose since both of them change the shape of your lines, and not in the sense of smoothing but of actually re-calculating what you've made to be mathematically efficient. You can see this by doing a number of maneuvers that force vectorization to make extreme decisions. One of the easiest, tho, is just to test whether or not there is actually such a thing as a pixel. On vector apps that are geared for efficiency there won't be: The smallest unit will be a circle because all a circle requires to calculate is a radius. You can achieve actual square pixels in vector, of course (see the excellent-for-what-it-is FlockMod) but the price is extreme overhead. FlockMod is a good example of someone actually doing an excellent job using vector to emulate raster. My take on it is do not go vector! The strong points of vector are not artistic points, they're design points. Scalability without loss, the ability to be tweaked and edited using control points and the ability to create extremely smooth lines (vectors) using calculations done at render time to decrease storage requirements are the strengths of vector... Which sounds good... But the catch is you have to design work made in vector AROUND those aspects of it to really make good use of it. Otherwise, vector art is only going to constantly wrench control from detail-oriented artists. I can summarize vector like this: One artist drawing in a vector app: "OH look how smooth my lines are! I can use these control points to get a nice, clean result so that my lines have mechanical precision and are perfectly mono-width!" Other artist drawing in a vector app: "I literally can't get that pixel to do what I want it to do. I literally can't make the shape that I want to make. Not figuratively can't. Literally can't."

`Peyo` Yeah that looks neat! That would eliminate a lot of my current slowdowns.

`Peyo` Personally, I think putting other more rarely used tools like the text tools and the stamper and duplicator, shape tools, et cetera, under submenus would be fine, especially if it leaves an easier way to add more related tools later. For example, if all the shape tools are put under one submenu, if you come up with another shape tool to add later, it can just go under that submenu with the others and requires no re-arranging of the main interface. Same with the text tools, if they're under one submenu, adding more text options later becomes really easy. But... I do think the brush tools, crayon, spray tool, eraser, line tool, eyedropper and pixel tool... The tools that are used directly for drawing and painting... Should not be in a submenu, and further, should be placed extremely close to the color picker and the size and alpha sliders so that when someone does art, they associate drawing with moving to one specific area of the interface and setting everything up, then getting to the art, then going back there when changes need to be made again to the drawing tool.

I'd say if anything, the whole thing should revolve around the basic drawing tools and them being easy to get to and use, and make settings for. Other stuff like the shape tools could go under a submenu since they're only used sometimes, but the actual drawing tools are why the whole thing exists.

`Peyo` I'd have to say please no on the brush submenu, that would just be extremely inconvenient when working. With other stuff I'm still not a huge fan of submenu operations but could live with it, but the actual tools for drawing should stay out in the open I think to keep the workflow easy. Also I had no idea we had a pixel tool, I always saw that checkerboard icon and kind of glossed over it not knowing what it was for. That's neat we have one! Submenu for the multiple text buttons makes sense because people who are doing a text pass would probably be focusing heavily on it. Also if text functions are under a submenu it would make it easier to add other text features later without worrying about layout.

`Peyo` Hey there! I tried the keyboard control of the colors and honestly couldn't figure out what was going on. Every time I would scroll back to a color I had selected it would open the color picker. If you're talking about saving the layers, maybe assigning hot keys to save each layer to for example numpad 9, 6, 3 and . or to numpad + for saving the current layer, or all layers.

`Peyo` Oh gee! That's like... Me: Wow, I am really excited for this new format! Google: We are not going to support this new format. Me: That was fast! This only makes me think even more it's a good format!

`Peyo` Oops I meant I'd save all the frames to the site by submitting, not make an actual local save. I think JPG XL is being greeted with a lot of enthusiasm by the open source crowd so you never know you might see easy support for it come down the pike!

`Peyo` Generally the closer a feature comes to being able to invoke with just a single keypress or click the better. For example, when I animate I tend to rough in all the frames first, meaning if I'm doing a 50 frame animation I'll rough in and save all 50 frames during a first pass, then do additional passes to add detail or effects. So, each frame gets loaded and saved multiple times. That unfortunately means having to confirm a save every time becomes a serious time sink, so of course it makes me wish for a one-click "save current frame and return to the main body of the project so I can quickly select and edit another frame" solution. The same will generally be true with a save feature, the easier it is for someone to save a copy and get on with things the more likely they will be to actually use it.

`Peyo` I'll keep an eye open to see if I spot anything helpful about saving other formats. That suggestion is definitely more of something for "a future thing if you were looking for a challenge that would have a good outcome" as opposed to "this is needed." And yes, using a timestamp or date and time stamp is great, because if it incorporates seconds it's going to never be duplicated under normal use. That could work well in place of incrementing a filename. Have you checked into the arising JPEG XL format? Its ability to store frames would allow it to hold layer data.

`Peyo` Another suggestion (this is a bit more advanced and is more for future proofing and possibly just something to keep in mind) would be create your own "Frame Format" that's a scalable container that just stores whatever might be in a frame, such as numbered layers, designations for exterior files on the site (such as backgrounds) actual .png files, captions, and anything else that might be part of a frame. This container could become a really easy way to move frames around or save them intact with their layers. It might be possible to use a compressed .ora (Open Raster) file for storing the graphical assets, because I know that's a really good open source format which is freely available. This would give a little side benefit that the file could be opened, intact, in Krita or Drawpile. So for example, the container which could be called something like .chu could be a 7zip file which contained a .ora file that had the graphical aspect of the frame on it, then could additionally hold text files with whatever additional info was needed such as frame rates for animations, captions, and so on. It might seem like a daunting idea at first glance but if you think it over, creating a container that can scale with need later streamlines a lot of things.

`Peyo` I have no idea how easily this could be done but if you want my opinion as someone who does an awful lot of safety backups and saving... Step one would be to make it trigger through an easy hotkey so that while working, someone can just hit a key to quickly save a copy of their work. (As far as I know this should have zero impact on the site since this is happening locally, so there's no implication for the site to letting people save as much as they want) Step Two I'd say make it do-able from the main interface, as having to go under the gear does keep it out of sight and therefore possibly out of mind. I'd say it should be clearly labeled as something like "Safety Save" so it's not icon reliant. A floppy icon would probably work great, either that or the standard line with an arrow pointing down from it download icon. Step three which would be an extra nice bonus for people like me would be to make the saves be sequentially named (there could be a checkbox option for this under settings in case someone only wanted one save) so for example if it was saving a panel from a comic called "Super Cool Comic" and was the 4th panel it would save as "Super_Cool_Comic_P4_TeeEffDee.png" and then if I saved again it would automatically iterate so the next save was called "Super_Cool_Comic_P4_TeeEffDee_001.png" and the next would be automatically named "Super_Cool_Comic_P4_TeeEffDee_002.png" and so on. This allows people to build up a practice of just saving repeatedly without over-writes which can be nice for a number of reasons, a couple of which are you don't have to confirm file replacement and you keep a list of your progress if you want to in the form of an image stack. Making sure to have descriptive filenames which keep track of the project name, panel number, and username means if those things change later for any reason it won't cause a problem.

`Peyo` With the inclusion of the download button, and your offer to help hack any lost pics back into the strips, you've gone waaaay above and beyond what most sites ever do. So you're definitely covered as far as being blamed for any losses goes. You have been on all fronts giving the users the tools they need to protect themselves whether it's from vandalism or art loss and that's really all you can ever do, the rest is up to the users.

`KMP` That's Cropsy from The Burning!

That costume is truly outrageous! Truly, truly, truly outrageous!

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.

... 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!

`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...

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.

It is truly excellent.

I was at first against this idea but then when I thought it over, I realized all the reasons I was against it were due to its potential for abuse in damaging strips easily. The other features `Peyo` has put in allow strip creators to defeat derailing and vandalizing, so now I like the idea! I'd love to use it for making backgrounds or panels that were method-heavy in Krita then uploading them to strips. I know this is not necessary to say but it would be wise to wall such a feature off so only established users can have it, otherwise it just becomes a potential vandalism tool for trying to expose users to unwelcome images before running away snickering, tripping over your shoelaces, and falling face first into dog poo.

`Peyo` I went and edited the original post and it seemed to work great now! Excellent! Also I wanted to test the `Peyo` functionality so, now is as good a time as any.

`Peyo` Oh good and I'll keep an eye out for stuff! Great work on the text tool that's going to really come in handy for comics

This kind of shows my level of knowledge on the matter! It sounds like you will find a solution soon, and great work so far!

`Peyo` I was looking around for possible solutions and found out using back ticks like ` instead of straight up quotes like ' can cause an issue with matching. I checked and noticed when I edited the Nooz post that the edit has back ticks. Maybe using straight quotes is worth a try.

`Peyo` Tried the text tool and it looks like it works great so far! The only weirdness I found is it scales fine up until size 30 then it snaps back down to a smaller size. I am not sure if this is even an issue tho since size 30 is immense. I just thought I'd bring it up in case it might be handy to know.

`Peyo` Interesting and I appreciate the insight! However there's nothing wrong with the site being made this way. That method describes the entire AAA Gaming industry and all products by Autodesk! The difference being unlike the people running those corporations, you're actually an invested user of the product and doing it as a passion project, so I think this site will end up doing fine from a technical standpoint. You could actually just put your foot down and say no new features and the site is still the best thing going based on the tools and the ability of users to protect their work from vandalism. It's really great! I appreciate it a lot! I was a little confused by the group feature at first but then I realized it was really allowing you to title things as a series, then I was like "Oh nice!" Good feature!

`Peyo` I'm sorry to hear it's not working as you wish but figuring out how to reliably do an exact string match is something definitely worth getting down. That's gold!