Users browsing this thread: 1 Guest(s)
PC Command Edit - targeting

#1
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
I've changed the command Possess so that it redirects to the MagiTek code, runs it, then pulls up a seperate menu of spells using the MagiTek battle window.

All of that works fine, selecting a spell and trying to use it works as well with the pointer going to the proper position and letting me select the player or enemies it should based off the target list I provided it.

After the spell is cast it ALWAYS comes up "miss" and always on one of the two enemies, no matter how it was targeted before casting.

I had this problem before, while running the same type of deal using the summon command but never figured out exactly what fixed it.

Any suggestions or advice?


The only true wisdom is knowing you know nothing.
  Find
Quote  
[-] The following 1 user says Thank You to Catone for this post:
  • ReturnerScum (01-09-2016)

#2
Posts: 149
Threads: 21
Thanks Received: 40
Thanks Given: 3
Joined: Dec 2013
Reputation: 9
Status
Auto-life
I don't know for sure, but since you mentioned the summon command, it has an aim issue and can't be used properly without modification. The following patch fixes the aiming issue: Summon Aim Fix Patch. Perhaps, you can find something related to your solution.

If i didn't miss the conversion, it only changes one byte at C2/4E49. (The PC address is 025049). The table begins at C2/4E46. It looks like a bit field, one bit for each command ID, by ID order. It is related to commands that need target adjustments.

Code:
(Data - commands that need to retarget.  8 commands per byte.)

C2/4E46: 80   (Swdtech)
C2/4E47: 04   (Blitz)
C2/4E48: 0B   (Rage, Leap, Dance)
C2/4E49: 00   (Nothing)
  Find
Quote  
[-] The following 1 user says Thank You to HatZen08 for this post:
  • ReturnerScum (01-09-2016)

#3
Posts: 1,633
Threads: 56
Thanks Received: 13
Thanks Given: 84
Joined: Apr 2014
Reputation: 12
Status
Atma
Oh, so that's not an unique problem of Summon command?
Gonna take note about this one... What?!


THE GREATEST CHALLENGE OF ALL TIMES AWAITS:
http://www.ff6hacking.com/forums/showthr...p?tid=2593
DO YOU HAVE WHAT IT TAKES TO SLAY A GOD?
------------------------------------------------------------------------
Tenkarider's project #2 is started: FF6 Curse of the Madsiur Joke (CotMJ)
http://www.ff6hacking.com/forums/showthr...p?tid=2755
What happens when Madsiur tweaks your account? This full game hack will show that!
  Find
Quote  
[-] The following 1 user says Thank You to Tenkarider for this post:
  • ReturnerScum (01-09-2016)

#4
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
Yeah, tried the Summon Target fix, it didn't fix this problem though.

I also tried changing to 01 instead of 02 because of Possess being the command in question (fairly sure it falls under a different field than Summon) still no change however.

As far as I can figure, THAT issue has to be caused by the Summon command code (or else other codes have other ways to handle it). I didn't run into that exact problem when I was trying to use the Summon command, I think, because it was running the MagiTek code the entire time, only the command number was different. (Also don't think I was using any spells that needed to retarget, maybe.)

Eitherway, somehow it worked using the summon, shock, and health command numbers (might have to go back to health or shock for the time being) but using Possess as a command number it fails to accept the chosen target.

Also note, I didn't apply that fix the first time around either.

Almost seems like it stopped doing that with the original code after I readjusted the spell calculation table. But that made the spells cast and the spells shown match up as well as accept their targets. Also note, that MagiTek is using the same spell calculations and working 100%. Possess is now running that same code though, so it has to be something that commands 19, 1A, 1B, and 1D do, that doesn't cover command 1C.

Going to look over the code one more time to see where Possess stands apart from the others, if nothing jumps out, going to switch the code over to run as Health and see if the targeting doesn't straighten up.


The only true wisdom is knowing you know nothing.
  Find
Quote  
[-] The following 1 user says Thank You to Catone for this post:
  • ReturnerScum (01-09-2016)

#5
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
did you edit its C2/278A data to use a different C2/2782 code pointer? and its targeting in CF/FE01?

and please tell me you edited the command code at C2/17E5 to no longer have a special effect.
Quote  
[-] The following 2 users say Thank You to assassin for this post:
  • Catone (12-07-2015), ReturnerScum (01-09-2016)

#6
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
That did it.

The reason it worked when I was editing Summon, Health, Shock is they all have a value of 04 in the table at C2/78A, while Possess had a value of 81.

That fixed most of it.

The second part, in CF/FE01, while I'm still not exactly sure how those values work by any means, CF/FE39 (for Possess being changed from 43 0A to FF 00 (same as MagiTek) seems to fix the rest of it.

Actually, changing it to FF 0A made it work. No clue what the 0A is for.

Regardless, that seems to fix the current most issue. Thanks for the intel.

(I should kick myself for not looking at something marked "get commands aiming")...


The only true wisdom is knowing you know nothing.
  Find
Quote  
[-] The following 1 user says Thank You to Catone for this post:
  • ReturnerScum (01-09-2016)

#7
Posts: 149
Threads: 21
Thanks Received: 40
Thanks Given: 3
Joined: Dec 2013
Reputation: 9
Status
Auto-life
To complement the information about the special effects, a few commands (and tools) have a hard coded feature. The variable $11A9 is set with a specific value and it will trigger a extended code for the command/tool. It is a specific code designed for the original code and it probably isn't versatile with its modification.

The tables of pointers at C2/42E1 and C2/3DCD will trigger the extended code, based on the value of $11A9. I will summarize the relevant pointers about commands/tools:

Code:
$11A9 value Command     Pointer ($42E1 table)   Pointer ($3DCD table)
A0          possess     C2/4095                 C2/3B98
A2          gp rain     C2/3FB7                 --/----
A4          steal       --/----                 C2/399E
A6          control     --/----                 C2/3AC5
A8          leap        --/----                 C2/3B71
AA          sketch      --/----                 C2/3B29
AC          debilitador --/----                 C2/3A8D
AE          Air Anchor  --/----                 C2/3C78
  Find
Quote  
[-] The following 2 users say Thank You to HatZen08 for this post:
  • Catone (12-07-2015), ReturnerScum (01-09-2016)

#8
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
... well funk me sideways...

I personally don't seem to be accessing that second table during my current endevor (else the user should be getting removed from the party afterwards, I'd think). The first table, maybe, but currently due to one spell I had assigned missing everytime, but I'm leaning toward that spell not extended code.

Will have to look up where this is accessed though, through the normal main line code, or the individual command's code. Could do some fun editing with such a table though depending on where it was called.


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

#9
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
disable the setting of variable $11A9 anyway. like HatZen08 said, it makes no sense for your new command.

Quote:The second part, in CF/FE01, while I'm still not exactly sure how those values work by any means, CF/FE39 (for Possess being changed from 43 0A to FF 00 (same as MagiTek) seems to fix the rest of it.

Actually, changing it to FF 0A made it work. No clue what the 0A is for.

keeping it as the vanilla 0A was a good idea. that second byte is the CF/FE00 (plus index) value of the next command. it governs Mimickability and Supported while Imped, so don't mess with it.
Quote  
[-] The following 1 user says Thank You to assassin for this post:
  • ReturnerScum (01-09-2016)



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite