If you are worried about low interest and all kinds of work going into it, I know it goes counter to your ultimate desires, but having it as a sub forum is always an option if it was just going to be a small insular community.
If it grows out from there you could invest that much more effort into it.
Hopefully though stuff goes well for you on the other sites and you do decide to go with the original plan though because yeah, peeps here are interested (which is the main reason throwing the sub forum idea back in the ring even if it isn't ideal).
The thing is, I did that before, and it did not end well. I don't know why, but being a subforum rather than a forum spooks users somehow. I really want to contribute to RPGDL in some way, but I know that a subforum won't work. Hence, my I-don't-want-to-make-this-painful-for-anyone attitude, and my insane level of preparedness/paranoia.
I did it with a SaGa Frontier data diving forum, and several other times with other projects for other games, only one of which is still only slightly alive.
Any collaborative media project which wants to suceed must make it as easy as possible for anyone - even the completely unskilled - to contribute. Part of making it easy for people - especially newbs - to contribute is to do everything you can to eliminate confusion. Sub-forums apparentally confuse the daylights out of newbs, so they're a no-go.
Also, this will work into my editor design demands, once we get some coders. The editor must be open source, cross platform, and it must be easily updatable (ie, gotta have clean and well-commented code) and as simple as possible. I believe simplicity can be achieved by first coding command line tools to do things like:
*de/compress different disk image formats
*extract/insert data from/into game files
*modify data tables in the game files
*rearrange data files within game files
*rearrange/delete/create new game files while updating the file system in the disk image
*increase or decrease the size of game files
*de/compress text and event data
*de/compress music and image file formats
*extract and reconstruct image and sound files
*import common file formats
*change raw image and sound files into a format the game can use
*parse and dis/assemble internal game-specific scripting languages, which may require another tool to:
**dis/assemble PS1 assembly language
The goal with these command line tools is to make one tool for each task, or at least make them share tasks which are related, like de/compression. Once we have all the tools, we can create a GUI (possibly using the phoenix API - application programming interface - if the editor is written in C++), and then create a set of scripts which link "moving parts" of the GUI to specific commands for specific tools.
I'm no programmer, but that is what I gathered by reading posts of people who program editing tools and emulators.
The other important tasks are:
*Investigation,
*Documentation, and
*Reverse-engineering.
All of which are required before we can continue to the next most important set of projects, which are:
*Optimization,
*Rearranging, and
*Expanding -
All which will eventually allow us to add the new capabilities to SaGa Frontier. But this is so far ahead, and there is so much to do, that there's no point in me talking about it right now.
EDIT
I forgot to mention, but trivial things in the editor - like the names of abilities and items, as they appear in the editor, along with various flags and bytes, explanation, and directions - should all be configurable through plain text files in the SF editor's home folder. Also, I eventually see an additional number of low-to-mid level tools/scripts which will integrate actual changes to game text - like changes to the names of main characters, for instance - into the text of the editor.
