Messages

76

Scripting and Reverse Engineering / Re: Enemy attacks don't respect range (FFVII). Can we change this?

« on: 2014-02-04 20:15:12 »

Perhaps I could look there first. If I can actually open the file property - I've managed to decompress it, and I've opened it in LemASM, but I can't match the functions in the reversing doc with the assembler I'm looking at. Am I supposed to parse the binary in little- or big-endian format?

Edit: Aha! Apparently, I needed to do a wordswap as well as a byteswap. I didn't know the words were read in reverse. Now the disassembled file looks a lot like Akari's reverse. For the sake of any future reader, I found that the point 0x32530 in the decompressed file matches up with line 26789 in the reverse, or 0x800D2530 in the PSX memory map. It's a distinctive jump opcode in a sea of NOPs.

Edit 2: I think I've found the assembler in question. It's at 0x0000DB00 in the decompressed BATTLE.X:

Code: [Select]

30 42 00 20 ANDI V0, V0, $0020
10 40 00 03 BEQ V0, R0, $0000DB14

I found this by looking at the excellent Q-Gears resources, under the 'reverse' folder. The function http://sourceforge.net/p/q-gears/code/ci/default/tree/reversing/ffvii/ffvii_battle/damage/damage_lower_calculation_function.cpp showed that the branch for applying back row modifiers was straight after the main X1 damage equation, just as in the PC version. Then, using http://sourceforge.net/p/q-gears/code/ci/default/tree/reversing/ffvii/ffvii_battle/ffvii_battle.asm as my guide, I found that the function for lower_01 damage resides at 0x8000D944.

From there... well, I cheated. I don't know MIPS assembler, but I do know what registers to look out for (the Q-Gears source helpfully uses them as local variables) and I know what the branch statements look like. I also know about some hardcoded numbers that I could look out for whilst eyeballing the source. From there, I could find a patch I could examine a lot closer.

Of course, none of this may have worked - I've yet to try actually modifying the source, and I could be totally wrong. I can't wait to give it a go though!

Edit3: Huzzah! It works! Setting the 20 to 50 re-enables the check. Only I now just realized... I don't want to re-enable the check; enemy attacks are already tested for range. I want to disable row effects for long range enemy attacks. Changing DB00 causes long range attacks to take quarter damage, because now row effects are being considered twice.

I feel so thick. I'm going to pick this up again tomorrow with a clearer head; I'm far too tired to continue tonight.

The odd thing is, when I look at http://sourceforge.net/p/q-gears/code/ci/default/tree/reversing/ffvii/ffvii_battle/damage/damage_lower_calculation_function.cpp#l46, I can see that the enemy back row status is considered, and that the user back row status is considered, but no checks around the long-rangedness of the attack. I need to find out where this is being handled.

77

Scripting and Reverse Engineering / Re: Enemy attacks don't respect range (FFVII). Can we change this?

« on: 2014-02-04 19:19:18 »

Ah, yes. That's an easy one.

There's a pair of ASM commands that forcibly restricts enemy actions (Command Index 20h) from having this applied during damage calculation. I know you do a lot of PSX editing so I don't know how this will translate, but the "offending" code is at 0x5DE704. It selectively blacklists the 20h command from receiving long-range consideration. Changing the command index checked to something out of range would be ideal:

0x5DE704: 83 78 28 20  ->  83 78 28 50

Hmm, I'm going to be working on the PSX version. Are the algorithms the same? When trying to track down this action, is there something I should look for? When about in the damage equation is this check taken?

Some of the battle engine is disassembled at http://sourceforge.net/p/q-gears/code/ci/default/tree/reversing/ffvii/ffvii_battle/ffvii_battle.asm - around 9163 and 9650 there's some stubs for 'battle_main_damage_calculation' and 'battle_damage_formula_run' - I assume these are the candidates to reverse? I'll try and get the ASM out of the overlay and see how they work.

To be "fair", those characters are optional.

You forget about Barret!

78

Scripting and Reverse Engineering / Re: Enemy attacks don't respect range (FFVII). Can we change this?

« on: 2014-02-02 21:59:31 »

when a player is a target of a back-row enemy, do they take quarter damage? It gets tricky to determine if damage has already been deducted.

I don't really think this should matter; all I want to do is make long range enemy attacks ignore player character rows. I don't need enemies in different row positions to deal differing amounts of short-range damage; it's 'long ranged-ness' I'm adding, not extra behaviour around short-range attacks. Presumably the existing function already does a check on player row - all I really want to do is skip this function call if the attack doesn't have the 'short range' flag enabled. Otherwise, the existing behaviour can continue however it's coded (though there's probably quirks with that stuff, too).

Do you have any other ideas for solving this problem?

79

Scripting and Reverse Engineering / Enemy attacks don't respect long-rangedness (FFVII). Can we change this?

« on: 2014-02-02 20:47:09 »

Edit: This issue has a patch. See http://forums.qhimm.com/index.php?topic=14998.0

Only recently, I discovered that all enemy attacks are treated as close range by the FFVII battle engine. Attacks that are not tagged close range, and attacks that are magical, will still perform half damage against player characters in the back row.

This is a bit of a problem for the balance of certain mods; allowing certain characters (e.g. those with long range weapons) to take half damage for the rest of the game is pretty broken.

The question is: what's the best way to handle this? I can think of two ways to try this:

• Put everyone in the front row, disable the row change effect on the mag-rod enemy attack, and find a way of disabling the 'change' and 'order' commands
• Force a check in the damage calculation for the short-range flag; if the attack doesn't have the flag, skip the row check function

What is best and most feasible? My gut instinct tells me that opting for 2 is the best choice, because it fixes the intended behaviour and creates a patch for other modders to use in other versions of the game.

What I don't know is exactly how to do this. I believe that the battle executable is in batini.x, and that the file is basically gzipped. I could probably get the asm out of it. Finding the relevant functions might be hard, though. I know the location of the enemy stats in the PSX's memory, so I guess I could look for a read and assume that read is the first part of the initial base damage equation. I guess I could try and follow what the game does from there. If I can locate the data for the enemy attack power, and all the attack stats are together, I could probably work out how to lookup the flag. If I need to make the binary bigger, it looks to me like the LBA+Size of batini.x are in the YAMADA.BIN (see the string 63 45 00 00 40 16).

How feasible is this? Is there anything I've missed? Has anyone else already looked at this problem and have any additional insights?


Another thing - how do I use the call stack info of the PSX emulator's debugger? What are the values in the stack viewer? Are they the locations the CPU are expected to return to once the function has finished? Is the most immediate function call at the top (as per a stack?)

80

Completely Unrelated / Re: hey

« on: 2014-02-01 15:53:30 »

I guess I should probably lock this thread.

81

Gameplay / Making modding less painful (FFVII)

« on: 2014-01-26 18:03:22 »

As someone who's been spending an inordinate amount of time over the last couple of years modding Final Fantasy VII, I thought I'd share some tips on testing and playing changes and making the debug process a whole lot less painful.

Testing battle changes (enemy stats, AI, formations, attacks)

If you haven't touched the battle scene lookup table in the KERNEL.BIN, you shouldn't need to reset your emulator to test these changes. You can just go ahead and instigate a fight on the world map. If you want to test a particular scenario, I would use the gameshark 'force enemy encounter' code (80116274 xxxx for NTSC), filling in the encounter ID you can get from looking at the formation data in Proud Clod.

Testing kernel changes (character stats, spells, etc.)

KERNEL changes require a reload of the game. For this reason, it's easiest to work with if you have a 'save anywhere' cheat enabled, particularly if you're tweaking things at the initial part of the game and you don't want to go through the intro video a thousand times. I have found the code 8009D2A6 0000 fairly reliable at giving me this.

Tweaking enemy damage

Use a damage calculator to tweak attack power rather than using trial-and-error with real battles. The relationship between power and final damage will not scale in the way you expect it to. I have one here: http://www.breck-mckye.com/final-fantasy-7-damage-calculator/calc.html

Testing new attacks

Don't use save states to try and get different outcomes for randomized attacks - obviously, loading a state will load all the pseudo-random number generator states.

I would also shove some Master Materia in your save with Black Choco etc., so you can activate attacks without any fussing around.

Skipping things

You can achieve some limited sequence breaking with a 'walk though walls' code (D00A99A4 A979; 800A99AC 0013; D00A99A4 A979; 800A99AE 1000). You should also see if your emulator has a skip frames / fast forward feature. On ePSXe, you can activate this with F4. On the PSX emulator, hit backspace.

Testing with arbitrary characters

The USO code can help you with this - it's a bit like a universal PHS. I believe the NTSC code is D0062D78 0022; 30049450 000B; D0062D78 0020; 30049450 0001.

Testing field changes

I believe fields are loaded on the fly, so simply entering an area should be enough to force a reload from disk. If you want to test things without getting bothered by enemy encounters, use a no-encounter code (8007173C 0000).

General tips

• Keep a folder you can easily reach on your desktop with shortcuts to all your tools
• Use this folder to quickly reach your mod source folders when doing imports with CDMage
• Keep revisions of your old files
• Use something like Wiki on a Stick to keep track of changes, reported bugs, documentation etc.

Hope that helps - and please, if you've any tips of your own, do contribute.

82

Completely Unrelated / Re: request legend of the dragoon mods

« on: 2014-01-26 14:56:41 »

Knock it off, Cupcake.

83

Completely Unrelated / Re: autism kids

« on: 2014-01-25 20:23:07 »

The user bobby678 is now banned. I'm going to lock this thread.

84

Graphical / Re: PSX/PSP Sephiroth and Shinra MOD

« on: 2014-01-21 08:56:58 »

No. Just because it's unfinished and hasn't been updated in a few months doesn't make it 'dead'. Projects like this are extremely time consuming, and done alone can take _years_.

Double check that you installed everything, and if it still doesn't work provide a *clear* description of your problem (screenshots are valuable), then wait. And don't double post. Developers have their own lives and other projects; don't badger people to respond just because you'd like daily updates.

Also: don't double post, and don't use the report post functionality just to get urgent attention from mods. If you want staff attention a PM will suffice.

85

General Discussion / Re: Wiki editing

« on: 2014-01-16 23:55:00 »

You should ask Halkun if you want wiki access. Posting some findings on a thread so we can discuss them first might be a good idea, though.

86

Scripting and Reverse Engineering / Re: Character counterattacks with limits break

« on: 2014-01-04 11:03:34 »

Has anyone got limits to activate on characters outside normal conditions on the first place? Knowing how hacky and brittle most of FFVII's code is, it wouldn't surprise me if the attacks themselves had some kind of limit-specific function calls baked in directly. These might fail gracefully and cause the attack to pass (you won't necessarily get a data error - I think that only happens due to a null pointer check on animation reads).

87

Scripting and Reverse Engineering / Re: Character counterattacks with limits break

« on: 2014-01-02 18:43:28 »

Eyeballing the code doesn't suggest you've done anything obviously wrong, though I'm working without any references or access to ProudClod/WM.

What is the exact issue you're having? Is the limit executing properly but without the attack name in the battle dialog, or... what?

88

Aali's Custom FF7/FF8 Driver / Re: Aali's driver [v 0.7.11b] Help/Bugs/Suggestions

« on: 2013-12-22 20:30:59 »

Do we even want to support the 2013 release? Square had taken community work and repackaged it without giving the slightest bit of credit. Do we really want to give them a free pass to taken even more stuff?

89

Completely Unrelated / Re: Cool / funny pictures

« on: 2013-12-19 19:54:58 »

90

FF9 Tools / Re: [FF-IX] Hades Workshop

« on: 2013-11-28 20:01:59 »

@ Bosola : I'm not sure to fully understand you. First, models are not the only thing Hades Workshop can edit. Second, I don't know how the FF7 tools you're refering to are coded, but I tried to make the binary saves (the "Save Mod" feature, if that's indeed what you're talking about) looking alike the binary data in the FFIX disc : this way, a program reading a FFIX disc should have little problem reading my files.

This is a good practice, as it promotes interoperability, but I don't think it goes far enough. You shouldn't just be saving to binary - for 'gameplay' data, I'd propose you should really be saving a model that may or may not be directly tied to the binary, then provide a compile step.

I can think of quite a few benefits:

• It makes supporting multiple releases with the same mod codebase trivial. Someone wants support for the UK version? Just open the source and tell the compiler to target PAL/EU
• It forces you to separate your model from your binary view in the app itself, which is probably a good architectural practice anyway
• It lets you create an interface with a more advanced model than a simple binary editor provides, e.g. inheritance chains between monsters, re-use of global variables
• It allows you to swap out your binary save implementation if it needs to be refactored
• It allows you to save data in a non-binary representation, which may be more effective (e.g. plaintext, which can be subject to version control)
• It allows players to distribute mods without copyright issues
• If the model save uses a familiar plaintext format (XML, JSON, etc.), players can hack their own mods
• Broken editor versions can't mess up mods as easily, and any issues are visible and recoverable if broken files are in plaintext (because you can just eyeball your mod source files and SVN->revert)
• It's probably a good opportunity to practice an MVC design, which is something you'll need to get to grips with at some point if you intend to become a software engineer

If I were writing this tool, that's the approach that I'd take.

91

FF9 Tools / Re: [FF-IX] Hades Workshop

« on: 2013-11-25 19:26:12 »

I haven't really looked at this application, but I thought I'd chip in with a few suggestions.

The first one is to try and avoid storing player modifications as binary files. Seriously. This was a major mistake with the FFVII tools and I really do think it has harmed serious efforts to create large scale modding projects for years. Player changes should be saved first as text files that represent the state of the model (not binary changes). This is really, really important, because it makes mods portable, it lets modders use source control and it makes it feasible to update the implementation of a particular effect etc. without forcing modders to rewrite their projects. This won't always be possible in all circumstances, like model or texture assets, but it's an absolute must for mechanics / stats patches.

The reason is that with 'abstracted' user files, it suddenly becomes trivial for a modder to immediately port a project to multiple international releases. They can store their projects in subversion and branch / merge features as they see fit (branching binaries is arduous; merging them is practically impossible). Updates to tools are no longer as risky, as if a tool's compile / save to PPF messes up a project, you can always wait for the next release and compile again (unlike with some of the FFVII tools, which occasionally lose data on save and force some very time-intensive regression testing). Faulty implementations are bound to tools, not project files, so modders can continue working on stuff whilst tools get fixed.

The other big thing is that abstracted project records can expose implicit global variables in the binary - like duplicate enemy records - without much trouble. In fact, the model doesn't have to represent the binary file at all - if you want to give users the ability to create monster attribute inheritance chains that don't exist explicitly in the binary, you can do so without (much) trouble.

I'm being a bit prejudiced here - I haven't seen your code, I'm just assuming it looks like a lot of the projects I've seen round here before - so possibly you've already considered this. But as it sounds like your project is growing steadily, you might want to think about these things as they'll have architectural implications (because they'll force you to separate out your model).

92

Troubleshooting / Re: Can not save at the end of disc 1

« on: 2013-11-24 19:01:51 »

I've merged the second topic, but in future, please do not post duplicate topics.

93

FF7 Tools / Re: Damage Calculator

« on: 2013-11-04 21:07:11 »

Nevertheless, I have raised a bug to fix the upper bounds of the randomized value: https://github.com/jbreckmckye/ffvii_damage_calc/issues/7 (I quite like these Github project tools, basic though they are).

94

FF7 Tools / Re: Damage Calculator

« on: 2013-11-03 01:02:42 »

1. I did actually implement some field switching at one point, such that selecting an attack type would turn certain fields and checkboxes on and off, but I figured it was better to leave everything open in case a user was curious about the relationship between e.g. mini and magic damage.

2. This is a fair enough point.

3. I could add some helptext, perhaps. Or maybe change the labels of the highest entries, e.g. 'Hero drinks: 4 (max)'

4. 'Long range' could be a better name.

5. Perhaps I could look at the tooltip text again.

6. Elemental affinity is on my 'to do' list.

7. Of course.

8. I can see that I forgot about the floor on the results of the Rnd function (so the max damage multiplier can never reach 1), but I'm not sure about your minima of 224/256. Terence's guide suggests otherwise:

Random Variation   (Physical, Magical, Cure, Item only)
  At last, damage is adjusted randomly by the following formula:
       Damage = [Damage * (3841 + Rnd(0..255)) / 4096]

I interpret this as meaning the fraction goes from (3841 + 0) / 4096 to (3841 + 254) / 4096, or 240/256 to 255/256.

I considered making something like this for FFVI, but gave up early on in planning. Good job for getting a beta of one for FFVII!

It was surprisingly time-consuming to write, actually. Most of the work was on wiring up the view to the model. I'm not sure I'd do something like this as a web project without some kind of framework to ease things along. I hear good things about Backbone.js and Angular; if I ever get round to that Nibelheim project it's likely I'll use one of them.

95

FF7 Tools / [FF7] Damage Calculator

« on: 2013-11-02 23:35:53 »

I have released an FFVII damage calculator as a web app. You can access it at http://www.breck-mckye.com/final-fantasy-7-damage-calculator/calc.html. You will need JavaScript enabled to use it.

Enter the statistics of the attacker and defender, set flags for battle conditions like berserk and critical hits, then hit the 'Calculate' button to estimate the damage. You can view a damage 'breakdown' to see exactly how the value was reached and whether there is any chance of causing overflow.

It's still in beta, so I would appreciate any reports if it acts in odd ways. I've tested it and it seems accurate, but there's always the chance of something slipping under the rug. I'd also appreciate any requests for features; there's no point to something like this if it misses something obvious.

If you'd like a local copy, you can pull a version of the source from Github. I've licensed the source under GPL2 in case anyone wants to re-use anything from it (not that I'd understand why; it's fairly simple).

96

Troubleshooting / Re: help would be appreciated!

« on: 2013-10-29 20:39:03 »

If this is sorted, I'm going to close the thread.

In future, please avoid double posting - use the edit function instead.

97

Completely Unrelated / Re: Blaustein and Shenmue

« on: 2013-10-26 15:07:14 »

Fascinating stuff.

98

Troubleshooting / Re: close-to-PSX console emulator

« on: 2013-10-26 15:00:41 »

If grey PSX support is a deal-breaker for you, I would suggest testing on a physical box. Otherwise I would write for common emulators and test on PSP alone.

99

Completely Unrelated / Re: So just got pokemon Y

« on: 2013-10-26 14:54:29 »

It is still the deepest, most complex turn-based rpg to ever be created

More so than FFT or Disgaea?

100

Completely Unrelated / Re: seeking input on my future career path

« on: 2013-10-26 14:53:19 »

I would suggest starting with a modest project on an original IP. This will give you practice and momentum before you try anything more ambitious.