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 - NFITC1

Pages: [1] 2 3 ... 113
... the function that contains the Ultimate Weapon formulas seems to hold a lot more besides.  Haven't looked into what other stuff it has.

If you're talking about what I think you're talking about then that's the Additional Effects handler function.

...the Conformer and Morph are conveniently in the same place...

No they're not... Conformer is in the Gelnika and Morph is in the Temple of the Ancients. However, the Gelnika is where all the enemies that morph into sources reside. You wouldn't know that unless you were trying to morph anyway.

No, the damage formula is really one part. The actual damage consideration is a single byte with two distinct nybbles. The upper nybble (X) determines a few considerations, but not damage directly. The lower nybble (Y) is what actually chooses which damage function to use.

Accuracy Checks are a two-stage look-up process. There's an array at 0x7B7700 that defines which accuracy checks to use with which accuracy consideration. The values range between 0 and 8 with 8 being the terminator of the sequence. These check methods are located at 0x7B77A8. There are 8 of them with three of them being pointers even though they are called. They determine three other things: whether the action is physical or magical, whether to use the special formulae (or stat-independent formulae if you want to be really specific about it, but that's a mouthful), and whether to apply the ultimate weapon modifiers. These are determined by a bit mask located at 0x8FF068. There is a single byte for each accuracy value and it follows this mask:

Code: [Select]
0x2=Secondary Formulae

There IS an entry for a magical action that uses the special formulae, but it is unused. Seems a shame to me. Due to some weird memory handling, secondary formulae cannot be combined with the multipliers.

Check out the look up table at 0x8FF1F8. That's where the pointers to the different damage calculations are. It even has the special formulae starting at 0x8FF238.

The AY accuracy function has a secondary effect of setting a special effect to the action based on the damage value provided (this array is located at 0x7B7720) then uses the standard X1 damage formula.

I had a discussion with DynamicDJ on GFAQs about a Conformer-related issue. Specifically reintroducing the Morph reduction to it. My proposed formula would correct this issue that you're encountering:

Code: [Select]
Power = 1 + ((Power * Avg_Targets_Level) / 16)
This follows most of the other ultimates' power modification calculations and would limit Morph's power AND would prevent power from being 0 or lower.

That check CANNOT be skipped as it is used during every action that has a 0/0 damage calculation. This is used primarily with actions from enemies that have no direct effect on a targets' HP (think Guard Scorpion's Search Scope is the earliest example of this), but it can include status changes. That flag is used to skip the part where the target is to play some reaction animation. Since reaction sounds/damage indicators almost always happen in the reaction animation scripts then nothing typically happens.
Oddly enough, the status changes magics (Toad/Sleepel/etc) typically use 2/2 with a power of 0 rather than 2/0 which would prevent damage completely even if a power were a non-zero value.

I've encountered this error on Windows 10, but don't remember it happening in Win 7. It's weird. I'll have to look at it when I get time. I'm not sure there's a work-around.

In vanilla there are four "categories" of magic: Restore, Attack, Indirect and "Forbidden". Each magic action is assigned to one of these categories in a specific order. If a character has even one of these actions in a category, the entire category is added to the magic menu for that character including the not-enabled magics that will just appear as a blank in the menu. If a character doesn't have a magic action in a given category, the entire category is omitted from the magic menu for that character. The categories can be rearranged in the options menu, though Forbidden will always be last.

Aerith has Cure1, Cure2, Poisona, Barrier and MBarrier on her. Cure1, Cure2 and Poisona belong to the Restore category and the Barriers belong to the Indirect category. Her battle menu would then look like this:

Code: [Select]
Cure1    Cure2

Barrier  MBarrier

Those blank lines fill out the Restore category and pad the beginning of the Indirect category.

Video clip

✔️ multiplayer ff8
✔️ button mashing
✔️ in-game audio replaced with random nonsense

Yup, modern filmmaking at its finest.

It's called "I want to use something I won't pay for and can't be sued for".

Could sub SUB forums be used?

eg, Forums »    Final Fantasy Forums »    Gameplay Mods »    Gameplay Releases »    FF7

That's because there are 56 entries in the order table, but only room for 54 in the magic window.

Master Magic doesn't pull magics past 53. 54 and 55 are dummy actions probably used by developers to test certain death animations or just to get through the game faster.
You cannot add new magic actions. Doing so would screw up so much.

You can't introduce NEW magic actions past index 53. Then you'll have to make sure the spell order (In the Initial Data tab) has the new action in the menu that you want it.

Super nova can work with more effort, but that takes a degree of modding outside of WM's scope. That would require some heavy exe editing. I once did some minor editing of the Ultima animation, but the code is so convoluted that it wasn't really worth the effort. Getting Supernova to work anywhere might be worth it, however. Sadly, the function to take a snapshot of the background doesn't exist (you might be able to hijack whatever method Odin uses to take 2D stills of actors, but even that makes assumptions) and it makes a lot of assumptions about targets. All of which are true in unmodded, but hard to change by hex editing.

If you can add 78 to the animation index and still be in the range of 0-255 then yes. However, you still won't get Super Nova to work. That relies on an asset that exist only in the swirling heavens battle background.

That only works on the PC version, btw. The PSX has different offset, but I'm not sure what it is.


Over two years ago I promised a version 1.5.0 would be on its way. I am please to announce that 1.5.0 is functionally where I want it and is technically ready for people to try out.

What's changed?

-No more third-party requirements. This is huge to me. Not only does it rid the requirements of Power Packs (an ancient library of obsolete objects), but it also remove the requirement of zlib.dll! The only reason that the dll was required was to achieve the maximum level of GZip compression. Until .NET Runtime 4.5 (which remains the only requirement) the GZip function had two settings of compression: compressed and not compressed. "Compressed" was just the fastest compression option that made it smaller. This was referred to as compression level 1 in the GZip document, but FF7 used compression level 9. Maybe back in 1997 there was a need for 9 different compression levels since it took a long time to compress large volumes at that rate, but not for a project of this size. The .NET 4.5 finally allows for compression level 9 without creating aliases in third-party dlls.

-Better visuals with the stat curves. In a perhaps ironically related note, Power Packs was only a requirement because of the stat curve indicators. Now that the requirement is gone I've reworked the way the curves are functioning to be smoother. It's now based on cursor position (you can right-click to freeze it on a level) and the bounding indicator works a little better. There's even a little highlighted polygon around the stat indicator. Nothing too special, I just wanted to point it out. :) The indicated stat label is now bound inside the preview window instead of to the side. I think it just looks cleaner that way. I've also added preview panels to the curves tab for stat, HP, MP and exp growth so you can compare them per curve entry. I might add a little bit of additional functionality to this, but don't count on it.

-Fixed text glitch? I'm not really sure on this one. Looking at the old code it was clear to me that it was all wrong. Not the method of generating the files, but that the code itself was unreadable. I had no idea what line was doing what. I completely rewrote it and refactored it into smaller chunks. The PC compresses nicely and seems to work just fine with my copy. I reworked the PSX compression, but have no way of testing it. It might be fine, it might be completely wrong. PSX "compression" still takes a long time compared to PC compression and it's more basic. The progress bar at the bottom is virtually functionless right now. Still working on getting that to mean something.

-XML-based labels and drop-downs. Here's where the technical changes stop and the cosmetic changes really weigh in. I've gotten numerous suggestions on how to display certain formulae/stat names over the years and my understanding on each of them keep changing. Instead of releasing a new revision each time an equation changes I'm releasing this version with an XML file that will allow you to change the equations yourself! If "(Power / 16) * (Stat + [(Level + Stat) / 32] * [(Level * Stat) / 32])" doesn't mean anything to you, you can change the entry in the XML to read something simpler like "Standard weapon damage". LOTS of labels and drop-down items can now be customized and I'm not through my list of changeable labels (which is why it's technically ready, but not cosmetically ready :P ).

-XML-based labels and drop-downs. Loading XML files can take some time so I added a little splash-screen to it while loading. It needs some work and is just a placeholder for now (potential copyright infringement ATM), but it's a touch I always thought WM needed.

What's not changed?
Hopefully nothing functional. I refactored a few things and added some threaded code and rejiggered a few things here and there (changed method parameter types and such) that should hopefully make the program run smoother and/or be less memory intensive. Not like it was visually/computationally demanding before, but it's satisfying as a programmer to go back to old code and apply new optimizations to old code.
I kinda wanted to change the AI editor, but I think I'm just going to leave it as-is FOR THIS VERSION. I've tried to change it several times and I was never pleased with the results. I might try again in the future after this version is released and ruminates a while.

When can we expect this version/any new version in the future?
When I get enough motivation to actually tidy it up. Honestly, I'm extremely proud of WM and PrC. Not because they use good code, but because WM has become essentially exactly what I wanted it to be: The de facto modding tool for all things KERNEL.BIN (sans text). PrC has a ways to go (next up will be the PrCMDI that I've been putting off), but when I see that people use, or even mention that they want, WM I get a little giddy inside. However, I've lost about half my enthusiasm for FF7 throughout this journey. I still have extremely fond memories of playing it with my friend back in high school and still love reversing the code to find little mechanics that people want help with. Put into perspective, it's a 20 year old game and my preferences of what games to waste my time on have changed. I still love RPGs, but FF7 now feels like a girlfriend that I got to know a little too well. I was infatuated by what was on the surface, but after digging at it for years I've learned that she's got some major flaws that she didn't want anyone else to know about. I'm still committed because I'm a faithful guy like that. I just don't want to be smothered.
Well, THAT got awkward. The actual answer is "just be patient". I'm not good with deadlines or even dedicating consistent blocks of time to do anything with it. I'd like to say "within the next month" because I only have tiny changes to make, but I won't be bound to that.

... Steam does not allow me to choose different folder as it has a default one :(
Mine does. Why can you not?

I'm not sure if that's the most recent version, but it's better than nothing. Could you either pass me a copy of what you have or put it on the new wiki?

pretty sure it's FF7/Battle/Battle Animation/Animation Script. It's not in the archive.

FF7 pages need to be added, for sure. There are some pages that are completely lost (unless qhimm restores the old wiki). I was writing a page that never got linked to another page so the archive never picked it up. I'd have to rewrite that page from scratch.

That's a good point that I hadn't thought about. Every time I think about this idea it's sounded less and less interesting mechanically for reasons I couldn't put into words. You summed it up nicely. I guess the concept doesn't translate well to an RPG.

Still the idea is out there and I might toy with a few randomized aspects.

I've noticed a few "randomizer" games starting to pop up in the modding community as a while (specically LoZ, LttP and SMB3) and thought it would be great/funny/frustrating to do this with FF7 as well. I think it's possible, with enough hijacking, to remove lots of the calculation of the mechanics and make them actually random rather than influenced by stats. statuses, power, etc. It would also be possible to randomize encounters (sans boss encounters), chest contents, shop inventories, chocobo breeding results, et al just by modifying the exe. The only question I really get stuck on is what SHOULD be randomized?

Here's a partial list of what I've determined should and shouldn't be randomized:

-Action accuracy: much more random on if it will hit or not. 50% hit rate across the board might not be great, but it will balance "well" with other plans
-Action damage/healing: as long as it connects, it can do anywhere from 0 to 9999 damage.
-Statuses/Elements being inflicted: this entire idea might be unbalanced since any random multi-hit action can one shot an entire party with paralyzation. Maybe just randomize a set of statuses (haste, slow, poison, regen, etc)
-ANY random encounter formation can be encountered anywhere: potentially terrible. Would almost certainly game over if the first random encounter was a Stilva or something.
-Chests have random contents with very few exceptions: One key among most randomizers is just randomizing placement of key items/unique items. Getting a Tissue when you thought you were getting the MP Absorb materia might be frustrating. Or using multiple save crystals might break the game.
-Shops contain random items: this is probably the hardest thing to implement and would require a seed stored somewhere. Making sure weapons had appropriate weapons/armor wouldn't be necessary if damage and accuracy is always random. :)
-Randomize materia: this will be the first on the chopping block since you won't be able to make mastered materia without at least one of each in a set. The best way to enforce this is to not randomize the materia at all.
-Randomize fields: Absolutely not. This will break the game in almost all cases.

Of course the most important question would be does this sound interesting to anyone? If no one would go for it then it's pointless to start. Maybe I'd release them all as individual patches so you can mix and match your favorite randomized features.

It would be nice to be able to change the duration of spells/status effects in wallmarket (like barrier, regen etc). I know it sounds like a request... :P but I hope you give that some consideration though and thank you for this tool.

If you read through all 49 pages of this topic (not a light read, admittedly) you'd know why that won't happen with this tool. WallMarket is ONLY a KERNEL.BIN editor and nothing else. The status durations are stored in the executable file. Since that's outside the scope of this tool it will not be an option. There are very few requests at this point that I'd be willing to entertain since it does allow editing of every byte in the entire file. There are a few cosmetic enhancements and fixes pending, however. I'm close to releasing a new "lighter" version, but it won't have any new things to modify.

C in general is way more complicated with its #ifdef and #define keywords. It's completely asinine IMO. C++ is just much cleaner. Still no implicit headers, though so it's still a pain. I think C# fixes a lot of those issues.

Pascal? I thought that was dead. I hate Pascal with as much (if not more) passion than you hate C. >:(

Completely unrelated / Re: Wow, is this place still here!
« on: 2018-02-23 18:31:14 »
I just noticed a 10 year old topic by you that I'm tempted to necro and answer. :)

Pages: [1] 2 3 ... 113