Program Design and Data Structure (TextAngel)

[Klarth]

To handle string counting dumps, I'd probably make a special case for PointerTableToStrings (if I have the var right).  One case for where subpointers == stringcount and one for subpointers == 1 (or 0 if you have it setup with a base location pointer).  Start/stop dumps aren't really meant to be handled in this framework, so I'd probably create a new node type for it.  That way, users can keep adding text dumps to the configuration tree and eventually have a tree that represents the game's entire text...and can be used if they need to redump.

Starting to look pretty sweet on the screenshot side.  The tool could be very popular if you add in text editing and would be quite easy to do if you stick with XML internally.  But that's down the road.

[Nightcrawler]

Now that I got the extremely long side tangent of the table standard mostly out of the way, I've gone back to this.

As you can see from this image, I've now got the program set up revolving around a project tree. How it works right now is you select the file/s to dump from. Then you add  any combination of building blocks you'd like. The building blocks (StringTable, PointerTable, PointerTableTree, PointerTree, AutoDiscoveryTable, PointerList, Pointer, and String) available cover all possible functions my dumper is able to do. Any combination of those items can be added to the files to dump whatever you need in the fashion necessary.

This by itself could be tedious depending on the situation. For instance, my Herc4 example contains decompressed data files 'decompX.bin'. In each one I simply want to dump the contents. I don't want to have to add StringTables to all of those files individually. So, I have a shortcut option 'Add to all Files' so I can add a newly defined building block to all files at once. That solves that. All of the building blocks will generate and dump associated subblocks or strings that may be necessary. So now whether you're dumping from a single ROM file, or various other data files, you can set up and dump sanely so far. It seems OK for the situations I've tried with it.

Where I have once again backed myself into a user interface design corner comes with insertion. With this hierarchy, how do I insert? By default the hierarchy is set up to insert directly back into the same files and places the data came from. Maybe that's OK for a single basic ROM, but that's not desirable for data files or any relocation. How would I go about inserting all those strings into a new set of files other than 'decompX.bin'? How would I go about putting all of those strings directly back into a single ROM file instead of multiple dump files? You can't just start with a clean slate and redefine all file and tables because you want to keep the dump hierarchy, all those strings, and the text edits you just made. I couldn't think of any sensible way to easily accomplish such simple insertion variations. That makes me think my hierarchy perhaps should not descend from files as it does. However, when I go down that line of thinking, it seems to make the dumping interface more complicated if it does not descend from files. I thought of having the file be simply an attribute to the building blocks. However, it seems to make logical sense to me to just select a bunch of files and tell it what to dump from them rather than create a bunch of blocks (that may all dump from the same file) and tell it the same file all the time.

It's true, engineers do suck at user interfaces. Any ideas? I can see why everybody else just uses an external command file and skips all this.

[DarknessSavior]

I know it probably won't mean much coming from me, but I like that interface. A lot. It looks kinda like byuu's interface for FoEZ, but obviously more complicated because it's not just a script editor.

~DS

[BlackDog61]

Hello,

I am probably a year-and-a-half late, and still using my humble talents. Bit I thought it may help keep the design discussion up.

As you said, I believe it makes a lot of sense to keep the visual hierarchy the way you have so far, because it represents very well the "dumping" operation. Purely from a user interface perspective, this inspires 2 thoughts:
- why not try and deal with the "inserting" operation in a different view (that you would probably not use so often), where the hierarchy is reversed, i.e. your strings are on the left, inserted in blocks and blocks into files, but this time the files are the ones used for insertion? This way you could drag'n drop blocks if you want (if you have the "target file for insertion" data at the block level). Or you can keep things at the file level if you so want. And you can always have a "right click menu option" to change the target insertion file for all selected items, to work on several elements.
- (If target insertion file is managed at the original file level) You could very well also show the target insertion file on the "dump" hierarchy, even if it is not interactive.

I hope this helps, and if it does not, sorry for bothering you.

I wish you a great day.

[Nightcrawler]

I have made a number of changes since then to continue in the direction of encompassing a project. There are now 'Group' nodes that the text nodes derive from rather than files. I decided the focus of the program should be the structure of the text and that structure should be stand alone in the program. The power of the program is providing the generic methodology to represent any type of text structure. So, what file/s the strings are taken from and/or where they are going is more of an import or export operation. Mind you these import and export operations are still complex and important operations in their own right. They are simply decoupled from the main text structure and strings allowing for greater flexibility.

This made sense to me because you might be pulling your blocks and strings from decompressed files, you may be pulling them from a single ROM, you may be pulling them from ISO files etc. You may even be importing strings from an external text files dumped from something else. The same mentality is being applied for insertion. You may need to insert to separate binary files for each block to be used by an external tool or assembler for your project. You may want to insert everything into a single ROM, or you may need separate files per block etc. Maybe you want XML for post processing. Possibilities are many.

So, by making these import and export type operations, you're not placing any restrictions on usage. You also can have separate interfaces more appropriate to these involved import or export operations. Perhaps, some of that could even be farmed out then to plugins or external tools.

The file information is no longer in, nor is critical to, the hierarchy. Only the independent text structure and strings are there. So, once they are initially imported/extracted, you can edit and do as you please with it. Then, you can export/insert that structure and strings in a manner suitable for your project. I suppose it would still be possible to provide a view that would still show some sort of file hierarchy, but at this point I have not done so.

This utility is still in development, but has forcibly grown in scope to accomplish it's objective. Recent developments for it have been focused in areas my current translation projects needed to try and get those done, rather than generally completion for public release. I haven't even begun any documentation. So, TextAngel as a public utility has taken a bit of a backseat to my other projects which are also long overdue.

[BlackDog61]

I believe this is a very good choice indeed!
Abstracted UI from technical constraints is, in general, seen as a good user-friendly design.
Good luck (again  ) with this project!