Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - codemann8

Pages: 1 [2] 3
26
I made a bit of a discovery on my quest to better understand the world map scripts.  Let me first explain about some stuff that is already known and in the wiki as a primer to my later-mentioned discoveries.  I extracted an EV-type file out of Section 4 of the WM0.TXZ file (as described here).  One first thing to note is that it is definitely NOT a copy of the WM0.EV file as the wiki suggests, but I haven't dug into exactly how or what is different about it, this will probably be something I investigate soon.  An EV file contains a call table which is a listing of all the functions/scripts that exist on the world map.

There are 3 types of scripts:
  • a system call - which will be called by various game functions, like when the world map is loaded or every frame tick (likely for things like animations of the water)
  • a model call - which will be scripts that are called by models, like when a model is loaded onto the map (like a Chocobo or the Highwind, etc)
  • a walkmesh call - which is called when your character enters a specific square on the world map

I mostly want to dive into the walkmesh calls, because I've been on a quest to figure out how your character transitions back and forth between the world map and field maps, and I have figured this out.

For each walkmesh call, there is also a set of coordinates attached to it, so it knows to execute only the portion of code that pertains to the area you're in.  The coordinates here are NOT the coordinates on the world map, but instead it is the mesh coordinate.  The world map is divided into exactly 1,008 equal squares (meshes), 28x36 meshes.  So the coordinates here will be 0-27 and 0-35.  Not all meshes have a script associated with it, but a few do.  We'll come back to coordinates later.

I'm looking specifically for code that deals with jumping to field maps, and it just so happens that there is one opcode that handles this, and many of them are called within these Walkmesh calls, the problem is, the opcode takes in two byte-size parameters, call them parameter A and B.  Parameter A is a number that never exceeds 0x40 and the parameter B is either a 0 or 1.  Field map IDs range from 0-768, so this exceeds the possible values that could come from these 2 parameters.  So, what are these numbers?  And how do they eventually reach a field map?

Moving back to the mesh coordinate system, I took the world map image from Black Chocobo and split it into a 28x36 grid.  I then took all the Walkmesh calls that contained a field map jump code and put a letter/symbol up on the world map at the coordinate that the call occurs and I came up with this map:



The first thing you can notice is that all the spots you see marked are all places we all recognize as points of entry into the various towns on the map.  (Note: You'll see that some of them seem to be slightly off, we can definitely attribute this to the world map image from Black Chocobo not being the absolute source of truth, but instead a good guide to point us in the right direction) What I then decided to do was to start with the code that has a parameter A of 1, which is notated on the map as 'M' (Midgar), then the code where parameter A is 2, which is 'J' (Kalm).  I made a list and kept going:

  • M - Midgar
  • J - Kalm
  • U - Chocobo Farm
  • 4 - Mythril Mine (Marsh side)
  • 9 - Mythril Mine (Condor side)
  • # - Fort Condor
  • Y - Junon
  • & - TOTA
  • T - Sleeping Man

Notice a pattern?  It's the same exact list that DynamixDJ posted earlier in this thread, all 64 (or the ones that exist) match up exactly with the WM* field maps.  This is definitely interesting, but still not enough information to land us to how the game gets us to the final destination since the data contained within those WM*.DAT files (which are all identical byte-for-byte) is not enough space to fit all the scripting required to tell the game where to jump to for all 64 cases.  Instead, I took note of all the field map names and Field IDs of where these SHOULD be going, then searching the binary to see if I see those same values anywhere.  Here's the list I started:

  • M - 170 - 0x00AA - Midgar
  • J - 335 - 0x014F - Kalm
  • U - 343 - 0x0157 - Chocobo Farm
  • 4 - 350 - 0x015E - Mythril Mine (Marsh side)
  • 9 - 349 - 0x015D - Mythril Mine (Condor side)
  • # - 353 - 0x0161 - Fort Condor
  • Y - 428 - 0x01AC - Junon
  • & - 600 - 0x258 - TOTA
  • T - 78 - 0x004E - Sleeping Man

I then found the FIELD.TBL file located within the /WORLD/ folder and it starts like this:

Code: [Select]
C7 02 8C F6 10 00 AA 00 84 84 84 84 00 00 00 00 00 00 00 00 00 00 00 00
01 FE B2 FC 77 00 4F 01 74 74 74 74 00 00 00 00 00 00 00 00 00 00 00 00
1E 02 E5 FB 0A 00 57 01 98 98 98 98 EF 04 B9 05 4F 00 57 01 CC CC CC CC
6C 02 CA 02 73 00 5E 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AF 00 08 00 17 00 5D 01 30 30 30 30 00 00 00 00 00 00 00 00 00 00 00 00
0B 00 DF FD 09 00 61 01 80 80 80 80 00 00 00 00 00 00 00 00 00 00 00 00
A9 02 9A 02 1D 00 AC 01 CC CC CC CC 00 00 00 00 00 00 00 00 00 00 00 00
FA 01 59 FA 00 00 58 02 80 80 80 80 00 00 00 00 00 00 00 00 00 00 00 00
02 00 1A 00 03 00 4E 00 80 80 80 80 00 00 00 00 00 00 00 00 00 00 00 00

If you notice, the first line contains 00AA, second line contains 014F, and so on thru the previous list, all of them at offset 0x6.  This file is just the map we are looking for!  When the opcode for jumping to field maps is called, it uses parameter A as what I call a Field Table Id, which is an ID value associated with records in this file.  There are 24 bytes per record.  The only thing left is to figure out what the second parameter B is.  Most of the time it is 0, but sometimes it is a 1.  In the case of the Chocobo Farm, the code looks like this:

Code: [Select]
Walkmesh(16, 29).FunctionType(4)
IF ((((GetSpecial(0008) == #0000) || (GetSpecial(0008) == #0001)) || (GetSpecial(0008) == #0002))) {
  IF (Bank0[007d].Bit(0)) {
    EnterFieldScene(#0003, #0001)
    GOTO Label 1
  }
  EnterFieldScene(#0003, #0000)
Label 1:
  GOTO Label 2
}
IF ((GetSpecial(0008) == #0013)) {
  WRITE Bank0[007e].Bit(0) = #0000
  WRITE Bank0[007e].Bit(2) = #0000
  WRITE Bank0[007e].Bit(3) = #0000
  WRITE Bank0[007e].Bit(4) = #0000
  WRITE Bank0[007e].Bit(5) = #0000
  WRITE Bank0[007e].Bit(6) = #0000
  WRITE Bank0[007e].Bit(1) = #0000
  WRITE Bank0[007c] = #0000
  IF (Bank0[007d].Bit(0)) {
    EnterFieldScene(#0003, #0001)
    GOTO Label 2
  }
  EnterFieldScene(#0003, #0000)
}
Label 2:
RETURN

Most of this you can ignore, but note the two possible ways to jump to the field map, notice one has a parameter B of 0, and the other 1.  Parameter B indicates whether an alternate scenario should occur.  If we look back at the 3rd record of the FIELD.TBL file, you'll notice that the second half of the bytes aren't zero like some of the other records.  That is because these records can be split into 2 12-byte pieces, each containing a potentially different Field ID to jump to, in this case it's the same.  What's interesting in the Chocobo Farm case, is that the first time we enter the farm, we enter from the bottom of the screen, while subsequent times we enter from the right side.  This FIELD.TBL file is how it handles that.  I'm not exactly sure how, but somewhere in the remaining 10 bytes of each scenario are the coordinates that the character should begin on.  An example of one area potentially leading to a completely different field map is North Corel.  This ONLY happens if you fail to stop the train during your mission there, you instead are transported to a map that has the crashed train in it.

And there you have it, the mystery of transporting from the WM to a field map is solved. And all my findings have already been added to the wiki.

For those curious: I've made a list of all possible field maps that can lead to the world map (left side of the wm field), and all the ways you can get back to a field map (right side of the wm field), sorry for the formatting:

Code: [Select]
fromMapId name menuText fieldTableId wmField toMapId name menuText
NULL NULL NULL 1 wm0 170 mds5_5 Slum Outskirts
170 mds5_5 Slum Outskirts 1 wm0 170 mds5_5 Slum Outskirts
335 elm Kalm 2 wm1 335 elm Kalm
345 frcyo Chocobo Ranch 3 wm2 343 farm Chocobo farm
343 farm Chocobo farm 3 wm2 343 farm Chocobo farm
350 psdun_2 Mythril Mine 4 wm3 350 psdun_2 Mythril Mine
349 psdun_1 Mythril Mine 5 wm4 349 psdun_1 Mythril Mine
353 condor1 Base of Fort Condor 6 wm5 353 condor1 Base of Fort Condor
370 junonl1 Lower Junon 7 wm6 428 ujunon1 Under Junon
428 ujunon1 Under Junon 7 wm6 428 ujunon1 Under Junon
600 jtempl Temple of the Ancients 8 wm7 600 jtempl Temple of the Ancients
78 zz1 Old man's house 9 wm8 78 zz1 Old man's house
79 zz2 Weapon seller A wm9 79 zz2 Weapon seller
712 itown1a Mideel B wm10 712 itown1a Mideel
712 itown1a Mideel B wm10 714 itown1b Mideel
713 itown12 Mideel B wm10 712 itown1a Mideel
713 itown12 Mideel B wm10 714 itown1b Mideel
714 itown1b Mideel B wm10 712 itown1a Mideel
714 itown1b Mideel B wm10 714 itown1b Mideel
84 zz7 Materia Cave C wm11 84 zz7 Materia Cave
443 del2 Costa del Sol D wm12 443 del2 Costa del Sol
458 mtcrl_0 Mt. Corel E wm13 458 mtcrl_0 Mt. Corel
450 ncorel North Corel F wm14 450 ncorel North Corel
450 ncorel North Corel F wm14 451 ncorel2 North Corel
451 ncorel2 North Corel F wm14 450 ncorel North Corel
451 ncorel2 North Corel F wm14 451 ncorel2 North Corel
452 ncorel3 North Corel F wm14 450 ncorel North Corel
452 ncorel3 North Corel F wm14 451 ncorel2 North Corel
481 desert1 10 wm15 482 desert2 Corel Desert
482 desert2 Corel Desert 10 wm15 482 desert2 Corel Desert
512 crcin_2 Waiting Room 10 wm15 482 desert2 Corel Desert
518 gongaga Gongaga Village 11 wm16 515 gonjun2 Jungle
514 gonjun1 Jungle 11 wm16 515 gonjun2 Jungle
515 gonjun2 Jungle 11 wm16 515 gonjun2 Jungle
525 cos_btm Cosmo Canyon 12 wm17 525 cos_btm Cosmo Canyon
284 nivl_3 Nibelheim 13 wm18 284 nivl_3 Nibelheim
285 nivl_4 13 wm18 284 nivl_3 Nibelheim
551 rckt2 Rocket Town 14 wm19 551 rckt2 Rocket Town
551 rckt2 Rocket Town 14 wm19 557 rckt Rocket Town
557 rckt Rocket Town 14 wm19 551 rckt2 Rocket Town
557 rckt Rocket Town 14 wm19 557 rckt Rocket Town
81 zz4 Lucrecia's Cave 15 wm20 81 zz4 Lucrecia's Cave
83 zz6 Materia Cave 16 wm21 83 zz6 Materia Cave
574 yougan3 Plains 17 wm22 574 yougan3 Plains
574 yougan3 Plains 17 wm22 579 uutai1 Wutai
581 yufy1 Yuffie's House 17 wm22 574 yougan3 Plains
581 yufy1 Yuffie's House 17 wm22 579 uutai1 Wutai
579 uutai1 Wutai 17 wm22 574 yougan3 Plains
579 uutai1 Wutai 17 wm22 579 uutai1 Wutai
82 zz5 Materia Cave 18 wm23 82 zz5 Materia Cave
617 bonevil Bone Village 19 wm24 617 bonevil Bone Village
629 sandun_2 Corral Valley Cave 1A wm25 629 sandun_2 Corral Valley Cave
654 snow Icicle Inn 1B wm26 654 snow Icicle Inn
80 zz3 Mystery House 1C wm27 80 zz3 Mystery House
85 zz8 Materia Cave 1D wm28 85 zz8 Materia Cave
NULL NULL NULL 1E wm29 425 semkin_5 Underwater Reactor
88 q_1 Hallway 1F wm30 88 q_1 Hallway
348 sichi Marshes 20 wm31 348 sichi Marshes
573 yougan2 Plains 21 wm32 573 yougan2 Plains
572 yougan Wilderness 22 wm33 572 yougan Wilderness
NULL NULL NULL 23 wm34 572 yougan Wilderness
382 jundoc1a Junon Dock 24 wm35 439 shpin_2 Cargo Ship
440 shpin_3 Cargo Ship 25 wm36 441 del1 Costa del Sol Harbor
382 jundoc1a Junon Dock 26 wm37 441 del1 Costa del Sol Harbor
429 ujunon2 Dolphin Offing 26 wm37 441 del1 Costa del Sol Harbor
441 del1 Costa del Sol Harbor 27 wm38 382 jundoc1a Junon Dock
86 sea 28 wm39 NULL NULL NULL
70 fship_23 Highwind 29 wm40 NULL NULL NULL
406 subin_1b Submarine Bridge 2A wm41 NULL NULL NULL
284 nivl_3 Nibelheim 2B wm42 284 nivl_3 Nibelheim
285 nivl_4 2B wm42 284 nivl_3 Nibelheim
311 mtnvl2 Mt. Nibel 2C wm43 311 mtnvl2 Mt. Nibel
70 fship_23 Highwind 2D wm44 NULL NULL NULL
71 fship_24 Bridge 2D wm44 NULL NULL NULL
72 fship_25 Highwind 2D wm44 NULL NULL NULL
313 mtnvl4 Mt. Nibel 2E wm45 313 mtnvl4 Mt. Nibel
NULL NULL NULL 2F wm46 654 snow Icicle Inn
658 hyou1 30 wm47 658 hyou1
662 icedun_2 Frostbite Cave 30 wm47 658 hyou1
NULL NULL NULL 31 wm48 NULL NULL NULL
NULL NULL NULL 32 wm49 70 fship_23 Highwind
NULL NULL NULL 32 wm49 72 fship_25 Highwind
NULL NULL NULL 33 wm50 72 fship_25 Highwind
NULL NULL NULL 34 wm51 71 fship_24 Bridge
NULL NULL NULL 35 wm52 347 fr_e
405 subin_1a 36 wm53 NULL NULL NULL
622 anfrst_3 Ancient Forest 37 wm54 622 anfrst_3 Ancient Forest
624 anfrst_5 Ancient Forest 37 wm54 622 anfrst_3 Ancient Forest
405 subin_1a 38 wm55 405 subin_1a
405 subin_1a 38 wm55 406 subin_1b Submarine Bridge
406 subin_1b Submarine Bridge 38 wm55 405 subin_1a
406 subin_1b Submarine Bridge 38 wm55 406 subin_1b Submarine Bridge
626 sango2 Corral Valley 39 wm56 626 sango2 Corral Valley
630 lost1 Forgotten Capital 3A wm57 630 lost1 Forgotten Capital
NULL NULL NULL 3B wm58 744 las0_1 Highwind, On deck
686 gaiafoot Base of Gaea's Cliff 3C wm59 686 gaiafoot Base of Gaea's Cliff
670 move_s 3D wm60 670 move_s
670 move_s 3E wm61 670 move_s
670 move_s 3F wm62 670 move_s
682 hyou12 40 wm63 682 hyou12

Another discovery I found was that of the Model calls (as described near the top of this post), some of the Model IDs are already known, such as Cloud being ID = 0, Tifa = 1, Cid = 2, Highwind = 11, etc.  Basically all 3D models used on the WM have an ID.  Previously ID 8 was unknown, but I found that to be the Cargo Ship as there is a Model script for ID 8 that deals with all 4 field map jumps pertaining to the Cargo Ship transports.

Thru similar reverse engineering, we can see that wm52 and fr_e are used for the Diamond Weapon battle and the dialogue that follows.  This also illuminates another unknown Model ID, which Diamond Weapon is ID 10.

Another area of interest is wm32 is where Yuffie Encounters end up after the battle. wm34 is where Yuffie betrays your team on the southern part of the western continent.

What I don't know is how the game knows which coordinates on the world map to drop the character when entering the WM from a particular town.  For the sake of my current project, finding that is out of scope for now, but possibly something I may dive into later.

27
Do you know who I can ask what the specific rules are? Knowing those are going to be essential in my tasks ahead.

28
I'm looking forward to understanding more after your video.  However, as I'm trying to quick get a working method of ignoring unused scripts, I need a little bit more to get started.  In MR, the different groups/entities have a "Type" and the scripts seem to have differ, based on the first opcode in Script 0.  The pseudocode logic is this:
Code: [Select]
switch(opcode) {
case Opcode::PC:
type = Model;
_character = charID;
return;
case Opcode::CHAR:
type = Model;
_character = 0xFF;
break;
case Opcode::LINE:
if(_character==-1) type = Location;
return;
case Opcode::BGPDH:
case Opcode::BGSCR:
case Opcode::BGON:
case Opcode::BGOFF:
case Opcode::BGROL:
case Opcode::BGROL2:
case Opcode::BGCLR:
if(_character==-1) type = Animation;
return;
case Opcode::MPNAM:
if(_character==-1) type = Main;
return;
default:
break;
}

And based on what type each group/entity is, the different scripts are given labels:
Code: [Select]
if (type == Model) {
Script 2 = "S1 - Talk";
Script 3 = "S2 - Contact";
}

if (type = Location) {
Script 2 = "S1 - [OK]";
Script 3 = "S2 - Move";
Script 4 = "S3 - Move";
Script 5 = "S4 - Go";
Script 6 = "S5 - Go 1x";
Script 7 = "S6 - Go away";
}

So, getting to the point: I know the all Script 0s and 1s execute (assuming they don't get shortcutted based on Jumps) on their own and those two scripts can execute other scripts in other entities.  However, I'm assuming that the Location type scripts (the ones that create lines in their first opcode) also execute scripts on their own (probably when your character crosses a threshold).  My question is, which ones execute specifically? Are there any other scripts that are also executed by other external forces?

I'm basically trying to weed out unused scripts, but first I need to know ALL the ways these scripts can be invoked.  If you know this, it would help out a lot.

29
Oh, so you're working on a video that soon then? Sweet!

Interesting tho, so without a stack how does it keep track of calls? Or does it just have the callee (is that a word) track it's execution while the caller continues it's own execution?  If so, how does it know that Script 1 hasn't executed yet if the IP changes on the callee?  Or maybe I'm interchanging the terms stack pointer and frame pointer inappropriately, and it uses a frame pointer? But it sounds like not. Sorry, it's been awhile since I briefly studied low level language in college, although I am a coder by trade.

30
Great post! I think a video would be great! When you say soon, how soon? Lol, reason I ask, is I'm looking to move forward on some things and wondering if it's worth waiting for that so I better understand it before writing logic around it.

So, if I understand this correctly. When a field is loaded, all groups will one by one execute their Script 0 in order sequentially. After all have been run, with each of the IPs (instruction pointer) are set on start of each Script 1 (since Script 0 and 1 are actually the same script just with a RETURN to indicate a pause in execution while the IP increments, clever way to handle that), the Script 1s start executing each group's Line 1 in sequential order, then Line 2, and so on. But every 8 instructions will advance the next frame.  But each group will have it's own context (stack and IP).  Anything missing or wrong?  I'm guessing so since there was mention of if a Script 1 hasn't begun executing on a certain group and there is a call to that same group's Script >1, it will execute the script and then follow it up with Script 1, but how can that be if there is only one IP, or is it technically the caller's IP?  If so, how does it handle ASync calls?  And also, it seems like that would be an extremely rare case since all Script 1s seem to execute relatively at the same time, the execute call would have to come very early, like the first line.

Also, I'm not sure how models are tied in with groups, and if there's any special rules or things that only apply to models when running scripts.

31
Are field scripts only called from within, or can things invoke from the outside? Is it that every script group calls its init (script 0) and its main (script 1)? Or a subset of the script groups, if so which ones? I'd imagine that ordering matters too, as a map jump could occur before it executes the rest of the scripts. To further complicate things, I also assume things run in parallel too, as multiple models need to animate at the same time.

32
There may be false positives in the results, as there may be unused scripts. But lastmap must either have a map jump defined in a script that's never invoked or a walkmesh trigger gateway that's impossible to reach.

Anyone have an idea how I can determine if a script will never be run? That would help narrow down on a more truthful graph.

33
For those who like this sort of thing, I created a graph of the maps of maps thing I was talking about.  I thought it was interesting to share.  Sorry for the overlapping, I didn't have a whole lot of control over the placement of the nodes, but also, there's just a sheer number of entry/exit points everywhere, particularly Gold Saucer (in yellow) and Great Glacier (in blue).  The Northern Crater (in green) I thought was interesting cuz you can actually see the left/right path.  Also, the black dot is the train station when you first start the game.

Link to larger version


34
I've read about the PSP method as well, Codemann... Is there a special version or generation of psp I would need? I'm not too familiar with them.  Will the file that it creates play on PS3? If nothing else works, I'll definitely try this :S
I just bought the cheapest one I could find, all of them operate on the same firmware so it'll work on all.  A little research into the comparison of specs will help you figure out which one you like better.  And yes, how it works, you play primarily on the PS3, transfer the save onto the PSP, following the steps on the guide, then open the save file with the game on the PSP, save the file into the other slot but in the same spot (as it will overwrite the save in that spot, thinking ahead to when you move it to the PS3), then transfer it to the PS3, you can then resume playing.

35
I was browsing around and found this little topic from August 2018, fairly recently.  It seems someone found a way to extract content out of PSX SCUS executables and has the potential to repackage a new one with mods, although, that's still at the pioneer stage.  I thought the topic was interesting.

36
I could always find the names of fields, it was always the IDs I had a hard time finding. Which is how fields are referenced inside the scripts.

But also, as far as specific coordinates, if I happen to find them, it'd be cool, but that's really just a "nice to have" at this point.

My current goal is to build a full "map of maps" (think graph theory, or Google maps) and be able to divide it into subsections and display the enemies for a general area (specific point in the game) along with attaching sections of a walkthrough to each subsection.

37
@DynamixDJ Do you know which TFerg guide mentions Yuffie Encounters? I looked thru all his guides, I don't seem to see any part mentioning Yuffie/Mystery Ninja. Looking at his findings may narrow my search in the end.

38
For future reference, if anyone else is searching for this, regarding the IDs of field maps:

Per Myster6, the field IDs are in order as they are arranged physically on the game disc, although IDs 1-64 are reserved for 64 dummy field maps (wm0, etc) that are used as entry points to the world map (for example, when you leave a city, a "world field map" is used as a placeholder to transport your character to a certain coordinates on the world map, usually on the south side of a city), then ID 65 and on are the rest of the fields.

I can only assume that the PC version defines this somehow thru the flevel.lgp file, albeit with many of the unused fields missing. And I believe ID 0 is the black background dummy field.

39
If anyone is curious, per Myster6, the field IDs are in order as they are arranged physically on the game disc, although IDs 1-64 are reserved for 64 dummy field maps that are used as entry points to the world map (for example, when you leave a city, a "world field map" is used as a placeholder to transport your character to a certain coordinates on the world map, usually on the south side of a city), then ID 65 and on are the rest of the fields.

I can only assume that the PC version defines this somehow thru the flevel.lgp file, albeit with many of the unused fields missing. And I believe ID 0 is the black background dummy field.

40
But PSX doesn't have an executable, just a bunch of assembly/scripts scattered everywhere, right?

41
I believe all Yuffie encounters are hardcoded into scripts, versus defined in all the other fixed encounter data, but I have yet to find it, this is among the things I'm definitely looking for.

Very interesting about the WM fields, that makes perfect sense, and thank you, that info will help me reverse engineer this.  I do still wonder why they needed to have all 64 DAT files in the directory, when they are all the same, probably just a lazy approach.  But now it makes me all that more curious as to what's actually in those DATs.

You wouldn't happen to know where those corresponding x,y,z values are stored, do you? My first guess is within those DATS and then the scripts also in the DAT to transport you to the xyz location.

42
I did read that wm0 is the overworld, wm1 is underworld, wm2 is the snowfield, however, in the FIELD folder, there are 64 WMx.DAT files (where x is replaced by a number 0-63) and all 64 files have identical contents, seems wasteful to me but also serves to stump me as to what's actually in there. But it's also not the same structure as the other field maps, so it still remains a mystery to me. There's also a WORLD folder which probably is where I'm supposed to be looking.

I do know that the lgp files made for the PC are simply repackaged archives that contain what would show up as multiple files under PSX. Perhaps if I knew more about all the things that CAN be found and what's still a mystery within world_us.lgp, perhaps that could help.

I will also definitely reach out to green_goblin as well.

43
I basically had the same questions you did. And basically wanted to accomplish the same thing you are, see above.  I landed on buying a PSP for cheap on eBay and using the method described in the FAQ here. It doesn't involve a modding method that is permanent, so you can sell your PSP or safely do it on someone's PSP that you know.  It's the best known way to mod a save file and continue playing on the PS3 without too much hassle.

44
This was meant to be a PM to DLPB, but it seems he has PMs disabled.

I noticed a couple forums he was involved in (ha, I know that narrows it down, right?) involving world map data, so I'm guessing he the's the right person to ask.

So, I'm working on a project that will take a walkthrough and split it into small sections (as it's kinda already done, by different parts of the story) but will basically attach all the field map IDs associated with that part of the walkthru and then display all the enemies that can be encountered during that specific portion.  All that is great, but things get a bit trickier when involving the world map.  Basically for field maps, I have a "map of maps", linking all the maps to the ones that can be accessed from (by walking off the screen to another).  I want to extend this to how field maps will transfer you to the world map (and vice-versa) and also how areas of the world map lead to other areas (ie. walking from Midgar Area Dirt to Midgar Area Grass) and continue my map of maps so it includes world map areas.  Another complication is the restrictive nature of some areas, like areas only the buggy can penetrate, but I want to consider those scenarios as my walkthru project will consider GameMoment to determine things like if you have the Buggy or Highwind (can jump from Grass to Grass areas) or Gold Chocobo is possible (after you have Tifa as your main party member, then can jump from any world encounter area to any other, although to cut down on the verbose-ness of the possible enemies you can encounter, it will only show the new ones you couldn't encounter prior).  Hopefully you're catching my drift.

A foreword tho: I know that there's a world_us.lgp file for PC, but I do not have this file.  I'm working with original PSX files, so if you know where to look there, that would help.

In a nutshell, I'm missing 2 things:
1) Where world map encounter rates/battle IDs are stored on PSX (I'm surprised none of this is on the Wiki, not even the world_us.lgp structure)
2) Where the scripting is located for world map areas, similar to how field maps have scripts to jump to another map when crossing a walkmesh threshold, I assume the world map has similar scripts to change the encounter rates at the point of crossing a threshold.

Hopefully someone can help point me in the right direction. As long as I know I should be working with a specific file, I should be good to get started, I am quite good as analyzing binary data structures.  Problem is, I'm spending so much time deciphering files just to realize it's not the right file.

45
I took a backup of the text file from 2 posts ago, since he said the link will expire this month.  Just hit me up if you want it.  This is great work happening in this thread, I'd hate to see progress fall short due to an expired link.

46
Yes, I checked the Wiki and the file structure doesn't have any mention of field ID.  After digging into MR's source code, I found that these IDs are actually hard-coded, versus obtained from any files.  I'm wondering if anyone knows where this can actually be found within the game's data.

47
Hi NFITC, you mention a 1.5.0 version but I don't see any links to it anywhere.  Also, are you planning on releasing the source at all?

48
I've got a question.  I'm working on a project involving extract field map names and their IDs.  Does anyone know where this is stored in the files?  Keep in mind I'm using original PSX data contents and not the Steam flevel.lgp file.

I've looked thru MR's source code and can't seem to find how it finds this.  In fact, I'm opening the PSX Disc ISO in MR.  It's clear the information displayed in MR sources from the individual field DAT files (also MIM and BSX) but the DAT files don't store the IDs so it means there must be something outside those files that it uses, but unclear which file that is. Any help here would be appreciated.

49
Hmm, that was odd, I did use the Continuous build yesterday along with a few other versions, it must've not all exported from the zip correctly.  But I have successfully opened my save file, so thank you very much.  However, upon making the necessary modifications, I am attempting to save the changes to overwrite the PSV file and there was a mention of a PS3 key and seed.  I did notice this in the options yesterday when I was playing around with the program.  I'm guessing it needs this to compute some sort of checksum in the PSV structure header.  I determined that when I made hex changes directly with another hex editor but my PS3 then recognizes the modified save file as corrupted data.  My question is, how do I know what the key and seed should be?  And is this possible to save off a valid "uncorrupted" modified save file that I can transfer back to my PS3?

As for the PS3 key and seed: I clicked the links on the program and they led to pages that didn't make any sense to me.  Seems like a reference sheet for something, but not much description as to what it should mean to me.

I also found this topic, but the links on ps3devwiki.com lead all seem to redirect me to dell.com or clickconfirmation.com

Also, my PS3 is version 4.82

50
Someone was having an issue with opening PS3 saves in BlackChocobo where the program just crashes after opening.  You replied below...
Please check that you have the newest version of black chocobo. Your saves work here correctly and i was able to import the all into one file with out issue. I cna't make you a steam folder you ahve to do that yoru self.

first open black chocobo then use file->import to current slot . and pick your first psv file.
then hit alt + right (move slot #2) and import your next psv
do the same for how ever many psv files your have
Save as PC format. save it whereever
then use file-> create cloud save folder . select your save path . it should pick out your id for you (its the numbers after user_ in your save path) then for file 1 select the pc file you just made.

I'm having the same issue but following your steps does not stop the program from crashing.  I've uploaded my saves to DropBox

The particular one I'm trying to modify is the SAVE06, which is the one ending in 6 I believe.

My goal is not to convert to Steam like the last person.  I'm trying to modify a PS3 save file and move it back to the PS3.

Pages: 1 [2] 3