Here's something for the future thinkers.

I strongly believe that if we're going to keep the community alive and productive past the relatively simplistic 16bit generation (besides the few ultratalented), we must find a way to lessen the learning curve in order to cultivate talent.  A few goals I feel we should be looking at:

1) An up-to-date user friendly document covering the process of videogame translation and every general aspect.
2) Improving the quality and presentation of documents.
3) Utilities that cooperate seamlessly with each other with the purpose of solving problems.
4) Utilities that reduce the difficulty of problems.
5) Utilities that are easy to learn.

From my personal contributions, Atlas in itself was designed to reduce the number of games that needed custom inserters.  This somewhat lessened the learning curve (it's easier to use Atlas than to learn to program, at least in my opinion ), but is definitely far from achieving a short learning curve for translation romhacking.  ScriptCrunch is certainly poor when it comes to #5, but is decent for #3 and #4.

Nightcrawler's table standard will hopefully help #3 in the future.  I am personally hoping to improve upon #1 and #2, but I don't have anything fully complete at the moment and this takes quite a lot of time.

So what does everybody think?  What are some ideas on how we can achieve those goals for the better of the community?  Or what are some goals that I've missed regarding the translation side of romhacking?

The problem here really is that many people think rom hacking would be fun and exciting every second of it. They're the low-skill crowd that comes, sees they don't understand anything and shortly leave.
It's just disheartening when you give advice to somebody and see it being constantly ignored (Rai, Lucario...). No good document will help those people, be it the language barrier or otherwise.

While I think that a new table format would be a good idea, I think heeding standards and being upwards-compatible would be great too. I don't think many people actually know what thingy's table format allowed and few tools support even half the range of it! So I don't get my hopes high that this will be adopted anytime soon. As long as new formats aren't upwards-compatible or at least support seamless conversion, people will tend to use old stuff that "sorta-works" for them.

That said, the reason that most things here feel 1998ish is simply because internationalization is not here. Yes, you heard me. Even when people use modern programming languages (Java, .NET...) they usually don't give a rats ass about Unicode support. Why? Because mostly it seems that people are just unaware, because the majority here really does only need the ASCII set and everything else is in "funny gibberish" ANSI that they could care even less about. While it's easy to have Unicode support (at least 3.0 and we currently are churning out 6.0!), most people just don't bother with it. So getting any character to display correctly in the dump becomes a challenge and sometimes you have to resort to ANSI for presentation. Not a good thing!
I'm not talking about Klarth in particular here, just clarifying.

We need programs that don't rely on command line usage and ASCII art with monospaced fonts only. We should also adapt modern vocabulary. There are tons of misconceptions out there simply because many people ascribe different term to the same things. Tile, block, meta-block, texture, character, char (as in programming), byte, data word will be regularly used to mean the same thing, yet sometimes mean different things.
Personally I think, anybody who still lives in the 1 byte = 1 char = 1 character world just isn't ready for modern systems yet. There is also much confusion about the native graphics formats of some 8 and 16bit consoles and what those should be called!

Maybe a break with "traditional" terminology will actually help newbies understand everything better. Also, for presentation, it usually pays off to have a standardized layout to describe file formats and so on. Pretty much just like major companies have the same or very close to the same layout for every CPU they build, for every opcode they describe etc.
While I like to work with text files, there is certainly nothing wrong with having a searchable PDF file in it's stead that has nice diagrams and standardized presentation of data.

But yeah, I think in the end, it all really comes down to the individual person. Some people can deal with this and learn much stuff, others would literally need to be taken by the hand and explained everything in great detail. In my experience, the latter usually have a problem with math in general, making it even harder to explain the most basic concepts, i.e. hexadecimal, binary, offsets, addresses.

While I think ASM can get pretty complex (and everybody involved here should probably know his fair share about that), I think it's really something that can easily be grasped with some programming background. I don't know what the huge deal is with ASM. It's just a bit more low-level than you're used to work with nowadays, however, it's quite powerful on modern machines and it's basic knowledge about ASM ― as opposed to knowing a certain set of opcodes for a certain CPU ― that is applicable to most other CPU opcode sets as well. You know one and you know them all. I think this is emphasized in many documents, yet, people get very confused about very basic stuff, simply because they don't see their options. And don't forget, all of this is properly documented on Wikipedia, in Wikibooks, in countless PDFs, DOCs, HTMLs out there with pictures, diagrams and much explaining text and people still don't master it.

In my recent experience at university, I can only say that I really see some big idiots being interested in, and even studying IT. Most of my fellow students couldn't maneuver their way around an English document if their lives depended on it! There's a huge crowd out there that just simply is inapt to do this, although they may be interested. Can't find info on their own, don't have enough patience to read documentation properly, can't use Google to find some really obvious places for documentation. For example, a student I had to work with couldn't find the Java API online. He claimed it just "simply isn't online" and I was wrong to think that such a useful document would even be online in the first place. Another guy claimed that some info wasn't contained in a document he searched for over an hour (while I did the rest of the worksheet... 9 out of 10 exercises). Needless to say, I went CTL+F on him and found the info in less than 10 secs ― those are the peeps we're talking about here. So it all boils down to the fact that the smart kids will learn even with bad documentation or no documentation at all, while the kids that need personal tutoring pretty much won't learn this if you don't force them in some way ― even when they want to learn it themselves; they simply don't know how. The latter are also usually the kind that will change some stuff, break the game and never touch that pointer/value/data again, because "it's dangerous" and "they're afraid of breaking something".

So yeah, while we certainly could and should produce compatible stuff in the future and have less confusing lingo, the newbies themselves play a vital role in this. Nobody can be taught to succeed at something. The proverbial light bulb will have to turn on in their heads and can't be forced on from outside.

cYa,

Tauwasser

One of my dreams is to build a ROM management utility. It would look mostly like a hex editor, but it would have a sophisticated bookmarking system. For example, you could mark a certain chunk of data (say 0x1000-0x2000 in the file) as GBA graphics, and it would hook into a graphics viewing/editing utility for that chunk. I think having a good view of how a ROM is organized would be useful for ASM hacking as well. The ultimate purpose though would be a flexible data description format. That way you just describe how the data is laid out and the utility can use it to make an editor GUI. This could easily handle stuff like item data for RPGs and character stats. It might be more difficult to make it do things like edit level maps, but I still think it's possible for this to be handled at a near-universal level. Also some sort of "free-space" manager would be really nice. Ideally you could just mark a certain token in your ASM files and it would compile at the right free space, adjusting all relevant pointers.

To summarize: I think a centralized ROM hacking environment would do a lot of good. Thoughts?

I notice a lack of documents covering certain things. For example, documents might tell you how to use utilities or hex editors but one really needs to understand how to use command line programs and how to create a batch file to compile their ROM from scratch. Many noobs just open up a hex editor and start translating and rewriting pointers by hand. This is what I used to do but I think there needs to be a document that explains better why the more advanced hackers do things the way they do and how to start moving towards that.

That's not the issue here, it's about new people and not the old farts

(Just mentioning this before this gets side-tracked into another discussion about the merits of 8 bit stuff yadda yadda)

You mean something like this?

Out of all the time I spent thinking about this using a standard format like XML never even crossed my mind. I was making up my own format that's similar to table file format, but you bring up a good point I think: a standard format should be used. That said, I don't think it should be XML because I'm not sure the complexity is necessary and it's kind of a pain in the ass to work with. What I'm leaning towards right now is JSON. The more I think about it, basically everything besides graphics and ASM stuff could be done really easily in Javascript. With a simple PHP script or something graphics shouldn't be too difficult (hell, plug in to FEIDIAN) and I can even see an ASM disassembler being possible. This could all take place on a localwebsite similar to TiddlyWiki (which I've had some luck using to take ROM hacking notes with) or in a centralized place where hackers can share all their findings! And of course standalone utilities could use the standard format as well.

Edit: Perhaps we should split this discussion into a different topic? Others seem to be focused more on the documentation side and less on the utility side.

I think the guides that are up now are great, I learned so much from them. Especially the basic newbie guides and the Romancia VWF guide.