Will O Wisp Portable - MCE - Discussion board

[ New messages · Members · Forum rules · Search · RSS ]

Page 1 of 1
1

Will O Wisp Portable

ムギ

Date: Thursday, 2013-05-09, 1:47 PM | Message # 1

Rank: Nerdy Presence

Messages: 203

Reputation: 2

Status: Offline

*.uni general Filestructure
(\PSP_GAME\USRDIR\UNION\)

File consists of 3 parts
1) UNI2 Header
2) Address Table
3) Data

container is aligned to 2048 bytes, uses sector addressing.
1 sector = 2048 bytes / 0x800 [hex]

example file: \PSP_GAME\USRDIR\UNION\SUB.UNI

Quote ( Header)

0x00: 554E 4932 0000 0100 0500 0000 0100 0000
0x10: 0200 0000 0000 0000 0000 0000 0000 0000
0x20: 0000 0000 0000 0000 0000 0000 0000 0000

0x00: UNI2 Signature (it's always 554E 4932)
0x04: unknown value
0x08: number of files (hex) (5 files in this case)
0x0C: Sector Address of Table file (1 in this case) (0x800)
0x20: Sector Address of Data Start (2 in this case) (0x1000)

Unknown values seem to be static regardless of size/number of files.

Quote ( Address Table)

0x800: 0500 0000 0000 0000 0100 0000 3000 0000
0x810: 1E00 0000 0100 0000 0400 0000 3018 0000
0x820: 3200 0000 0500 0000 0100 0000 A002 0000
0x830: 3300 0000 0600 0000 0100 0000 7001 0000
0x840: 3C00 0000 0700 0000 0100 0000 9002 0000
0x850: 0000 0000 0000 0000 0000 0000 0000 0000
0x860: 0000 0000 0000 0000 0000 0000 0000 0000

Each File entry is 16 bytes, below pattern repeats for number of files decribed at 0x08 in UNI2 header.

0x800: unknown value
0x804: Sector Start Address !!
0x808: Sector Size
0x80C: File Size in bytes (hex)

!! Sector start Address is relative to data start (in the case of example file, 0x1000)

Attachments: 1905509.png (152.0 Kb)

ムギ

Date: Thursday, 2013-05-09, 2:50 PM | Message # 2

Rank: Nerdy Presence

Messages: 203

Reputation: 2

Status: Offline

sysfile.bin structure.
(\PSP_GAME\USRDIR\SAVEDATA\)

This container holds the save icons.

consists of 2 parts:
1) header.
2) data.

header size is 36 bytes (0x24)
data starts at 0x24

Quote (Header)

0x00: 0100 0100 0000 0000 D55C 0000 D55C 0000
0x10: 0000 0000 D55C 0000 7126 0200 4683 0200
0x20: 0000 0000 |||||||||||||||||||||||||||||||||||||||

0x00: File Signature (0100 0100)
0x04: First file start address !
0x08: First File Length
0x0c: First File End Address !
0x10: Blank value (always 0000 0000)
0x14: second File start Address !
0x18: Second File Length
0x1c: Second File End Address !
0x20: Blank value (always 0000 0000)

! the addresses are relative to data start (0x24)

Attachments: 7685355.png (137.6 Kb) · 6747798.png (23.2 Kb)

ムギ

Date: Saturday, 2013-05-11, 11:25 PM | Message # 3

Rank: Nerdy Presence

Messages: 203

Reputation: 2

Status: Offline

STCM2 FILE MAKE BY MINKU 07.0
General Structure

After an antagonizing moment with my hex editor, i made it work and here it is:

the file consists of 4 parts:

1) Header
2) GLOBAL_DATA
3) DATA_START
4) memory management code

note: im using 7th file of script.uni as an example.
this file is the prologue chapter script.

Quote (Header)

0x00: 5354 434D 3220 4669 6C65 204D 616B 6520
0x10: 4279 204D 696E 6B75 2030 372E 3000 0000
0x20: A44A 0100 0D00 0000 0000 0000 0000 0000

0x00: file signature (0x1D in length)
0x20: Address of memory_init
0x24: Unknown value

GLOBAL_DATA starts at 0x50 and it's size varies depending on the filesize.
i'll just be honest and say that i have no clue what the GLOBAL_DATA is used for,
however, it is not necessary to edit it.

CODE_START is the main data of this filetype, it contains all the events and dialogues of a chapter.

the CODE_START works by reading blocks of data defined in the block itself.
there's tons of values i dont know actual meaning for, so i will only describe the necessary ones to
make the file work.

-------------------------------------

0x1D0: Signature (CODE_START)
0x1E0: Unknown value
0x1E4: Unknown value
0x1E8: Block Size

the file works by reading a designated amount of bytes at once (one block)
the first 4 bytes of a block describe the amount of bytes to be read.
at 0x1E8 a value of 44 is written, meaning that the first block is 44 bytes in length.

from 0x1E8 reading 44 bytes ends up to 0x22C, where a value of 40 is written.
meaning the second block is 40 bytes in length.
the file works by reading blocks in sequence and even if you do make a mistake editing it, it will work all the way until it runs into an error.
the contents of the data blocks are not relevant at this point.

the actual dialoque data is a little more complicated.

-------------------------------------

0x148C0: block length
0x148C4: Event start address !
0x148DC: Length of text string !!
0x148E0: Text string !!!
0x1490C: 4 Null bytes (0000 0000)
0x14910: Unknown value
0x14914: Unknown value

0x14918: Block length (58 bytes was read from 0x148C0, so a new block starts here)
0x1491C: Event start address
0x14934: Length of text string
0x14938: Text string
0x14954: 4 Null bytes (0000 0000)

0x14960: Block length !!!!
0x14968: Unknown value
0x1496C: Unknown value

0x14970: Block start (10 bytes was read from 0x14960, so a new block starts here)
0x14974: Event start address
0x14998: Length of text string !!!!!

0x149B0: Block start (40 bytes was read from 0x14970, so a new block starts here)
...
...

This pattern repeats throughout the whole file until EXPORT_DATA command is reached.
unfortunately editing it is very time consuming unless a file parser is written.

it's necessary to patch blocksize, event start address and string length for each block that is altered.

! the dialogue has a 16-bytes long subheader that consists of 3 unknown values and the string length
- only string length needs to be modified

!! This can be anything, and can be padded with zeroes

!!! Starts the visible text string and is always followed by 4 null bytes after it's designated length

!!!! there are many blocks in the data that are 0x10 in length and do not need to be modified in any way,
--- as they dont contain any addresses, just control data.

!!!!! in this case the "text string" is not and actual visible line of dialogue, but instead a command parameter
---- "switch". These handle the baground, character graphics, BGM, and everything else on the screen.

-------------------------------------

The memory management code consists of blocks of 0x28 in lenght and always contains atleast the following:

memory_init
memory_exit
cm_play_event
cm_play_presentation
savegp_set
sure1

a variable amount of "sure" parameters also exist, how many there are, depends on the file.

0x14AA4: memory_init
0x14AC8: Address of memory_init

0x14ACC: memory_exit
0x14AF0: Address of memory_exit

0x14AF04: cm_play_event
0x14B18: Address of cm_play_event

0x14B1C: cm_play_presentation
0x14B40: Address of cm_play_presentation

0x14B44: savegp_set
0x14B68: Address of savegp_set

0x14B7C: sure1
0x14B90: Address of sure1
..
..

This example file contains 8 "sure" values but im only listing one, the remaining work just the same.

each block in memory management starts with 4 null bytes (0000 0000)
followed by the parameter name and ends with an address to said parameter
The addresses these parameters point at are seemingly null. However it is essential to patch the
values to point in their exact locations or the file will not work and crashes the game.

quick test for a proof of concept:

Attachments: 4888619.png (5.1 Kb) · 1288639.png (11.1 Kb) · 5682886.png (16.1 Kb)

ムギ

Date: Tuesday, 2013-05-14, 10:05 PM | Message # 4

Rank: Nerdy Presence

Messages: 203

Reputation: 2

Status: Offline

reserved for graphics format diagnostics

Will O Wisp Portable

Page 1 of 1
1