[Idea] The Ultimate ROM Hacking Tool: The Garage

[Zehn]

This sounds quite good, similar to the gen 3 rom hacking suite though

 

[GUMI 02]

I love the idea! My desktop is full of pokemon rom hacking tool icons!
Hope you can make it work. {XD} Best Of Luck To You!

- TheRealOCD

 

[Tsu_brO]

I don't know much about it, but even so, the tool itself would have to be built to work with a specific line of games, wouldn't it? Like it would only work for Gen IV games, or even only DS games, if it was written to work with those, and wouldn't work on other games.
Or not?

 

[Nakasu]

This would work. It'll clean up a lot of the mess rom hacking does to my desktop.

 

[Deokishisu]

Is this really any different than having a master ROMHacking tool folder? If it's a shell with a GUI, well, a Windows folder basically does that already. Oh, I need to open NSE? I'll go to this master folder that's always open when I'm hacking and start it. My taskbar is basically the tabs in the Garage, as all my programs that I'm currently using (or planning on using for this ROMHacking session) are open and sitting right there. And if a plugin for what I want isn't available? Or I prefer another program (the different hex editor preferences that you'll never get the developers to plugin-ize being an example) that doesn't have a plugin yet over something that does? Then I'm doing what we're all already doing.

This, like Gamer2020's program, really serves to save me maybe ten or so clicks at the start of every ROMHacking session I do. It's not even a constant click-saver. It just saves me those clicks when I'm sitting down to start.

 

[AceRoku]

This would clean the mess of having alot of tools and other bunch of stuff. Im pretty sure people would contribute to this.

 

[esperance]

This sounds like a nice way to bring the community together, as well as standardize the hacking tools.
But, why limit it to just GBA? There could be a whole set of base tools (Garage for GBA, Garage for GBC, etc.) which could be managed by a user or users, and which anyone could contribute plugins for.

I'd love to help get this project off the ground if you ever want to actually implement it.

 

[Johto_legend]

I love the idea, but I don't understand the decision to develop it with .Net framework. Even if .Net 5 is going to make it cross platform, but there will be bugs early on, so why not just start from the beginning using Java. I feel it would be much easier and less chaotic in the long run to have everything under an already developed cross-platform language. It would help the community since more people would have access to hacking tools. plus it would encourage future plugin makers to use make their programs cross-platform instead of having several similar plugins just for different operating systems.

I only ask because as a Mac user myself, its a struggle to run a virtual machine or wine, so if a big project like this were to happen, it really should aim to be available for everyone from the start.

 

[Oloolooloo!]

I'm assuming it's a GUI that launches other programs, the whole "plugins" discussion is a little confusing.

If you are able to put plugins into a directory that lets them appear on a list, what's stopping you from taking already established tools like XSE (after asking permission, of course), bundling them with your download, and creating a crude but effective all-in-one tool that way? I'm not an experienced programmer but it seems like this could take a very short amount of time to do a lot of good.

Is this really any different than having a master ROMHacking tool folder? If it's a shell with a GUI, well, a Windows folder basically does that already. Oh, I need to open NSE? I'll go to this master folder that's always open when I'm hacking and start it. My taskbar is basically the tabs in the Garage, as all my programs that I'm currently using (or planning on using for this ROMHacking session) are open and sitting right there. And if a plugin for what I want isn't available? Or I prefer another program (the different hex editor preferences that you'll never get the developers to plugin-ize being an example) that doesn't have a plugin yet over something that does? Then I'm doing what we're all already doing.

This, like Gamer2020's program, really serves to save me maybe ten or so clicks at the start of every ROMHacking session I do. It's not even a constant click-saver. It just saves me those clicks when I'm sitting down to start.

One word: Newbs. Instead of having them scour the web for every tool they need, they can get it all downloaded from one place. Plus it makes it easier to write tutorials and helps organize the huge database of tools to show which ones are important to learn. It's a Lazy Newb Pack!

 

[Toni88]

I really like the idea, I'll stay tuned to support the development if possible.

 

[Johto_legend]

Thing is, most applications here are actually done in .NET, and .NET 5's release is apparently supposed to be rather soon. As in, before July. The code that we make for the Windows-only version for now should be compatible entirely with .NET 5 when it releases, so the transition from Windows to a multi-OS application shouldn't be much an issue. Plus, if memory serves, the VS2015 preview has support for cross-platform already to a limited degree, so it's already getting plenty of public testing to ensure it's as bug-free as possible. I don't think it'll be terribly buggy, plus the public beta of VS2015 (Whose release will coincide with .NET 5) will ensure that it's not a pile of crap.

Plus I'm not versed much in Java, I'd be relying on people too much for something that I should be working on. However, what I want to do is see that plugins can be made in different languages (Such as Java, Python, C++, etc etc) and still work to a fair degree, only requiring the base application use .NET.


You wouldn't have to worry about that. TG is simply a driver application, everything else can be coded the way you want it to be. Heck, it'd take a plugin for a NES game, or even a DS game. There's nothing from stopping you. It's not limited to GBA at all.


Anyways, I apologize for not driving this any further lately, I've been busy with school as I've been falling behind and I'm in the midst of searching for a new job while working my current one. I do have at least one person that's on board with this though (Make this two?).

I didn't realize that .Net 5 was so close to releasing, by the time this project really gets moving, .net should be more than capable to meet our needs. And I am definitely on board, though I do work on a Mac and have mostly worked with Java from my university course. Being a university student as well, I understand your struggle to balance out school and other projects, but I think this is a great opportunity to move forward as a community and the ROM hacking environment by making this project a reality.

One of the biggest things I think this project will need though to advance and attract people to make plugins is proper documentation. It would greatly help both users and developers in understand how The Garage works and how you can add your own plugin/tool to it.

If there's anything I can help with, I am more than happy to learn and contribute.

 

[Alexander Nicholi]

Some clarity should be brought to .NET 5.0: Microsoft is not bringing out-of-the-box support for other operating systems! They are merely open-sourcing the .NET core and leaving the community to port it to other operating systems. So yeah, it's not all that.

For an application like this to be as cohesive as possible, and since it is a collaborative sort of application, it being written in C or C++ is imperative. It will never gain the deserved traction it needs being written in Java or Python, let alone .NET anything. There are plenty of arguments against performance, code writing, and other things with all of those higher languages and tbh when someone is bitching about C(++) they're pulling your leg or aren't worth your time. And besides, it's my understanding interfacing from C(++) into those managed/interpreted languages is doable for those who still want to code in JavaScript, Ruby on Rails, IronPython or whatever silly language they want to use. So it's that much better for developers for Garage to use the mother tongue.

 

[Touched]

Some clarity should be brought to .NET 5.0: Microsoft is not bringing out-of-the-box support for other operating systems! They are merely open-sourcing the .NET core and leaving the community to port it to other operating systems. So yeah, it's not all that.

For an application like this to be as cohesive as possible, and since it is a collaborative sort of application, it being written in C or C++ is imperative. It will never gain the deserved traction it needs being written in Java or Python, let alone .NET anything. There are plenty of arguments against performance, code writing, and other things with all of those higher languages and tbh when someone is bitching about C(++) they're pulling your leg or aren't worth your time.

Yeah, no.

C++'s ABI is terrible and varies from compiler to compiler. Name mangling gets in the way, among other things and requires any plugins written to be compiled with the same compiler as the original. Name mangling is non-standard and thus varies between compiler implementations.

Now, while C doesn't have this problem, you still have to compile the code. This results in a packaging nightmare, as every author would have to package everything at least 3 times. End users don't want to have to compile stuff to use it either, so this is difficult.

C is also a notoriously difficult language. Do you really want every damn plugin to have a memory leak or segfault? This is the reality with a C framework as you suggest. Half the tools on here are .NET - those authors simply won't care to use C. I don't see how C/C++ would encourage collaboration.

And besides, it's my understanding interfacing from C(++) into those managed/interpreted languages is doable for those who still want to code in JavaScript, Ruby on Rails, IronPython or whatever silly language they want to use. So it's that much better for developers for Garage to use the mother tongue.

Now you don't even seem to understand the opposing argument. Even if we did do this it would result in MORE bloat and dependencies. Get your terminology correct by you write us off as silly. Neither IronPython nor Ruby on Rails are languages. The former is an implementation of a language spec, the latter is a web application framework. I'll give you a break on the IronPython, since that's managed, but Rails? Seriosuly? JavaScript is not managed, and in the case of V8, isn't interpreted either - it's compiled. To machine code.

I don't think C or C++ are viable options for an extensible ROM hacking tool. A scripting language would be ideal, I just don't see why you're so against them. Something like nw (node-webkit) or Electron (Atom shell) would be ideal. Everyone can write HTML and JavaScript and thus everyone could contribute.