Qhimm.com Forums
Miscellaneous Forums => Gameplay => Topic started by: Roden on 2014-10-23 02:06:36
-
Quite new to FF7 modding (well, just yesterday actually lol) - I'm aware of pages such as http://wiki.qhimm.com/view/FF7/Savemap and some other variable analysis: http://finalfantasy.wikia.com/wiki/User:JBed/FFVII/Variables#Variable_analysis
And was wondering if there was a general consensus on some unused variables I can safely use in my mod (and get saved)? The first link doesn't seem to have too many unknowns which is worrying! I don't need too many, but hey, the more the merrier.. I already used some at random, and I guess I can change it later while testing..
I see a lot of data like this: z_16[36] (Field Objects, Sector 7 Train Graveyard):
0x01: Train 1 Position.(mds7st2)
0x02: Train 2 Position.(mds7st2)
0x04: Train 3 Position.(mds7st2)
0x08:
0x10:
0x20:
0x40:
0x80:
Does that mean I can use 0x08, 0x10 etc for anything I want? I guess for example BIT ON/OFF function in Makou Reactor? Or am I on completely wrong track here? :P
And is there a way to quickly see what variable an offset in the wiki is referring to in a program like Makou Reactor - I see for example (0x0BA8) 1 byte (Tifa's current love points) is listed as variable 1:4 in the program. And in the wiki its in the fourth row, but whats the formula in regards to 0x0BA8? Or do I manually go to that area and look at the scripts?
Thanks! :)
-
just because its not shown on the save map does not mean its unused. there are some spots that we know are unused but you have to check the documensts. becareful if you set some things the game may crash at some points or one very specific one. you can use the unused var under the test tab in black chocobo to compair slots to see what changes when testing to make it a bit easier to spot.
please see: http://blackchocobo.sourceforge.net/wiki/index.php?title=Savemap
for a more updated savemap. (i have not updated the qhimm one in abit)
and https://drive.google.com/file/d/0BxqH9L8_QubjV0EwTnJmbGlKdmc
for some of my notes that are not on the savemap . i have other notes that finish off all the used field vars for items (most of the notes focus on items not progression)
as for the offsets they are not as stright foward as you might think 1/2 are the same address one bank is used for 8bit access the other for 16bit access. (all the field used banks have this dualility) some blocks addressed by the field are not saved.
you can also view the fielditemlist from ff7tk for all offsets and bits
https://github.com/sithlord48/ff7tk/blob/master/data/FF7FieldItemList.h
you should also look at FF7Save struct
https://github.com/sithlord48/ff7tk/blob/master/data/FF7Save_Types.h
there might also be some more hints located in FF7Save.cpp as well since some of the "unused" data (z_#) is accessed outside the struct.
-
just because its not shown on the save map does not mean its unused. there are some spots that we know are unused but you have to check the documensts. becareful if you set some things the game may crash at some points or one very specific one. you can use the unused var under the test tab in black chocobo to compair slots to see what changes when testing to make it a bit easier to spot.
please see: http://blackchocobo.sourceforge.net/wiki/index.php?title=Savemap
for a more updated savemap. (i have not updated the qhimm one in abit)
and https://drive.google.com/file/d/0BxqH9L8_QubjV0EwTnJmbGlKdmc
for some of my notes that are not on the savemap . i have other notes that finish off all the used field vars for items (most of the notes focus on items not progression)
as for the offsets they are not as stright foward as you might think 1/2 are the same address one bank is used for 8bit access the other for 16bit access. (all the field used banks have this dualility) some blocks addressed by the field are not saved.
you can also view the fielditemlist from ff7tk for all offsets and bits
https://github.com/sithlord48/ff7tk/blob/master/data/FF7FieldItemList.h
you should also look at FF7Save struct
https://github.com/sithlord48/ff7tk/blob/master/data/FF7Save_Types.h
there might also be some more hints located in FF7Save.cpp as well since some of the "unused" data (z_#) is accessed outside the struct.
Great, thank you! So looking at your notes, if I delete those two potions from the dead guards at the start (md1stin), I can use those values for my own purposes?
But how did you know Var[15][32] correlates to Z_38[44]:0? Whats the difference between Var and Z values, and how do you work it out? I looked at this specific slot in the Black Chocbo test data and saw: 0F 15 00001111 - that means the save already has the two potions and some more stuff in reactor (but not the poison materia you mentioned later).
So earlier you said "as for the offsets they are not as stright foward as you might think 1/2 are the same address one bank is used for 8bit access the other for 16bit access. (all the field used banks have this dualility) some blocks addressed by the field are not saved." so what does that mean exactly for the above? How does that affect me if I just want to delete those two potions and use that value elsewhere?
Thanks for the Black Chocobo link, that's a great program. I looked in the test data and understand how it works with the memory slots, but I'm not sure how to use those unknown vars in Makou Reactor yet as I don't know which variables it points to (or is it something we all have to work out)?
Sorry for the questions, I'm very new here and just trying to understand :)
-
when i get a chance i will write you a correct responce to that above message.
-
when i get a chance i will write you a correct responce to that above message.
Thanks, man. Really appreciate it!
-
http://wiki.qhimm.com/view/FF7/Savemap
I'll also send you a list of bytes that Aali sent me detailing what the world map uses. Battles can only affect bank 1 (field 1/2). Field can be seen with Makou.
Remember that Field vars:
1/2 are Bank 1
3/4 are Bank 2
5/6 are temporary vars in game and not saved. They reset to 0 every time you enter new field.
8/9 & A cannot be written to.
B/C is Bank 3
D/E is Bank 4
7/F is Bank 5
Field vars 1,3,5,7,B,D are for one-byte writes
Field vars 2,4,6,C,E,F are for two-byte writes
Remember that 1/2, 3/4, 5/6, B/C, D/E and 7/F share the SAME 256 bytes.
So if you write to var [1][10] you are ALSO writing to [2][10].
And if you write two bytes to [2][10] you are ALSO writing to [1][10] and [1][11]
From my own tests, Field B/C (Bank 3) is the safest bet. I am using [B/C][243] through to [B/C][255]
For my Soldier mod. So if you want your mod to remain compatible with mine, avoid those and
start at [B/C][242] I am pretty sure a lot of those bytes down are unused.
edit.
Oh... PSX again. I keep assuming PC. Well, you are free to use B/C[255] down really. Can't see my Soldier mod being used in PSX game, though you never know.
-
http://wiki.qhimm.com/view/FF7/Savemap
I'll also send you a list of bytes that Aali sent me detailing what the world map uses. Battles can only affect bank 1 (field 1/2). Field can be seen with Makou.
Remember that Field vars:
1/2 are Bank 1
3/4 are Bank 2
5/6 are temporary vars in game and not saved. They reset to 0 every time you enter new field.
8/9 & A cannot be written to.
B/C is Bank 3
D/E is Bank 4
7/F is Bank 5
Field vars 1,3,5,7,B,D are for one-byte writes
Field vars 2,4,6,C,E,F are for two-byte writes
Remember that 1/2, 3/4, 5/6, B/C, D/E and 7/F share the SAME 256 bytes.
So if you write to var [1][10] you are ALSO writing to [2][10].
And if you write two bytes to [2][10] you are ALSO writing to [1][10] and [1][11]
From my own tests, Field B/C (Bank 3) is the safest bet. I am using [B/C][243] through to [B/C][255]
For my Soldier mod. So if you want your mod to remain compatible with mine, avoid those and
start at [B/C][242] I am pretty sure a lot of those bytes down are unused.
edit.
Oh... PSX again. I keep assuming PC. Well, you are free to use B/C[255] down really. Can't see my Soldier mod being used in PSX game, though you never know.
Thanks for the great reply, DLPB. That makes a lot of sense - I was looking for that "safebet" list! Does B/C refer to VAR{11}{255}/VAR{12}{255} in Makou?
Only thing I don't quite get (because I don't usually work at this level) is the whole writing one-byte/two-bytes thing? Why would I need one or the other? For example in the first very field map in the initialization is:
Var[6][9] = 12 (16-bit)
Why not Var[5][9] = 12 (8-bit)?
Or Var[6][9] = 12 (8-bit)
Though actually I have no idea what that is trying to set. Most of the things I would be adding is simple "switches" (such as the BITON/OFFs I find in the code?)
Also I removed those potions from the start of the game, is OK to use those bits for my own purposes now?
-
Yes, B is 11 decimal, and C is 12 decimal.
The writing issue is weird one, and Aali / NFITC1 explained it to me a while back but I forgot.
All you need to concern yourself with is that when writing a 16 bit (2 byte) value, you MUST use C (12) and if using one byte, you can use B or C (I think). Though I'd just use B for one byte, and C for two.
B/C is same bank, so keep track of it. I requested to Mystere that he start marking bytes used across fields... so that when you use [11][1], [12][1] is also marked as used. As it should be. Or some sort of byte used tracker.
-
one bytes and two bytes is 8 bytes and 16 bytes. This use for the size of the code, for example if you write If Var[3][133] bitON 6 (else go to label 1) in 8-bit
and you write a lot of code before the label, Makou says a error like this (Label 1 is unreacheable), if you change to 16-bit you can go to label 1.
If you want a free var to use, you can use 14-22, 14-23, 14-24, 14-25 with bit on to 8 ( bit on 0, bit on 1....)
I hope i´ve been hepful, sorry for my horrible english.
-
Thanks guys, I understand it a hell of a lot better now :)
DLPB: What's this SOLDIER mod your working on?
Vayneruel, your example for the labels (8-bit/16-bits jumps) is just to do with the field map scripting and nothing to do with variables, right? I already changed a few to long jumps. Hope that didnt screw anything up! :)
-
Yeah, what he said had nothing to do with this.
Also, see Reunion thread for Soldier mod explanation.
-
Well, this is all very worrying info about banks sharing bytes; I've been using whatever banks are marked as empty on Makou but:
B/C is same bank, so keep track of it. I requested to Mystere that he start marking bytes used across fields... so that when you use [11][1], [12][1] is also marked as used. As it should be. Or some sort of byte used tracker.
That's got me sweating so I'm going to check all the variables I've used but could someone confirm if this is correct:
For Bank 2 (3/4) I've used [3][107] for something in the mod but [4][106] is also marked as used (unaltered), which is for writing 2-bytes and would write to [3][107] when triggered?
-
For Bank 2 (3/4) I've used [3][107] for something in the mod but [4][106] is also marked as used (unaltered), which is for writing 2-bytes and would write to [3][107] when triggered?
You cannot write a 2 byte value to var [3]. Only [4] would allow a 2 byte write. [3][107] Conflicts with [4][107].
And [4][106] conflicts with [3][106] and [3][107].
And [4][107] conflicts with [3][107] and [3][108].
Remember also, BANKS do not share bytes. The VARS that the FIELD script uses shares the bank bytes. There are only FIVE savable banks (and six usable, one is a temp).
Makou will not alert you to this conflict as it scans only for the vars used, and not the actual bytes used.
-
Ah, I see 1/35 Soldier? Haha, in the days of old it was said you could rebuild Sephiroth with 99 of those and a masamune!
-
Yes the 8 and 16-bit its for field map, but you must pay attetion what you change to not create conflicts in code
-
Sega Chief , also Makou can only show you what vars are being used in field.
Bank 1 (Field 1/2) is used for savable things in battle (i.e., battle script sometimes writes to Bank 1).
Avoid Bank 1 like the plague.
And world map writes to some other banks also. For all I know, more things write to the banks. So using Makou to decide a bit is free can be catastrophic.
-
Cheers for the info, Dan; that would have been a nasty time bomb to sort out later on as more variables got used ('re-used', I should say). I'd better consult that savemap link you posted when picking variables from now on.
-
And remember it isn't complete... These are the ones world map writes to (for a start):
BANK 1
0x0000: word
0x0054: byte
0x0055: byte
0x0056: byte
0x0057: byte
0x0058: byte
0x007a: bit 0
0x007a: bit 1
0x007a: bit 2
0x007a: bit 3
0x007b: bit 0
0x007b: bit 2
0x007b: bit 3
0x007c: byte
0x007d: bit 0
0x007e: bit 0
0x007e: bit 1
0x007e: bit 2
0x007e: bit 3
0x007e: bit 4
0x007e: bit 5
0x007e: bit 6
0x007f: bit 0
0x007f: bit 1
0x007f: bit 2
0x007f: bit 3
0x007f: bit 4
0x007f: bit 5
BANK 2
0x01cf: bit 0
0x01cf: bit 1
0x01cf: bit 2
0x01cf: bit 3
0x01cf: bit 4
0x01cf: bit 5
0x01cf: bit 6
0x01cf: bit 7
BANK 4
0x0350: bit 3
0x0351: byte
0x0352: bit 2
0x0352: bit 3
0x0380: byte
0x0381: byte
0x0382: byte
0x0383: byte
0x0384: bit 0
0x0384: bit 1
0x0384: bit 2
0x0384: bit 3
0x0384: bit 4
0x0384: bit 5
0x0384: bit 6
0x0384: bit 7
0x0385: bit 0
0x0385: bit 1
0x0385: bit 3
0x0385: bit 4
0x0385: bit 5
0x0385: bit 6
0x0385: bit 7
0x0386: bit 0
0x0386: bit 1
0x0386: bit 2
0x0386: bit 3
0x0386: bit 4
0x0386: bit 5
0x0386: bit 6
0x0386: bit 7
0x0387: bit 0
0x0387: bit 1
0x0387: bit 2
0x0387: bit 3
0x0387: bit 4
0x0387: bit 5
0x0388: word
0x038a: word
0x038c: byte
0x038d: byte
0x038e: byte
0x038f: byte
0x0390: word
0x0392: word
0x0394: byte
0x0396: byte
BANK 5
0x0491: bit 2
Note 0000 is Bank 1 (Field 1/2) Byte 0.
And as it is a Word value, it is 2 bytes. Note this is the game progress value (Var [2][0])
The bytes are offset from 0.
0 being Var [1][0] or Var [2][0] or Bank 1, byte 0.
Banks run consecutively in memory 1 through 5.
So byte 256 (100h) is in fact, Var [3][0] or Var [4][0] or Bank 2, Byte 0
Thus, it's easy to note
Bank 1 [1/2]: Starts 0x0000
Bank 2 [3/4]: Starts 0x0100
Bank 3 [11/12]: Starts 0x0200
Bank 4 [13/14]: Starts 0x0300
Bank 5 [7/15]: Starts 0x0400
-
Got it, I've added this to my notes. What might be handy is if we label the variables in Makou and produce a more complete vars.cfg file that can be distributed with the tool itself (sort of like how Game Moment/PPV is labeled but with more of them identified, particularly the ones not marked as used). I'm going to make one for my own use, but would that be worth distributing (assuming it was all correct)?
-
I think we need a comprehensive byte checker somewhere on Qhimms to let everyone know how the game works, and which bytes are used. Aali has produced the above comprehensive World Map list. NFITC1 could no doubt easily produce the Bank 1 writes that battle makes. Field changes are easy to spot using Makou.
I am not sure if anything else writes to the banks. Minigames do, but they should be easy to spot with Makou also.
The byte check list should probably also note which modders are using what. I will be using 99 bits starting [11/12][255] (Bank 3, byte 255) (as said above) for Soldier mod. So at least we could know what conflicts we will be having with others also.
In fact, maybe this thread needs stickying somewhere under "Read this before attempting to edit field script vars" or something.
-
That'd be useful, would be able to coordinate with other mods better and see what's 'safe' too. Would it be like a spreadsheet or something?
-
I'll sort something. A lot of people have started mods without fully realizing the implications of the shared bytes. The Nightmare mod I think escaped an issue through pure luck.
-
In fact, maybe this thread needs stickying somewhere under "Read this before attempting to edit field script vars" or something.
Good idea, but may I suggest a more simpler title? Rename the thread to something like "variables safe to use in your savemap, read before editing" or something. I tried searching google but couldn't find anything so I made this thread. :)
-
@ Roden what DLPB said!
@DLBP thanks for answering that when i was unable to get it done :D
-
5/6 are temporary vars in game and not saved. They reset to 0 every time you enter new field.
Actually this one seems very handy for certain rooms - do you know which ones are unused (or if someone has documented it?)? It seems a better alternative than trying to set a variable from other banks to 0 whenever you exit a room :P
-
They are all unused... since they reset to 0 every time. To avoid conflicts you should check the script with Makou.
-
Haha, ah right.. they're field-only vars, that's cool! I just wasn't sure if something else was writing to it outside the script. Good to know :)
-
I'm not sure... it could and probably should be that world map can use it too. But it wouldn't matter since vars are returned to zero every time you enter a new field.
-
They are all unused... since they reset to 0 every time. To avoid conflicts you should check the script with Makou.
Bank 5 gets used in basically every question in the game to short-store the answer. You obviously can't leave the field while you're answering a question dialogue.
I don't remember if I've seen bank 6 used but I believe so, again, for temporary stuff just for that field.
-
That's not a bank. A field var ID is what you mean. 5 and 6 are both the same temporary bank (or let's just say using same 256 bytes). See the previous posts.
Whenever you enter a new field, the entire bank is reset to 0 (256 bytes are reset to 0).
If you look at the savemap, banks 1-5 are listed there since they are the only ones saved. As you noted, [5] is usually used for questions, since it is a one-byte write var (and no option cursor in the game requires over 256 responses. If it did, you'd see the 2-byte [6] location used as well). One-byte writes are far more frequent than two, hence the frequency of [5].
Hopefully, Mystere will agree with my solution to this nonsense, and in the future, we'll have BANKS 0-6 referenced in Makou Reactor only.
-
Technically I meant that Bank 5 is used since Var 5:10 (usually 5:10 or 5:8 or something like that, you know what I mean) is used in questions.
-
I know what you mean, but Bank 5 isn't the temporary bank. Bank 5 is Field [7] and [15]. Temp bank (Field [5] and [6]) doesn't have an ID on the savemap (which we named anyway, let's face it). Temp bank should probably be called Bank 0 or Bank 6 for clarity (or just Temp Bank).
-
DLPB: Do you think it would be possible to set a variable in the field that's used in a battle? For example, the next enemy's HP or something. Probably a long shot, but you never know :)
-
The battle script can set bytes in Bank 1. NFITC knows about battle script. :)
-
@Roden
This thread might be handy: http://forums.qhimm.com/index.php?topic=15445.0
Sithlord and NFITC1 recommended using Battle Love Points, which function but aren't actually used for anything (it's used by character AI which can be edited/removed in Wall Market). If they can't store a big number for an enemy's HP value, then you could instead have the HP values/HP multiplier stored in pre-battle AI with the variable triggering which value gets pushed into the monster's actual HP before the fight starts.
-
@Roden
This thread might be handy: http://forums.qhimm.com/index.php?topic=15445.0
Sithlord and NFITC1 recommended using Battle Love Points, which function but aren't actually used for anything (it's used by character AI which can be edited/removed in Wall Market). If they can't store a big number for an enemy's HP value, then you could instead have the HP values/HP multiplier stored in pre-battle AI with the variable triggering which value gets pushed into the monster's actual HP before the fight starts.
Very interesting, thanks. Battle love points, hey, never knew that.. kind of shows how ambitious FF7 developers were about this dating game. I'm with you about not editing scene.bin (especially since I'm developing only for PSX), did you find a way to effectively have any affect on the battles through field vars only?
Is pre-battle/post-battle AI editable in Makou Reactor/field? Or only Proud Clod? I don't really like using Proud Clod as its not 100% compatible with Japanese versions of game :(
-
Makou Reactor is for field edits. Proud Clod is for battle. There's no way around that :)
-
Like Dan says, I'm afraid you might be stuck; as far as I know, Proud Clod is the only tool capable of editing enemy AI (the other editor, Hojo, can't do it) and it can't be done through Makou.
Is editing the Kernel, as in the character AI, an option? There might be a round-about way to make this work by having a routine where the player character pre-battle AI checks for a specific enemy ID instead and, if true, adjusts that enemy's HP based on the aforementioned variables. Cloud would be the best bet as he's usually in the party. You could also put in several checks if it needs to happen with a few different enemies, but I'm not sure how size affects the kernel and how strict it is for PSX.
I have a working prototype for using these variables in fights, I'll dig it up if you want to have a look? It could be copied out and placed in the PSX kernel (Wall Market doesn't have a copy-paste function for it's AI editing if I remember right). But I'd maybe get some opinions about Kernel size first if you haven't already; I've not worked with the PS1 files but what I know about it is that changes in file size can derail the game. Also, if the kernel falls 'out of synch' with the scene.bin then problems like wrong encounters being referenced will start to appear.
-
Like Dan says, I'm afraid you might be stuck; as far as I know, Proud Clod is the only tool capable of editing enemy AI (the other editor, Hojo, can't do it) and it can't be done through Makou.
Is editing the Kernel, as in the character AI, an option? There might be a round-about way to make this work by having a routine where the player character pre-battle AI checks for a specific enemy ID instead and, if true, adjusts that enemy's HP based on the aforementioned variables. Cloud would be the best bet as he's usually in the party. You could also put in several checks if it needs to happen with a few different enemies, but I'm not sure how size affects the kernel and how strict it is for PSX.
I have a working prototype for using these variables in fights, I'll dig it up if you want to have a look? It could be copied out and placed in the PSX kernel (Wall Market doesn't have a copy-paste function for it's AI editing if I remember right). But I'd maybe get some opinions about Kernel size first if you haven't already; I've not worked with the PS1 files but what I know about it is that changes in file size can derail the game. Also, if the kernel falls 'out of synch' with the scene.bin then problems like wrong encounters being referenced will start to appear.
Actually, editing the Kernel might be fine, good that you remembered - Wallmarket works somewhat so far with my Japanese versions, so I'd definitely be interested in that prototype. Though just having a look at the character AI tab in Wall Market now (under Initial Data), it appears only Barret, Tifa, Yuffie have any data for "pre-battle", Cloud has none, and if you double click it (even in the US version) it just gives me "System.ArgumentOutOfRangeException: Index was out of range. ", though Barret's pre-battle AI seems perfectly editable (not that I understand whats it doing yet). How did you add stuff to Cloud's pre-battle without crashing it?
-
Actually, I take that back, even the other character's AI is extremely buggy (typing anything brings up .net framework error - even though I've verified .net is perfectly fine with microsoft developer tool). Is it problem with PSX kernel?
-
Usually to start editing, I click once on the group and then hit 'Enter'. I try to avoid double-clicks because things can go wrong from that sometimes. That said, I tried double-clicking on Cloud's pre-battle but there was no error message so it might be the way your tool is set up or the kernel itself (more likely it's the kernel itself). Try single-click and then hitting Enter to start a new AI in there, though; see if that works (a 73 should appear).
-
Usually to start editing, I click once on the group and then hit 'Enter'. I try to avoid double-clicks because things can go wrong from that sometimes. That said, I tried double-clicking on Cloud's pre-battle but there was no error message so it might be the way your tool is set up or the kernel itself (more likely it's the kernel itself). Try single-click and then hitting Enter to start a new AI in there, though; see if that works (a 73 should appear).
Alright, thanks - I just tested on an unmodfied and modified kernel on two Windows 7 PCs, I can get the 73 to appear by hitting ENTER on both of them. I imagine there is some sort of trick to inputting the data in the correct format it needs? I managed to create a bunch of white boxes, and get 0000 to appear in some of them, and then when I click on another option and come back it just gives an index error (doesn't crash) and all the white boxes are gone and its just 73 again.
-
Edit: It's not as easy to show this visually as I thought it would be. Here's how I generally do it:
I single-click the empty AI group and hit Enter twice. That gets the 73 and an empty block (it behaves slightly differently in older builds of ProudClod though). I then click on the empty block and enter the value before hitting the Down-Arrow key to move to the next cell. As a general rule, I try to write it out all in the one go, copying from a Notepad, and avoid clicking away until it's all in. Then I can save it and make adjustments without risking lost time.
And one thing to try and avoid is actually highlighting the numbers themselves; you want to have the whole cell itself highlighted when you start typing. It usually tricks out otherwise, especially if you try to move to the next cell. And sometimes, when you enter numbers in wrong, it can bug out then too so try to avoid mistakes.
Try this to start with; it's the first part of the test AI I had:
01 01C0
60 00
40
70 0009
11 0000
60 50
90
73
It should look like this in the decompiler when it's done:
If ( (LocalVar:01C0 == 0) )
{
LocalVar:0000 <- 80
-
Thanks! Kind of strange but I got it inputted eventually! After I click disassemble it says:
If ( (LocalVar:01C0 == 0) )
{
LocalVar:0000 <- 80
}
SCRIPT END
Which is great as it matches what you said, but what does this code do (i.e. how do I use/modify it?)? Localvar 01C0 refers to which variable in Makou?
-
It doesn't do much on it's own, it was just a practice to get used to inputting AI without problems popping up. The whole code was:
01 01C0
60 00
40
70 00##*
11 0000
60 50
90
60 00
01 0000
95
11 2018
01 2010
90
01 2010
60 32
44
70 00##*
11 01A0
03 2050
02 42E0
80
90
11 01C0
03 2050
02 42E0
80
90
11 2050
03 42E0
80
01 01A0
60 02
32
90
11 01C0
60 00
90
93: **
73
*: Set this to the current cell value of 73/End Script; it auto-updates as the script gets shorter/longer, at least in simple scripts like this.
**: The 93 here is optional, I use it to check if something is triggering. In the ** cell you'd enter a bit of text, like 'test' or something.
Which in the decompiler looks like:
If ( (LocalVar:01C0 == 0) )
{
LocalVar:0000 <- 80
TempGlobal <- &GlobalVar(0000)
Unknown(2018) <- GlobalAddress
If ( (GlobalAddress > 50) )
{
LocalVar:01A0 <- ActiveMask.Exp
LocalVar:01C0 <- ActiveMask.Exp
ActiveMask.Exp <- LocalVar:01A0 * 2
LocalVar:01C0 <- 0
Display String: ""EXP sum triggered""
}
SCRIPT END
One thing to note is that while this script did appear to trigger in battle, it was a half-finished prototype where I essentially gave up on the EXP thing and was just trying random combinations to get it working so don't worry about that bit where it says Active Mask or EXP. The '0' at [LocalVar:01C0 <- 0] was supposed to be a 1 too, can't remember why I wanted the script running every time I attacked.
I'll get yelled at again for being hazy on the actual details, but here's what the things in this script sort of are:
LocalVar: 0000, 0020, ..., 01C0
These are like temporary variables the battle engine uses. They're not related to the field variables, I don't think. Most of the enemies of the game use these to determine their attacks. They go up in 20's but I've seen Gjoerulv use 0010, 0030, etc. for his AIs so y'know. I generally use high numbers to avoid conflicts, so I'm using that 01C0 up there to shut it down after it's been run once (or at least, it would if that 0 toward the end was a 1).
GlobalVar: These are the ones that access field variables. Only Bank 1 is accessed, so first we need to specify which variable we want to read in this bank and we can use the battle engine's temporary variables to carry the numbers about. We want [80] in Bank 1, so:
LocalVar:0000 <- 80
My memory is very hazy at this point, but I most likely copied this from Jenova SYNTHESIS or Zombie Dragon who both use Global variables:
TempGlobal <- &GlobalVar(0000)
Unknown(2018) <- GlobalAddress
I'm not sure what that does, I'm afraid. But it seems to enable the If string that follows, and I think it didn't trigger whenever the value of [1][80] was set below 50; it's been a while since I used the script:
If ( (GlobalAddress > 50) )
So with the IF string triggering based on the value loaded from the variable, you can now adjust things like HP for enemies and other things. Now if you'll excuse me, I'm going to go hide before certain scary people find this post.
-
I've already explained this. Battle script can only write (and read from?) to the first 256 bytes of the save map. That's what we are calling Bank 1 (which in the field script is [1] / [2]. 0000-00FF (0-255).
A battle write to Byte 0 is equal to [1][0] in Makou.
A battle write to Byte 255 is equal to [1][255] in Makou.
That's its whole range. In battle there is no "field var". In fact, there is no "field var" full stop. In reality there is one lump of data that can be written /read at 0000-04FF (the 5 "banks"). And battle can only write from 0000 to 00FF.
-
It doesn't do much on it's own, it was just a practice to get used to inputting AI without problems popping up. The whole code was:
01 01C0
60 00
40
70 00##*
11 0000
60 50
90
60 00
01 0000
95
11 2018
01 2010
90
01 2010
60 32
44
70 00##*
11 01A0
03 2050
02 42E0
80
90
11 01C0
03 2050
02 42E0
80
90
11 2050
03 42E0
80
01 01A0
60 02
32
90
11 01C0
60 00
90
93: **
73
*: Set this to the current cell value of 73/End Script; it auto-updates as the script gets shorter/longer, at least in simple scripts like this.
**: The 93 here is optional, I use it to check if something is triggering. In the ** cell you'd enter a bit of text, like 'test' or something.
Which in the decompiler looks like:
If ( (LocalVar:01C0 == 0) )
{
LocalVar:0000 <- 80
TempGlobal <- &GlobalVar(0000)
Unknown(2018) <- GlobalAddress
If ( (GlobalAddress > 50) )
{
LocalVar:01A0 <- ActiveMask.Exp
LocalVar:01C0 <- ActiveMask.Exp
ActiveMask.Exp <- LocalVar:01A0 * 2
LocalVar:01C0 <- 0
Display String: ""EXP sum triggered""
}
SCRIPT END
One thing to note is that while this script did appear to trigger in battle, it was a half-finished prototype where I essentially gave up on the EXP thing and was just trying random combinations to get it working so don't worry about that bit where it says Active Mask or EXP. The '0' at [LocalVar:01C0 <- 0] was supposed to be a 1 too, can't remember why I wanted the script running every time I attacked.
I'll get yelled at again for being hazy on the actual details, but here's what the things in this script sort of are:
LocalVar: 0000, 0020, ..., 01C0
These are like temporary variables the battle engine uses. They're not related to the field variables, I don't think. Most of the enemies of the game use these to determine their attacks. They go up in 20's but I've seen Gjoerulv use 0010, 0030, etc. for his AIs so y'know. I generally use high numbers to avoid conflicts, so I'm using that 01C0 up there to shut it down after it's been run once (or at least, it would if that 0 toward the end was a 1).
GlobalVar: These are the ones that access field variables. Only Bank 1 is accessed, so first we need to specify which variable we want to read in this bank and we can use the battle engine's temporary variables to carry the numbers about. We want [80] in Bank 1, so:
LocalVar:0000 <- 80
My memory is very hazy at this point, but I most likely copied this from Jenova SYNTHESIS or Zombie Dragon who both use Global variables:
TempGlobal <- &GlobalVar(0000)
Unknown(2018) <- GlobalAddress
I'm not sure what that does, I'm afraid. But it seems to enable the If string that follows, and I think it didn't trigger whenever the value of [1][80] was set below 50; it's been a while since I used the script:
If ( (GlobalAddress > 50) )
So with the IF string triggering based on the value loaded from the variable, you can now adjust things like HP for enemies and other things. Now if you'll excuse me, I'm going to go hide before certain scary people find this post.
Not sure what surprises me more - that you actually came up with that code or that it works on FF-J original version :P Great job! I assigned one high 16-bit number and one low in init of two rooms and walked between each and it worked as expected. I noticed the string didn't appear for enemies that say stuff though such as "intruders" in the first reactor. Also by default it seems to be over 50..
Just a few more questions - if its OK! :D
1. So Bank [1] 80 is the battle points love variable? Is this the only one we can use? Or is there a few like 81, 82? Also, is it overwritten (or increased?) when the battle is finished (so we need to overwrite it to 0 again?)
2. How would I begin experimenting and adjusting HP values? I'm not familiar (at all) with the opcodes FF7 uses.. I think basically I would want it to read if the variable is higher than 50 (or whatever to trigger it), and then have another variable act as the HP value (i.e. so it doesn't set the HP variable everytime, only when I tell it).
3. If Cloud is not in the party, does it all fall apart, or can I add it to all party members somehow?
4. Could you pass a string "variable" to say different things? I think the string function is kind of cool as well.
-
Not sure what surprises me more - that you actually came up with that code or that it works on FF-J original version :P Great job! I assigned one high 16-bit number and one low in init of two rooms and walked between each and it worked as expected. I noticed the string didn't appear for enemies that say stuff though such as "intruders" in the first reactor. Also by default it seems to be over 50..
I had a bunch of help from NFITC1 and Sithlord getting that together (well, that and the code already in the game). I was told that there's four variables used for B. Love Points: 80, 81, 82, 83 and that they're set to start at 100. In Makou I set it to 0 and tried it at above 50; I remember testing it and I think it worked (triggers above 50, doesn't trigger below 50), but I can't commit to that because it was a while ago. Not sure about the text string interference either, you might need to test it at different points of the game to make sure.
1. So Bank [1] 80 is the battle points love variable? Is this the only one we can use? Or is there a few like 81, 82? Also, is it overwritten (or increased?) when the battle is finished (so we need to overwrite it to 0 again?)
2. How would I begin experimenting and adjusting HP values? I'm not familiar (at all) with the opcodes FF7 uses.. I think basically I would want it to read if the variable is higher than 50 (or whatever to trigger it), and then have another variable act as the HP value (i.e. so it doesn't set the HP variable everytime, only when I tell it).
3. If Cloud is not in the party, does it all fall apart, or can I add it to all party members somehow?
4. Could you pass a string "variable" to say different things? I think the string function is kind of cool as well.
1. Sith told me that 80, 81, 82, and 83 are used and that they're set to 100 by default. You can set them lower through Makou; I usually give random NPCs on the Highwind codes like this in their talk script to quickly trigger it. As far as using others go, I guess any can be used so long as they're not already in use (I'm still trying to clean that up in my mod).
2. There's an OPCode list but I think the one I snagged is out of date by now. As far as adjusting HP goes, it depends on what you want to do; what is it specifically you're after? Because the HP value will generally be bigger than 255, it needs to be stored in the actual AI somewhere and pushed into the enemy from there (unless we're multiplying Enemy HP, but I've never had much luck with multiplying and multiplying enemy HP tends to go south eventually). I'll upload that OPCode file in any case.
3. There are scripts in there that 'link with scripts on character 0' (Cloud being Character 0) that should have other characters run his scripts whether he's in the current party or not. NFITC1 warned me that I'd need to find a way to make this only run once, but there might be ways to make it so that it doesn't matter if the script is run 2-3 times in one battle. You'd want:
60 00
75
73
In Barret, Tifa, Cid, and Yuffie pre-battle AI. I think that covers everyone. Also, I'm not sure if pre-battle runs if a character starts a fight dead; assuming there's no kernel mishaps, if you can put that small code into all 9 characters then I guess that'd completely cover it.
4. Dunno what you mean, it's just for making text appear. If you want the string to have a pause after it displays, then enter it like this:
93 TEXT
60 24
60 00
92
Seems to do the trick. To have a character's name appear, it's {EA000#H} where the # replaces the character's ID (Cloud is 0, Barret is 1, etc.) So it'd be written as: '{EA0000H}: "{EA0001H}! Attack while it's tail's up!"' However, using EAs makes a bunch of 60 00s appear for some reason. Probably to handle space or something. Not sure how the character AI will react to it either, it handles differently from the older Proud Clod versions I use.
-
I had a bunch of help from NFITC1 and Sithlord getting that together (well, that and the code already in the game). I was told that there's four variables used for B. Love Points: 80, 81, 82, 83 and that they're set to start at 100. In Makou I set it to 0 and tried it at above 50; I remember testing it and I think it worked (triggers above 50, doesn't trigger below 50), but I can't commit to that because it was a while ago. Not sure about the text string interference either, you might need to test it at different points of the game to make sure.
1. Sith told me that 80, 81, 82, and 83 are used and that they're set to 100 by default. You can set them lower through Makou; I usually give random NPCs on the Highwind codes like this in their talk script to quickly trigger it. As far as using others go, I guess any can be used so long as they're not already in use (I'm still trying to clean that up in my mod).
2. There's an OPCode list but I think the one I snagged is out of date by now. As far as adjusting HP goes, it depends on what you want to do; what is it specifically you're after? Because the HP value will generally be bigger than 255, it needs to be stored in the actual AI somewhere and pushed into the enemy from there (unless we're multiplying Enemy HP, but I've never had much luck with multiplying and multiplying enemy HP tends to go south eventually). I'll upload that OPCode file in any case.
3. There are scripts in there that 'link with scripts on character 0' (Cloud being Character 0) that should have other characters run his scripts whether he's in the current party or not. NFITC1 warned me that I'd need to find a way to make this only run once, but there might be ways to make it so that it doesn't matter if the script is run 2-3 times in one battle. You'd want:
60 00
75
73
In Barret, Tifa, Cid, and Yuffie pre-battle AI. I think that covers everyone. Also, I'm not sure if pre-battle runs if a character starts a fight dead; assuming there's no kernel mishaps, if you can put that small code into all 9 characters then I guess that'd completely cover it.
4. Dunno what you mean, it's just for making text appear. If you want the string to have a pause after it displays, then enter it like this:
93 TEXT
60 24
60 00
92
Seems to do the trick. To have a character's name appear, it's {EA000#H} where the # replaces the character's ID (Cloud is 0, Barret is 1, etc.) So it'd be written as: '{EA0000H}: "{EA0001H}! Attack while it's tail's up!"' However, using EAs makes a bunch of 60 00s appear for some reason. Probably to handle space or something. Not sure how the character AI will react to it either, it handles differently from the older Proud Clod versions I use.
Thanks for the detailed reply.
2. Use case would be to set certain enemies HP higher, thats all really. If it can't be set to a certain value, then I guess I could take a shot at multiplying it somehow as I don't want to edit enemy stats directly..
3. Understood, that's handy. I noticed they're linked to character 3 at the moment, so it would just be a one digit change.
-
If you're just setting HP to a certain amount for specific enemies then that's probably the easiest thing. If Enemy ID = #### would probably do the trick; actually, if that works then you might not even need the globalvar thing after all (unless they're only to get more HP after a certain criteria is fulfilled on the field).
Here's that OpCode list: http://www.mediafire.com/view/umiqacyau66u9c9/opcode_list.txt
-
If you're just setting HP to a certain amount for specific enemies then that's probably the easiest thing. If Enemy ID = #### would probably do the trick; actually, if that works then you might not even need the globalvar thing after all (unless they're only to get more HP after a certain criteria is fulfilled on the field).
Here's that OpCode list: http://www.mediafire.com/view/umiqacyau66u9c9/opcode_list.txt
Thanks, that list is awesome. Yeah it would definitely be via field criteria so I need the variable.
I've been trying to code it (while looking at Proud Clod AI to get some ideas), but having some problems:
For example, if I set this command at the top of the If statement: "AllOpponentMask.HP <- 82" like so:
AllOpponentMask.HP <- 82
If ( (LocalVar:01C0 == 0) )
{
LocalVar:0000 <- 80
TempGlobal <- &GlobalVar(0000)
Unknown(2018) <- GlobalAddress
If ( (GlobalAddress > 50) )
{
Self.HP <- 82 //just ignore this test one obviously
LocalVar:01C0 <- 0
}
SCRIPT END
It works fine and guard scorpion dies quickly. But if its inside the If statement it doesn't work, only the display message works. If I put self.hp = 255, for example, works fine outside if statement, but inside it doesn't work. Is it something to do with Unknown(2018)? Or have I screwed up a line somewhere? Seems odd only the display message works..
Of course this script is just for testing, I will want to use a global variable not hardcoded value, I assume that will let me drop in a higher value 16 bit number rather than 255?
-
I will want to use a global variable not hardcoded value, I assume that will let me drop in a higher value 16 bit number rather than 255?
then you better put two bytes together to make it 16 bit in size. ;)
-
then you better put two bytes together to make it 16 bit in size. ;)
Well I haven't got to that part yet, I'm just trying to get the If statement working for that assignment statement first. Maybe I screwed up something in-between the lines or something, as when I was removing the multiplication symbol from Sega Chief's code, I might of took something necessary out, even though the decompiler still reads it OK. That might explain why the display message part works OK as its just one line (93) hard to screw that up :P
-
It might be the method being used to adjust HP. One thing you should do is have an English scene.bin you can open up and have a look at the AI in; I learned a lot from looking at the default game's enemy AI and how they work. So for HP, I looked at how Bizarro and Safer determine and adjust their HP before the battle starts (because it rises/drops depending on previous battles, player level, etc.)
This is a portion from a test group I had for adjusting enemy stats; I can confirm this works in the scene.bin, but the enemy is applying this to itself (which is why it uses Self.) so you'd need to use a different mask.
13 01A0
61 2710
90
12 2060
13 4180
80
03 01A0
90
12 2060
13 4160
80
02 2060
03 4180
80
90
Which looks like this:
LocalVar:01A0 <- 10000
Self.MHP <- LocalVar:01A0
Self.HP <- Self.MHP
Thing to note there is that we're using 61 instead of 60 for the number being pushed into 01A0. We can't put a number like that into [1][80] because it's a one-byte address (and we can't get battle to read [2], which is where 2-byte stuff is read from). For stats like Strength and Magic Attack, you can apparently just push a value in directly but enemies I've seen do it this way for HP. What we need to do now is change the mask so that it applies to the enemy. There's two ways to try, but one I've not tested yet:
Enemy ID
12 0100
02 2050
02 4120
80
60 16 [Scorp's Enemy ID]
40
90
By Bit (untested)
12 0100
60 03
87
90
With that loaded into the 0100 variable, you'd then replace the 2060s in this code with 0100 for:
LocalVar:01A0 <- 10000
LocalVar:0100.MHP <- LocalVar:01A0
LocalVar:0100.HP <- LocalVar:0100.MHP
Ideally, if the second one works (Bit) then it could be applied to any single enemy. Give it a whirl and see what happens; but if it doesn't work inside the IF thing then there must be something wrong with the way I set it up originally. You could perhaps get rid of the top IF bit because pre-battle only runs once so that part is now obsolete.
-
It might be the method being used to adjust HP. One thing you should do is have an English scene.bin you can open up and have a look at the AI in; I learned a lot from looking at the default game's enemy AI and how they work. So for HP, I looked at how Bizarro and Safer determine and adjust their HP before the battle starts (because it rises/drops depending on previous battles, player level, etc.)
This is a portion from a test group I had for adjusting enemy stats; I can confirm this works in the scene.bin, but the enemy is applying this to itself (which is why it uses Self.) so you'd need to use a different mask.
13 01A0
61 2710
90
12 2060
13 4180
80
03 01A0
90
12 2060
13 4160
80
02 2060
03 4180
80
90
Which looks like this:
LocalVar:01A0 <- 10000
Self.MHP <- LocalVar:01A0
Self.HP <- Self.MHP
Thing to note there is that we're using 61 instead of 60 for the number being pushed into 01A0. We can't put a number like that into [1][80] because it's a one-byte address (and we can't get battle to read [2], which is where 2-byte stuff is read from). For stats like Strength and Magic Attack, you can apparently just push a value in directly but enemies I've seen do it this way for HP. What we need to do now is change the mask so that it applies to the enemy. There's two ways to try, but one I've not tested yet:
Enemy ID
12 0100
02 2050
02 4120
80
60 16 [Scorp's Enemy ID]
40
90
By Bit (untested)
12 0100
60 03
87
90
With that loaded into the 0100 variable, you'd then replace the 2060s in this code with 0100 for:
LocalVar:01A0 <- 10000
LocalVar:0100.MHP <- LocalVar:01A0
LocalVar:0100.HP <- LocalVar:0100.MHP
Ideally, if the second one works (Bit) then it could be applied to any single enemy. Give it a whirl and see what happens; but if it doesn't work inside the IF thing then there must be something wrong with the way I set it up originally. You could perhaps get rid of the top IF bit because pre-battle only runs once so that part is now obsolete.
Thanks for the code, many cool things to learn from trying this out! I'll do it shortly.
And yes, I'm already looking through scene.bin. I'll also just mention again that the Guard Scorpion's HP WAS lowered when I didn't use your If statement, does this still fall under "It might be the method being used to adjust HP?" would it need to be different method just because its in that if statement?
-
I'm not sure. I usually copy the game's layout for doing things to avoid potential issues popping up so it's worth a shot (but it's probably something to do with the If). It's also handy for learning how to put values into variables and then pushing the variable into different things; gives you more control over what happens. You also want to adjust MaxHP which is treated as a separate value from CurrentHP, otherwise things like General Counters (a lot of which operate based on what % of HP a boss has left) will be out of whack. And you especially want to do it if you're setting CurrentHP higher than it was originally.
-
Yep, I was just playing with HP only and not MaxHP so I could get the basics down first.
I can report gladly that all the code above works (as I thought it would). Excellent! While I understand Enemy ID, I'm not sure I quite understand what is Bit 3? Is it monsters from the area you are fighting in or something? How does it only affect Guard Scorpion?
This is my code (setting HP to 5):
LocalVar:01A0 <- 5
LocalVar:0100 <- FlagBit(3)
LocalVar:0100.HP <- LocalVar:01A0
SCRIPT END
Now for the big test, throw it into an if statement haha. I haven't had any luck with this at all previously. Maybe with the enemy ID located in a variable it can work this time :)
-
There are 8 bits in a byte.
Any one of those 8 bits, numbered 0-7 can be turned on. Bit 3 is the 4th bit. 0000X000
Before you tackle this stuff you will need to understand the basics of programming.
-
I forgot to say about the bit thing. For Jenova BIRTH's AI, she puts Flagbit 0, 1, and 2 into three separate variables and these have her attack each separate party member during a 'wave' of laser or w-laser. Later, I saw something in another AI where it targeted other enemies using bit 3, 4, etc. My hunch is that from 3 onwards it's enemies, problem is there can be 6 enemies on the field which is one too many for a byte. I'm trying to track down that enemy again so I can have a closer look at it.
Edit: Found it, was in Elena's Death Script
02 21A0
60 00
40
70 00C6
12 21A0
60 01
90
93 Reno “Let's call it a day.”
12 2070
02 2060
90
60 20
61 0164
92
12 0000
60 04
87
90
12 0000
10 4020
80
60 00
90
12 0000
10 4023
80
60 00
90
12 0000
10 4022
80
60 00
90
12 0000
10 4024
80
60 00
90
12 0000
60 05
87
90
12 0000
10 4020
80
60 00
90
12 0000
10 4023
80
60 00
90
12 0000
10 4022
80
60 00
90
12 0000
10 4024
80
60 00
90
12 0000
60 06
87
90
12 0000
10 4020
80
60 00
90
12 0000
10 4023
80
60 00
90
12 0000
10 4022
80
60 00
90
12 0000
10 4024
80
60 00
90
0x000 If ( (Unknown(21A0) == 0) )
0x000 {
0x009 Unknown(21A0) <- 1
0x00F Display String: "Reno “Let's call it a day.”"
0x02C TargetMask <- Self
0x033 Perform("(Report)"[0164], EnemyAttack)
0x039 LocalVar:0000 <- FlagBit(4)
0x040 LocalVar:0000.Flag:Unknown(00000001) <- 0 (Cure)
0x04A LocalVar:0000.Flag:Enabled? <- 0 (Cure)
0x054 LocalVar:0000.Flag:Unknown(00000004) <- 0 (Cure)
0x05E LocalVar:0000.Flag:MainScriptActive <- 0 (Cure)
0x068 LocalVar:0000 <- FlagBit(5)
0x06F LocalVar:0000.Flag:Unknown(00000001) <- 0 (Cure)
0x079 LocalVar:0000.Flag:Enabled? <- 0 (Cure)
0x083 LocalVar:0000.Flag:Unknown(00000004) <- 0 (Cure)
0x08D LocalVar:0000.Flag:MainScriptActive <- 0 (Cure)
0x097 LocalVar:0000 <- FlagBit(6)
0x09E LocalVar:0000.Flag:Unknown(00000001) <- 0 (Cure)
0x0A8 LocalVar:0000.Flag:Enabled? <- 0 (Cure)
0x0B2 LocalVar:0000.Flag:Unknown(00000004) <- 0 (Cure)
0x0BC LocalVar:0000.Flag:MainScriptActive <- 0 (Cure)
0x0C6SCRIPT END
From the look of it, it pushes FlagBits into the variable and then uses that to target them for disabling their Main script so that the battle ends when one 'dies'. Thing is, it looks like it starts from 4 and not 3. Not sure why, but I do know that player characters are 0, 1, and 2. I assumed 3 would be next. Try replacing the 3 with a 4 if it doesn't work. I remember reading that there's another actor, something to handle camera, but that's just a guess for why it jumps from 2 to 4 here (although Elena did originally have two placements on the field to handle her Row jumping; maybe it's a left-over?)
-
I'm using bit flags in my mods already (said it in my first post here), just asking how it relates to this battle script.
Actually, I may have made a mistake in testing "by bit" by using wrong ISO, it doesn't seem to function now. But the enemy ID one works fine though, I'll see if I can retune it by checking out what Safer Sephiroth does.
Edit: Ah, right, I'll try using bit 4 in a moment to see if that has any affect.
Edit 2: Excellent, I got the If statement working with this code (modified from Sega Chief's original code)
LocalVar:01A0 <- 5
LocalVar:0000 <- 80
TempGlobal <- &GlobalVar(0000)
If ( (GlobalAddress > 50) )
{
LocalVar:0100 <- (ActiveMask.EnemyID == 22)
LocalVar:0100.HP <- LocalVar:01A0
Display String: "test"
}
SCRIPT END
-
OK, now I need to contribute here. :)
I forgot to say about the bit thing. For Jenova BIRTH's AI, she puts Flagbit 0, 1, and 2 into three separate variables and these have her attack each separate party member during a 'wave' of laser or w-laser. Later, I saw something in another AI where it targeted other enemies using bit 3, 4, etc. My hunch is that from 3 onwards it's enemies, problem is there can be 6 enemies on the field which is one too many for a byte.
Flagbit is just the command for turn on bit X. OpCode 87 turns on bit pop0 of a 32 bit value. Since the last push was the value 4, that's the byte that's turned on:
00000000 00000000 00000000 00010000This gets stored as a word value because the "LDA" command was issued via 12 which tells the STOR command to read it as a two-byte value.
Further, 0-2 are player characters (0 is top, 2 is bottom in the menu)
"actor" 3 doesn't really exist and shouldn't/can't be manipulated in this way.
4-9 are indeed enemies 0-5 as indicated in Proud Clod's formation menu. It's a little unsafe to refer to them this way, but so is referring to them by IDs in the case of multiple instances.
Other values can't be "MASK"ed by command 80 and are ignored.
Finally, 4020, 4023 and 4022 are, in no particular order (mostly because I'm still not sure which is which), "ATB running/can counter attack," "Targetable," and "Active". Only turning off Active will flag this as "defeated", but there are other reasons for turning off the others as well. Mostly camera related.
-
Cheers for the info, NFITC1. Is there a safer way to refer to enemies, though? Only other thing I can think of just now is Active Formation which Bizarro uses when getting the stats of it's different parts sorted out.
-
I was planning to pass value from bank1 var 81 (via field scripting) to refer to enemy ID (I tested it with regular variable and it works, so I assume that would work). Most bosses aren't multiple parts..and there could be special exceptions for them. Though I'm not sure 1 byte is enough to refer to all enemy IDs?
-
Past a certain point, it won't be big enough anymore. Once you reach Guardian in the Underwater Reactor, that's when it goes past 255 (in the actual formation, his left hand is FF/255 and his right hand is 0100/256).
I was thinking from the field you set the variable to 1 when you need it On and to 0 when you need it Off.
01 2010
60 32 (change to 60 01)
44 (change this to a 40)
Then it'll be If ( (GlobalAddress = 1) ) and you can toggle it on and off for those certain boss enemies you want to buff, if that's the goal.
-
Past a certain point, it won't be big enough anymore. Once you reach Guardian in the Underwater Reactor, that's when it goes past 255 (in the actual formation, his left hand is FF/255 and his right hand is 0100/256).
I was thinking from the field you set the variable to 1 when you need it On and to 0 when you need it Off.
01 2010
60 32 (change to 60 01)
44 (change this to a 40)
Then it'll be If ( (GlobalAddress = 1) ) and you can toggle it on and off for those certain boss enemies you want to buff, if that's the goal.
Hmm, seems quite simple, how about this instead?
var 80 and 81 - add them together in script to get enemy ID
- add secondary if statements, if encounter Guardian, etc, then affect ALL enemy IDs in battle (maybe lose some flexbility though)
var 82 - A MAX HP value to set (same as HP)
var 83 - multipliers for stat combos/MP (allowed 255 combinations right? maybe you could even include a combo for random encounters which simply sets HP multipler for all enemy bitflags)
If all four vars are active, turn on the script for next encounter?
Lol, would this actually work?
Edit: Not asking you to give code example, I think I know enough now to experiment at least (thanks to you) ;D
Edit 2: Just remembered only 1 byte for var 82.. maybe can merge HP multiplier into var 83 and have one var free for something else?
-
So long as you don't put a number above 255 into 80, 81, 82, or 83. And try not to let the code get too long, you might have kernel problems and end up with the wrong encounters loading up. And be careful with multiplying stats; that can quickly get out of hand. It's better to fine-tune stats manually, enemy by enemy, but I guess that's not an option if the scene.bin can't be edited.
To be honest, the simpler you can make it the easier you'll be making it on yourself.
-
Is there a safer way to refer to enemies, though?
Not really. All I mean is there's no error-checking involved so I'm not keen with that method. Pairing with enemy ID will make it better when you have combinations with different numbers of enemies.
Say you have a enemy party of two bandersnatches, a griffin, and a Jabberwockies (just say). Now Bandersnatches are bitter enemies with griffin, but friendly to jabberwockies. So you want them to heal jabberwockies and randomly hinder griffins. If you have different formations of these three enemies then you'd want the Bandersnatch AI to refer to them by ID because their formation positions aren't fixed.
However, if you have a fixed formation, like a boss fight, where you know exactly where all the pieces are in the formation then it's perfectly reasonable to refer to them by formation ID. One advantage to something like this is for Boss minions/bits/options (whatever you want to call them) that have identical enemy IDs, but need to be handled individually. The other is it makes the AI shorter by, maybe, one byte per reference. No Boss AI even comes close to filling its scene's allotted AI space. In fact, I think the only scene that DOES come close to filling it is the one that contains Eligor.
Also, refer to Ultima Weapon's AI for how to store multi-byte values.
-
Yeah I'll keep it short and sweet. I think it will be fun.. and will give me flexibility in the field having power over those stats. Actually, it looks like the only things I can't change is morph/steal/item drops (don't see them on opcode list, unless its unknown?). I was expecting only to be able to change HP values at the most :lol: Oh, modding FF7 is awesome!
I looked at the Kernel sizes for the Japanese version its just under 20kb by default, while the US one is 22kb by default. Does the script section have a specific limit or is it a overall kernel limit you're talking about (I'm not planning on making many significant changes to it other than scripts)? I've seen people saying around 27kb is maximum? I pasted in 200 lines of opcodes/argument numbers in a text file and it came up at around 1.6kb. Not sure how much it would be in the kernel, but I hope that's alright..
-
Not really. All I mean is there's no error-checking involved so I'm not keen with that method. Pairing with enemy ID will make it better when you have combinations with different numbers of enemies.
Say you have a enemy party of two bandersnatches, a griffin, and a Jabberwockies (just say). Now Bandersnatches are bitter enemies with griffin, but friendly to jabberwockies. So you want them to heal jabberwockies and randomly hinder griffins. If you have different formations of these three enemies then you'd want the Bandersnatch AI to refer to them by ID because their formation positions aren't fixed.
However, if you have a fixed formation, like a boss fight, where you know exactly where all the pieces are in the formation then it's perfectly reasonable to refer to them by formation ID. One advantage to something like this is for Boss minions/bits/options (whatever you want to call them) that have identical enemy IDs, but need to be handled individually. The other is it makes the AI shorter by, maybe, one byte per reference. No Boss AI even comes close to filling its scene's allotted AI space. In fact, I think the only scene that DOES come close to filling it is the one that contains Eligor.
Also, refer to Ultima Weapon's AI for how to store multi-byte values.
Gotcha, I was worried there was a memory problem with using ID or FlagBit. I clean forgot about Ultimate Weapon and it's HP though, that'd definitely be the place to look for applying a big HP value.
Yeah I'll keep it short and sweet. I think it will be fun.. and will give me flexibility in the field having power over those stats. Actually, it looks like the only things I can't change is morph/steal/item drops (don't see them on opcode list, unless its unknown?). I was expecting only to be able to change HP values at the most :lol: Oh, modding FF7 is awesome!
I looked at the Kernel sizes for the Japanese version its just under 20kb by default, while the US one is 22kb by default. Does the script section have a specific limit or is it a overall kernel limit you're talking about (I'm not planning on making many significant changes to it other than scripts)? I've seen people saying around 27kb is maximum? I pasted in 200 lines of opcodes/argument numbers in a text file and it came up at around 1.6kb. Not sure how much it would be in the kernel, but I hope that's alright..
I think the best thing to do is make regular back-ups and test often. Fight encounters in three different parts of the game to be safe and keep on the look out for the wrong encounters loading in. But like NFITC1 suggested, check out Ultimate Weapon's HP too:
60 00
60 5B
95
13 0000
01 2010
90
60 00
60 5C
95
13 0020
01 2010
90
60 00
60 5D
95
13 0040
01 2010
90
12 2060
13 4160
80
03 0000
62 010000
32
03 0020
61 0100
32
30
03 0040
30
90
12 2060
10 402C
80
60 01
90
11 00A0
60 03
81
60 03
34
30
90
13 0080
02 2060
03 4160
80
90
0x000TempGlobal <- &GlobalVar(005B)
0x005LocalVar:0000 <- GlobalAddress
0x00CTempGlobal <- &GlobalVar(005C)
0x011LocalVar:0020 <- GlobalAddress
0x018TempGlobal <- &GlobalVar(005D)
0x01DLocalVar:0040 <- GlobalAddress
0x024Self.HP <- LocalVar:0000 * 65536 + LocalVar:0020 * 256 + LocalVar:0040
0x040Self.Flag:DeathImmune? <- 1
0x04ALocalVar:00A0 <- 3 + Random MOD 3
0x055LocalVar:0080 <- Self.HP
0x060SCRIPT END
Seeing it there, it pushes three variables into three separate LocalVars and then combines them all into an equation to find current HP. The stuff starting from 0x040 is other stuff to handle his attacks, when he flies off, etc.
-
Yeah I did check that out along with Safer Sephiroth's AI. That part doesn't seem too complicated but makes me think of a good question.. whose pre-battle AI goes first? If I change Ultimate Weapon's HP in Cloud's pre-battle AI, would that affect Ultimate Weapon? I'm assuming my one would kick in first (as the first character/bitflag?), and then Ultimate Weapon's HP would go back to normal (unless I also change scene.bin).