• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
April 25, 2024, 03:24:55 am

News:

Use of ePSXe before 2.0 is highly discouraged. Mednafen, RetroArch, and Duckstation are recommended for playing/testing, pSX is recommended for debugging.


(Solved) Why are enemies equipping armor, shields, etc. in their right hand?

Started by Ramza Stan, March 07, 2021, 01:40:32 am

Ramza Stan

March 07, 2021, 01:40:32 am Last Edit: March 09, 2021, 12:11:54 am by Ramza Stan Reason: Solved
(Solved) I have been having a problem with enemies equipping things that are very much not weapons in their right hand.  Miluda 1 wielded a Genji Shield in addition to her regular shield despite the item being enemy level 40 (due to some of my changes it is no longer marked rare, however), and in the next few fights I saw a White Robe, Small Mantle, and Spike Shoes wielded in the right hand slot (if there were any others I forgot).  I don't know what could possibly be allowing units to bypass the requirement that random gear be equippable to the slot, and I especially don't know how they're bypassing the level requirement in the case of the Genji Shield and White Robe.  I have no idea what is causing this, if it isn't something in the patcher then my only guess is it's a side effect of an ASM hack I used, I say side effect because no ASM I have used should have effected enemy equipment in any way.  Is there a way to check what ASM hacks have been applied to a given ISO?
  • Modding version: PSX

Ansehelm

I don't have experience with this particular bug, but not knowing what ASMs have been applied is a major red flag and could lead to something like this.  If it's a mod you're making, you should know all the ASMs you've applied.  If you apply ASMS or other changes to someone else's mod, you open a pandora's box of bugs due to all kinds of unforeseen conflicts with unknown ASMS in the base mod (or bugs due to you making any type of changes in the wrong order).  Again I'm no expert on ASMS, but I'm 99.9% sure there's no tool currently that reads an ISO for applied hacks, and even if there was, it wouldn't necessarily get a clean read due to potentially overlapping ASMS.
  • Modding version: PSX

Ramza Stan

That's understandable.  And I could probably remember which ones I applied if I looked through the list, and I did apply them to a copy of FFT 1.3 that I modified, I just was unsure because I don't think any of them effected equipment.  Although, one of them was a hack that was supposed to change Equip Change to not consume your action and it didn't seem to actually work, but that's the closest thing.  That and a hack to fix it so that innate reaction abilities don't overwrite the equipped reaction abilities because I gave every class innates and some of them are reactions, but I don't see how that would effect equipment. (I am more or less aware of the reaction priority system that convolutes such a thing by the way, but am unsure of the specifics)  I will edit this comment with a list of the ASM hacks I applied, to the best of my knowledge.

EDIT: ASMs I have applied (All of these came with the ASM tool with the exception of the reaction ability overwrite fix which I found on the forums)

Fixed override problem (the aforementioned innate reaction fix)

Katana break chance (Set to 0)

No zodiac compatibility

(?) Random unit equipment more selective (I dont think I used this one, I remember taking note of it but I don't think I actually applied it)

Crystals can include special job abilities

Start button skips events, effects, battle and event text, etc.

Unit slots backfilled when unit is removed from party

Speed up text crawls

Crits always deal bonus damage

Learn on hit = XX% (XX set to 64, or 100%)

Teleport chances per extra tile reduced by XX% (XX set to 14, or 20%)

Float status grants Fly (sadly doesn't work, units move like they have fly but don't actually get the benefit)

Un-Truth Faith/Innocent bugfix

(?)Broken/stolen items can be bought back at Fur Shop (I don't think I used this, partly because I removed stealing from the game, but looking at it there's a possibility I did... And I read somewhere this one can be glitchy, so maybe that's it?  But I'm also pretty sure I didn't use it for that very reason)

Special characters can do propositions (I think I used this one)

Mighty Sword has XX% chance to break equipment (XX set to 19, or 25%, plus I did the code change mentioned in the hack's description to undo the half damage change)

Equip Change innate all (I think I used this one)

Require sword - require weapons (I believe set to make sword skills work with any weapon)

Equip Change fix (Is supposed to allow changing hand equipment with equip change without spending action, doesn't seem to work)

Removes permanent brave alteration (version 2.0) (I think I used this and the next one, but if I did I'm not sure they work because the brave boost from choosing to save Argath/Algus at Mandalia gave a permanent +2)

Removes permanent faith alteration (version 2.0)

And that should be all of them!  All the other hacks in the list weren't ones I would have used.
  • Modding version: PSX

Nyzer

Stacking changes on top of another mod, especially one you didn't make & don't have the documentation for, is generally a no-no.
  • Modding version: Other/Unknown

Ramza Stan

What do you mean by don't have the documentation for, if I might ask?
  • Modding version: PSX

Nyzer

You don't have the full list of exactly what was changed, what ASMs were applied behind the scenes before you applied even more.

Also, I removed your other topic since the errors you're having with it are likely related to the issues in this topic anyway.
  • Modding version: Other/Unknown

Ansehelm

That's quite a list of hacks, so the odds of interference are extremely high. Even if the hacks you added don't normally alter how items are equipped, they could very well be using the same space as some of the ASMs that 1.3 uses, so there's a very high likelihood that the base hacks are getting partially overwritten in a way that's causing these bugs.  Unfortunately 1.3 has long been unsupported, and I don't know if there's even an accurate list of the ASMs it uses. For best (read: not terribly buggy) results, I wouldn't recommend modding over someone else's mod, especially if the contents of that mod are unknown.  That said, here are a couple leads I might recommend if you're up for a little troubleshooting.

-(Easy) Use the FFTOrgASM conflict checker to see whether any of the ASMs you've applied conflict with each other.  There's a (small) possibility that some of them are conflicting in a way that creates this bug.

-(Less Easy) Starting from a clean 1.3, apply each ASM one by one until you recreate the bug, and do without the offending ASM in the future.  Not guaranteed to work and possibly tedious, but probably your second best bet.  Your best bet, by far, is either to take 1.3 as-is, or to make your own from scratch with the elements from it you like.
  • Modding version: PSX

Ramza Stan

@Nyzer That makes sense, I can see the potential for unpredictable things to happen due to that.  I was hoping there was a simple answer as both this issue and the deleted one seemed to be pertaining to rather specific and isolated things to where I thought there might be a clear cause and fix.  I appreciate the response.

@Ansehelm Thank you, I will try those things out.  The way my mod started I simply opened 1.3 in the patcher, made some changes, and applied it to a clean ISO before applying any ASM hacks.  I only changed it to directly modifying an ISO patched with the 1.3 PPF because I realized there were some non patcher changes I would need, though I think the only thing that brought that to my attention was the Tonberry still using Panther sprite.  Also text changes, though I later realized that was something I could to with FFTacText the same way I did with the patcher.  And then I kinda went off the deep end and made more and more changes and experimentation until what started as an attempt to simply create 1.3 Content with the current version of 1.3 plus maybe a few tweaks to things I didn't like became major reworks all over the place.  I didn't even end up doing the removal of story battle level scaling, I just nerfed JP costs all over to reduce need for grinding to keep levels lower before moving on to other stuff.

All that is to say, maybe it would benefit me to save my work as a patch and a text patch and apply them to a fresh vanilla ISO so there's no 1.3 hard-coding involved, rectify my Tonberry issue another way (Possibly even bring Panthers back instead, I'm more of a cat person than a Tonberry person lol), and start fresh with ASM hacks.  Thank you for the input, it made me realize the use of the 1.3 PPF was way less necessary than I may have thought! ^^

EDIT: Nyzer, if I were to create a more stable version of this mod as per the above paragraph but still have the Ziekden issue, may I recreate the topic considering the title of this topic gives no indication of that issue?  Again, provided the likely culprits from this thread are eliminated and I still have the issue.
  • Modding version: PSX

Nyzer

Not for a 1.3 edit, and, yes, that includes even just the Patcher changes. If you could make these errors occur with a clean ISO as your base, after you 100% know what changes were made to the game, absolutely, since then we could actually have a chance of narrowing down what the cause was.

But, for example, 1.3 might not use the normal ENTD or ATTACK.OUT slot for the Zeakden fight. I've actually heard that the extra story battle added to 1.3 was added in rather... roughly, and caused some kind of issue, but I've never asked for specifics.

It IS dimly possible that units failing to deploy is an issue related to the event commands themselves or something, but I really don't see any reason for it to happen if you ripped out all the other units from the ENTD and cleared up the sprite limit.

It'd be easiest to start/download a save file from an unmodded game, get to Zeakden, and see if you can't expand the deployment at that point while doing absolutely nothing else. If THAT causes an issue, we can figure out why, and you could almost certainly carry that fix over to your 1.3 file. It could be as easy as the final deployed unit having an Erase or Remove command but not an Add/Draw one later.

Otherwise, if it's not already a known issue in the base game, folks are going to shrug and say "welp, that's 1.3 I guess".

  • Modding version: Other/Unknown

Ramza Stan

Alright, thank you.  Honestly I think at this point it might be best if I start fresh altogether, not even using 1.3 as a base.  I love a lot of what 1.3 did, but with how much I ended up changing it would have been comparatively small work to bring along the 1.3 changes I wanted into a fresh ISO and not bugger with things I'm unsure about.  I initially approached this project as minor tweaks because that's what it was, but then my ambitions expanded a bit beyond my methods.
  • Modding version: PSX

Ramza Stan

@Nyzer Sorry to ping but I can't find where to mark this as solved.  I looked at the topic on not forgetting to mark as solved but there isn't anything for me to click in the area the example pic on that topic shows.
  • Modding version: PSX

Nyzer

  • Modding version: Other/Unknown