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

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?

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).

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] Now, from a bird's eye view (at 0,8000,0) looking down the Y-Axis it looks like this:

Code: [Select] 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.

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?

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

Click to expand...

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

Click to expand...

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

Click to expand...

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] Note 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..

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.

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] etc.
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] etc.
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.

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)

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.

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).

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

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
   }
}

Click to expand...

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.

Some of my notes

Code: [Select] 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)

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] 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] 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] What happens in the game is this:

Code: [Select] That was very strange....can anyone offer any other clues?

@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.

UPDATE for formation 0xA: a 0D in row 2 (and probably anything higher) can cover a 03, 04 and 18 in row 3 so the higher it is in row 2 the more it can cover.
a 0B in row 2 can cover a 03 and 18 in row 3, but not a 04 in row 3.....? Maybe this isn't about values. Let me look at this in binary:

Code: [Select] I think that's it! I tested this a little and this is what I got:

Say Enemy A is in row x with an 0xA of m and enemy B is in row y with an 0xA of n:
Enemy b cannot be targeted if ((y < x) and (m and n) > 0).
I just changed the 0C in row 2 to 1B (from 01100 to 11011) and the 04 in row 1 (00100) didn't cover it. Looking at my other example (now in binary):

Code: [Select] It fits! Unless anyone can find a situation where this doesn't work this is what I'm going to call it.

sounds good to me ^^. we now have a fully working new part to use that was there the whole time .

i think i may try to find the psx master materia data now, since a good bit of the formation data has been opened up more, i know it isn't in the shopmenu.mnu file, since i checked the entire thing (if it is stored as 46 in the hex, 70 normally, then it isn't in it ). my guess is that it is in the slxx file, since that is like the main part of the game, everything starts from there.

@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.

Click to expand...

Camera type (or battle type 8) set formation type 3 (enemy advantage). You need to look at battle type 8 for formation type 5. This is hardcoded. But formation type are one of the major thing in battle formations (positions, rows, target mask, directions and so on)

If timer greater than ffff if starts from 0 again.

By the way, battle camera switched in animation scripts. (You discuss this while ago)

ok, ok, my bad then . i get it now...

i will probably be off for a little while, maybe a day or so to play ffvi, since seeing typhon (aka chupon) gave me the urge to play >. i will see if i can find the psx master materia multiplier first, but i may not find it.

ok, i think i am going to continue working on my main mod, because it has been left out in the cold for a while and probably needs fed  :lol:. if you want help in finding anything out, let me know cuz i will be still keeping an eye on this thread.

hey nfitc1, do you think you could make it so that PrC can create ai dumps, showing both disassembled and coded (or just the normal coded, you could just manually disassemble the script) forms so that you wouldn't have to look through two different PrC instances to compare ai?

if so, could you also possibly implement a way to one, import the ai back in from the dumped file (like for restoring older versions of ai instead of manually doing it, which is nice for when the enemy is the only one in the game, and you lost the old version of the ai. it could be easier to do if you made prc create an ai dump for every enemy, so that you wouldn't have to make it point to a specific place in a file, just have it point to a single file (name the files based off of the scene and enemy number in the scene, like scene 75, enemy 0, the MP enemy). you could make the format of the files look exactly the same as in PrC's ai section, the opcode, then a space or two, then the argument, and then a new line, making it pretty easy to read, and should be easy enough to import back in.

i could see a problem being if someone were to make changes in the files, if they made it formatted differently, because that could cause errors to happen during importing. this could also be a way to easily import ai to different areas of a scene without having to copy, but would be more of an asset when importing to a different scene.bin altogether.

also, how is PrC coming? you kinda fell off the front page when i started my mod (i took away the life support :roll. are you still working on the copy/paste function (not that it doesn't work, or is difficult to use, just wondering  ), and how is the multi-pass disassembler coming, because i would really like to see that when it is done?

ok, i know this will likely be very hard to implement, but could you possibly make it so that when you click on a specific area of the disassembled code, it will jump to that area of the code to the left (i know, not an easy feat to do)? you could just make the main things like self, target, enemy, etc. masks, and variables clickable, since they would be the easiest to keep track of, and are the key pieces of coding to want to look for anyway (when disassembled, make every variable store it's starting offset somewhere for the disassembled script to change the current position of the coded section, so 0x and 1x opcodes would trigger this). if it is too much to ask for, then forget i even asked .