Users browsing this thread: 1 Guest(s)
Patch: Replaced Command - Possess with 8 spell list

#21
Posts: 644
Threads: 40
Thanks Received: 46
Thanks Given: 30
Joined: Jan 2015
Reputation: 11
Status
Zombie
At one point I had this new command using the Lore animation by default. While it worked a little smoother with alot of monster spells (probably because its ment to cast monster style spells already) it included the litle blue casting effect behind the actor. Maybe desirable for some, just didn't like it as default.

A quick adjustment would be to change the animation pointer entirely, but that would also remove the blue casting effect, so to do it proper I think the adjustment would have to be made at the animation code.

Could probably compare the code for Lore animation at C1/B8E5 and the general casting at C1/ABEB and start swapping values. Haven't looked at either enough to know what to change or attempt to convert half of it without changing all of it. That's where I'd start, other hand that info could be handled out in the great beyond.


The only true wisdom is knowing you know nothing.
  Find
Quote  

#22
Posts: 89
Threads: 2
Thanks Received: 3
Thanks Given: 1
Joined: Jul 2009
Reputation: 5
Status
Vampire
ok so for a non coder I know that i usme would let me change the casting frame. perhaps if i copied red magics specs but changed the glow to blue... still it wouldnt have the unique triangle thingy...

also any non learning magic skill is lore according to program? still I think a casting stance is appropriate
  Find
Quote  

#23
Posts: 349
Threads: 27
Thanks Received: 140
Thanks Given: 129
Joined: Dec 2018
Reputation: 20
Status
Moog
NECROMANCY!

So I've been using this wonderful patch for a while, and the false negative on the command swap was giving me balance problems.
I finally figured out what causes it, though!
$2BAF won't have the right value if someone else is performing an attack when you open the menu!
Since it's a single command parity instead of a series of distinct commands using the Magitek frame work separately, the easiest way to fix the problem is to check a different variable. $64BA is set when at least one party member is in Magitek mode. Since Magitek Mode removes other commands anyway (unless you're doing something REALLY complex), you can safely use this as the flag to check "Hey, is this the Possess Replacer or not" instead of trying to read which menu slot the player's cursor is hovering over.

Just replace the two $2BAF checks with $64BA checks that BEQ when compared to 0 (indicating the Magitek menu should be used instead).
  Find
Quote  

#24
Posts: 644
Threads: 40
Thanks Received: 46
Thanks Given: 30
Joined: Jan 2015
Reputation: 11
Status
Zombie
Is it still a necro post when the poster is more of a necro than the last post?

Anyway, I can't help but admit I'm about as rusty as it gets and from the looks of things when I wrote any of this I had barely kept things considered half propped documentation. That being said, I wasn't aware of 2BAF would be changed if another attack was in progress (kind curious how that happens, honestly). 
According to dates on my files this is an old one and I doubt I was enough of a "coder" or intoxicated well enough at the time to have even thought of 2BAF being off, I also don't remember what else I was cussing at the time. So not sure if this was a quick side project, with the hope of being usable without interrupting the vanilla game, or if I was playing with airships, quest, and magitech armor around that time. Regardless, does 64BA also flag if anyone has the magitech command, or only when someone is flagged in armor? (I seem to recall the flag for being in armor as sepperate from the command...)? 
Not saying its not a better solution, hell I barely remember testing this at all and never got around to rewritting a battle field to require "guest" that would need it either. 

Oh and again, I'm rusty enough to be a complete noob ATM so it'll probably take me a week and a few shots to make sence of any propper answer, so....
  Find
Quote  

#25
Posts: 349
Threads: 27
Thanks Received: 140
Thanks Given: 129
Joined: Dec 2018
Reputation: 20
Status
Moog
$64BA gets set if anybody in the party is found with the Magitek Status... I think it gets set at the start of battle, and it doesn't check if everybody has the status... only if at least one person has it. It's the same ram value that tells the game to draw the MTek Armor instead of the regular character stances (and it is otherwise only used for draw purposes). It does NOT check for the Magitek command separately, so the fix I shared last year is only useful if you intend to restrict the Magitek Command to armor segments and the new command to unarmored segments with no overlap... so no Gestahl with Magitek simultaneously with Terra using Tech, unless you want to risk somebody loading the wrong menu if the player inputs too fast.

I'm not sure how to go about making it more robust than that, it might be an unavoidable quirk to the menu functionality itself. I know that FF5 had similar problems for that Void Divergence hack: there were ways to trick a displaced menu into loading the wrong offset with player swapping. Seems to be a problem that carried over into more modern games too, like that FF8 swap-character limit break exploit.
  Find
Quote  

#26
Posts: 644
Threads: 40
Thanks Received: 46
Thanks Given: 30
Joined: Jan 2015
Reputation: 11
Status
Zombie
So the problem is with 2BAF and what it's actually looking at instead of what it should be looking at. 
Don't get me wrong, its a very interesting quick repair, I was never aware of that problem. Course as I said, it was a quick project either way so I'd have probably never caught it regardless. 

If I last long enough to remember anything I want to know whats going on with 2BAF, even more so since the Magitech status is set when you get the armor, through event code, or like the opening of the game when the characters are "created" and placed on the map. Which leaves the question, why would a status check, which as far as I remember can't change in battle, be thrown off by another attack?

Edit: I say "when you get the armor" because I did some work on another that allowed it to be equipped from the airship. Don't think I ever got it to show on the world map though. The point was more adding stuff to the airship rather than the armor specifically, think I got a little more occupied with the chocobo riding instead. (And then it shows up on the "random" screen shot with its far outdated "arrow to the knee" reference... Regardless,

Thanks for the reply.


The only true wisdom is knowing you know nothing.
  Find
Quote  

#27
Posts: 349
Threads: 27
Thanks Received: 140
Thanks Given: 129
Joined: Dec 2018
Reputation: 20
Status
Moog
(07-22-2022, 05:43 PM)Catone Wrote: So the problem is with 2BAF and what it's actually looking at instead of what it should be looking at. 
Don't get me wrong, its a very interesting quick repair, I was never aware of that problem. Course as I said, it was a quick project either way so I'd have probably never caught it regardless. 

Yeah, the problem is that 2BAF (pending user command from battle menu) gets stale between the player readying the action and the player performing the action.  If it detects a different command, which it might if somebody else loads a menu, then the custom menu loads based on that information instead.  If it helps, it only seems to be a problem when both Tech and Magitek commands are in play on the player menu.
Could go about it by setting aside free workspace RAM for all of the actors, saving who has Magitek and who has Tech at the start of each battle (so that the value is fixed throughout the battle) and then determining which list to load based on actor position in that new RAM table.

...There's got to be a better way to put that.
...
If you had 4 adjacent bytes of RAM (doesn't need to be SRAM), you might be able to run a check at the start of battle that records "This position has Tech" and "This position has Magitek".  Then, when deciding which list to load, you set X to the character position, convert that from a number to a bit position (so 0x08 becomes #4), and then load the RAM at that offset to decide.  ...Oh, wait, that would have the same problem, X as character position becomes a stale variable as soon as the action is readied.

...
I'm not sure there's a good way to fix dynamic menu adjustment outside nailing it down before the battle begins, which means you can't have both in the same fight.  I don't think that will interfere with your plan to have optional magitek armor on the airship, because you'd set the status in an event, that'd set Magitek draw mode, and using that $6B4A for the list swap would then accurately prevent Magitek from randomly swapping to Tech mid-fight.
  Find
Quote  

#28
Posts: 644
Threads: 40
Thanks Received: 46
Thanks Given: 30
Joined: Jan 2015
Reputation: 11
Status
Zombie
Okay, I came across my notes for that one and... Yeah, LDA $2BAF (Load "current" command number) would obviously load CURRENT command.

Personally, I think it needs a rewrite to either only check certain characters, or an entirely different method of checking. Since I'm just now re-learning event code exclusively, it mightbe awhile before that happens. Of course, with what I'm doing now, I'll have to rewrite it anyway (that line about "is actor 15 or less" won't work with my build.

I mean, the main purpose was to make it requireminimal hex editing (usable without having to get intimate with hex) without screwing with much of anything else in the game. So, hopefully I'll make it to a rewrite and it'll be more stable and mostly complete-hex-noob friendly, but we'll just have to see.


The only true wisdom is knowing you know nothing.
  Find
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite