Can monsters be made to display their status?
#1
Something that frustrates me to no end as I'm testing my hack is the fact that monsters give absolutely no indication of their status.  Are they asleep?  Poisoned?  Mute?  Condemned?  Some of these things can be checked by wasting a turn on Scan, but it would be so much more convenient and aesthetically pleasing if the monsters would use head graphics for their ailments like the player actors do.

I've seen some info in the C1 disassembly where statuses can change colors for _player_ actors.  Hatzen made a patch that changes recolors into head graphics for _player_ actors.  LeetSketcher made one that cycles the outline coloration.  But all of these are for the player party.

Is it feasible to force draw the muddle, mute, sleep, countdown, and poison animations over afflicted monsters in the same way?  What about making a monster's palette outline (color 1) cycle colors like the player's does?  Has anyone already made a patch to that effect (I couldn't find one)?  And most importantly, does anyone other than me perceive this sort of thing as a problem/missing feature?

I'm trying to decide if I want to delve into it now, or just release my mod once testing is complete and look into these kinds of things later.  All the assembly I've done thus-far has been extensions of patches that other players programmed, and since xKas won't run for me I have to program directly in hex.  Does this sound like the kind of thing that would be a quick change (like removing a check for whether the target is a player) or an extensive rewrite?
Reply
#2
I admit I haven't looked into this at all or even know how to begin but this sounds like this would be a very complicated reprogramming.

There are two main problems that I can see with the idea. The first is monster palettes have more colors than player palettes, and many of those statuses modify multiple, specifically designated player sprite colors. Trying to do that for monsters might not even be possible due to palette & capability limits.

The second is that unlike players, which have a very standardized appearance, monsters can look like anything, and their sizes vary. Which standard colors in a monster pallete would you swap for zombie? Where would you position the boxes for Sleep and Poison?

If there are no known VRAM issues you could probably create a simplified icon to display a status, but even that will be a nightmare to implement. But, again, I don't necessarily know what I'm taking about, so maybe someone more knowlegable can chime in.
Reply
#3
That probably classify as an extensive rewrite. You could however inspire yourself from the palette cycle code and extend it to monster. If all monster have color 1 as their black outline, itcould be doable to use that. It's not something I would try coding in raw hex though.
Reply
#4
Quote:Something that frustrates me to no end as I'm testing my hack is the fact that monsters give absolutely no indication of their status.  Are they asleep?  Poisoned?  Mute?  Condemned?  Some of these things can be checked by wasting a turn on Scan,

no, it doesn't even do that!!  that's why ADDING the info to Scan would be a very nice starting point (and Square was idiotic to not include it originally).  walk before you run.
Reply
#5
Thank you all for your advice. I've looked into it a little bit, and my rough estimate is that I'd first need to procure about 280 bytes of continuous space in the RAM to replicate player status storage for the six monster slots. If I can't find that much space, then the feature really is impossible for FF6.

I can't believe Scan doesn't list the statuses... I must have been thinking of FFX. However... setting up new strings is rather complex from my position, whereas making a tweaked copy of an existing display is more down my alley. I was able to extend GrayShadow's Relm learning patch (Natural Abilities) to six casters without really understanding the register or carries, simply by replicating code that already works and repointing it. I'd be doing the same thing here with statuses.

From my cursory examination of C1 (well, the part relevant to head graphics for statuses), it seems the function builds a heirarchy of statuses through various 'and' commands, then displays the highest-priority head graphic over the actor. It's set up to do this for Actor 1, and then when the subroutine is called for other actors it applies a RAM shift.

Anyway, it's a big rabbit hole to explore, and I'd rather not banish my mod to vaporware while I delve into it. I'll revisit the idea as an addon patch after I've contributed something substantial to this community, since I've gotten a lot from this place and have as-of-yet failed to give a return on that loan.
Reply
#6
So, I've been looking into this and Assassin was very much correct; it's very impractical to add graphical indication to an enemy to indicate their status. The two patches I was hoping to use as guides to that effect change existing RAM infrastructure to modify how statuses display on players, but that data then points to undocumented draw commands. Additionally, monsters have no similar data structure in the RAM, and there does not appear to be space to add it.

Even if there was, my basic comprehension of hex editing lacks the skill to implement it.

All hope is not lost, however! Notifying the player of the monster's status should be possible with the monster script system. If the monster is given a conditional attack (through battle command FC) reacting to the spell Scan, that could trigger a status check, which in turn could trigger a message to display, then that message would be appended to the Scan display and tell the player if the monster has a status.
Also... if I can find out where the color for command FA's red flash is stored, maybe I can change it conditionally and have the monsters occasionally flash different colors based on their statuses (haste, slow, stop, shell, safe, reflect).

There are two flaws with this approach, of course; it'll eat up a LOT of battle script space _and_ if the monster is berserk or muddled the status messages will not display (since it causes the monster to ignore its script). Still, it's at least a start; going to see how far I can get with this.


I also had another idea which might work to display more statuses, but it would severely limit the possibilities during battle. If each formation was restricted to three unique monsters (no duplicates), the remaining three slots could be reserved for each monster's corresponding 'sleep' variant. When subjected to the sleep status, the awakened monster would be hidden and its sleeping variety (with a separate graphic) would be revealed (using variables to transfer HP and MP). Likewise, when sleep is removed (by timer, physical damage, or what-have-you) the sleeping monster would be hidden and the awakened monster would appear once more.
By limiting the roster to three unique monster types, statuses like Poison, Stone, and Frozen could be additionally represented by changing the monster's palette (there are only 3 per battle, by monster type, hence requiring uniques).
This idea introduces even more problems than the first, however, since it would not only eat up monster script space but also monster graphic space, halving the variety of battles in the game. It'd also probably require heavy scripting for multi-wave monster fights [scripted formation changes] to keep the battles interesting, considering the number of monsters on screen is severely limited. Finally, this wouldn't work in a patch that uses Leap for learning Rages because every monster formation would have six entities in it... it's really something to explore on a from-scratch project.

Anyway, I'm going to toy with the monster script editor and see if I can make something interesting with this.
Reply
#7
You are right on several points. It's certainly not the case that no one has thought of adding a method to indicate or check monster statuses. That's not to say it's impossible, but it is sufficiently hard to say the least. (Of course some are indicated already: imp, confuse/muddle/control, death/petrify, vanish)
The idea of adding the info to Scan as text is the easiest way, in my opinion, as text is fairly easy to work with and we have game examples to work from. 
Doing a tint or flash may be possible as well, given that monsters already flash when they attack, and there's that script command that tints red. 
I'd recommend not using the AI script to do it, as you noted that would lead to huge scripts. 
Something like a head graphic is probably the hardest. If you can just reuse the character ones, that's an idea. Mute, for instance. I dunno, it would be an awesome patch if done well.
I appreciate the prayers and good wishes. Those who don't know, I was diagnosed with stage 4 melanoma in 2019, and I have done well with the treatment, but eventually treatments stop working and you change.  I recently had a seizure at work, now I am healing but not able to work or really do much at all. The focus is just to get better. Again, thanks for the support and if I can help you I will.  I've forgotten more about this game than most people should ever learn, lol.
Reply
#8
Has anyone ever expanded and/or relocated the monster scripts before?  If so, how would one go about doing such?


I'm still in the theorycrafting stage; I want to have a good plan of attack before I dive in.  My current idea is to condense redundant monster abilities (such as Raid and Shimsham, which are easily simulated with Drain and Gravity) and use the spells freed up by discarding Slot from my game to make 'dummy' spells that play certain animations.  For instance, the Haste animation, depleted of its index 1 setting, masks its target and overlays a textured color which is customizable.
Then, I can either have a monster script cast these spells as counters to the presence of certain statuses, or I can write some hex to trigger the casts like the forced "Doom" cast at the end of a condemned counter (preferably with some random element such as with Evil Toot, to avoid a string of long spell casts).

It'd be easiest to do this in a monster script, as described, but as discussed that's going to eat up a LOT of space, way more than there is currently room for.  I know people have expanded things like monster graphics, though, which is why I ask if and how the scripts can be relocated.  Is there a tutorial on the matter?  Alternatively, is there a way to prepare a single block of redundant monster script and then inject it in place of another command (or rather, point to it and return once it has run)?  Like say, setting it up so that putting XX YY ZZ in a monster script will run the monster status script?
Alternatively, if I can code a splicing of Evil Toot and Enemy Roulette, I guess I could insert it right before monsters complete their ready stance (a JMP to and fro somewhere in the vicinity of C2/4E66).


Hrm... wait, I've got another idea.
If I sacrifice one monster slot per formation, I can make a nameless and invisible 'Status' monster with its own script.  It would check the other monsters on screen when it gets a turn, and cast the corresponding 'status' spell on them (randomly from the statuses in play).  That'd solve most of the redundancy problems.  Granted, it limits formations to 4, or 5 for non-Veldt sets, but it might be worth it to have that information on hand for the player.
Any thoughts on that approach?
Reply
#9
Monster script space can be expanded with FF3usME. You'll have an extra 0x8000 bytes (there is a potential bug with scripts past second half of extra bank).
Reply
#10
Okay, so here's my first attempt at a script for an invisible status monitor monster, to be added to every formation to supplement battle function.


EDIT: Eureka!  I've got a working proof-of-concept.  It's a little slow, but it functions as intended.
Quote:Old post:
[spoiler]
Code:
[Script generated by: Final Fantasy 3us Multi Editor, Coded by Lord J]
[FF3usME version: 6.8.0]
[File version: 1.00]
[Section: Monster Battle Scripts]

[script #-1]   ; orig idx=0, "Guard", nb. bytes=185
FC 1C 00 00    ; Executes commands, even if Quick is in effect
FB 01 36       ; Target self becomes invincible
FB 07 36       ; Target self becomes untargetable
FC 13 01 01    ; If 1 monster(s) or less remain
F5 00 01 00    ; Monsters  are killed, suddently
FE             ; End If and reset targeting
FC 0D 56 0C    ; If variable VAR086 is greater than or equal to 12
F8 56 00       ; Set VAR086 to 0
FE             ; End If and reset targeting
FC 0D 56 0B    ; If variable VAR086 is greater than or equal to 11
F8 56 81       ; 1 added to VAR086
FC 08 37 02    ; If target all monsters except self is affected by status Poison
69             ; Poisoned
FE             ; End If and reset targeting
FC 0D 56 0A    ; If variable VAR086 is greater than or equal to 10
F8 56 81       ; 1 added to VAR086
FC 08 37 15    ; If target all monsters except self is affected by status Shell
6A             ; Warded
FE             ; End If and reset targeting
FC 0D 56 09    ; If variable VAR086 is greater than or equal to 9
F8 56 81       ; 1 added to VAR086
FC 08 37 0D    ; If target all monsters except self is affected by status Muddle
6B             ; Muddled
FE             ; End If and reset targeting
FC 0D 56 08    ; If variable VAR086 is greater than or equal to 8
F8 56 81       ; 1 added to VAR086
FC 08 37 16    ; If target all monsters except self is affected by status Safe
6C             ; Protected
FE             ; End If and reset targeting
FC 0D 56 07    ; If variable VAR086 is greater than or equal to 7
F8 56 81       ; 1 added to VAR086
FC 08 37 0C    ; If target all monsters except self is affected by status Berserk
6D             ; Berserk
FE             ; End If and reset targeting
FC 0D 56 06    ; If variable VAR086 is greater than or equal to 6
F8 56 81       ; 1 added to VAR086
FC 08 37 13    ; If target all monsters except self is affected by status Haste
6E             ; Hastened
FE             ; End If and reset targeting
FC 0D 56 05    ; If variable VAR086 is greater than or equal to 5
F8 56 81       ; 1 added to VAR086
FC 08 37 00    ; If target all monsters except self is affected by status Dark
6F             ; Blinded
FE             ; End If and reset targeting
FC 0D 56 04    ; If variable VAR086 is greater than or equal to 4
F8 56 81       ; 1 added to VAR086
FC 08 37 12    ; If target all monsters except self is affected by status Slow
70             ; Plasma
FE             ; End If and reset targeting
FC 0D 56 03    ; If variable VAR086 is greater than or equal to 3
F8 56 81       ; 1 added to VAR086
FC 08 37 0B    ; If target all monsters except self is affected by status Mute
71             ; Snare
FE             ; End If and reset targeting
FC 0D 56 02    ; If variable VAR086 is greater than or equal to 2
F8 56 81       ; 1 added to VAR086
FC 08 37 14    ; If target all monsters except self is affected by status Stop
72             ; Cave In
FE             ; End If and reset targeting
FC 0D 56 01    ; If variable VAR086 is greater than or equal to 1
F8 56 81       ; 1 added to VAR086
FC 08 37 0F    ; If target all monsters except self is affected by status Sleep
73             ; Snowball
FE             ; End If and reset targeting
FC 0D 56 00    ; If variable VAR086 is greater than or equal to 0
F8 56 81       ; 1 added to VAR086
FC 08 37 17    ; If target all monsters except self is affected by status Reflect
74             ; Surge
FE             ; End If and reset targeting
FF             ; End first wave of attack
FF             ; End
Unfortunately it's not behaving as intended.  I was trying to get the statuses to cycle each time this 'monster' got a turn, so that it would display something different.  However, it seems to exclusively favor conditions near the bottom of the script, which is bizarre because other enemies with variable timers (Like the Imperial Airforce Base) appear to be arranged the same way and work as intended.  For instance, if any enemy has sleep, the status monitor will never cast the spell associated with Safe.

Any pointers on what I'm doing wrong here?  Is there a better way to set up a monster spell cycle?[/spoiler]

Have a weird follow-up question, now.  Enemies are only allowed three unique palettes per battle formation... how does the game determine which palettes to use?  Are they indexed by monster number, or by formation position?  That is, if I put in a fourth enemy type in a single battle but it's in the last or nearest-to-last formation slot, will it use the palette of an already-loaded enemy?

I ask because my current approach adds an enemy to every encounter, and while this enemy will be invisible I don't want its palette mussing up the others in the fight.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Monsters are invincible/Algorithm question??? ExiaTreason 12 8,889 10-30-2017, 07:01 AM
Last Post: seibaby
  Have monsters appear in places where they usually don't? Kugawattan 1 2,444 12-13-2015, 09:08 PM
Last Post: Lockirby2
  Sharing some Spell Animations made via FF3usME Badass 23 26,268 03-25-2012, 04:19 AM
Last Post: Badass

Forum Jump:


Users browsing this thread: 1 Guest(s)