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.

Topics - STARWIN

Pages: [1]
Programming / Find-Replace Patcher
« on: December 15, 2014, 10:32:53 am »
Recently I tested if I could apply a patch meant for a headered version of a SNES ROM to the headerless ROM. The tested patch formats included IPS, UPS, BPS, PPF, xdelta3, bsdiff and linux diff/patch. They all failed to produce the file I could produce by adding the header, patching, and removing the header.

Some failed because they use offsets and others failed because of the checksum mismatch (so I don't know if they would have produced the correct file). The linux patch thing seemed to only work for text. Overall I imagine that all these are meant to change a specific file into another, and as such operate by file offsets.

Does anyone know of a patcher that would pass this simple test?

It is interesting that the lack of a checksum allows some IPS patches to target differing source files with the desired outcome, as checksums are otherwise thought as a good thing. IPS only requires the file size and structure to remain the same in the affected offsets, and that the file usage regarding these offsets remains the same. If these offsets contain program code, there is also the added requirement of RAM manipulation by the code not conflicting with any other code that gets executed.

In a typical (?) patching process, offsets are used to identify the location of bytes that will be changed/removed/inserted. An another way to identify the location would be searching for a unique byte sequence that resides in/near it, and then perform the necessary operation.

I think I might try designing/implementing a patcher that operates this way.

Ideally this more local approach would allow one patch to work against many differing source file versions. Examples include headered/headerless ROMs and different language/release versions of games, as long as they share the bytes-to-be-changed. A less common use case would be targeting bytes that have been rearranged to a different location by some other hack, though all inserted references and jumps containing an absolute offset to a shifted location would still break (if the patcher doesn't have knowledge about the arch in question, at least..).

Creating a patch format just to solve the SNES headered/headerless -issue would be trivial (offsets would be enough), but taking the more generic route sounds more interesting, as it should solve the simpler case as well.

The design consists of two primary parts: the identifier and the operation. I'll focus on the identifier.

While a some kind of hash function could be used to identify, I think it is simplest to use the raw bytes themselves unless the lack of uniformity in the data becomes an issue (leading to long identifier sequences). Though if rare bytes are to be modified, the lack of uniformity is actually beneficial.

The identifier should be as local as possible. For example, if data is changed in the beginning of a SNES ROM, a patch using header bytes to identify the location will fail for a headerless ROM. Ideally the identifier resides within the change location, so if it cannot be found, the file couldn't be patched anyway. However in general this degree of locality is unrealistic, so the patcher has to be only ~as local as allowed by the file structure.

The perfect example of both non-locality and long identifier sequence would be code inserted in the middle of a long run of 00s or FFs ("empty space"). I think the best way to solve this is to include a relative offset to the identifier (allowing us to name the emptiness by the unique bytes at its edge and an offset). This much locality has to suffer.

As this type of a patch is meant for an ambiguous collection of source files, failure will always be a possibility. If the byte sequence is not found in the entire file, the patcher won't know where to operate. If the source file is improper, this is good, as we can then deduce the validity of the file without a conventional checksum. If a differing file has exactly one similar spot, patching will happen and in the worst case it will break later when playing the game. But how likely is this to be a problem? I'd say only with shifted data (applying a hack to an another hack) with absolute references.

One could ask why the identifier has to be unique, as just adding a count to any identifier would make it unique. The reason is that locality would suffer, and the patcher would also get confused if data was swapped. Just as with file offsets.

I can think of some extra functionality for patch creation. Giving a collection of alternate source files as hints to the patcher would allow it to choose identifiers that uniquely match all files, or notify the user of the task being impossible. Architecture knowledge would be both an interesting and scary form of extra functionality (think of searching for correct places to point pointers/jumps to).

I don't have any special ideas about the operations themselves. Which probably means that something primitive can be made without much thinking. Detecting a data shift would mean scanning the source file for each difference during patch creation. If nothing is found, insert new data. If something is found, change source scan pointer location there and continue. I'll probably think more about it if something doesn't work.

Any feedback on the idea? Issues noticed?

1. Vanguard Bandits mod

I'm in the progress of creating a mod for Vanguard Bandits. My intention is to change some things I simply feel like changing, which someone might call a balance mod. I'm interested in increasing the difficulty of the game slightly, but I'm not aiming for a hardtype mod specifically.

The current plan for changes is as follows:

¤Replacing WEP stat with SPD stat
Because I feel that AGL stat is too powerful as it offers both evasion and speed (and accuracy). Because ~no one picks WEP stat as the weapon offers a considerable boost to it. SPD stat would receive AGL's effect on speed - and possibly the effect from BAS as well. WEP stat would actually stay, but it couldn't be picked at level-ups and it would basically equal the weapon WEP boost.

This would be a somewhat major change. I'd prefer not to rebalance opponents too much, but this change will reduce everyone's WEP stat (so I probably have to increase/scale the weapon WEP boost a bit) and it will also mess with everyone's speed (so I have to set their SPD stat to compensate). If the SPD speed boost equals original AGL speed boost, compensating is trivial. I'd probably want to remove the speed effect from BAS as well, but then there will be forced speed rebalancing, as the BAS speed boost is smaller  :(. I'm a bit afraid of some specific scenario being turn-order sensitive. As this will make one more stat useful and I'll fix opponents to have their original speed, this will automatically increase difficulty for the player.

¤Less money available
This is really simple. I think it is more exciting to plan when you can only afford few items from shops. I'm thinking of cutting the monetary reward for slaying an opponent by 75%, but that number is just a shallow guess.

¤Change requirements for abilities
I just think it might be fun to change these. At least of the dormant abilities. Also, if someone is familiar with the game, this would offer them an opportunity to re-explore it a bit.

Changes that I'm less certain about:
-Some amulets offer certain abilities that are quite useless and/or already known. Either make these cheaper, make the abilities harder to obtain or they are just doomed to be irrelevant items?
-Increase difficulty of final battles? Earlier changes may already result in this.
-Allow final boss to move, perhaps with low movement

Nothing is set in stone yet, as I'm still exploring the game code. I'm not planning to change every aspect of the game - the less work the better actually. Still, if someone has thoughts about making this game more interesting, feel free to write about it.

Various game mechanics for this game are unknown in their accurate form, as of writing. I couldn't find anything from the internet besides the usual shrine/manual knowledge and some posts about speed/HP calculation. Due to WEP->SPD change being major, wanting to know what the stats precisely do and curiosity, I'm reverse-engineering some of the simpler parts of the game. This knowledge also serves as a partial list of targets for possible changes. All numbers are in hex uppercase.

speed = agi*18 + bas*4 + FA

accuracy calc: real calc uses (51EB851F*x*m)/2000000000 instead of x*m/64 that i have here (approximation)
a- attacker d- defender
DEXmW, AGImW = penalty 4B, normal 64, bonus 96 (bonus modifier weight (swirling icons))
counter = 1 counter skill used, 0 not
C H calmness happiness, value range 0 .. 9 .. 11 default 9
Dm direction modifier | 64 7D 96 7D  |  front side back side
SAm skill accuracy modifier (eg ingame number 1.20 would be hex +14)

if r30==0, always hit (dDizzy?)
a1 = (aDEX*3+aAGI)*(37+5*aC)/64
a2 = aDEXmW*a1/64
a3 = Dm*a2/64
a4 = (aSAm+64)*a3/64
a5 = a4/(1+counter*(2-aMentalVision))
a6 = a5*((aAltitude-dAltitude)*5+64)/64

d1 = (dDEX+dAGI*3)*(37+5*dH)/64
d2 = dAGImW*d1/64
d3 = d2*(1+(dAvoid?))
d4 = d3+1*(d3==0)
d5 = d4*(dTerrainBonus/(1+aHoverJets)+64)/64

accuracy = (a6*64)/d5 , capped in range [0,63]

not going to solve the entire damage calc.

parry & reflect attack seem to override counter, but not a 2-part attack exchange. they may trigger regardless of defender action pick (but only frontal attacks).
if aAcc.bit3==1 and dParry and rand16-64*((51EB851F*rand16)>>25) < ((dWEP*3+dDEX)*64)/((aBAS*3+aDEX)*4) then deflect attack, rand16 from 0 to FFFF

2. Cooperative 2 player (controller) hacks for turn-based RPGs

-good ~turn-based RPG that feels suitable for 2 players
-for a system which has an emulator that has netplay
, then I have some interest in making a hack that:
-allows convenient character ownership choosing between 2 controllers
-allows controlling own characters in battle for both (not simultaenously, just automatically pick input controller depending on character when it is their turn)
-allows swapping control outside battle conveniently enough

So far I made these for FF3 and FF5 (just the outside battle part). I plan to make these for Romancing SaGa 3 and FF6 (IIRC some character swaps are broken in the sense that it doesn't remember character ownership over all characters, just over the 4 slots) at some point.

These are somewhat simple hacks, so it's probably simper to see them all as a single project. Few people care about such hacks, but those few who do can give feedback here if they have something to say.

Gaming Discussion / hosting ROMs?
« on: December 31, 2013, 06:06:45 pm »
..or so I hear:

What will happen next? Is it a single person soloing in their organization or do they have some kind of legal backup for anything this drastic?

It seems that there are also pre-patched translations.. which might interest some around here, at least in principle.

ROM Hacking Discussion / Unused ROM/RAM space and hacking
« on: April 09, 2013, 11:46:11 am »
While I'm thinking mostly about NES/SNES, feel free to discuss other architectures as well if you want. This will be a swarm of questions, no need to answer everything.

1. What do you do when you need to add more code/data to the ROM? How will you ensure that the new locations you require are unused?

As I understand, some answers are:
-code/data logging while playing the game under the debug emulator
-checking existing structures for unused locations (ends of banks or ends of memory areas artificially reserved for a given purpose) for blocks of FF or 00

Logging answers the opposite question: What locations are used?

Structural analysis relies on coherent organization inside the ROM.

I assume the structure is the determining factor in the mind of the hacker, while the logging part only helps to reveal the structure and acts as a check.

Are there other methods?

Is it common for games to leave ROM unused?

Does anyone have experience of failing (causing side-effects) while using these methods?

2. What do you do when you need to add a new variable to RAM?

Are there RAM access loggers? Technically I can already use breakpoints while playing to eliminate location candidates. Again the answer we get is to the opposite question.

In case the emulator initializes the RAM space, finding location candidates may become very easy, if there is actual unused RAM. This would be similar to ROM structure analysis.

Is it common for games to leave RAM unused?

Does anyone have a more systematic approach?

Any experiences of difficulties?

3. Solving a ROM

Have there been tries to create programs that automatically solve the usage status of every byte in ROM/RAM?

So, instead of a human going through various codepaths and using a logger, the program would do it (as it has more time than we do).

Now, the amount of increasing possibilities obviously leads into combinatoric explosion. I think it might be fun to think of heuristics for this.

Depending on how well the methods for finding free space work, this kind of a solver may be completely unnecessary. Although I believe if there was a program that could solve a NES game, for example, it wouldn't be too much more to also include some codepath/causality information, e.g. mapping all the code that affects graphics memory given some causality distance. In general, automating the analysis of the game to some extent. And obviously full disassembly.

Pages: [1]