Unused/useless variables safe to use in savemap? (PSX)

  • Thread starter Thread starter Roden
  • Start date Start date
Status
Not open for further replies.
R

Roden

Guest
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.
Click to expand...
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.
 
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.
 
Last edited:
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.
Click to expand...
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.
 
Last edited:
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.
Click to expand...
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?
Click to expand...
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.
 
Last edited:
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.
 
Last edited:
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):

Code: [Select]
Code: 
BANK 10x0000: word0x0054: byte0x0055: byte0x0056: byte0x0057: byte0x0058: byte0x007a: bit 00x007a: bit 10x007a: bit 20x007a: bit 30x007b: bit 00x007b: bit 20x007b: bit 30x007c: byte0x007d: bit 00x007e: bit 00x007e: bit 10x007e: bit 20x007e: bit 30x007e: bit 40x007e: bit 50x007e: bit 60x007f: bit 00x007f: bit 10x007f: bit 20x007f: bit 30x007f: bit 40x007f: bit 5BANK 20x01cf: bit 00x01cf: bit 10x01cf: bit 20x01cf: bit 30x01cf: bit 40x01cf: bit 50x01cf: bit 60x01cf: bit 7BANK 40x0350: bit 30x0351: byte0x0352: bit 20x0352: bit 30x0380: byte0x0381: byte0x0382: byte0x0383: byte0x0384: bit 00x0384: bit 10x0384: bit 20x0384: bit 30x0384: bit 40x0384: bit 50x0384: bit 60x0384: bit 70x0385: bit 00x0385: bit 10x0385: bit 30x0385: bit 40x0385: bit 50x0385: bit 60x0385: bit 70x0386: bit 00x0386: bit 10x0386: bit 20x0386: bit 30x0386: bit 40x0386: bit 50x0386: bit 60x0386: bit 70x0387: bit 00x0387: bit 10x0387: bit 20x0387: bit 30x0387: bit 40x0387: bit 50x0388: word0x038a: word0x038c: byte0x038d: byte0x038e: byte0x038f: byte0x0390: word0x0392: word0x0394: byte0x0396: byteBANK 50x0491: 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

Code: [Select]
Code: 
Bank 1 [1/2]: Starts 0x0000Bank 2 [3/4]: Starts 0x0100Bank 3 [11/12]: Starts 0x0200Bank 4 [13/14]: Starts 0x0300Bank 5 [7/15]: Starts 0x0400
 
Last edited:
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.
 
Last edited:
Status
Not open for further replies.
Back
Top