Location ID numbersEdit
These can be derived either from the textures (TIX files on cd) or from the memory by inspecting the current_location variables.
|Location ID||Location name||Japanese|
|00||Bright Moon Cottage||明月荘|
|01||Pit & Temple||寺院|
|03||The Natural World||自然界|
|04||Happy Town||HAPPY TOWN|
|11||Sun Faces Heave||太陽はヒーブ直面|
In the root of the disc is a folder called CDI where all of the game data is stored. jPSXdec can open the CD image file, and another tool that can open .TIM and .TIX files is PSicture 1.01 on Windows 8.1 (64 bit). The .TIX format is unrecognized by PSicture but the files can still be accessed if the file is scanned.
|CARD||The bulk of the user interface assets in TIM format|
|ETC||Non-dream videos, fonts and images.|
|FILM||Dream videos and any "EVENT" videos triggered by interacting with the world such as the ferris wheel or the gear room|
|IMG1,IMG2||The pages of Kanji sometimes seen instead of a dream|
|STGxx||A list of folders called STGxx, where xx is the Location ID. STG is likely a shortening of STAGE, as each STG folder appears to contain data for a specific room or area.|
Also it has a ZDUMMY folder with a ZDUMMY.STR. This was done so that the game data was close to the center of the disc so that loading was quicker.
There are four .TIX files for each location containing the four different texture themes. The textures stored within these files are in the .TIM format.
|File name||Texture theme|
Each STGxx folder has five BGx.SEQ files, ranging from A to E (BGA.SEQ to BGE.SEQ). The SEQ files contain sequenced music (the PSX MIDI equivalent) which can be used together with the VB (sample) and VH (header) files in /CDI/SND/ to compile the tracks. seq2mid can convert the SEQ files into MID files. pSound can extract the VB file content. The mixes can be compiled to PSF using vgmtoolbox which can then be played using Winamp with the in_psf plugin or using foobar with the foo_psf plugin.
These files always begin with a "magic number" of "pQES" followed by "1" as a big-endian value. While the PS1 was little-endian as far as this dreamer knows, the dream journal mentions using a Macintosh, which was big endian, and the tools used to create these scripts were likely on a Mac as a result. 1 could refer to a version number. Note that pQES is SEQp which backs this up.
The .LBD files contain most of the models in the game. The models contained within these files are in .TMD format. They can be extracted with jPSXdec (uncheck raw) and further extracted with PSXMultiRip. Milkshape3D can import .TMD models which can be exported for editing in other modeling programs. LBD could also refer to Level Build Data.
In larger environments these files are split into subfolders called Nx, which in the Natural World, for instance, span all the way from 1-9. The reasoning behind this is unclear, but perhaps it was just to keep the folder structure tidier. Maybe there were file system limitations or the map was split between developers.
One way to understand the underlying game mechanics is to perform memory analysis on an emulator running the game. Once the analyst know about a variable, the variable itself can be monitored for studies. A variable can be modified directly by changing the memory of the emulator process. The game behavior can also be modified if the instructions are changed.
How to analyse the memoryEdit
Cheat engine is a program made for game memory modification. LSD: Dream Emulator running on the emulator pSXfin v1.13 was tested and worked well together with Cheat engine. There is rar file containing a version of Cheat engine without (the potentially unwanted) OpenCandy on their official website download page. Be sure to read the guides available for free on various websites and to try Cheat engine with their demo tool before analyzing the game. Be sure to specify the memory region to scan from the address psxfin.exe+171A5C (2 MB game memory) and 0x200000 steps ahead instead of the entire emulator process memory (around 30 MB).
Before starting Cheat engine, start the emulator application, load the CD image and start a new dream. Once you have run the Cheat engine main application, open the Process List window and select the emulator process.
Locating a days variable
In this example, we will modify the number of days that has passed in the game. This game screen show us that we are on day 110. The game stores this as current_day = 109 with two different 4 Byte variables. Enter 110 - 1 = 109 as Value and press First Scan. Some variables that contains the value 109 will appear in the window to the left. Some of these are unrelated but simply happen to contain the value 109.
Play through a dream and the day will change - along with the dependant variables. Now enter the next current day Value 111 - 1 = 110 in Cheat engine and press Next Scan. This will filter out all variables that are not equal to 110. This is a good thing as they are unrelated.
A finished scan should have two variables that are dependent as we already knew that there were exactly two variables that contains days - 1. These can now be monitored or modified. Try entering Flashback mode. The variables will change indicating which day the Flashback is from. Once your Flashback dream is over, try changing both variables to a high value (more than 365). This has been speculated to trigger more frequent The Gray Man visits.
There are some variables that control textures and some that are affected by The Gray Man if you get too close to him but those are complicated to map. Huge parts of the memory are modified when bouncing into something, linking and with The Gray Man encounters.
The offsets are measured from the beginning of the game memory. The variables are reached by adding the value found at psxfin.exe+171A5C. In Cheat engine, this is done by referring to psxfin.exe+171A5C as a pointer with the specified offset.
DayEditThere are two 4-byte integers that both contain day-1. These can be modified.
|Offset||916B0 & 8AC74 (2 copies)|
You can get and set the amount of time you have spent on a location with this variable. It is stored close to the current_day variable, suggesting that they are used for seeding randomness or that they are key variables. Some memory locations nearby fluctuates a lot. This might suggest that the location is used for randomness. Modifying this does not influence gameplay directly.
Repeatedly setting location_time and game_time to 0 before and during linking is known to have caused a glitch similar to the glitch texture.
|Variable||Speculated: location_time||Speculated: game_time|
|Type||4 Bytes||4 Bytes|
Each location has a unique ID which is the same one as files are indexed (including texture files). Maybe setting the values to 4 (Happy Town) would trigger more The Gray Man visits and setting them to 0 (Bright Moon Cottage) would disable them. They are numbered by the order they change when linking. They keep the same value once linking is done. The value equals one of the location ID numbers. Invariant: 0 ≤ current_location ≤ 13. Changing them during a half-complete linking will corrupt maps and sometimes freeze the game. Changing just 8ABF8 will load just that map's object behaviors, producing strange results.
There is also a starting position variable that can be used to determine where on the location you will start. The value will change when walking the stairs in the Bright Moon Cottage where the four bytes tell you in which direction you walked and which floor (third byte) you are currently on. When exiting a tunnel, this value follows another pattern. If you save one of the correct pos_start values and enter them after linking, you will likely start at that position. It may also give you a strange starting positon.
|Variable||Speculated: current_location||Speculated: pos_start|
|Type||4 Bytes||4 Bytes|
|Offset||91694, 8AC6C & 8ABF8 (3 copies)||9169c|
PositionEditThe x,y and z values are stored separately as signed integers. Modifying them teleports the player. There are some copies which are kept in sync with the main variables.
|Variable||Speculated: x||Speculated: y||Speculated: z|
|Type||4 Bytes signed||4 Bytes signed||4 Bytes signed|
Copies: 91e94 (display),
91dd8 & 91df8
Copies: 91e9c (display),
91de0 & 91e00
Copies: 91e98 (display),
91ddc & 91dfc
These variables are used when the chart is drawn on the screen. chart_draw_x and chart_draw_y are identical 4-byte versions of the mixed 4-byte copy containing chart_return_x and chart_return_y. This suggests that the latter two are taken from a return value. These variables are dynamic and have other meanings in other contexts.
The values are can be calculated as chart_draw_x = steps to the left(-) or the right(+) from the nose * 10 - 5. If we are 2 steps to the left, this gives us chart_draw_x = -25.
|Variable||Speculated: chart_draw_x||Speculated: chart_draw_y||Speculated: chart_return_x||Speculated: chart_return_y|
|Type||4 Bytes signed||4 Bytes signed||2 Bytes signed||2 Bytes signed|
There is an event counter. This increases by one when linking and seems to increase when the player triggers events. This can be used to detect if something happens. There is also a variable that might hold the return value of the finished event. The final two bytes (offsets 91674 and 91675) holds the signed values added to the event_x and event_y respectively. This can be used to decide how the event affected the chart x and y values. x = event_x / events_triggered and y = event_y / events_triggered gives a rough approximation of the final chart x and y values.
|Variable||Speculated: events_triggered||Speculated: event_return||Speculated: animations_triggered|
|Type||4 Bytes||4 Bytes||4 Bytes|
|Variable||Speculated: event_x||Speculated: event_y|
|Type||4 Bytes signed||4 Bytes signed|
Future memory analysisEdit
The texture filenames are stored as text strings. There seems to be pointers to them. They might explain how textures are swapped. Another possibility is that the text strings are only stored by the emulator software.
There are many different music tracks to distinguish from one another. Tracks are level specific. The track number and theme could be identified by comparing the in-game level music with extracted music tracks. Each level and theme identifies a track. The tracks can be identified using combinations such as AMBIENT_STG00_BGA.
The graph changes when the user first modifies the days variables and then enters the graph screen, suggesting that the positions are stored in arrays. Some unknown variables could also be correlated with the x and y positions on the graph screen you see after each dream. The linking screen colors might be correlated to the positions. One problem is that it is unknown how, not just where, those potential variables are stored. They could also be based on calculations with lots of data. It is also hard to know where zero is on the graph and how that should be interpreted.
Objects such as Greyman are dynamically allocated, which makes it difficult to find them. Using saved states, one might go back and forth within the same dream while the object remains at the same place in memory. It is not known how objects are pointed to (pointers) in the memory. The Grayman object, for example, contains its positon and flags to make him fly forward or disable the linking.