To those of you who haven't looked closely at the editor in the last five or six months, there was an update released that introduced a powerful new concept - frame presets. A frame preset enables you to take a frame in the editor and save it as a preset. That means that there's a menu where you can click to insert a frame identical to the preset. However, this has a few limitations. The one that concerns us here is the selection menu.

At present...* Each preset appears in the dropdown, described by the text dialogue when the dropdown was created. The only way to keep "Apollo Objection" and "Klavier Objection" straight is if you give them different dialogue when you save them as presets. But why are you giving them dialogue in the first place?* Once you have a preset, you can't see what it will do without creating a new frame from the preset. While creating frames is cheap, you have to do this for each preset.* It's impossible to modify existing pre-sets. If you forget the [#s] from your objection preset, then you have to create a new preset rather than change your own one.* Combining the first and third problems, it's impossible to rename a preset!

These are issues worth improving, if possible. Personally, my biggest concern are problems 1 and 4, the inability to rename presets, and that presets are always named by their dialogue. This topic is here to discuss possible improvements to the system.

My first thought for an improvement is the following:Create another tab in the editor, similar to frames, that only displays presets. The frame id section will be replaced with the name of the preset that will appear in the dropdown menu. This will be changeable. The preset itself will also be changeable, so future uses of the preset will use the "edited" version than the old version. These changes would probably be concurrent with a change to make these presets permanent.

Any thoughts or alternate proposals? Your feedback will affect what this feature looks like!

[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson

I agree with this proposal overall, it's the natural evolution of the basic frame preset mechanism I put in place.

Regarding the preset label, I had another idea though : some people had mentioned it would be nice to be able to add programming-like comments to a frame, that is, text visible only by the author and ignored by the player, in order to keep some information about how complex structures work.If we do that, I'd suggest that a preset should use its comment (or a truncation of its comment) as label, instead of the frame text.

Also, if we want to have a browsable and persisted list of presets, it's actually quite simple in theory (mostly reusing the storyboard code) - but we should enforce presets to have a unique integer id. Currently, it's set to null, and dynamically replaced by a real frame id when instantiating the frame, but to reuse the storyboard code we need a numeric ID.As for displaying the frame name instead of the ID in the UI, it'd still be possible - after all, we do need to render presets in a slightly different way than frames anyway (since we don't want insert buttons and such) so adding one small difference is not a big deal.

I definitely agree with Enthalpy's idea of having another tab that only deals with your preset frames, but Enthalpy, when you say "similar to frames", do you mean having a new button next to the "Insert frame button" in the Storyboard? Or are you suggesting a new tab alongside the Characters and Evidence tabs?

Spoiler : If you weren't suggesting the latter, then... :

I would propose a new tab that acts as the Characters and Evidence tabs, except now the author can make Preset Frame objects.

Like how you don't have to insert a new picture every time you want to show a particular piece of evidence, along with being able to edit the name and information about that piece of evidence without having to re-insert it, having these features with PFs would be very useful.

This would also solve every problem that you've pointed out in your asterisks:

1. The dropdown menu for all your preset frames would have their own custom name. The Apollo Objection frame could simply be called "Apollo Objection".

2. You could easily look at the new PF tab and see what each of your preset frames do. Also, since you can custom name your PFs, it will make it easier to remember, so you won't even have to check. You could have an "Apollo slam desk with shouting" frame and a "Apollo slam desk with angry sound" frame.

3. If you change the preset, all frames of that preset will change in exactly the same way. You don't have to worry about each individual frame you've inserted into the editor.

OR

All the presets you've previously used are permanent and must be changed manually. All future uses of that preset frame can be modified.

In addition, the Editor currently remembers all the frames where Evidence X was used. In the same way, if you want to delete all the frames of a certain preset, the Editor will be able to tell you which frames they are.

In summary, if a Preset Frame was its own object like how the editor currently handles a piece of evidence, it would be more flexible to use.

If you WERE suggesting this new tab, then ... well I suppose I'm repeating the original idea. At the very least, I think I've shown just how useful a new tab called PFs could be.

Either way, I do agree that the Preset Frame function can be greatly improved with the original suggestion.

About my avatar: That is literally a picture of my dog. I edited in the red-eye.Picture was taken in the evening with no flash, and that's how it turned out.

@ Unas: Ah, that makes sense. I'd have to familiarize myself with the storyboard code before working out an implementation, but it doesn't sound too bad. As for comments, how would we do that? My first thought is to create a new "comment" tag. Comments would, more often than not, be sparse enough that I can't justify to myself giving them space on the frame div. If comments were their own field in frame objects, we could create a button in the dialogue-div to switch the view from displaying dialogue to displaying comments. However, unless there's some master "turn all to comments" option, that makes Ctrl+F searches on comments very difficult. It also would complicate viewing comments and dialogue at the same time.

I'm open to other thoughts on this, but my instinct is to implement comments with a tag, and only create an alternate field for developer commentary. The name of the preset in the GUI would then be the contents of the first comment tag, defaulting to the preset ID if no comment tag is found.

@ HellPuppy: The plan is to have it as another editor tab, yes.

[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson