This was the first instance of text in the file TOWN.DAT 
address references for those who may need it.

in sorting through about 94.6 MBS of hex, i can say the following about all the .DAT files on disc 1:
BATTLE.DAT --> Some in-game textbox data found (not much), mostly algorythms and such for battle.
EVENT.DAT --> A few strings of text, not much else. Seems to be automated scenes players have no control over.
SCENARIO.DAT --> Story outline listing and random strings of text (fair amount) It lists all the chapters of the game, pretty interesting layout.
SYSTEM.DAT --> Mostly menu data and memory card dialogue.
TOWN.DAT --> Great deal of dialogue/text stored here. (main script with lots of text)

I suppose few read my document.

http://www.nobis-crew.org/cd-tool/

Wouldnt It be to hard to ask to do the menus and skills and stuff first to at least make it a little more playable?

Probably because this looked better on paper than in practice. As to the latter question, I think you're wanting an FAQ.

Right now the project seems stalled because nobody wants to code a font dumper and/or a script dumper.

There you go. THAT is where modular and/or object oriented concepts can save you a ton of time. The core table handling and dumping functionality is the same for all games. You shouldn't have to write a totally new dumper. If you plan out a table handling class and some basic dumping and inserting functionality, it's only a matter of writing a small bit of code to adapt or handle something special about game x.

I've been there man, writing something completely new for every task in every game. With some smart planning and modular or object oriented code, you can writing a core ONE time and use it on all of your games. It can save you tons of time.

Quick example. Create a table handling object. This object will be able to load a table up into a key/value array or however you handle your tables. It can set it up for dumping or inserting lookup and will return the desired value. There you go, now you never need to write table handling code again. Every game will use a table and every game will look up a value. If some games use two tables or do something extra, you can extend your classes functionality to handle multiple tables if necessary. The whole point though is you're never writing code more than one time. This object should be able to handle any table for any game. You'll reuse those functions or that class for every game.

If you have that codebase, what's necessary for a script dump for Black Matrix 00? Assuming you have decompressed text, not much aside from having your program be able to locate all blocks the dialog text to dump for that game. Beyond that, you just run it through your table class and output the results.

Look at Atlas.. ONE codebase, yet it can handle script activities of so many games. Why? Because it was well planned out and coded in a modular fashion. You don't need something that flexible, but it's a good example of the benefits.

You spent all those hours to get a dumper working right. Don't pour all those hours in again if you don't have to.

I only lecture because I care. I have also taken a bit of a personal interest because I was in your exact position before. I was late to the table for learning how to program 'the right way' and really taking advantage of well designed code and object oriented, or just plain any reusable code model. Then I saw the light and experienced the HUGE time savings and benefits it has when it comes to organization, readability, and ease of modification. I am trying to help you see the light as well because I know you're doing things the same way I used to.

I know exactly where it comes from as well. These are common pitfalls to self taught programmers. You only know what you've learned and many times are oblivious to better ways to do things until you discover them somehow. The only reason I know any of this stuff is because I've had more years of trial and error to see the error of my ways and come across better ways. I even had an object oriented C++ class years ago, but it just didn't click. I understood the concepts, but the advantages just didn't dawn on me of why that was reallu any better than what I was doing already. I still could write some poor C++ code. Finally, things started clicking. It's not even the type of language that's important, but your own program design and programming model that makes the difference. Using an OO language simply helps bring out the best in that aspect for many people by making it easier to make a smart model and design. It certainly does for me. My designs are pretty messy in procedural languages despite taking time trying to think out a good design. I did the same damn thing again with this site when I originally coded it in procedural PHP. When I switch to an OO frame of mind, much better designs come out of me. Thinking in those terms somehow results in a much better design through process in my head.

It's just a matter of growing as a programmer and using some tools make that easier to do. I gave you a C# table class example in that other topic. It should be simple enough to help you see some benefits of having something like that.

I know you're using C#, but the concepts of OO design are pretty much identical. I don't know of any links with C# examples that really show why or how to use OO for program design off the top of my head. Most are simply the generic C# tutorials. But they don't really explain program design and how to design your objects. I'd just do a general search on google for object oriented program design. The language is really irrelevant other than syntax and how to specifically accomplish programming tasks. That's really a different thing though.

OO Advantages Overview