The PokéCommunity Forums  

Go Back   The PokéCommunity Forums > ROM Hacking > Tools, Tutorials & Resources
Sign Up Rules/FAQ Live Battle Blogs Mark Forums Read

Notices

Tools, Tutorials & Resources Various tools to help you develop your hacks can be found here.
New threads in this forum are to be approved by a moderator before they are displayed.


Advertise here

Reply
 
Thread Tools
  #1    
Old February 2nd, 2014, 04:01 PM
Full Metal's Avatar
Full Metal
C(++) Developer.
Community Supporter
 
Join Date: Jan 2008
Location: In my mind.
Age: 19
Gender: Male
Nature: Timid
Send a message via Windows Live Messenger to Full Metal

Advertise here
Patch Builder



What is it?


Patch Builder is a completely new methodology to hacking that focuses on files and data structures rather than offsets, pointers, and bytes. In other words, when you're mapping, you save a map file -- not your ROM file. Later, this tool takes that map file, finds free space in a ROM, turns the map file into appropriate bytes, and then saves an IPS patch for it. This tool is designed to run with Python 3.3, but is 2.7 compatible ( to my knowledge ). You can get Python at the official site.



Why Use It?


As it stands, ROM Hacking involves a certain level of maintaining knowledge of where things are inserted, tracking changes, dealing with various bugs in tools, etc. This tool circumvents this by keeping the tools separate from the ROM. An other advantage to using this methodology is the ability to collaborate as a team on the same ROM Hack Project.



How Does It Work?


It's a lot more simple than you might think. First - this program depends on descriptions of in-rom structures. It looks for these in a few places:
  • A semicolon seperated list of paths in the environment variable "RomStructureSearch".
  • A subfolder "RomStructureSearch" in the location of the script.
  • A subfolder "RomStructureSearch" in the current directory.
  • The current directory.
.

Rom Structure definitions need to be named with the extension ".RomStructure.json". Since this software still has some engineering left to be done, the exact structure is not presently defined or set in stone. I plan to add support for specialization according to each game code. ( You can specify different structure definitions on a "per-game-code" basis, in other words ). These structures will also specify any enumerations ( "bulbasaur" is pokemon 0x00, for example), as well as any constants that need to be determined ( the map bank table, for example ). To notate a field as having a reference, prefix it with an "@" symbol in the fields list ( see the Git folders RomStructureSearch for an up-to-date example of a RomStructure file ). If it points to a table, then you can specify that like so "@[field_saying_how_large_the_table_is]@[field_name]". ( I need to add support for x-terminated tables, I just haven't yet ).

Entity's are what make up a project. Entities are named like so: entity_name.[entity_type].json. So if you made a map, the correct filename would be farmtown.pokemonmap.json. This would indicate to Patch Builder that the entity is named "farmtown" and that it is a "pokemonmap". Like Rom Structure's, you can also specialize on a per-game-code basis. These are the files that editors will work with. To refer to an internal rom structure in a referring field ( "@connection_header" ) then just set this field in the entity data area to be an integer set to the offset of the structure in-game. If you want to refer to an entity file, then you can simply enter "farmtown.connection_header" in the appropriate data field.

You'll notice I keep mentioning "game-code-specialization" -- for good reason! One of the huge benefits to this project is that you work on the meta-level. In other words, a map you make can be inserted to both Ruby, and Saphire, or even Fire Red. If you want to make two versions of your game ( like Ruby and Saphire ) then you can do that, too!

As it stands, there's not any existing tools for this type of hacking. But lo! Being as these are JSON documents, editing them manually is simple, and intuitive ( when compared to using a hex editor ).



Where Can I Find Out More?


This project is currently hosted on Github at this repository. Fee free to fork and pull away!

You can also clone it using Github For Windows or from this .git url using your console.

If you don't have git and don't feel like installing it, you can also download the latest revision at this url.



Who All Is Involved?


So far, this has mostly been a one-man-show. However, this is a big show and I'm looking for some help. Whether it's Rom Structure ideas, Rom Structure information, Table offsets, or anything, I'm interested in hearing what you have to contribute. If you're interested in helping, you can use Git, or Skype me through my signature.
  • Karate Kid - LZ77 Algorithms
  • Full Metal - Main Coder



__________________

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote
  #2    
Old February 2nd, 2014, 10:41 PM
Shiny Quagsire's Avatar
Shiny Quagsire
どないやねん, ヤドン
 
Join Date: May 2009
Location: Hoenn Safari Zone
Age: 16
Gender: Male
Nature: Jolly
Interesting idea. It seems like a bit of a reverse disassembly but with data only. Definately like the idea of it, and I'm actually interested in seeing this take off because this might be a good feature to add to MEH, that is, adding support to export maps to this specific patch format. And let me tell you, I can give a lot of into on the map format. Like, a lot. So if we get this thing going I could see this being a big thing in ROM Hacking. And it's nice to see that it's written in Python so that other users on different OS's can benefit as well.
__________________



Reply With Quote
  #3    
Old February 3rd, 2014, 08:54 AM
Full Metal's Avatar
Full Metal
C(++) Developer.
Community Supporter
 
Join Date: Jan 2008
Location: In my mind.
Age: 19
Gender: Male
Nature: Timid
Send a message via Windows Live Messenger to Full Metal
Quote:
Originally Posted by Shiny Quagsire View Post
Interesting idea. It seems like a bit of a reverse disassembly but with data only. Definately like the idea of it, and I'm actually interested in seeing this take off because this might be a good feature to add to MEH, that is, adding support to export maps to this specific patch format. And let me tell you, I can give a lot of into on the map format. Like, a lot. So if we get this thing going I could see this being a big thing in ROM Hacking. And it's nice to see that it's written in Python so that other users on different OS's can benefit as well.
> Bit of a reverse disassembly but with data only

Basically. Although, adding support for assembly wouldn't be outrageous or difficult, either. If I can ever make a proper EBNF parser, I'll probably design a specialized assembly language for use. This whole project very vaguely reminds me of this xkcd comic:



Seeing as we don't even need to have a ROM to do it anymore, theoretically.

And if you have information on map structure's, I would definitely appreciate it! Collaboration on our parts would definitely be a good idea, I think. However, if you really want this to work smoothly with your existing editor, you'll want to design it so that it primarily works with json documents and external images rather than from a ROM, but so that it asks for a ROM should it need one. Writing a hybrid tool could get complicated and confusing fairly quickly.

And yeah, Python is great. 8)
__________________

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote
  #4    
Old February 4th, 2014, 02:29 PM
itari's Avatar
itari
悪魔の妹
Community Supporter
 
Join Date: Mar 2010
Location: 紅魔館
Age: 17
Gender: Female
Nature: Relaxed
Well it certainly does sound cool.
In a way, it reminds me of how DS ROMs are already structured, with their internal file system and all. This way, GBA hacking would be similar to how DS hacking is done. Cool!
__________________
Touhou Puppet Play: Sapphire

SubscriptAdvanced SongType Effectiveness EditorTilemap CreatorPython IPS Patcher
Reply With Quote
  #5    
Old February 4th, 2014, 03:21 PM
Full Metal's Avatar
Full Metal
C(++) Developer.
Community Supporter
 
Join Date: Jan 2008
Location: In my mind.
Age: 19
Gender: Male
Nature: Timid
Send a message via Windows Live Messenger to Full Metal
Quote:
Originally Posted by itari View Post
Well it certainly does sound cool.
In a way, it reminds me of how DS ROMs are already structured, with their internal file system and all. This way, GBA hacking would be similar to how DS hacking is done. Cool!
Actually, that's what inspired this idea ages ago. But back then when I had the idea, I didn't have the practical knowledge or skillset required to implement it.
__________________

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote
  #6    
Old February 13th, 2014, 04:12 AM
IndianCharizard#'s Avatar
IndianCharizard#
Making johto anime hack.
 
Join Date: Sep 2013
Location: Delhi ,India
Age: 19
Gender: Male
Nature: Brave
Send a message via Skype™ to IndianCharizard#
Good idea! It can help many people like me!

Good luck bro! Complete it!
__________________
My PC Family
| Pokelovers Server | Johto League Showdown Hack Thread |My Team ThreadPaired With - Ansirent Rytham
Reply With Quote
  #7    
Old February 21st, 2014, 09:24 PM
Full Metal's Avatar
Full Metal
C(++) Developer.
Community Supporter
 
Join Date: Jan 2008
Location: In my mind.
Age: 19
Gender: Male
Nature: Timid
Send a message via Windows Live Messenger to Full Metal
update:

I've finally determined a data structure that should encompass all the immediate needs I can think of for an Entity object:

Code:
{
  data:{ // default data. Consider this to be a "bottom layer", see comments below.
    field_name: field_value
  },
  specialization:{ // the "top layer" for data. Overrides any data in the root "data" node.
    game_code:{
      field_name: field_value
    }
  },
  meta:{ // not used by the compiler. simply used by the editor for convenience.
    field_name: field_value
  }
}
Then for data structures, my proposed final structure is as follows:

Code:
{
  fields:{
    name:{
     byte_code: struct.compile_code// see specification of struct's bytecode in the python docs.
     order: where_in_structure_should_be_placed
     description: optional_string
     refers_to: null_or_name_of_structure_type
    }
  },
  tables:{
    table_name:{
      index_name: null_or_name_of_field_in_structure // null means use meta information '$index',
      entry_structure: name_of_structure_for_entry // you can also pass in a structure object here instead of a reference string, but it's recommended to use a reference string.
      location: internal_rom_pointer_to_table
    }
  },
  constants:{
    name: value
  }
  specialization:{
    game_code:{
      fields: {},
      tables: {},
      constants: {}
    }
  }
}
There will also be a file used for maintaining a list of known free-space chunks given a game code. I'm undecided on whether this will be stored in a single file with a constant name, or if it will be spread over other files. It's not needed, but if you don't have this, then you do need a ROM so that you can process it for free-space information. Anyways, the structure for an individual game will be this:
Code:
[
  {
    location: internal_rom_pointer,
    size: how many bytes can be overwritten safely,
    value: 0xFF // optional.0xFF is assumed unless specified otherwise. Anything beyond the size of a byte will be interpreted as "any byte".
  }
]
Developers, do you have any questions or feedback for this proposal?
__________________

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote
Reply
Quick Reply

Sponsored Links


Advertise here
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Minimum Characters Per Post: 25



All times are UTC -8. The time now is 07:09 AM.


Style by Nymphadora, artwork by Sa-Dui.
Like our Facebook Page Follow us on Twitter © 2002 - 2014 The PokéCommunity™, pokecommunity.com.
Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, The Pokémon Company or The Pokémon Company International. We just love Pokémon.
All forum styles, their images (unless noted otherwise) and site designs are © 2002 - 2014 The PokéCommunity / PokéCommunity.com.
PokéCommunity™ is a trademark of The PokéCommunity. All rights reserved. Sponsor advertisements do not imply our endorsement of that product or service. User generated content remains the property of its creator.