Language…
10 users online: AJ1Ayrton, Daizo Dee Von, GRIMMKIN, Hidincuzimsmokin, Klug, Oskise,  Ringo, Rykon-V73,  Telinc1, Tsquare07 - Guests: 252 - Bots: 389
Users: 64,795 (2,375 active)
Latest user: mathew

IPS FLIPPER

Thread title is from here.

I need to get this one published. It's been lying here for months.

Floating IPS is an IPS patcher, intended to replace Lunar IPS. List of changes:
+ Can apply multiple patches at once. (Can't create multiple patches at once, though; make a batch file if you need that.)
+ Generated patches are (usually) (slightly) smaller. (Both LIPS and Flips are fully capable of applying patches generated with the other.)
+ Can apply and create patches through the command line. (Note that it's a hybrid console/GUI apps, and cmd doesn't really like that, so the output gets misplaced. It acts sanely if called from a batch file.)
+ Can apply a patch and run it in an emulator without forcing the user to create temporary files.
+ Can handle files containing characters outside the 8-bit character set. (But I'd bet you didn't even know LIPS can't handle that, they're rare.)
+ Open source, in case you care.
+ The executable is smaller, in case you care. (You probably don't.)
- Does not set up file associations.
- Interface is a bit less sophisticated.
- Icon is a blatant ripoff.
Have fun.

However, I've got a vague memory of a previous thread mentioning the perfect LIPS replacement having a few features this one lacks. Could you guys remind me what they are?

Edit: Changelog LIPS vs latest Flips:
  • Can apply multiple patches at once. (Can't create multiple patches at once, though; make a batch file if you need that.)
  • Can apply and create BPS patches.
  • Generated IPS patches are (usually) (slightly) smaller (99.9994% on SMWCP2 1-15-13.ips) than those from LIPS. Both LIPS and Flips are fully capable of applying patches generated with the other.
  • Can apply and create patches through the command line. (Note that you'll get the C:\> prompt again, with Flips' output on top, if launched from cmd directly; it works fine from batch files. It's either that or flashing a console window for a tiny while when it's double clicked, and a rare bug is better than a common bug.)
  • Can apply a patch and run it in an emulator without forcing the user to create temporary files.
  • Can compile and run on any platform you want. You can get Windows or GTK+ GUIs, or a CLI-only app depending only on libc. (No plans for an OS X port; I don't have any Macs nearby, though I'll include it if someone else makes one.)
  • Can handle files containing characters outside the 8-bit character set (for example フローティング.ips). (But I'd bet you didn't even know LIPS can't handle that, they're rare.)
  • Refreshes all folder windows once file associations are claimed, instead of waiting until next reboot.
  • Open source, in case you care.
  • Despite the added features, the executable is smaller than LIPS. (Not that you have any reason to care.)

<blm> zsnes users are the flatearthers of emulation
It's nice but I think the interface kinda sucks.. try making it look like LIPS?
Is this the same code base as Clips?

Anyways, seems like a great tool (and it obviously loads up fine in wine), but I'd recommend adding a readme.txt with your download just in case you encounter a user that's completely new to IPS patches.
Yes, the interface is rather primitive. I'll fix that when the rest of the tool is done; I have a feeling this set of buttons isn't going to be the final set, and I'd rather not spend more time than neccessary on a temporary interface. I'm pretty slow at interface design.
What could this missing feature be...?

I think the patcher was originally Clips-based, but I'm pretty sure it's been rewritten beyond recognition. The creator is original; Clips could never create patches.

I'm not sure what would go in a readme. Should I copypaste the FAQ entry?

...oh, and apparently I included all .h and .cpp files in the Flips folder - while using C instead of C++, and naming the source code accordingly. It's fixed now, though I think the binary is identical.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
I'm not sure what would go in a readme. Should I copypaste the FAQ entry?


Maybe something like

Code
--------------------- Floating IPS (flips) ---------------------

  Version: 1.0
  Release thread: http://smwc.me/t/61289

  By Alcaro
  Profile: http://smwc.me/u/1686

------------------------- Normal usage -------------------------

- Applying a patch:
1 Open up flips.exe
2 Click "Apply IPS patch"
3 Find the IPS files you want to use and click "Open"
4 Find the file you want to patch and click "Save"
5 If everything went well you should get a message saying
  "The file was successfully patched!". Click "OK"


- Creating a patch
1 Open up flips.exe
2 Click "Create IPS patch"
3 Find the ORIGINAL file you want to use and click "Open"
4 Find the MODIFIED file you want to use and click "Open"
5 Give a name to your IPS file.
6 If everything went well you should get a message saying
  "The IPS patch was successfully created!" Click "OK"


- Applying a patch and running emulator directly
1 Open up flips.exe
2 Click "Apply and run in emulator"
3 If you haven't set up an emulator path, go to step 3 in
  "Setting an emulator path" and then come back here
4 Find the IPS files you want to use and click "Open"
5 Find the file you want to patch and click "Save"
6 If everything went well the emulator should open up
  with the patched game


- Setting an emulator path
1 Open up flips.exe
2 Click "Set emulator path"
3 Navigate to the installation of your emulator, click on it
  and press "Open"

----------------------- Batch file usage -----------------------

- ???
1 ???
2 ???
bump.

Rewrote the frontend from scratch (libips is basically unchanged).
Changes from last time:
  • Can apply BPS patches now, in addition to IPS patches. I think this is the missing feature I was thinking of. Note that it can't create them yet; you'll get "this patch is corrupt" errors if you try, despite every part of the frontend claiming support. I'll submit this thing to the tool section once this is resolved.
  • Filled in the version information for the executable.
  • Replaced the auto generated interface with one with manually placed buttons. Looks far neater.
  • Can now claim the file associations for .ips and .bps, if you let it. (LIPS claims .ips automatically; I'm not sure which method is better.)
  • Command line is more sensible; --help does what it should, and a couple of other flags are added too.
  • Dropped the attempt to make parts of the frontend usable under Linux. It just made it messy. The patching libraries still hold no dependencies outside libc.
tldr: Every unpolished corner from the old Flips is polished up, and partial BPS support is added.

(I wonder how much Wine likes AttachConsole(ATTACH_PARENT_PROCESS)?)
<blm> zsnes users are the flatearthers of emulation
And it's done.

Now to see how many of LIPS, IPSharp and Clips it manages to obsolute.

Edit:
  • Went agressive and shrank flips.exe by 25KB; functionality is not impacted. Rather good for an app that isn't bigger than 70KB to start with.
  • Removed a gray pixel from the icons. I didn't test them on anything except white backgrounds; it looked ridiculous on a dark green one.
  • Found and fixed a bug where LIPS made smaller patches in certain circumstances. (Okay, wiiqwertyuiop did the first half.)
  • Flips now offers to write the patched ROM to another location, instead of editing the input ROM. If you want the input ROM edited, hit Enter again; it defaults to the input ROM.
  • Increased the granularity for the bps-delta creation progress bar.

<blm> zsnes users are the flatearthers of emulation
OK, so apparently the Flips announcement thread discussion is supposed to be continued in this thread.

Originally posted by Alcaro
Quote
Side note: have not tried FLIPS yet, but thanks for making it. Please be sure to include an option to bypass the checksum verification so that multiple patches can be applied, and forgive me if this was already done.

None of our patches would benefit from that. Our full hacks will crash if applied to wrong ROM, and the "feature patches" were converted to xkas format long ago, which already allows applying multiple patches in a safer way than IPS. Therefore, I must decline your request.

Is this supposed to be a SMW hacking tool, though, or a general IPS+BPS patching tool? It may not be relevant for SMW, but it might in other cases-- in those cases, not having a feature like that would discourage using Flips (or encourage using IPS over BPS, which doesn't seem like something you'd want to encourage).

For example, I created an IPS patch in the past for the Pokémon GBA versions that modifies the level-up EXP requirement table so that you level-up at an insane rate. It's intended to work on original or hacked ROMs. (Now, you could say that patch would be better off as some kind of GBA assembler patch, but I'm not even sure how to do that, and casual players probably wouldn't want to download whatever tool is needed just for a joke patch either.)

–=–=–=–=–=–=–
Advynia: a Yoshi's Island editor - Alyssa's Unlikely Trap demo 3
Your argument is valid; an override option is desirable for that use case.

However, I'm not sure how to handle the technical parts. There are multiple ways to handle it, but all of them have highly serious drawbacks.
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.
Method 2: Ignore the checksums entirely. Will just create an annoying bunch of threads asking "why hax crash" when people try applying our hacks to Super Mario World (E).smc or something.
Method 3: Treat .gba differently from .smc. Will give millions of false positives in both directions and be annoying as hell for everyone.
Method 4: Extend the BPS format somehow to allow marking a patch as applicable to everything. byuu has spent a fair bit of effort on squishing all possible extensions like that (I can't find any sensible location for such a flag), and I don't think he'd like it if I tried either.

Edit: A few minor tweaks.
  • Default name for the output ROM when applying a patch is now patchname.romext in the ROM folder.
  • Flips/Linux no longer claims to be flips.exe because that's complete nonsense.

<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.

Well, you just need to make sure the warning message is unambiguous and the options are unambiguous as well.

Originally posted by Alcaro
Method 4: Extend the BPS format somehow to allow marking a patch as applicable to everything. byuu has spent a fair bit of effort on squishing all possible extensions like that (I can't find any sensible location for such a flag), and I don't think he'd like it if I tried either.

Theoretically, you could use metadata, although that means you would need an XML parser.
GradientToolLevelMusic UtilitySM64 Clean ROM verifierHQX VirtualDub FilterImoSPC2 (Alpha)Music Section SPC PlayerEmbeddable SPC Player for SMWCYouTube EmbedderJSRomcleanJS Address ConverterLazyHDMA
GBA needs a counterpart to Asar, methinks.
Let's milk Sunny Milk. Then she'll have enough money to fund Sunny Milk Real Estate.
Everypony's digging with a shovel
Originally posted by Alcaro
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.
This. There's no reason it should confuse people if written well.

Quote
Method 4: Extend the BPS format somehow to allow marking a patch as applicable to everything. byuu has spent a fair bit of effort on squishing all possible extensions like that (I can't find any sensible location for such a flag), and I don't think he'd like it if I tried either.
He seems pretty dead set on the idea that checksums should be mandatory and nobody would ever want to apply a patch to a hacked ROM (or by extension, more than one patch to anything).
Renamon is best pony.
Originally posted by Alcaro
Your argument is valid; an override option is desirable for that use case.

However, I'm not sure how to handle the technical parts. There are multiple ways to handle it, but all of them have highly serious drawbacks.
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.
Method 2: Ignore the checksums entirely. Will just create an annoying bunch of threads asking "why hax crash" when people try applying our hacks to Super Mario World (E).smc or something.
Method 3: Treat .gba differently from .smc. Will give millions of false positives in both directions and be annoying as hell for everyone.
Method 4: Extend the BPS format somehow to allow marking a patch as applicable to everything. byuu has spent a fair bit of effort on squishing all possible extensions like that (I can't find any sensible location for such a flag), and I don't think he'd like it if I tried either.

Edit: A few minor tweaks.
  • Default name for the output ROM when applying a patch is now patchname.romext in the ROM folder.
  • Flips/Linux no longer claims to be flips.exe because that's complete nonsense.

On Windows, I propose making confirmation message like "The ROM's checksum is incorrect, which means the file has either been previously modified by another program or is corrupt. Do you still want to patch the ROM?" (blatantly stealing from Lunar Magic, I know). On Linux, I propose similar error message (on STDERR), except instead of "Do you still want to patch the ROM?" something like "Force patching using --force option" and exiting with some error code.
Originally posted by Rena Kunisaki
Originally posted by Alcaro
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.

This. There's no reason it should confuse people if written well.
Originally posted by GlitchMr
Originally posted by Alcaro
Method 1: Throw a warning on checksum errors and let people bypass it. Will confuse users in both directions.

On Windows, I propose making confirmation message like "The ROM's checksum is incorrect, which means the file has either been previously modified by another program or is corrupt. Do you still want to patch the ROM?" (blatantly stealing from Lunar Magic, I know). On Linux, I propose similar error message (on STDERR), except instead of "Do you still want to patch the ROM?" something like "Force patching using --force option" and exiting with some error code.

Okay, there seems to be consensus for this.
Then I want one of you guys to demonstrate the exact way to create those well written error messages. GlitchMr's method feels like it'd induce doubt if a patch is intended for any SMB1J ROM.

Quote
Quote
Method 4: Extend the BPS format somehow to allow marking a patch as applicable to everything. byuu has spent a fair bit of effort on squishing all possible extensions like that (I can't find any sensible location for such a flag), and I don't think he'd like it if I tried either.

He seems pretty dead set on the idea that checksums should be mandatory and nobody would ever want to apply a patch to a hacked ROM (or by extension, more than one patch to anything).

That doesn't explain why he personally suggested exactly that feature. His own BPS patcher doesn't have such a thing, it just gives an unspecified error and refuses to do anything.
Nor does it remove SMC headers, a feature he personally suggested too (it's somewhere on his forums, but the search feature over there sucks). Weird guy.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
any SMB1J ROM

The data of Japanese and American SMB1 ROM is identical, if we aren't talking about Famicom Disk System version.
Quit nitpicking my examples. Go do something constructive instead.
<blm> zsnes users are the flatearthers of emulation
I've got a couple of other changes lined up for Flips 1.03, and I'd rather not wait forever with it. I'll release it on Monday, without the checksum bypasser, if you guys don't speak up before then.
<blm> zsnes users are the flatearthers of emulation
Like GlitchMr's one, it makes perfect sense for patches that belong on only one ROM, but I still fail to see how it will not scare people if a patch is supposed to be applicable to anything.
<blm> zsnes users are the flatearthers of emulation