Tulunk Village

kmeisthax wrote:...You've never heard of Python?

It's just, well, PHP is annoyingly unreadable and a cruddy language. I don't like it.

Sorry but I disagree with you, and so do alot of other people for that matter. As for unreadable, that's just the way I wrote my code in this case, not php in general. This is because I wrote several lines of code in one line. Twice (I wasn't really intending for it to be readable). Plus the forum annoyingly stripped most of the whitespace from my code when I posted it. <_<

Differences in server-side languages aside I hope your question routine hack works out.

Okay, so I had an idea today, which I think is going to really help the patch and future Team Tulunk (do we even have a name?) projects. One thing I've been calling for a while is better tooling; we currently have just a text inserter and everything else is done by opening up a hex editor and manually assembling all of our code patches. Well, I just wrote (er, almost done writing) a script which parses xLink map files and overlays the relevant sections onto a base ROM. What this means is that now we can just write our patched code in RGB/ASMotor and have the assembler/linker machinery build our code patches for us. And, as time goes forward and we have more stuff in this new patch tooling system we can accomplish bugfixes by just altering our asm files and producing a new patched ROM.

The goal over time is that the target that our ROM hackers have for achieving modifications is the patch source, rather than in progress testing patches. And instead of having two ROM hackers continuously releasing patches that force the other guy to reimplement their work, they just push nice git commits around on the patch source files and stuff just works.

I plan to use this system to produce my next patch, as a proof-of-concept. Then I want to port all the hacking we've done so far over to Speed Version, but in the new system. So then we'll have a patch source for the entire project. And then having the patch build Power or Speed will be a simple matter of swapping out some include file somewhere which makes a bunch of variables that hold the relevant patch locations change. So basically what I need is a semi-comprehensive list of the things we changed, so that when I go and find those functions and port the patches over I don't make stupid mistakes.

Not sure how I could use this though. I write all my assembly as raw machine code.

Version 89:
http://wikifang.meowcorp.us/etc/TPatch89.ips

* Updated Kimbles' translations
* Corrected evolution graphics which were crashing before.
Check out Wikifang for exact changes. Props to PrinnyAce for reminding me to fix it!

wrote:Team Tulunk (do we even have a name?)

TULUNK VILLAGE ALL STAFF

wrote:One thing I've been calling for a while is better tooling; we currently have just a text inserter and everything else is done by opening up a hex editor and manually assembling all of our code patches.

I wrote punika.py!
But yeah all that sounds real cool.

So, I went kinda overboard writing this; Basically I'm having to rewrite the entire linker because I grabbed a much never version of my assembler of choice's linker and it doesn't support mapfiles for some reason. So in the middle of that I got tired of writing file format parsers for the object code format, so I decided to write an entire declarative structure parsing framework in Python. You just inherit from cmodel.Struct and declare fields, and it parses it for you. So I have about half of the object code file format done in this now, I just have to write up some extra support so I can do the fixup tables, which are stored as RPN expressions in a weird opcode format. For that I need to finish cmodel.Union, which lets you implement parse switches (i.e. opcodes with variable size operands). Then I'll post the whole script here because it's really useful for writing parsers. You just do this:

class XObj(cmodel.Struct):
. magic = cmodel.Magic(b"XOB\x00")
. numgroups = cmodel.LeU32
. groups = cmodel.Array(SectionGroup, "numgroups")
. numsections = cmodel.LeU32
. sections = cmodel.Array(Section, "numsections")
.
. order = ["magic", "numgroups", "groups", "numsections", "sections"]

(or something similar) to make the format you want. (Sorry for the dots, BBCode doesn't really mesh well with languages that have significant whitespace.) But basically this is a really nice framework for dealing with every binary format I can think of so far (at least ones that can be read in linear order).

I think I have a solution for the whitespace issue. Replace your tabs with "&nbsp; &nbsp; ". Apparently html entities aren't escaped in submitted posts on this board.

Example:
1 Tab.
2 Tabs.
3 Tabs.
4 Tabs.

---

I could dump all my asm from bank 34 and comment it all if it helps any. *shrug*

That'll work... I really just need to know what changed more than anything, since we essentially have to redo our entire hack. But the goal is a single source repository that builds both versions.

kmeisthax wrote:That'll work... I really just need to know what changed more than anything

Sounds easy enough. I'll get to it as soon as I can.

Just curious, how upset would you be if I considered changing Toronko to Tronko? >_> The towns all have a plant theme, and that's probably closer to what they were going for. (Kuri=chestnut, for what it's worth.)

I've added the translations for Freesia to the wiki, so we'll be getting a new patch pretty soon. Again, feel free to check it for typos/spelling and nitpick the wording and stuff, that would be pretty helpful. *nod*

EDIT:
Since we're getting a bit far into the game, here are some save states for different towns to help with testing: Kurinon, Iris, Freesia
You load them in VBA with the "Load..." option. *nod* The first one's from an old patched version but should work fine, and the other two are originally from an unpatched Speed (hence the Fungus). Let me know if it doesn't work. ^^;

Here's patch version 90 with Freesia translations by Kimbles!
http://wikifang.meowcorp.us/etc/TPatch90.ips