News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SCO

Pages: 1 2 3 4 [5] 6 7
The 'rar' is actually a zip. Or at least that was what i had to rename it to open it on linux. WinRar just opens the zip, so someone brainwaved naming it rar.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: September 03, 2017, 07:49:38 am »
It spits in the face of the very foundation of the emulation scene. Namely the open secret and expectation that everyone pirates, disguised under the euphemism of "backups".

Or maybe you could quit being judgmental and realize the translation community depends on the same exact dumps in order to have a translation reach everyone. If the dumping process is not reproducible, or gives different results, it is 'A Problem'. Proliferation of even more dumping 'standards', or being 'forced' to use a different base for a hack is something i don't want.

Them fixing the dumps is the 'right' solution, but i wish these cases were documented and the archives had a 'workaround' patch too. Anyway, to show this is not only a problem on game hacking, Everdrive has this problem too.

Uh, while the romset doesn't update, it's not the romset i will change, but the patch, so i can softpatch. I prefer to redownload a patch if the set ever updates to having the base file wrong on ctrlmamepro, which will be a long-ass time until updates, and i can already see them not bothering if the 'plan' is to strip all headers and they're using *that* as a excuse to not correct wrong ones (because it will break patches much more than individual fixes).

Have you thought about re adding the extra content from the Saturn version, for a "definitive" version? It's probably outside the league of this project, since this is mostly bug fixes, but it's still an option.

I do wish for a 'ultimate' version that could switch the script and voices at runtime (gemini translation + jap voices + corny script + english voices) + maria with this hack on top.

I'll never happen lol. Besides, Maria is such a broken character with her super jumps... I do actually dislike her walking though. PSP version does have her, but she's nerfed iirc. Maybe a better idea to base a hack on that.

Yes, i suspected that. I believe bps does not behave that way, so i expected it to replace ips in more games by now.

I'm sure anybody doing hacks and translations has access to the right tools.  Even if they didn't know about a program like hashmyfiles, you can easily see the CRC value of the rom in winrar.  If somebody is actually grabbing these values from some place online it's probably because it's a site with a good repuatation and they just didn't double check that the info was right.  Hell... Even after all the work I did documenting issues with NES and FDS roms that I've posted here I would never say my info is 100%.  It would require me to re-patch every single game and re-verify, which is something I would NEVER do.  :)

I believe this happens mostly to people not using windows and that don't have the habit of using the cmd line. Mostly IOS users, and some linux users. Of course actually using a value that you calculated yourself is better, but webpages with crcs are unexplainably popular as sources, even if they guarantee nothing. Thus my suggestion of that being a verification step on the site javascript before the author uploads (javascript runs on the local computer so the rom won't be uploaded). Though i can totally see that backfiring and the 'hardpatched' crc being calculated instead of the original rom if whitelisting is not used.

Besides that, a accurate database of these things would be useful, for knowing when to upgrade the translation automatically instead of constantly checking the site. That would be helpful for *anyone*. I'd admittedly prefer if the 'softpatching' usecase was catered for too, but i'm aware as you can tell from the bitching about the 'preprocessing steps' on my posts that is not so simple to do consistently if you insist on a consistent collection of base roms (like i do, all no-intro), because many translations need to be modified with the 'hardpatch and create a new softpatch from new base to hardpatch' trick, or the tricks below.

On a subject change, more of that consistency bitching, another annoying thing is snes rom headers being needed or not for translations. When something like ipsbehead exists.

Yet another annoying thing that is rather specialized is n64 patches. n64 have 3 (!) different byte order organizations on their 'base' roms, and it's not unusual for a ips or bps file to have to be recreated on the 'target base rom' for a softpatch to decrease from the size of the rom to 150kb.
The process is like this:
1. find out patch base rom is not the no-intro byte order.
2. *sigh*.
3. copy n64 no-intro rom, use tool64 to change no-intro rom to byte order the patch needs, verify crc.
4. hardpatch byte order changed rom
5. use tool64 to change byte order changed rom to no-intro rom byte order
6. create a bps or ips patch from original no-intro to hardpatched rom, delete extras.

August 21, 2017, 06:50:04 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
BTW, i think the lagrange point page is saying that the 'base rom' doesn't matter in this case (or doesn't matter as long as it is a header variant of that one 'base rom'.

This is very strange thing to say because ips doesn't make a distinction between the header and the rest of the rom and will happily overwrite the header if i understand it correctly.

Maybe the original was supposed to be bps and you supposed to ignore the crc error if it happened?

Regardless, i just 'tried' (not exhaustedly) the lagrange point translation on the no-intro  rom crcs:

9ac10a68   Lagrange Point (Japan).ips
ead4dedc   Lagrange Point (Japan).nes

and didn't see a problem in the intro, though that doesn't mean anything of course (especially with the mentions of 'SRAM disabled', maybe saves don't work?)

Another possibility to 'it was supposed to be bps' is that something similar to ipsbehead (similar because this is a nes rom not snes) was applied to the ips and that text simply doesn't matter because the ips no longer affects the header and it is ready to run on a no-header rom.

August 21, 2017, 11:47:00 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
BTW, i've been applying nes translations and found that sometimes, when the game has both .bps patch and ips patch translations, since bps is 'stricter' and will not apply if the base rom doesn't have the right checksum, you sometimes want to use ips even if it's 'wrong'


is one such case. The no-intro rom changed (probably the header). BPS fails, but the IPS will happily overwrite (or maybe just ignore) the header and apply the translation.

August 22, 2017, 02:01:33 am - (Auto Merged - Double Posts are not allowed before 7 days.)
There is also another strange case i've found:
Juvei Quest (Japan) translation here:

applies not to the first no-intro version but not to the last (Rev 1). A bit off-putting. Another bps + ips patch, haven't tried the ips on the Rev 1, because the page says to use the first.

August 22, 2017, 03:37:04 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Another. This patch:

Says on the main page it uses the no-intro rom (with crc32: d994d5ff ) but this corrupts the game on movement and the readme says it uses the rom with crc32: b661b602 (whatever that is).

August 22, 2017, 05:06:37 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Yet another:

The crc checksums on that page look familiar...

Oh right:

August 22, 2017, 10:35:12 am - (Auto Merged - Double Posts are not allowed before 7 days.)

The quest of Ki patch doesn't apply to no intro. It's claimed this is because no-intro has wrong headers, but the user needs to modify the patch anyway.

August 22, 2017, 11:34:53 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Another case of the same thing (no-intro rom having wrong header). Check the translation description on the page, i verified the 6th byte has 40 instead of 41 on the no-intro rom:

But since this is a ips patch not bps it 'applies'. Just wrongly. It's quite easy to regenerate the patches to apply to the normal no intro with the 'create a new patch' trick if you're aware of this problem.

I dislike when patches requires 'transformations' not included in the patch to work, like the light of indra patch.

Since i prefer softpatching, it's a extra layer i 'have' to do to keep things consistent with the base rom being no-intro. What i do is copy the rom, do the expansion and hardpatch on the copy, and only then create a new patch from the original no-intro to hardpatch and keep only that.

This also serves to softpatch for patches which use a different base rom while using no-intro roms as a base of the new patch, but it's tiresome to remember.

I've also seen very many romhacks pages where it seems the crc of the base rom was lifted from the net, *not* from a md5sum or crc32 tool. Mostly because for some reason the person doing the patch doesn't have access to these tools (whyyyy?). They're often wrong.

But anyway, a way for verification of the base rom to be done on file upload (javascript calculating hashes asking for the base rom, maybe matching against approved dats?) would probably be useful.

I prefer the VWF and item translation on the Gemini translation myself. But to be honest, i keep both versions of the game... the corny lines and audio is nostalgic. Sometimes i wish the gemini hack allowed switching the jap voices and script (not items descriptions) for the english horribleness at runtime given the two games.

I do know that is rather unlikely to ever happen because of the space limitations and pointless effort.

Personal Projects / Re: Arcana - Seal of Rimsala! (SNES)
« on: August 12, 2017, 09:25:32 am »
Haven't forgotten about uploading a standalone fastrom patch for vanilla. After optimizing Super Ghouls 'n Ghosts to playable levels, learned some new tricks.

Speaking of that, i just submitted a critical review on that hack because i noticed that the intro was broken. At first i thought it was because of confusion between the base game (no-intro vs. goodset or similar) as i've seen other games break, but now i'm not so sure. Can you tell me if it happens to you and what game should be used as base?

I suppose it might be a confusion with the graphical part having a different origin rom and the hacking part having the no-intro rom and and the combination going wonky.

Newcomer's Board / Re: Translating Downtown Nekketsu Monogatari
« on: July 04, 2017, 01:08:34 am »
There is a version of this game on the x68k that might interest you.

It's supposedly a 'bit' different. More zones and some moves or something, don't remember well.


I agree with that goal. In fact, i wish there was a version of wine that could be bolted 'on' a emulator to run single windows games without all that virtual machine OS nonsense. Winbox so to say. Wine by itself is fine more less bugs, but having it on a emulator would spread it out of its ghetto and gog would start selling 'awkward' windows games without major hacks and on other platforms too.

Filesystem transparency, less possibility of a buggy 1990 FAT driver corrupting the disk image, device passthrough, not having to deal with 'boot' and autostart app if you want to do a 'click to play' etc.

They're still dos though, and that is a opportunity for HLE.

Not really. It has some different graphic drivers, tandy, pcjr but not pc-98 or other dos systems. I think it's a shame but understandable, with the way every other game seemed to customize their own version of DOS bundled in, on the pc-98.

No hdi version of this game?

edit: guess i should have read the readme. Just because it wasn't tested doesn't mean the patcher will not run.

With the good amount of pc-98 games i'm hoping dosbox starts to emulate them well. Neko Project 2 is ok, but its usability is rather poor (expecially on retroarch).

ROM Hacking Discussion / Re: Reverse
« on: June 26, 2017, 10:07:08 pm »
Yeah, good point, for some platforms that use text bitmaps. It's just that its frustrating to get to 90% of a elegant solution and then have to drop down to hacks. Still better than caring about coordinates and doing it all by hand ofc.

I hope the retroarch guys take the single day it would take to code this option. Doesn't seem like a maintenance burden...

June 26, 2017, 11:35:12 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Seems like they don't want to implement it - called it 'niche' and said it was easy for a user to do it themselves (aha, programmer skewed perspective). Anyway, if you want this there, your best chance is doing it yourself and sending a pull request.

News Submissions / Re: Site: RHDN 3.0 Site Refresh Launched!
« on: June 26, 2017, 06:22:55 pm »
One functionality loss that annoys: there is no longer a message why a translation or hack was updated on the 'latest ....' pages. This makes it more troublesome to figure out what is actually new and may cause mistakes.

Also people, you can change the forum to the old look at least.

ROM Hacking Discussion / Re: Reverse
« on: June 26, 2017, 06:07:47 pm »
I meant that since this is actually pretty easy to do on a emulator, you could ask for a 'feature' for it on retroarch. And then i asked myself.

In comparasion to a dedicated game hack, the main problem is that flipping the image also mirrors text, so all text is 'unreadable' (well, Leonardo da Vinci wrote and read like this, so not really, with practice).

The advantages are great though, including using it on any game that RA cores support (many many games)

News Submissions / Re: Site: RHDN 3.0 Site Refresh Launched!
« on: June 23, 2017, 06:46:57 pm »
How do you change the forum theme to something darker?

Bump. Is there a version of this translation that uses plain files to be replaced on cdmage or similar? I ask because the base dump used in this binary patch is not the redump version, that i'd prefer (edit: i was wrong. It is the redump version, just turned into a iso first.)

edit: Tried to do it myself but apparently my method doesn't work with patched files larger than the originals.

If you're curious, i have the redump DFII dump, and the one the xdelta patch wants, same version (1.006), then apply the patch to the right iso, then mounted both isos and did a byte compare with diff -r cd1 cd2, extracted the different files from the patched iso, loaded the redump image on cdmage and tried to replace the files (right click -> import file). When i got to "DF2_LOGO.CHM" it wanted to truncate it because the replacement was larger than the original, so this is no good.

I can't simply replace track 1 from the redump dump with the patched iso because they're different formats, bin vs iso... maybe if i convert the iso to bin somehow (without being a dumb rename because i'm pretty sure these are completely different formats) and then do a xdelta patch from one to the other.

edit 2: tried gBurner that has a 30 day unlimited size free trial for the editor (unlike PowerISO / MagicISO) and the resulting edit of the cue/bin track1 file makes the game be recognized as a music cd instead of a game on mednafen saturn or yabuse. Pretty sure it's doing something wrong. Saving just Track 1 as a bin using 'data cd' and replacing that file in the original mixed mode cd has the same result: the emulators boot to bios music player.

Also what gave me this idea was the Story of Thor 2 Saturn hack here; the process the hacker says for the users to do is to use cdmage to replace the files on any dump. It worked on redump (though as said, all the replacement files were less or equal in size). Though yabuse boots it as a audio cd, but that happens on the original redump too. Mednafen boots it fine.

edit: turns out that this is not very practical. While it is possible to create a new track 1 with the same mode as redump (MODE1/2352), unlike the case where the size of the files is the same, the very fact that they change size offsets everything and changes the checksum data in the MODE1/2352 of most of the iso, which leads to hundreds of mb of xdelta patch unfortunately. I really didn't expect this, but oh well. Makes me think a specialized binary patcher aware of the cd modes that turns a cd into mode1/2048 before calculating the differences / patching could be valuable for distribution and softpatching (that mode has no checksums).

Also what i was missing is the saturn header mentioned here.

ROM Hacking Discussion / Re: Reverse
« on: June 22, 2017, 02:57:48 am »
Maybe retroarch can accept a shader + option (to invert controller and pointer coordinates x axis) that does this as a contribution? Sounds easy and compatible with multiple emulators.

However, obviously this is mostly cosmetic, not like a true hack 'starting from the end to the beginning' etc. OTOH, it wouldn't break games progression and would be enough to give the illusion of novelty for a while in already memorized games.

You should open a request for enhancement, i think it wouldn't be closed.

edit: nvm, i did it.

edit: doooh, forgot about text and reading. Mirror text was what Leonardo Da Vinci used as a poor attempt to i don't know what (obfuscation??) so it might be fun.

Pages: 1 2 3 4 [5] 6 7