[PSX/PC] Battle editor - Proud Clod (1.5.0/FINAL)

[secondadvent]

ok, from what i have seen, if it is stored as a 46 hex number, which it should be, then it isn't in the shopmenu.mnu file from what i can tell, though i did find some unusual things (all were changed from 46 to 10):
0x17bd - selling materia would freeze the game
0x2929 - same as above, but for buying items (froze on entering the buy screen though)
0x2d02 - changed all itme buy prices that were shown to 16777215, still cost the same as usual though
0x2dc0 - screwed up the item icon in the buy windo (not the sell window though)
0x301d - causes it to freeze when selling a materia
0x3052 - changed the sell prices to 1 (not sure if it actually sold for 1, didn't check)
0x316e - made the prices very odd (not 16777215, but very high), made the remaining gil off as well, but sold as if nothing changed, so normal sell price
0x4151 - froze the shop on entering

i am still going to bet that it is in the slxx file, since that is like the .exe of the psx version, unless it isn't stored as 46 or some reason, but i am not going to check right now. i want to check for some more ai unknowns, a much easier thing to do than search a large file for one (or two) values.

[ARMs]

Well you dont have to do it, gotta give you props for trying.  Hopefully you dont quit like i did, but take your time.

Man i'm messing with too many games and i really wish i knew something about compression.

Edit:  0x3052 - changed the sell prices to 1 (not sure if it actually sold for 1, didn't check)

IF this one works i'm happy with this also lol.  Need to check on it later.

[secondadvent]

it was for the actual items, not materia, so it wasn't what you were looking for.

4280|ReturnedGil - the gil an enemy gives as soon as they are killed
4290|ReturnedItem - same as above, but for the items

these are how the vice type enemies (thieves) give back the item they stole from you, but it can also be used to have any enemy give an item/gil right away when killed.

ok, is it possible for an enemy to not drop an item, even with a 63 chance of dropping it? because if  they aren't able to not drop it, then the area from 41a0-41bf may have some effect on the drop rate, since i had one occurrence without any potions, and a few with only one drop...

and bug report, if you click on open with a scene.bin already open, then cancel out, and try to save, it will give an "invalid path" error, likely because it stopped pointing to the current open scene, and became pointing to nothingness.

i also think that something with PrC is causing internal issues with my computer, as i have gotten multiple BSoD (blue screen of death) errors, all with the message IRQL_NOT_LESS_OR_EQUAL, and the most recent one happened after experiencing the previous bug a few times (may not be related), but it did cause some oddities with the ai (like the newfound variable not setting right), but now it is working and i was able to get it to drop an item on the first attempt this time, while the bugged time was causing errored items to appear in my inventory.

[nfitc1]

ok, PrC bug time... when trying to add something to a blank section of ai, if the first thing added besides the end statement is a string to be displayed, and then you click tab/enter/click away, the thing will give you an error message, as well as making the script vanish, and the only way to get around this is to click back onto the script section you tried to edit, skip past the error, and reenter your info (it will allow you to add the script with no trouble the second time around)

I think this is now fixed.

also, i noticed at some random time when trying to change an opcode from 12 to 10, the field where the newly entered 10 was, was completely blank, and iirc the hex offsets were all screwed up, and there was no end statement in the disassembled code, though it was in the actual script (side effect i am guessing, fixed when i reentered the opcode).

I think this is fixed too.

and something else that has been bugging me for a little while, but i kept forgetting to post, was the problem that occurs when filling a box, then clicking into another box without hitting enter or tab, the data stays, and everything is seemingly fine

Not planning on fixing.

and bug report, if you click on open with a scene.bin already open, then cancel out, and try to save, it will give an "invalid path" error, likely because it stopped pointing to the current open scene, and became pointing to nothingness.

Fixed in two lines.

Also fixed a bug where trying to enter a 93 or A0 opcode in a blank script would crash the program.

Added a new feature. Currently very basic (but fully-functional) because most values are unknown and making this was easier than making a lot of "unknown" fields.

I'm also considering a multi-pass disassembling feature that would pass through the script more than once (hense "multi-pass") to make a more accurate disassembled code. No more of that scripts ending in an else block, etc. Only thing is that it would probably take more time. For longer AIs this could take minutes. Of course the single-pass disassemble (the one that's there right now) would still be there, but another button would exist below it to allow for multi-passes.

[secondadvent]

looks good, i think that i am correct on half of the battle setup 2, i have to do more checking though, but got tired of  havng to recreate the scene.bin from pieces .

still trying to find the drop/steal (and morph ) items in the ai, but finding the gil/item drop thing that is used from the thief enemies like vice, so i can use that as a last resort if needed.

[Kudistos Megistos]

Added a new feature. Currently very basic (but fully-functional) because most values are unknown and making this was easier than making a lot of "unknown" fields.

Oooh, I like the look of this 

I'm also considering a multi-pass disassembling feature that would pass through the script more than once (hense "multi-pass") to make a more accurate disassembled code. No more of that scripts ending in an else block, etc. Only thing is that it would probably take more time. For longer AIs this could take minutes. Of course the single-pass disassemble (the one that's there right now) would still be there, but another button would exist below it to allow for multi-passes.

As long as both options are there, this sounds like a good idea as well.

[secondadvent]

heh... i found a set of flags for making an enemy receive a status when hit (similar to setting an attack to a 63 chance, but for all attacks received), gonna check to see if it works for magic as well and not just attacks (using blade beam with death on it caused an enemy to not be hit by it, and be made unable to be completely killed... i had to use life so i could kill it ). going to check for more about it, but it starts on 4040, and should end on 405f.

still not entirely sure on the mechanics behind it, because i killed one enemy, and the other gained shield, not the original one hit.

it seems to not cause the status to the main enemy, but causes it to the other enemies in the group... it could just be to the other enemies of the same name... still more checking to do . it caused a status to a guard hound when set to an MP, so it could be used on bosses to give their allies a status when hurt (does not work on the first enemy so far, even with two of the same in battle).

ok, from what i can see it acts like a status version of blade beam, causing statuses to enemies in the same row, but will work at any time. however it will not work on the original enemy so far...

[nfitc1]

OK, I uploaded the working version for now. There is no multi-pass that you can use yet. As soon as I figure it out I'll let you know.

The current one is actually between a one and two pass. It's decoding everything line by line then going in and spacing everything out. This is, of course, much of what I want to change with the multi-pass, but keeping track of all the jumps is hard. So far it's doing about four passes and it's still not right. Don't take that to mean it's going to take any longer.

[gjoerulv]

Yeah, the formation editor looks good! 

I noticed that the 0x402C flag was unknown. When it's checked, the death animation (red fadeout) will not occur. And when the enemy is killed, the idle animation will simply continue. Well, at least this is true on the single enemy I tested it on.  There kinda was a huge facepalm in the AI of my "phoenix boss" where the enemies' models wouldn't be visible when revived. Thus I checked the 0x402C flag and upon death the idle animation simply continued (though not targetable and quite dead).

And I use the 0x4020 and 0x4023 flags unchecked to make the enemies unmarketable, invisible and not needed to kill to end the battle. I can't quite remember but as I recall 0x4023 is the targetable flag. At least if both are unchecked, the above is true. Sorry if this was old news.

[secondadvent]

yeah, i said about the NoDeathAnimation flag a little bit back and the 4020 is the flag to make them invisible, and you will also need to turn off the main battle script and enable the death flag (not quite sure on this) to make them stay dead.

[nfitc1]

I haven't been updating the .dat file that comes with all this so....sorry.

secondadvent, can you hit me with what you know about the formation data all in one post?

[secondadvent]

yeah, give me a couple minutes to find my notes, and i will post it all here.

ok, most of what i know is about the setup 2, which is where all of the camera data is for the starting camera movement, which is fully customizable from what i saw.

there are four groups of 12 bytes, each (sans the last, which seems to be padding, or a fourth type at one point, like with the fourth enemy id, and the fourth manip/berserk move) is for a specific battle type: normal, special (bad), and special (good, preemptive). i do know that the first one is for normal battles, but i did not check the latter yet (easy to check, would just take a litle bit to get both types of encounter in the guard hound/MP area... i think i will find that out after this post). now, here is what i know about each specific byte:

0x0 - *

0x1 - a low amount zooms slightly forward, facing forward, a high amount zooms past and faces backwards (to the party)

0x2 - *

0x3 - a low amount moves down and faces up (can even see through the ground if low enough), a high amount moves up facing down (aerial view)

0x4 - *

0x5 - a low amount moves the camera right, and looks left (center), a high amount moves left and faces right (center)

0x6 - *

0x7 - a low amount zooms little to none, facing backward, a high amount zooms in facing forward

0x8 - *

0x9 - low moves the camera down, facing down, a high amount makes it move up, and face up

0xa - *

0xb - a low amount makes the camera move right, facing right, a high amount makes the camera move left, facing left

*these may have a smaller effect (tweaking reasons i guess) on the larger ones next to them (0x0 would work with 0x1, 0xa with 0xb), setting them alone did not give that much of a visual difference to me, but it is likely that this is what these are used for.

setting them all to 00 or ff will result in the same thing - the camera moving perfectly centered forward, past the fight and into the ground where you cannot see anything, so they are used to turn off a part of the camera it seems.

i haven't really toyed around with the other battle setups yet, though i could if you wanted me to, all i have done in them is make a chain battle, but for easy testing purposes (no running through the game for one enemy, or if i made changes to one i passed if i would play through to test). it shouldn't be too hard to figure them out, just have to do a lot of playing around with things.

do you think you could make it create a hexdump of all the battle formation data from all the scenes, separated by scene, so that it would be easier to figure out some of the things? i used a hexdump of a couple scene files' setup 2 data, and is partly how i came about figuring it out (values to try out and the layout).

[nfitc1]

There should be four sets of coordinates to the camera movement: Initial Position, Initial Direction, Final Position, Final Direction. I believe these 12 bytes are Final positions, but the next 12 don't seem to influence initial position at all. In fact, initial position may be somewhere else.

This is what I gather from what you posted:

0x0 - 2 bytes - Finishing X-Position
0x2 - 2 bytes - Finishing Y-Position
0x4 - 2 bytes - Finishing Z-Position
0x6 - 2 bytes - Finishing X-Direction
0x8 - 2 bytes - Finishing Y-Direction
0xA - 2 bytes - Finishing Z-Direction

All of which are apparently signed. Of course, this is dependent on what you're calling the X, Y, ans Z axises. Here's a graphical representation of what I mean:

The very middle of the battle field is point 0,0,0. You're Cloud in the Middle slot. You're at point 0,0,0800 or so (where the middle character is) looking down the Z-axis. This is what you see:

Code: [Select]

              8       
              9       
              A       
              B       
              C        <- Y-Axis
              D       
              E       
              F       
7 6 5 4 3 2 1 0 F E D C B A 9 8   <- X-axis
              1       
              2       
              3       
              4       
              5       
              6       
              7       
Now, from a bird's eye view (at 0,8000,0) looking down the Y-Axis it looks like this:

Code: [Select]

              8       
              9       
              A       
              B       
              C        <- Z-Axis
              D       
              E        (enemy side)
              F       
7 6 5 4 3 2 1 0 F E D C B A 9 8   <- X-axis
              1       
              2        (ally side)
              3       
              4       
              5       
              6       
              7       
So the first three words are X,Y,Z coordinates of where the camera will remain. The second three words is the point on the field where the camera will remain focused.....
After testing this I've confirmed that is what is happening. I still don't know where the initial camera position/direction is located. I know it's not the same every time.

[secondadvent]

yeah... i suck at camera info, but at least you were able to understand it enough .

i have no clue where the initial data would be, possibly in another file in the battle folder, since i doubt that the setup 1 would have it. the fact that the 10 bytes are seemingly the same in many formations (first two ff, then something like 2c01/e703) kinda makes it unlikely to be the camera data though... have to try toying around with this to see what it does.

the initial isn't the same for every different formation, but it is the same for a specific formation every time you fight it. the victory/fanfare thing's camera changes even in the same battle, but it seems to be the same ones throughout. maybe this data is stored in the camdatx files?

[nfitc1]

I think the cam files store movements used by the attacks and the victory cam is randomly selected. It may be based on the one that did the killing blow like in FFIX.

I managed to get a text dump of the data from the Setup1 and Setup2 sections in each formation and discovered that 0x6 and 0x7 aren't used and that 0x8 - 0xF are used for something related to the Battle Arena. There are four sets of words that look like indexes. Let me give you an example:

From TFergusson's Enemy Mechanincs FAQ:

Until you get the Tiny Bronco, Battle Square will have the following battle
sets:

  1st Battle - Group A
    2x Mono Drive
    2x Grunt
    3x Grunt
    1x Guard Hound

This group happens to have indexes of 0168h, 0171h, 0178h, 0185h in those words in that order.

 1st Battle - Group B
    2x Guard Hound
    1x Grashtrike
    2x Chuse Tank
    3x Grashtrike

This group has 0170h, 0179h, 0184h, 018Bh in that order.

See what it is yet? Keep reading if you don't.

Likewise, these groups:

   7th Battle - Group A
    1x Malboro
    1x Blue Dragon
    1x Gigas
    1x Dragon Rider
  7th Battle - Group B
    3x Gremlin
    2x Wind Wing
    2x Ironite
    1x Tonberry

Has the following: 0324h, 00E3h, 031Bh, 02FDh

The Battle with Maximum Kimaira (battle 7 of the Special Event) is four 03CDh. Using the indexing method pointed out by secondadvent, this points to scene 243 formation 1 where the Proud Clod for the final Special Event battle exists! So these four words are indexes of candidates for the next Battle Arena battle to take place.
If a formation doesn't appear in the Battle Arena then it gets 03E7h (999) stored in these places.

Now all that's left is the final number.

UPDATE:
Default values for the Unknown section in Setup 2 are:

Code: [Select]

10 27 78 EC 70 17 00 00 90 01 2C 01 10 27 78 EC 70 17 00 00 90 01 2C 01Note that the pattern 10 27 78 EC 70 17 00 00 90 01 2C 01 is repeated twice. Maybe this is two sets of something. The "first" unusual battle that you can encounter occurs in scene 13.
Mandragora x4
Levikron x1 Elfadunk x2
These two do not have the default values, but they also repeat down the middle. Many battles do not do this like the Grangalans. So it looks like it's two sets of 12 bytes whose purpose is still unknown..

[secondadvent]

do you think i could get a copy of that hexdump? i kinda thought that something would have to be in the scene files about the battle arena, and i did notice a few fights that did not occur anywhere else, sans the battle arena, like the one triple bloatfloat battle in the 80's near air buster, which is a possible encounter in group a's second fight. maybe we can finally figure out the scene.bin in it's entirety?

we would also need to find here the strength boost comes from, and it is probably not from the scene files, more likely from the exe.

yeah, i knew those were the default ones, since most every enemy has them, one of the three air buster formations has it set for all three groups of data, making the default the initial camera movement.

[nfitc1]

Filefront's not uploading right now (grrr), but I'll tell you what's in the file. There's a setup1.txt and a setup2.txt totaling about 174K in size. Setup1.txt is a hex dump of all the setup1 segments labeled and organized by scene and formation.
Sample:

Code: [Select]

Scene 0:
Formation 0:  00 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Formation 1:  04 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Formation 2:  00 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Formation 3:  31 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Scene 1:
Formation 0:  04 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Formation 1:  04 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 00 00
Formation 2:  43 00 FF FF 02 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 02 00
Formation 3:  07 00 FF FF 01 00 FF FF E7 03 E7 03 E7 03 E7 03 FD FF 05 00etc.
Scene2.txt only contains those first two blocks of 12 bytes that haven't been identified, also being labeled and organized by scene and formation, followed by a "true" if the two 12-byte blocks are equal and a "false" if they are not.
Sample:

Code: [Select]

Scene 0:
Formation 0:  B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE True
Formation 1:  B0 1D 6C EE 38 31 08 07 A8 FD A4 06 B0 1D 6C EE 38 31 08 07 A8 FD A4 06 True
Formation 2:  B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE True
Formation 3:  37 26 E1 EE 99 22 09 00 05 01 6B FC B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE False
Scene 1:
Formation 0:  B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE True
Formation 1:  B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE True
Formation 2:  B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE B0 36 60 F0 40 1F 0A 00 D4 FE 0C FE True
Formation 3:  10 27 78 EC 70 17 00 00 90 01 2C 01 10 27 78 EC 70 17 00 00 90 01 2C 01 Trueetc.
There wasn't any point in examining the rest of the setup2 because the last 12 bytes are always NULL and I know what the first 12 bytes are.

EDIT:
Filefront works now.

[secondadvent]

ok, i got them. i will check over the info, test things in-game, and so on to see what all i can find (put finding the psx master materia sell price, and the drop/steal/morph items in ai on hold for now). are your planning on doing one for the formation info as well? i could do it if needed, from a fresh scene.bin, since mine is massively edited atm , but it would take me some time to put together. i don't know if you are ripping them scene by scene, or as a whole through a program, but i would have to do it all manually >_<.

going through the beginning of the game part listing enemy formations that appear, so that it is easier to find out if any special formation data is held here. not going to write it all, just up to GS, since that should give a good idea of the basic info.

i see what you were talking about with the battle arena data, it is pretty easy to see with it lain out like that, not that i would have seen it right away . the double mp fight at the beginning has a repeating 012c (300) thing going on, i don't know what that is about as of yet, but at least a big portion of the first setup is pretty much known now, though it will still probably take a good bit more to completely understand it all.

hmm... a quick search showed that it was the only one with that data in it, what does that mean... was it like a dummy fight for the arena at some point? it seems to be pointing back to itself rather than to another enemy group. if i am seeing correctly, the 03e7 is pointing to an enemy that has all 00 for the arena data (dummy enemy), and the PrC that is the final in the arena also has all 00 in the arena data, so i am guessing that it acts like an end statement, or something like that (03e7 calls a dummy enemy which has 00 in the data, and formation 0 has a similar dummy enemy which points back to the final dummy enemy, something there has to prevent it from looping, or the 7th fight ends the battle chain, and the jump doesn't matter)

[nfitc1]

I now believe I know what they are. They are each 12 bytes worth of camera positions. I don't think I have any doubt of that now.

The first one is definitely "Primary camera position" (index 0?) that the camera moves to at the start of a battle
The second one I think is "Secondary camera position" (index 1?) where the camera will move to when the enemy changes state. An example of this would be the Midgar Zolom rising up or Hell House revealing itself.
I guess the third one is "Tertiary camera position" (index 2?) that could also be called upon at some time.

These is triggered by an enemy's animations. Not attacks or AI, but AI might be able to change it now that we know what we're looking for. There's info in the animation for an attack that tells it "Move the camera to index 1" or something. These are all camera data so I guess it's up to the enemy on whether or not to change the camera to a different position.

[secondadvent]

hmm... i knew it had to be camera data, but i thought it was for different battle types . i wonder exactly how the game determines when to use the change camera animations? it may be helpful to look in the enemy animations themselves (the raw data in the battle.lgp file), but i have no knowledge of animation data, so i wouldn't be of too much help there right now.

i will see what happens with the remaining offsets in setup 1 (0x10-0x13, check what happens when 0x6-0x7 are changed, and check out how the escape counter works, since it is only listed as a counter, with no details  ), and get back to you soon, hopefully.

0x6-0x7 doesn't seem to do anything when changed, but it could be something internal, or dealing with the arena as well, and since i am not at the arena to test it out, i do not know for sure if it does anything at all.

what does 2020 (camera data) in the ai work with, does it work as a mask using certain variables, or is it called from another mask? if it is a mask itself, some of the unknowns could be working with it alone, and could be why some don't seem to do anything when set to an enemy. i was wondering this to see if the camera could be called upon in the ai like the game does for the initial camera movement (if it works through ai the same way, it could be used as a way to make multiple camera movements, or to actually change the camera without an animation).

[nfitc1]

It apparently returns an index between 0 and 2, but setting it doesn't seem to change anything.

[secondadvent]

hmm... i figured that it would be the key to changing the camera in battle. oh well.

anyway, i am trying to figure out what each of the flags in the escapable byte(s) is for... so far they are all on by default, and bit 2 seems to handle the escaping, if it is off, there is no escape. trying to learn what the others are... bit 1 seems to be off all of the time, could be what turns on/off the spoils pages, have to get back on that one . bit 4 is off in some of the later reactor 1 fights, and seems to do nothing when turned off... could be dealing with the specific area, since GH has it off as well. get back when i determine more about it.

all on seems to act like the normal battle, but something has to be different since on of the normally off flags is set. whatever these enable/disable is probably anything from a wide range of things.

going to make a list of used values to see if i can narrow down the usage more.

bit 3 may be used as something for side attacks, since air buster has this turned off in his fight.

ok, values i have seen are:
FF, FD, FB, F9, F7, F3, F1, EF, ED, EB, E9, E3

bits seen disabled are bits 1-4, and any combination of that (sans all four off, most off is all but 1)

f3 is used in the bizarro sephy fights (first formation in each, not sure which is used), f1 is used in all sephy fights, and air buster. e3 is used in the diamond weapon formations, and ruby has ef, so maybe bit 1 has something to do with temporary escape prevention?

0x11 seems to be always ff as well, so i think it was just used as a placeholder for something, something that was removed at some point, or just to make it an exact 20 bytes, so should have no real use.

ah... ok, so far this is what i have:
bit 0 - ?
bit 1 - ?
bit 2 - on, escapable, off no escape
bit 3 - on, victory dance, off, no victory, fade to spoils pages
bit 4 - ? (may have something to do with enemies with special death animations, like how the sword dance enemy, as well as many other machine enemies break apart rather than just fade away)
bit 5-7 - unused?

hmm.. i noticed accidentally that in terence's enemy mechanics guide that the levrikon enemy uses the camera data in it's ai to use an extra attack if the conditions are right:

AI: Setup
{
   If ([2020] == 2) Then
   {
      [0000] = 1
   }
}
AI: Main
{
   If ([0000] == 0) Then
   {
      Choose Random Opponent
      1/4 Chance: Use Flaming Peck on Target
      3/4 Chance: Use Bird Kick on Target
   } Else {
      Choose Random Opponent
      1/4 Chance: Use Bird Kick on Target
      3/4 Chance: Use Flaming Peck on Target
      [0000] = 0
   }
}

when exactly would it do this, becuase it could answer what the third set of data would be for, since it seems to be looking for that information. and in the ai itself, i noticed that the other enemies handle the chocobo script, as in when you can catch it, not the chocobo... that is pretty strange to me...

and introducing the initial camera data... offset 0x13 of setup 1. i am guessing it is from specific set starting places, so tweaking it may not be as easy as the actual camera final position.

now i know these are known, but i don't see them listed out anywhere, so here goes... for the formation type (offset 0x12 of setup 1):
00 - normal fight
01 - preemptive
02 - back attack
03 - side attack
04 - attacked from both sides (pincer attack, reverse side attack)
05 - another attack from both sides battle (different maybe?)
06 - another side attack
07 - a third side attack
08 - a normal battle that locks you in the front row, change command is disabled

i am guessing that the different side/attack from the side battles are just for different starting formations. kinda hard to tell by using the first enemy fight, since the enemies do not move where they are supposed to, like your party does - they have to be programmed into position by the formation data. command 08 would be a nice addition to a difficulty mod by disabling the back row for your party, which is an evil thing when the enemies are powerful .

as of right now, setup 1 should be around 99% figured out... just a few flags to learn and that should be all... the same could be said for setup 2, all we need to know is how the second and third are called upon. i guess i should hit up the formations themselves to see what i can uncover there.

hmm... al that isn't really known well is the one unknown, and the initial flags, and it will take some time to look through it all, but i already know bit 0 in the first byte of flags is initial invisibility. bit 1 seems to be dealing with side attacks, and how you receive back attack damage. if no enemy had this flag disabled, you will not receive any back attack damage at all it seems, and it has to be set on the side that is at your back, or else it would be happening in reverse, taking back attack damage when facing the enemy.

the value at offset 0xa seems to make certain rows normally unreachable until the rows in front of them are killed (but can be hit with ranged and magical attacks). i tested this on the back attack triple blood taste battle (a battle normally using this unknown), which had it's unknown the same as it's row, and i could normally attack the back row even without long range attacks. so i am guessing that the value is essentially used like "if the value is less than the row, then all enemies within that row must be killed before able to be hit by short range attacks". 0 seems to be like an off switch, and is off in most battles.

the value does not have to be set in only back attacks either, it can be done in any type of fight. there is even at least one normal fight in the game which uses this ability... an example would be formation 0179, a singe whole eater, and two hedgehog pies... the back row hedgehog cannot be attacked with short range attacks until the front two are killed.

the second hell house (hidden one) is packing the invisible flag, and bits 4 and 3 off as well, so it uses two at once. bit 4 is the main ai flag, and bit 3 is the targetable flag... it seems like the flags that are able to be set in the ai are initially set here, so 4020-403f should be able to be set from the formation data initially if i am right, and it keeps the same order as in the ai.

i guess not... turning on what should have been the physical/magical resistances did nothing, so maybe it is just the first 8 that are in the same order then?

ok, to make it easier to read the previous findings for the initial flags (first byte only):
bit 0 - invisibility flag
bit 1 - side attack flag (changes facing, needed for those "behind" the party, usually the left side of the screen)
bit 2 - probably the same as the 4022 flag in the ai
bit 3 - targetable flag
bit 4 - main ai flag
bit 5 - ?
bit 6 - ?
bit 7 - ? (could be current facing, which deals with back/side attacks, and switches when attacked from an enemy with the same facing, because that is when back attack damage occurs)

i think that is enough for tonight... my eyes hurt .

ok, addition to the 0xa offset unknown... it acts more like this - if an enemy is currently in the 2nd row with one value there, and an enemy is in the first row with the same value, it is unreachable with short range attacks until the front row one is killed. this can be with multiple numbers as well... if there are four enemies, two front, two back, and the front were to have, say 1 and 2, and same for the back, then only one back row enemy could be reached if the enemy in front of it (same number) were killed, but the other would still remain out of reach. this is also true for multiple rows. i used the 5x proto machinegun battle, setting each one's row higher than the next (1-5), and set all of their 0xa values to 1... i could only attack one at a time with cloud's sword, though i could freely attack with magic just the same.

setting someone to 3 makes you unable to hit with short range attacks as long as there are any in the front row with a 1 or 2, so a group of five, two set to 1, and two set to 2 (or any combo really, just one would work) would block access to the one set to 3 (if it was behind everyone... if it were in row 2 with the second set of each, it would be able to be hit then), until ALL enemies were killed in front of it.

ok, this is how the flow works: if there is a 1 in front of a 2 or 3, they are out of short range until it is killed. if a 2 is in front of a 3, the three isn't able to be hit just the same, so all 1's and 2's need to be killed for a three to be killed (if it is in the row(s) behind the 1's and 2's). the same is for 4,5,6, but they will not work with 1,2,3, only with their own group. also, if a 3 is in the front row, any 1's or 2's behind it cannot be reached until the 3 is killed, kind of reversing the usual role.

[Akari]

Some of my notes

Code: [Select]

+14 battle setup 1
    00 [][]     battle location ID.
    02
    03
    04 [][]     Set to 1 if previous battle result &0x40. Store this to 800f7db2. Some related to escape (maybe escape counter)
    06
    07
    08
    09
    0A
    0B
    0C
    0D
    0E
    0F
    10 [][]     some flags checked as &10 during enemy init. If (this & 4) == 0 then add 0x08 to previous battle result. Make this&fffb if previous battle result &08. Add 0x04 bit to this if previous battle result &40. Looks like escape flags
    12 []       camera data byte (0,1,8 - CAMDAT0.LZS, 2 - CAMDAT1.LZS, 3,4,5,6,7 - CAMDAT2.LZS). Checked if this ==0 during enemy init and store 1 here if few conditions met.
    13 []       store (random byte & 3) + 0x60 here if previous battle result &0x40.
In addition to this +12 byte contain formation data. As follows 0 - 0, 1 - 1, 2 - 2, 3,5,6,7 - 3, 4 - 4, 8 - 5
According to formation type set position of players (enemy position sets from formation data) and their timers.
As I remember formation 5 used in sephiroth battle.

Initial timers are as follows

normal - (player:random(0-ffff)+e000 - max_timer, enemy:random(0-ffff)+e000 - max_timer)
player advantage - (player:fffe, enemy:random(0-ffff)/8)
enemy advantage - (player:0, enemy:random(0-ffff)+f000)
special (sephiroth?) - (player:fffe, enemy:0)

[nfitc1]

So can 0xA be expressed as "short-range order"? Look at the battery caps x6 battle:

There are three rows and this is a representation of their 0xA values:

Code: [Select]

Row 1:     04
Row 2:   06  0C
Row 3: 03  04  18
So from your explanation, Row 2 cannot be targeted (we'll just assume a short range attack) until row one is defeated. Then, Row three can't be attacked until one of them in row two is defeated. What happens in the game is this:

Code: [Select]

Row 1:     04
Row 2:   06  0C
Row 3: 03  04  18   <-- only Row 1 is targetable

Row 1:     XX
Row 2:   06  0C
Row 3: 03  04  18   <-- only Row 2 is targetable

Row 1:     XX
Row 2:   XX  0C
Row 3: 03  04  18   <-- only 0C and 03 are targetable

Row 1:     XX
Row 2:   06  XX
Row 3: 03  04  18   <-- only 06 and 18 are targetable
These are obviously directly related to the A value, but I can't see how, exactly. It's almost like "if there is another enemy in the row ahead that has a higher order than 'me' then 'I' can't be targeted". But that doesn't work in the first or third scenario. Row probably plays a bigger role in this too. This is all this battle tells me:
A 04 in row 1 can cover a 06 and 0C in row 2.
A 06 in row 2 can cover a 03 and 04 in row 3, but not a 18 in row 3.
Likewise, a 0C in row 2 can cover a 04 and 18 in row 3, but not a 03 in row 3.

Now I made this scenario:

Code: [Select]

Row 1:     01
Row 2:   01  02
Row 3: 01  02  03
What happens in the game is this:

Code: [Select]

Row 1:     01
Row 2:   01  02
Row 3: 01  02  03   <-- only Row 1 and Row 2 02 is targetable

Row 1:     XX
Row 2:   01  02
Row 3: 01  02  03   <-- only Row 2 is targetable

Row 1:     XX
Row 2:   XX  02
Row 3: 01  02  03   <-- only Row 2 02 and Row 3 01 are targetable

Row 1:     XX
Row 2:   01  XX
Row 3: 01  02  03   <-- only Row 2 01 and Row 3 02 are targetable
That was very strange....can anyone offer any other clues?

[secondadvent]

@akari type 5 is used in a couple battles, some are dummy battles. here are the locations of each fight if you want to check them out (starting from scene 0):
scene 1 - formation 4
scene 9 - formation 2
scene 23 - formation 3
scene 25 - formation 4
scene 172 - formation 3
scene 180 - formation 4
scene 188 - formation 1

i couldn't really tell what was up with them, because the battle wasn't set up for it (used the first MP fight ), but these should give a better idea of what goes on in the sephy version.

for the enemy advantage... wouldn't the amount given overflow if the random was too high? either way i guess they would still end up going before you most of the time.

@nfitc1 yeah, this is how it seems to be working so far... i haven't gotten to that fight yet (started at 75, the MP fight, and am around 200 now, then will go back to previous ones... odd, i know ), so i am unsure how the higher numbers work, and i havent done a ton of testing, but what i wrote seems to be how that part is working at least so far.

i can see the 4 covering a 4,5 or 6, or a 6 covering a 4 or 5, since multiples of 3 can cover the smaller ones in the same group only?, and it seems that the multiples of 3 cannot cover each other unless? they are the same number. perhaps multiples of 3 can only be attacked if all non-multiples of three are destroyed in the rows in front of them (same row has no effect). this is what i think is happening form my earlier testing and your results from this battle, but i cannot be entirely sure unless i do more testing on this, so just speculation for now.