Drag-n-Drop aseprite files?

[russmatney]

Hey there! Thanks a ton for this plugin, it rules!

I got annoyed at having to go through the whole file tree when selecting a source aseprite file, so I managed to make drag-and-drop from the FileSystem Dock work in my own project.

It's all in a commit here: https://github.com/russmatney/dino/commit/e7ab71e176f3ac32d07707164d5537a0e102b9cb

Note that you'll also need to add ase and/or aseprite to TextFile Extensions in Editor Settings > Dock/FileSystem to see Aseprite files in the FileSystem Dock itself.

There's a bit more potential related work:

• validating the extensions in _can_drop_data seems useful
• supporting more than just the AnimatedSprite2D type
• I have a feeling the aseprite file godot import plugin can opt-in to showing those files in the editor, rather than having everyone update their editor settings

I can take a shot at a PR at some point if you're interested in a feature like this! I'm not sure when I'll get to it (maybe in the next month or so?), so wanted to share the commit and thoughts... and feel free to impl it yourself if you have the time and interest!

[russmatney]

To update re: .aseprite files showing up in the file-tree - I hadn't opted in to the auto-import features of AsepriteWizard yet, but I've learned now that doing so gets the .aseprite files to show up. Maybe a refactor to support showing the files by default, and moving the 'auto-import' feature to a branch within the import plugin's implementation makes sense as well.

[viniciusgerevini]

Heyo! Thanks for looking into it and sharing your findings. A feature like that would be much appreciated. Searching for files in the files system is tedious indeed.

I think adding to the TextFile extensions to show it in the doc is not a good idea, mostly because Godot tries to load the file in the script editor and throw a bunch of errors because the file is not really supported as a text file.

You are right auto-import already allowing drag-and-drop directly to the frames field. That doesn't cover AnimationPlayers though, so implementing a default empty importer might be a good idea. If that's the case we could remove the importer configuration from the project settings and set two different import options, the default one being the stub that doesn´t do anything and the other one the SpriteFrames importer, which can then be chosen as the default if people wish.

I don´t think that's too bad. Feel free to have a stab on it. I might look into it whenever I have time, but I let you know here so we don´t step in each others toes :D

That also makes me think on a different solution that helps with the problem. You know how in other fields in Godot you can load a file or select "quick load" which shows a list that can be filtered? Regardless if we implement this import feature I think it would be cool to have this option as well. Personally, I use that more often than drag-and-drop. Not sure how much work it is though. If Godot doesn´t have the foundation for the list with filtering it might be a lot. Anyway, it's definitely something separated from your proposal here.

[russmatney]

Sounds good! I’ll keep poking at this in my own project and let you know how it progresses.

I struggled to get an ‘empty’ importer working without running into issues yesterday - Godot doesn’t seem to like imports that don’t add a file to .godot/imported/, and seems to always create a *.import file for each aseprite one, so it gets messier than it’s worth (vs the textfile extensions version). Hopefully there is something I’m missing…

i think the quick load ui makes more sense and is probably more useful than the drag and drop anyway - i also want to learn how that is implemented, so i’ll check out next.

[russmatney]

Just saw your PR, it looks good! I'm about to pull and mess around with it.

I also was able to toy with the Load/Quick-Load style import on another project this week, so I'll take a shot at it here next. Some details on that if you want to just go for it: it's called an EditorResourcePicker, and I had to create a class extending it to be able to add it to the UI (I was toying with it on https://github.com/bitbrain/pandora but did not end up opening a PR for that use-case). It can't run at game-time, only editor-time, but it should be fine if it's limited to the inspector itself. I think a noop importer is actually necessary for it in this use-case, b/c the EditorResourcePicker expects to import a Resource of some type.

[russmatney]

I had some success with this commit: https://github.com/russmatney/dino/commit/55091fccdf9d232409d99ce1b5cebd5d8bbeb5c2

I was wrong about subclassing/extending the EditorResourcePicker, it can be used directly. I specified the PackedDataContainer as the base_type to match the new noop import's created type, and with that, the picker's Quick Load option pulls up the fuzzy-finding search modal, which is great. For now I connected that back to the existing path-based flow (vs a potential new resource-based one).

Unfortunately the resourcePicker did not automatically populate with a resource name and preview - maybe that comes from a fuller aseprite import, or maybe it's some other component, or maybe i'm doing it wrong? Anyway, the flow is pretty great for now, tho slight wonky in the UI (with two 'buttons' as siblings).

[viniciusgerevini]

Thanks for looking into it Russ. This is quite useful information I can apply to my other projects as well.

I was thinking on what you said about the resource pickers and I have some concerns.

First of all, the resource type PackedDataContainer does not guarantee the file is from Aseprite. I guess there is no way to workaround that by limiting the extension to aseprite/ase? If other plugins are using the same resource that list might get crowded.

The second thing is that different importers will create different resources. The noop importer generates a packed container resource, while the other one creates a SpriteFrames resource. In the future we might implement packed scenes for Animation Players. There is also the case the person manually sets the import to the built-in "Keep", which would cause the file to not appear in the list at all. I guess technically someone using the dock wouldn't be using automatic importers, but people work on weird ways haha.

I guess we could implement our own selector based on the file system, but that feels like a lot of work.

On the bright side, your initial drag-and-drop suggestion works pretty great. I've never realised the file system dock had fuzzy search before:

[russmatney]

No problem! I'm quite curious about these better UX options myself, so am happy to dig into this kind of thing.

Yeah, agreed this isn't perfect or necessarily shippable yet (tho I am using enjoying using it in my own projects already).

Some thoughts on the issues you mentioned:

• The noop importer could instead create a custom resource type (AsepriteDataContainer, some class that extends PackedDataContainer) - that would allow something more specific than just PackedDataContainer.
• The EditorResourcePicker's base_type property supports multiple classes, separate by commas - so something like AsepriteDataContainer,AsepriteSpriteFrames would show only the imports created by either importer (maybe we could get a 'path' back from AsepriteSpriteFrames?)

I'm not sure the right move, just some details to noodle. Maybe there's a quick win that's worth it in there.

I've not yet worked with the other 2d animation classes, but I know I should, to better inform the workflow here. (Especially with the AnimationMixer coming soon, sounds like it's a combination of the AnimationPlayer and -Tree).

[viniciusgerevini]

Yeah, I thought about the custom resource alternative, but one of the principles I've been following for this plugin is to have it as a dev dependency. If the user decides to use something else they can just remove the plugin and everything that was imported before will continue working. That won´t be true if it uses some custom resources.

It feels like a big shift for a quick load feature. Also, that's something to validate but I wonder if the drag-and-drop to an AnimatedSprite node would still work if the generated resource is a subclass of SpriteFrames.

[russmatney]

I didn't think about the cons of the Custom Resource type when dropping the addon, that's a good point.

Thanks for the updates with the drag and drop and file picker! Closing this for now. Maybe some resource-less/file-based quick-load picker will come along at some point.