Tools to improve hacking workflow?

[nitwit]

I was thinking earlier about how much effort it would take to actually rewrite a set of routines, like reactions or forumulas.  Most of the difficulty even for an expert assembly programmer isn't in the programming itself, it's in managing all the information.  Everything you need to know is spread across hundreds of pages on the wiki, so first you need to manually copy and paste all those pages into a bunch of text files and come up with a system to document them and how they all fit together.  When you're done with that you must develop a build cycle so you can compile all these things, put them in the right place, and then get them into a disc image and test them.

This is suboptimal.  It's like trying to develop using build methods and techniques from the 1950s.  It's insane that we still do this in an era of free online source hosting with automated build tools.

Please note that I intend this thread as a discussion on the nature of these problems, and potential best practices and solutions.  I will present my opinion in replies to this.  I encourage everyone - hacker or not - to do the same.  My goal is to create a system where we can do the best hacking and programming with the least effort.  Do not be afraid to comment!

1. What is the ideal build cycle for an average assembly hacker?

2. What is the ideal build cycle for someone who wants to rewrite and optimize large portions of the game mechanics?

3. What is your current build cycle?

4. What tools exist to improve our build cycles?

5. What is the gap between the tools that exist and what would be ideal?

6. What tools, techniques, and protocols would lower the entrance barrier for assembly hacking?

7. What non-coding obstacles prevent you from setting up your ideal build environment?

8. Why did previous attempts at rewrites fail?

[nitwit]

1. What is the ideal build cycle for an average assembly hacker?

If you're just editing a few things you'll probably do much of your preliminary work in a debugger or a save state, then move to whatever is easiest for inserting your little snippet of code.  I'm not interested in small scale things so I can't comment.

2. What is the ideal build cycle for someone who wants to rewrite and optimize large portions of the game mechanics?

My ideal build cycle would be complete disassembles for a given file, hosted on a third party site like github, from which I can set up a local fork when I'm commenting the code or differentiating between a table and code.  By this I mean BATTLE.BIN would be one file (called battle_bin.asm or something), SCUS_whatever would be scus.asm, and so on.

If I want to build my own version of a given file, I would fork the entire repository (where the repo is every commented disassembly for this game) and make my changes as I see fit.

Once I'm done I call a command locally and assemble the file(s), then import this into a disc image.

3. What is your current build cycle?

I don't really have one as I'm busy with work and other projects.

4. What tools exist to improve our build cycles?

Github, for one.

5. What is the gap between the tools that exist and what would be ideal?

Doing the initial work of getting all the routines into a single file is a shit job that requires lots of copy and paste from the wiki.  A good one-time tool would be something to get all those comments and disassemblies and move them to a single file.  That single file can be uploaded to github, and then a team of hackers can get it into a state where it can be compiled.

Once it's compiled the wiki is largely obsolete, as it's easier to search for things in a single text file than in hundreds of wiki pages.  Getting to that point is the hard part.

6. What tools, techniques, and protocols would lower the entrance barrier for assembly hacking?

What I outlined above would be a huge leap forward, as it would put all the information into a single, central location (or several locations, one for each file that's being hacked).  It will be much easier to see where it all fits together when it's all one one page, and that says nothing of what we can do once EVERYONE knows where the free space is (because it's all commented), what routines are suboptimal, and we can use advanced features like labels for subroutines.

I can't speak for others, but seeing EVERYTHING and being able to look for patterns was the first real flash of insight when I first learned how to program.  It shouldn't be that hard for someone that has experience event scripting or doing scripting for other games to get into assembly language once they can actually see (for instance) how many formulas are repeats with only one or two things changed.

7. What non-coding obstacles prevent you from setting up your ideal build environment?

I think I covered everything.

8. Why did previous attempts at rewrites fail?

From what I've heard and read previous efforts were done in secret, by a few people or a single person, without revision control, were stretched out over time, and were worked at intermittently.  The non-public nature of these efforts allowed bad blood between members to cause data loss, which further increased bitterness, which may or may not have been merited.

It's inevitable that people lose interest and move on with their lives.  Some people do this peacefully, others are compelled to lash out and burn bridges, and some people with for whatever reason like to troll other people into doing these things.  It would be very wise to allow for this in the systems we create so that we can survive these events with no lost data.  Our world isn't ideal and we should prepare accordingly.

[3lric]

1) It's weird that you are answering your own questions

2) The people who make mods here, already know how to do what they want to do. In case you haven't noticed, there is like, maybe 10 active people on this site who work on things. You aren't currently one of them.

[nitwit]

1) It's weird that you are answering your own questions

It's standard form not to provide your own opinion in your initial post asking for opinions.

2) The people who make mods here, already know how to do what they want to do.

Good, then they won't mind if I ask other people!

In case you haven't noticed, there is like, maybe 10 active people on this site who work on things. You aren't currently one of them.

I wasn't aware that it was FFH policy to limit discussion to those who are active hackers, especially given that:
1. I'm a programmer and not a hacker,
2. I already made a tool for my own purposes and shared it with people on this site, and
3. If this site is so inactive, then my post in reply to my OP shouldn't be a huge burden on the servers.

I encourage you to revisit your posting policies regarding trolling and what constitutes harassment.

[Lionheart537]

Would reorganizing the wiki be easier than compiling the information on a 3rd party? I'd vote the most user-friendly option for community sharing. I'm pretty new here so I can't really voice an opinion on the current efficiency of information storage.

[nitwit]

The issue is that we are getting closer to complete documention of some files but we lack a means to assemble them as a whole.

If files like battle.bin and scus_* were in a state where they could be assembled, you wouldn't need FFTPatcher.  You could edit the data directly in the text file which would be assembled to produce a new scus_*.  For some things you'd need a spreadsheet to do that more easily, but it's trivial to make a spreadsheet from which you could copy plain text bytes.