Author Topic: (FF7) Savemap: where do non field changes come from?  (Read 3123 times)

Vegeta_Ss4

  • Fast newbie
  • *
  • Posts: 42
  • Karma: 1
  • Dark Wizard of the Savegame
    • View Profile
    • Black Chocobo
Well I have been doing a research and I found that many savemap vars are changed from outside the field script. Some of this vars are used by the field doing some action based on the value; some others are even unreferenced in the fieldscript (particularly seen on mini-games).

So any one has any clue about this?

DLPB

  • No life
  • *
  • Posts: 9064
  • Karma: 273
  • For I realized that God's a young man, too.
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #1 on: 2013-10-04 16:31:26 »
Minigame scores and so forth will be passed to variables by the exe more than likely.  I am not sure about battle, does that allow changing of memory?

NFITC1

  • No life
  • *
  • Posts: 2825
  • Karma: 68
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: (FF7) Savemap: where do non field changes come from?
« Reply #2 on: 2013-10-04 16:52:01 »
Battle variables (like Dragon Zombie's "I have used Pandora's Box" variable) only affect memory bank 1/2 (0xBA4 - 0xCA3). This should be where all battle-related persistent variables reside.

Bank B/C is mostly mini-game related variables (high scores and such) but can, of course, be modified by field scripts.

Everything else is a field variable of some sort.

Vegeta_Ss4

  • Fast newbie
  • *
  • Posts: 42
  • Karma: 1
  • Dark Wizard of the Savegame
    • View Profile
    • Black Chocobo
Re: (FF7) Savemap: where do non field changes come from?
« Reply #3 on: 2013-10-04 16:56:55 »
Thanks for replying so fast!
I see... on pc version is hardcoded in the exe, but how about the psx version?
Is there any other place where we can find opcodes that change those vars?

DLPB

  • No life
  • *
  • Posts: 9064
  • Karma: 273
  • For I realized that God's a young man, too.
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #4 on: 2013-10-04 17:31:36 »
Battle variables (like Dragon Zombie's "I have used Pandora's Box" variable) only affect memory bank 1/2 (0xBA4 - 0xCA3). This should be where all battle-related persistent variables reside.

Bank B/C is mostly mini-game related variables (high scores and such) but can, of course, be modified by field scripts.

Everything else is a field variable of some sort.

offtopic kinda...
I need Midgardsormr to die for good at some point.  is there any spare bit in that range that I can use?  I suppose the real issue would be that I would need to check that bit using world map script. And there is no editor for world map script yet...  I am sure that the sormr was meant to die completely you know but they never got round to it.

Kaldarasha

  • No life
  • *
  • Posts: 2211
  • Karma: 133
  • Prince of Model Editing
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #5 on: 2013-10-04 18:05:28 »
How do they do this with the Weapons?

NFITC1

  • No life
  • *
  • Posts: 2825
  • Karma: 68
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: (FF7) Savemap: where do non field changes come from?
« Reply #6 on: 2013-10-04 18:05:47 »
offtopic kinda...
I need Midgardsormr to die for good at some point.  is there any spare bit in that range that I can use?  I suppose the real issue would be that I would need to check that bit using world map script. And there is no editor for world map script yet...  I am sure that the sormr was meant to die completely you know but they never got round to it.

The likely candidate for that would be 0x0C1F of the 1/2 memory block. That has some bits for the death's of the WEAPONs. The highest bit, 0x80 I guess, would be ideal for that if nothing else uses it. That still begs the question of the world map scripts, however. Also, I don't think he was intended to disappear completely. Canonically, Cloud & co barely escape out of the swamp in their first trip and meet what Sephiroth did to the one he met. Since there's still one in the swamp I think there are supposed to be many (or an infinite number) of them. That would make a pretty neat side-quest though. Kill 10 of them and get....something. Of course, they'd need to get harder and harder as you kill them.

DLPB

  • No life
  • *
  • Posts: 9064
  • Karma: 273
  • For I realized that God's a young man, too.
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #7 on: 2013-10-04 18:16:11 »
No I'd have to disagree there, because the guy at the farm explains that there is one (The text makes it reasonably clear).  I think what has happened here is a mistake with the writing (or deliberate mistake so that the player gets to fight it).  The scene of what Sephiroth has done to it is really a flaw in the game flow, since you see the MS there swimming about and then instantly it is dead.  The best way to really think about it is in the story, Sep kills it, and in the game, it is alive purely as  a gameplay element.

If a story was made of VII it would be easy.  Cloud is told about the monster, but when he reaches the swamp he sees that it has already been killed. (Obviously in the game this would be boring).

Also... the way they did the killing is plain stupid.  How did Sephiroth get it spiked on a pole? And was what the pole doing there? haha
« Last Edit: 2013-10-04 18:20:04 by DLPB »

sithlord48

  • No life
  • *
  • Posts: 1454
  • Karma: 33
  • Dark Lord of the Savegame
    • View Profile
    • Blackchocobo
Re: (FF7) Savemap: where do non field changes come from?
« Reply #8 on: 2013-10-04 18:36:16 »
@ dlpb i always thought he made the spike out of a tree..

we are trying to determing how we can track the non field changes for progression, any one have more ideas about how we can do this. we have found that several times the field data is changed from out of the field. this happens for many modules does anyone know what modules are using what sections of the savedata remaining undiscovered?

NFITC1

  • No life
  • *
  • Posts: 2825
  • Karma: 68
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: (FF7) Savemap: where do non field changes come from?
« Reply #9 on: 2013-10-04 18:36:44 »
I thought that odd my first time through as well. Just because the farmer thinks there is only one doesn't mean there aren't others. I don't think we're supposed to take everything every NPC says as plain fact. Maybe Cloud fights Sephiroth's victim's offspring. That would mean that the ones Cloud's party fights are weaklings compared to the impaled one. :O

Sephiroth's awesome enough to flip one on to the ONLY tree in the area which impaled the snake and defoliated the tree. THAT'S how powerful he was. :)

we are trying to determing how we can track the non field changes for progression, any one have more ideas about how we can do this. we have found that several times the field data is changed from out of the field. this happens for many modules does anyone know what modules are using what sections of the savedata remaining undiscovered?

Pretty much any holes in the data here indicate unknown usages. But I would expect YOU to know that. ;)

Field variables are modified directly out of the save map starting at 0xDC08DC. The main writing function is at 0x61031E from the field scripts. There are a lot of direct references to memory locations all up and down the field script blocks all the way to 0xDC0CDC. Most of them from mini game-related functions. Here's a list of direct references in that region and at least one reference to each of them.

Code: [Select]
0xDC08DC Memory12Start   dw ?                    ; DATA XREF: WriteByteToGlobal+1Br
0xDC08DE MysteryNinjaStartingLevel db ?          ; DATA XREF: AddNewCharacter+12Er
0xDC08EC GameTime_Hours  db ?                    ; DATA XREF: sub_60C94D+39w
0xDC08ED GameTime_Mins   db ?                    ; DATA XREF: sub_60C94D+67w
0xDC08EE GameTime_Secs   db ?                    ; DATA XREF: sub_60C94D+83r
0xDC08EF GameTime_Frac   db ?                    ; DATA XREF: sub_60C94D+9Ew
0xDC08F0 byte_DC08F0     db ?                    ; DATA XREF: sub_60C94D+E2w
0xDC08F1 byte_DC08F1     db ?                    ; DATA XREF: sub_60C94D+110w
0xDC08F2 byte_DC08F2     db ?                    ; DATA XREF: sub_60C94D+12Cr
0xDC08F3 byte_DC08F3     db ?                    ; DATA XREF: sub_60C94D+147w
0xDC08F4 byte_DC08F4     db ?                    ; DATA XREF: sub_4090E6+284r
0xDC08F5 byte_DC08F5     db ?                    ; DATA XREF: sub_4090E6+29Fr
0xDC08F6 byte_DC08F6     db ?                    ; DATA XREF: BeginBattle?+9EBr
0xDC08F7 byte_DC08F7     db ?                    ; DATA XREF: BeginBattle?+A05r
0xDC08F8 byte_DC08F8     db ?                    ; DATA XREF: ClearMemory+ECw
0xDC08F9 byte_DC08F9     db ?                    ; DATA XREF: ClearMemory+F3w
0xDC08FA byte_DC08FA     db ?                    ; DATA XREF: sub_6CA346+7Fr
0xDC08FB byte_DC08FB     db ?                    ; DATA XREF: sub_60BCFA+96Fr
0xDC091C byte_DC091C     db ?                    ; DATA XREF: sub_714FA3+32r
0xDC0927 byte_DC0927     db ?                    ; DATA XREF: AddMateriatoInventory+50r
0xDC093B TimerDirection  db ?                    ; DATA XREF: fptc+AEr
0xDC094C BattlePoints_XXXXXXFF db ?              ; DATA XREF: sub_6E384F+6Er
0xDC094D BattlePoints_XXXXFFXX db ?              ; DATA XREF: sub_6E384F+75r
0xDC094E BattlePoints_XXFFXXXX db ?              ; DATA XREF: sub_6E384F+82r
0xDC094F BattlePoints_FFXXXXXX db ?              ; DATA XREF: sub_6E384F+8Fr
0xDC0950 byte_DC0950     db ?                    ; DATA XREF: sub_6DAA08+E8w
0xDC0956 byte_DC0956     db ?                    ; DATA XREF: sub_5CB127+32r
0xDC09E5 byte_DC09E5     db ?                    ; DATA XREF: ClearMemory+C5w
0xDC09E6 byte_DC09E6     db ?                    ; DATA XREF: sub_61CB92+10r
0xDC09E7 byte_DC09E7     db ?                    ; DATA XREF: sub_61BE95+140w
0xDC0A3E byte_DC0A3E     db ?                    ; DATA XREF: sub_5E8E0B+10w
0xDC0A3F byte_DC0A3F     db ?                    ; DATA XREF: sub_5E8E0B+24w
0xDC0A4F byte_DC0A4F     db ?                    ; DATA XREF: sub_650509+8r
0xDC0A61 CanEncounterMK  db ?                    ; DATA XREF: sub_767CC1+5r
0xDC0AA0 byte_DC0AA0     db ?                    ; DATA XREF: sub_6CBDCE+58w
0xDC0AAA byte_DC0AAA     db ?                    ; DATA XREF: sub_723CBB+15w
0xDC0ADC Memory_BC_Start dd ?                    ; DATA XREF: sub_718DBE+361w
0xDC0AE0 BC_0DA8         dw ?                    ; DATA XREF: sub_772357+D81r
0xDC0AE2 BC_0DAA         db ?                    ; DATA XREF: sub_76B87E+131w
0xDC0AE3 BC_0DAB         db ?                    ; DATA XREF: sub_76B87E+50r
0xDC0AE4 BC_0DAC         db ?                    ; DATA XREF: sub_76B87E+10r
0xDC0AE5 BC_0DAD         db ?                    ; DATA XREF: sub_76B87E+19w
0xDC0AE6 BC_0DAE         db ?                    ; DATA XREF: sub_772357+191r
0xDC0AE7 BC_0DAF         db ?                    ; DATA XREF: sub_772357+199r
0xDC0AE8 BC_0DB0         db ?                    ; DATA XREF: sub_772357+1B0r
0xDC0AE9 BC_0DB1         db ?                    ; DATA XREF: sub_772357+1B8r
0xDC0AEA BC_0DB2         db ?                    ; DATA XREF: sub_772357+1CDr
0xDC0AEB BC_0DB3         db ?                    ; DATA XREF: sub_772357+1DFr
0xDC0AEC BC_0DB4         db ?                    ; DATA XREF: sub_772357:loc_772640r
0xDC0AED BC_0DB5         db ?                    ; DATA XREF: sub_76C01F+E1r
0xDC0AEE BC_0DB6         db ?                    ; DATA XREF: sub_772357+247r
0xDC0AF2 BC_0DBA         db ?                    ; DATA XREF: sub_76C01F+5Ar
0xDC0AF3 BC_0DBB         db ?                    ; DATA XREF: sub_76B87E+71r
0xDC0AF5 BC_0DBD         db ?                    ; DATA XREF: sub_778C5D+41Ew
0xDC0AF6 BC_0DBE         db ?                    ; DATA XREF: sub_772357+20Er
0xDC0AF7 BC_0DBF         db ?                    ; DATA XREF: sub_772357+215r
0xDC0AF8 BC_0DC0         db ?                    ; DATA XREF: sub_778C5D+40Fw
0xDC0B47 byte_DC0B47     db ?                    ; DATA XREF: sub_650AD5+E7w
0xDC0B48 byte_DC0B48     db ?                    ; DATA XREF: sub_650AD5+D5w
0xDC0B49 byte_DC0B49     db ?                    ; DATA XREF: sub_650509+41r
0xDC0B4A byte_DC0B4A     db ?                    ; DATA XREF: sub_650509+28r
0xDC0B4B byte_DC0B4B     db ?                    ; DATA XREF: sub_6CA346+BDr
0xDC0B4C unk_DC0B4C      db    ? ;               ; DATA XREF: sub_7253FC+6o
0xDC0B5B byte_DC0B5B     db ?                    ; DATA XREF: LoadSnowboard:loc_723263r
0xDC0BDC NeededDisc      db ?                    ; DATA XREF: sub_40414A+2AAr
0xDC0BDE byte_DC0BDE     db ?                    ; DATA XREF: sub_5C6B60+26r
0xDC0BE2 byte_DC0BE2     db ?                    ; DATA XREF: sub_60B2C6+49r
0xDC0BE3 byte_DC0BE3     db ?                    ; DATA XREF: sub_60B2C6+65r
0xDC0BFA byte_DC0BFA     db ?                    ; DATA XREF: sub_60D4F3+18r
0xDC0BFB byte_DC0BFB     db ?                    ; DATA XREF: Field_5B_ADDMAT+83w
0xDC0C39 byte_DC0C39     db ?                    ; DATA XREF: BeginSubMiniGame+1Dr
0xDC0C3A byte_DC0C3A     db ?                    ; DATA XREF: EndSubMiniGame+446w
0xDC0C3B byte_DC0C3B     db ?                    ; DATA XREF: EndSubMiniGame+45Ew
0xDC0C3C byte_DC0C3C     db ?                    ; DATA XREF: sub_7150A0+2Br
0xDC0C3D byte_DC0C3D     db ?                    ; DATA XREF: sub_408027+5r
0xDC0C44 byte_DC0C44     db ?                    ; DATA XREF: ClearMemory+E5w
0xDC0C62 byte_DC0C62     db ?                    ; DATA XREF: sub_766B9F+6Er
0xDC0C90 word_DC0C90     dw ?                    ; DATA XREF: sub_767641+5BBr
0xDC0C92 word_DC0C92     dw ?                    ; DATA XREF: sub_766C7A+154r
0xDC0C94 unk_DC0C94      db    ? ;               ; DATA XREF: sub_766C7A+163o
0xDC0CC4 dword_DC0CC4    dd ?                    ; DATA XREF: sub_766C7A+1C3r
0xDC0CD0 dword_DC0CD0    dd ?                    ; DATA XREF: sub_766C7A+143r
0xDC0CD4 word_DC0CD4     dw ?                    ; DATA XREF: sub_766C7A+96r
0xDC0CD7 byte_DC0CD7     db ?                    ; DATA XREF: sub_766C7A+190r
0xDC0CD8 byte_DC0CD8     db ?                    ; DATA XREF: sub_7674D2+6w
0xDC0CD9 byte_DC0CD9     db ?                    ; DATA XREF: sub_766ECB+5Ew
0xDC0CDA byte_DC0CDA     db ?                    ; DATA XREF: sub_766C6E+5r
0xDC0CDB byte_DC0CDB     db ?                    ; DATA XREF: sub_766ECB+163w
« Last Edit: 2013-10-04 18:57:28 by NFITC1 »

DLPB

  • No life
  • *
  • Posts: 9064
  • Karma: 273
  • For I realized that God's a young man, too.
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #10 on: 2013-10-04 18:42:46 »
It's a bit overdone imho.. making spikes out of trees.  Looks nice, but pretty sure Sep would have just slaughtered it and left it in a heap.  ;D  :P Anyway....  Also way it dies is like a boss.  Be nice if i could also get boss music for it.
« Last Edit: 2013-10-04 18:46:09 by DLPB »

Kaldarasha

  • No life
  • *
  • Posts: 2211
  • Karma: 133
  • Prince of Model Editing
    • View Profile
Re: (FF7) Savemap: where do non field changes come from?
« Reply #11 on: 2013-10-04 19:08:00 »
It is still Jenova who kills the Midgardsormr.  :P
As a side note Sepihroth is designed after it. His front hair symbols the fangs of the snake.