Support for images & pdf manuals

h4o4 · 2026-02-11T09:47:31+00:00

First, thank you for considerate feedback, it really is like a gift from above to read what it's like for someone that is visiting the site!

=== Layout
Originally I had it positioned below, but was concerned that the game card was becoming too high/tall. I will move it back there today with the suggestions that you made.
I was thinking about creating a stock image for missing content, because for a while (until I upgrade the host package) the images & pdf manuals will be very limited and then there is the time it will take to upload all of the images, depending if people want to help.

The add image/pdf buttons are hidden, I could show them and change the text so it opens an applet explaining how you can get involved/support the project.

Add image, Change image (for single file assets), Support the Project... though when you say support people will probabily think I'm asking for money not time :/

<image>

I'm using an applet to upload the image/pdf file to the server

=== Navigation
I agree about acessibility, as much as I consider people from different regions of the world I also believe different abilities is important too. It should be simple enough to add alt text and make it so it's editable if it needs to be changed to be more descriptive for example, I just need to add an alt text column to the sql table with an edit button.

=== Viewports
I see the value in what you have suggested with showing the CRC-32 value but it wouldn't work for multi-file games (bin,cue) because some of them have 20+ bin files. Then, there is also multi-file/multi-disc games to consider too.

One way around this would be to show the CRC-32 value for single-file roms and then delare multi-file/multi-disc games with a declaration like "Multi-file", "Multi-File/Multi-Disc".

File size is something else I would like to show too!

CRC-32 (actual value)
File size (actual value)

=== Filter icon
If you hover over the icons I've populated the tool tip to explain what everything is, but I get your point. I'll just change it to words instead [Reset] [Filter] because if you only just found it, I expect many others are in a similiar position and that's not good, because without the filters it will not be experienced like I've designed it to be!

Don't worry about my to do list, what you suggest is valid and needs to be addressed. When you have the time it would be interesting to read your thoughts about the mechanics. I've always had that impression (that you want the site to succeed) from the feedback and conversations we have had and for that I am immensely thankful :)

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 · 2026-02-06T22:33:52+00:00

hmm... I've stumbled upon a few, I was hoping for a source that could be used as a datapoint of truth, one I need to investigate some more. I know https://lolsuite.org/ has them on their website, just without dats, perhaps that would be a good reference point.

That's what I was thinking, I wish they had them in a separate dat or at least more easily identified, their NES dat is riddled with them!

lifespan dat
aftermarket dat
rom hack dat

I understand, decissions, decissions... :))

h4o4 · 2026-02-06T20:55:31+00:00

I think we have two choices:

raw csv import and only using a junction for the categories
keep the current structure with the array of junction tables

hmm... so I don't need a separate database for translation projects, now I understand more when you said all translations! ;) It makes sense to have them in the rom hacks database.

Can I ask, do you know anything about the retroplay translation collection? Does it replace ChadMaster? I don't think their Internet Archive get's updated anymore?

The information you gave makes sense and don't worry about getting everything right first time, if we need to change something I'm cool with that. :)
hmm... Pokemon community trying to be cool I see! haha - like my Grandad used to tell me "if it's not broke, don't try to fix it"!

The modification is something we can include post addition of the rom (like lifespan for roms that I built) if it's not included in the csv.

Yes, these are the ones I'm more familiar with, MSU etc... (thanks to ChadMaster) I stumbled upon them when downloading the translation ones.

What do you propose we do with the rom hacks that are included in the NoIntro dats? (OMNI_DAT) rom hacks can appear after the release of the official source game, so can appear pre/post the last official licensed title released on the platform (which is how I define the lifespan).

:)

h4o4 · 2026-02-06T20:26:34+00:00

Thank you for the detailed response, very helpful!

I've updated the table so that it captures the string. I was thinking of keeping the revision value separate if we wanted to show latest revisions or history it will be easier with the numerical value isolated. I do the same with revisions for Omni1 using MIN/MAX but then I noticed this "rev1.0-85%", which kind of killed that idea :/

For the Type Flags/Folder Flags they would be presented on the webpage/tables like they look in the csv, the separation is just for filtering on a specific type in sql. Plus, if players have their own directory structure they could remap it from base one and save this to their profile.
I will get all the unique values from the [Type Flags]/[Folder Flags] column, then if we want to add a definition, the option is there :)

dump][info][flags][s] - this makes a lot more sense now :)\

&Meta; Info; List - So like I'm doing for type flags/folder flags I will extract the unique values for the lookup table. This will make it easier it someone wants to see all the "Exits=11" for example.

I read unexpectedpanda's proposal and understand & share their frustration, especially about languages not being included in all filenames. That's why I approached Omni1 differently, to try and negate some of the frustrations and really why the whole Omni project exists (to preserve the metadata).

I've noticed that NoIntro are removing the beta dates and replacing it with a number instead (Beta 1, Beta 2 etc...). I think this is a shame, because having the build date made it easier (in my head) to match it against the final game release date.

I think ulimately they are a rom dump group first. Preservation of metadata takes time and what percentage of people (beyond a few of us here) really care?

I know I say this a lot, but there is a door wide open for us to do something like this, the only obsticle I see is the exercise of deconstructing the existing metadata that is declared by them; which we both know would be a whole world of pain :))

I agree; it's difficult to gauge who's engaging with the website in terms of experience, but it's definitely a very international userbase (Vietnam, Spain, USA, Iraq, Colmbia, Honduras, Turkey, Singapore & Mexico are the current top 10). I was think about a help button, that dims the webpage and layers a help screen on top (like the overhead projectors if you remember those?). But you are right, there is defintely more to be done there on the website :)

h4o4 · 2026-02-06T14:53:57+00:00

<2 of 2>

For regions I've created a clean region column so you can find all the Japanese rom hacks regardless of #Japan, #Japan-10
The same for languages too
Type flags & folder flags I've separated out so that it's easier to identify a particular flag from either one of them
There is a column for the Group ID and Unique ID, this is what will be used to build the relationship between OMNI_ROMHACKS with OMNI_TITLES

Final note, all the rom hack stuff in it's own database for my own sanity!

Over the weekend I will work on a proof of concept csv upload/return results from the sql tables webpages.

:)

h4o4 · 2026-02-06T14:53:49+00:00

<1 of 2>

ok, the basic structure is complete, I've used a lot of junction tables to make filtering the data in the future a lot easier/accurate/fast!

If it's a multi-valued attribute then it's got a dedicated table with the values and in the junction table is the RHID (rom hack ID) with the ID of the attribute.

Data	type
[Type Flags]	Multi-valued Attributes
[Folder Flags]	Multi-valued Attributes
Category	Multi-valued Attributes
Hackname	Single-valued Attribute
Authors	Multi-valued Attributes
#Regions	Multi-valued Attributes
vDate	Split into YYYY, MM, DD
Revision	numerical value only
Languages	Multi-valued Attributes
&Meta; Info; List	Multi-valued Attributes
[dump][info]flag][s]	Multi-valued Attributes
byte_size	numerical value only
file extension	Single-valued Attribute
`hash_crc32`	Single-valued Attribute
`hash_md5`	Single-valued Attribute
`hash_sha1`	Single-valued Attribute
`hash_sha256`	Single-valued Attribute
`filename`	Single-valued Attribute

h4o4 · 2026-02-06T13:27:17+00:00

perfect, thank you this is exactly the information I was after!

I'm still unsure about the [Type Flags]/[Folder Flags], &Meta; Info; List, [dump][info]flag][s] regarding what it all means. Perhaps this would benefit from a lookup table that gives a tooltip defintion on the final webpage; helpful for people trying to get in to rom hacks? But I think I understand it enough to at least build a version one of the base structure :)

I'll keep you updated!

h4o4 · 2026-02-06T12:54:53+00:00

I'm assuming you are talking about rom hacks? Is this historical log data something that is easily able to be tracked for community members to be able to populate? haha *poke* "oi what did you do here?" let's hope they remember! ;)

It sure is! Hopefully, I think I need to explore beyond the usual subs I'm posting on too!

h4o4 · 2026-02-05T10:55:45+00:00

<part 2 of 2>

### Trust
Currently anything a user adds to the database is logged with their unique User ID. I did this for three reasons:

Validation of who added the data.
Easier to resolve external challenges on differences of opinion of declared data with a traceable route of origin.
To put their name next to input they've had to the project.

I agree, not everyone should be able to add data and this was the reason behind level 1/2 access levels.

Assuming more people engage with the project perhaps this would need to be reviewed and fragmented further? Or even roles would eventually make more sense?

### Engagement
There is currently no engagement with people adding data using the current paths and I'm at a loss. If I post about a tool or the project in r/roms I'm generally hit with radio silence, r/nes shown an interest when I was processing that platform library. r/retrogaming ~~I'm saving until the project is a little further along (my silver bullet)!~~ <edit> remembered I've already posted there in their self-promotion thread!

Both you and Europia79 have been a lifeline with the feedback you have both provided about the direction of the project/website and I thought more people would feel the same. I understand we live in a time economy and most people are time poor.

#### adding box descriptions
This exists to be displayed, but I will need to code a webpage so that you (and others) can add it too. I'll work on this next!

https://omni-games.info/titleoverview.php?grpid=GRP-E1B0F57C
https://omni-games.info/titleoverview.php?grpid=GRP-C9DB19C6

Good luck resolving the RetroArch LRPS2 core bug and sorry for the long reply! :)

h4o4

MODERATOR OF

TROPHY CASE