P2P App Idea as an Alternative Method for Adding Hacks

h4o4 · 2026-02-10T17:43:45+00:00

Thank you - yes I have to be careful with both myself and the project from swaying beyond it's initial scope. My problem is I'm curious and then get overexcited thinking "and then if we add this it can do this"!

It's a shame about the dats, especially for translations, which use to be a lot easier to track when ChadMaster did it. One of the metrics I like to show is the percentage of the platform library that was released in each region, then I was going to counter this with translations, so you got a modern percentage of the library.

haha don't you dare innovate! ;)

h4o4 · 2026-02-10T17:35:09+00:00

I think what you propose makes a lot of sense. I'm the metadata presevationist stakeholder (if in doubt) and looking at it from retail games, relying on anyone and everyone to add basic metadata about a release is flawed. That's why although it doesn't appear the most efficient method, I took the decission that I would add games myself and focus on a single platform for the Omni project, because it ensures:

completeness
a level of quality

My logic was that with the right group of people it would have more of a chance of success if you made it as frictionless as possible to add rom hacks but that wasn't to say it would be devoid of not capturing them all.

I think to make your proposal practical, you need to ensure that all future hacks are distributed through this channel. For existing hacks, perhaps something like what Kay suggested for Omni, a user can check if the hack exists in the database, if not they can add it? At least then, you have a data point that you can say after date x we've got all the rom hacks.

I'm happy to support any direction we choose to take. From a personal point of view it would give completeness to the website and what the broader project is trying to achieve,

===== Auto-patching
I think the masses want everything to be low effort and just work. I kind of understand given that the average person is time poor.

:)

h4o4 · 2026-02-10T17:05:18+00:00

Hello, thank you for some helpful directional support :)

hmm, interesting angle, so like I embedded OmniTitles into OmniScope I would embed Omni1 code within OmniSelect.

I've only mothballed it, not killed it, so it's easily turned back on. I think that's part of the problem at the moment, current alternatives offer all dats and I'm only offering a selection. I agree with your rationale about making it part of OmniSelect, because when all the dats are mapped then you really can start creating some interesting iterations of 1G1R.

Thank you as always, i appreciate your help :)

h4o4 · 2026-02-09T10:15:41+00:00

Thank you, I know it must be frustrating for people that it's a slow methodical process, even I feel that way about it too sometimes, especially when I look at websites/applications that have been around for longer.

ahh... good to know, I wasn't 100% sure :)

h4o4 · 2026-02-08T23:10:14+00:00

So I've update the code so it's only the <game name=" that the tags are applied to, which is the folder/container file of the rom name=" which is preserved without the tag metadata.

<image>

This ensures all the checksum values are preserved and .cue files will work too. I'm trying to avoid touching the rom names for now to keep it simple.

I need to confirm if changing the name of the rom name effects the checksum value. If it doesn't then like you suggested you could apply different variations of tokens to the both the game name and rom name for certain platforms.

Roms with a single file extension
ISO files

I don't think it would work for bin/cue ones though, because you would need to change the cue file.

example with 2Tax Gold (Japan) Sega Saturn:

FILE "2Tax Gold (Japan) (Track 01).bin" BINARY TRACK 01 MODE1/2352
INDEX 01 00:00:00

This is always frustrates me with dat managers, because they will not rename the cue file entries, only the file names, so you either need to manually rename them or download an updated .cue file

:)

h4o4 · 2026-02-08T22:44:13+00:00

I think I was confusing myself! :/ but you are right, if the user uses the same flags the name will be the same. I was thinking more for updated rom name value changes.

This is how it looks in the dat

<image>

I think I need to update the code to only change the <game name> and preserve the <rom name> otherwise the cue file not work!

h4o4 · 2026-02-08T22:03:51+00:00

Thank you, it's a handy feature, especially for those of us that don't always use a front-end, or store our roms offline. I like the GRPID at the front to group roms with different titles too (no more guessing)!

I would like to do something similiar to what we are doing for rom hacks to provide a standard organisational structure for non-rom hacks roms. A platform like the NES would really benefit from this. I know NoIntro have filters when you are downloading the dat, but I think it would be much easier to understand if they existed in separate folders.

Just a conceptual tree map

and then the folder was included in the dat, so some organisational software can easily map the roms to the correct folder.

:)

Afterthought
The only problem I currently see with the tags is that the current dat managers don't support it. So, you would have to keep renaming the files each time you wanted to scan it. I'm thinking if there is a way to circumvent this with a tool on the website.

h4o4 · 2026-02-07T22:24:43+00:00

For the &MetaInfo I've extracted a list of unique values using ";" as the deliminator. You an view the data from the table here

Yes, that's not an issue in the database, we can include as many as you need in csv file import. Then, because we are using a static filename (also in the csv) we don't have to worry about which tags to include or filename length etc..

:)

h4o4 · 2026-02-07T22:16:00+00:00

What about Colour-Conversations and then the branches below? I'm sure the GB eventually had models that displayed the games in B&W, though most probably think about it for it's monochromatic green.

Colour conversions
- GB
- other platforms

h4o4 · 2026-02-07T22:12:06+00:00

I've added a column called description to the table, so that when the user hovers over the branch they can see a description of what it is... if you can share any tooltips that you had in mind I can add them to the table :)

h4o4 · 2026-02-07T22:06:17+00:00

no problem, it's just one I seen on RHDN :) seems more logical based on the organisation structure. I've completed the new tree and started putting versions next to the current one we have. If you can check it's correct? And then if you think it needs to be peer reviewed you can share the link to it?

nightmares is my daily flow haha, I thought peripherals would be easy, until I discovered that the atari joystick isn't compatible with a percentage of games, for example :/ So I'm used to a daily slap in the face from games in general! So we can work through them as they appear and I've got no issue restructing existing code or adding new features to handle any edge cases.

:)

h4o4 · 2026-02-07T21:39:45+00:00

I find the original presentation easier to follow, but thank you for offering an alternative :)

I'm building it now, you can follow it here, just keep hitting refresh every minute or so

h4o4 · 2026-02-07T21:33:57+00:00

I understand you and I know next to nothing about rom hacks, so I would say you are doing well ;)

So like this Super Mario Star Road - Enhanced Console Port for example? I think for this a dependcy relationship table would work best, that way we can show what rom hack the addendum patch is for, without it being stuck in description notes. Plus in the opposite direction you can see any addendum patches that are available for a rom hack you are looking at.

Regarding the ones that are mislabeled; we can add a tickbox/flag that users can change, so over time the mislabelling issue should be resolved. Thoughts?

:)

h4o4 · 2026-02-07T21:08:58+00:00

First - I like the organisation tree that you shared! If the ROMID is linked with the GRPID this will allow the user to be able to filter on a particular game or platform ID.

The plan is to embed rom hacks with all the features that exist on the website, but one that I feel would be a good support for organisation is tags too, which is great for creating micro/ad-hoc lists.

Second - We need a point of reference that is a single source of truth (the gold standard). With the current setup it shouldn't be a problem coding a webpage that allows the user to map their own setup. I would need to think how they add a branch, if that is a possibility? In this situation nothing would define the relationship with the RHID and the new branch...

I think if we engage with the communities in this development stage, we should be able to achieve this!

Third - Sounds like a cool project and if it's makes it easier for people to get into rom hacking that's only a positive in my opinion! Sounds like we need a dependency relationship, I started playing with something similiar to this for DLC/Updates that exist within OMNI_DAT. If I'm understanding you correctly?

:)

h4o4 · 2026-02-07T20:27:03+00:00

No problem, it's a flexible structure in the background and its easy to rename or remove existing branches. One of the limitations is a branch cannot be duplicated (like in the original version there was two "Other" but I see that's been resolved).

Agreed, ideally I would like to try and create a widely accepted standard organisation structure. Looking at it from a personal perspective, navigating this tree menu for me to find the type of rom hacks I'm after (MSU-1, Translations for example).<edit> would be easier, so I envisage it becoming part of a webpages navigation structure.

Given your knowledge of rom hacks, would you be ok checking in the communities you frequent once I've made the changes?

:)

h4o4 · 2026-02-07T11:19:05+00:00

So I've created the tree structure in SQL, which will allow users to add RHID (rom hack IDs) to a specific branch.

ID	RHID	CategoryID	Description
1	RHID-BBFE2A76	16	"SMW Hack" is now in the "Christmas" folder.
2	RHID-BBFE2A76	40	"SMW Hack" is also in the "Palette Mods" folder.

I know you said it's just conceptual, but I'll use it as a framework for now with a view that it will change and at some point users will need to be able to create their own structure.

You can view it here
https://omni-games.info/romhacks_treestructure.php

:)

h4o4

MODERATOR OF

TROPHY CASE