folder structure is not very convenient

[Awuwunya]

Lets say I want to edit an object. To edit its code, I need to go to the Objects folder, and search for its code file (or worse - multiples!) Then I need to navigate to Mappings to edit its mappings data, and I need to go to Animations to edit any animations it has. Then I have to know whether its graphics are compressed or not - and go to either Graphics or Graphics - Compressed to edit them. Finally, I need to go to Palettes to find its palette. And quite likely, I yet need to go to hunt where the heck could Sonic's DPLC file be in case I need to edit that. The only files to have unique file extensions are the art (thank you for finally at least doing that much!), so I then also have to choose the program to use from a dropdown list or similar, rather than having the OS automatically choose the program I want for this file.

Editing anything for a hack is a terrible experience when you have to do this over and over again. This is 2021, not 2005. Can we not have file structures that are sensible?

My proposal on how to deal with objects is roughly following: Object/ObjectName will be a folder that contain all the data associated with an object (some obvious exceptions may need to be made, of course.) They would contain files such as the mapping, animations, art, palettes, code, any misc data as well. Files that are used in multiple places could be symlinked (although, this could provide an issue with Git/users computers, but its worth exploring) so that the file is only once in the hard disk, but can be accessed by the user from everywhere. Otherwise, there should be a system in place to put these kind of files in sensible locations and making it easy to navigate there. And the names should be updated in accordance to this rule of course.

Levels and game modes should have a similar treatment, though again, specifics would need to be thought over.

I am absolutely sick of this terrible, impossible to learn, mishmash of an unusable structure. The current Github disassembly is already bad enough with this, can we please finally have something more sensible for the end users? Something intuitive, convenient and fast.

Thank you for coming to my TED talk!

[Brainulator9]

If it means anything, I'm pretty certain mappings and animations were included as part of the same file as the main object code, going by Sonic 2's code (where there are branches-to-jumps aplenty, with those jumps being at the end of a file, often padded to the nearest longword). So it seems there's some precedent to having things closer together. Then again, going by this, animals and points would be the same file... which may be either confusing or helpful.

[DevsArchive]

With this, I also propose that we should split out common engine functions into their own folder, especially the ones in the "Objects" folder.

[cvghivebrain]

I've been thinking about this recently, and I'm probably going to combine all the animation/mappings files with their respective objects like this. There doesn't seem to be any particular reason to keep them separate.

Palettes and graphics I'm not sure about. I'd prefer to keep graphics in one folder for batch compression.

[Awuwunya]

This will make it more difficult to use programs such as Flex2 to edit mappings data though, especially because they now have to parse and preserve a lot of unrelated data. It could also interfere with editing the code of an object along with mappings simultaneously

[cvghivebrain]

Compatibility with Flex2 was presumably broken when I started using macros for sprites.

Maybe I could add an option to use separate binary mappings files. So "binmappings=1" would make the spritemap macro incbin a file, and the piece macro would do nothing. Each sprite would then be its own file, instead of all the sprites (plus the sprite index) for an object being bundled together, which might be a more sensible way to do it since some objects share frames with other objects. Flex2 would just need an option to load a sprite without the index.

[Brainulator9]

Alternatively, Flex2 could just be given an ASM label to look for in a given file, seeing as it already has an option to provide an ASM label, though this would require modifying the program itself (which I probably could do with little issue, just time).

[cvghivebrain]

I've come up with a way to keep compatibility with everything. Basically I did what I said earlier, except each sprite file has a fake index of 0002 at the beginning, so Flex2 and SonLVL will see it as a normal single sprite. The fake index is excluded when incbinned. If no file is specified, it'll revert to ASM mappings as usual. I tested it on Yadrin and it seems to work.

[Awuwunya]

my point was sharing a mappings ASM file with unrelated stuff (code), not ASM files in general. Even poor old SonMapEd can parse ASM mappings, and supporting macros on newer programs shouldn't be too difficult