Comments (14)
If you look at hmt parser, ReadTexture() - there are some skipped/unknown bytes, it could be one of them.
Not sure what you mean by more versatility, but go ahead, if you're more comfortable with C.
If you stumble on something useful, update the file docs and make a pull request?
from rerogue.
I found a solution:
- Take the entry bytes (0x01 0x02 0x03 0x04 0x...)
- 0x01 XOR 0x02 -> first char = L
- 0x02 XOR 0x03 -> second char = V
- 0x03 XOR 0x04 -> third char = N
- etc.
That's the last double char who help me: xor them and you get the famous \0 char!
Edit: The initial char use the last byte of the previous entry. This implies we've to read all the entries, XOR them and do the stuff.
Edit2: For the first entry of the section (who does'nt have initial byte before it), we need to use special "byte-key": 0xF5
Probably an "easter-egg" of Factor5 studio.
Edit3: The five sections correspond to the language (in the order):
- English
- Dutch
- French
- Spanish
- Japanese? Unknown symbol on my computer :/
from rerogue.
Not so bad... ;)
from rerogue.
Good job! :D
from rerogue.
Hi, nobody is actively working on this. There are definitely some texture issues, repeated textures are broken as well, iirc.
from rerogue.
Hi, that's what I thought. What do you mean by repeated textures? Those that are applied on several faces simultaneously?
from rerogue.
No, those that are used as a repeating pattern, even on one face, see world devastator's side windows. Actually I think the issue was that I couldn't find the data that decides if texture should be repeating or clamped (it was quite some time ago, so I don't remember the specifics).
from rerogue.
Okay, thank you, I think it's can be a good tips.
I'm about rewriting some of your code part in C (for a more versatility) and try to complete what can be unknow datas.
I will export all textures datas to hexdump, I think the more datas I have, the more luck I have to extrapolate the functions of each segment.
I can send you my advance through discord (we are on the same server).
from rerogue.
Hi everyone,
I've continued the analysis of the game data, and I am stuck on what seems to be the display of the in-game text (subtitles, mission description, etc.) in _TXT file type.
I can draw a draft of some header information:
LE
Header | (Part_header | entries) * number of parts
Header? (28B):
unsigned short [2B]: number of parts (always 0x05)
unsigned short [2B]: count of entries?
unsigned int [4B]: offset to part 1
unsigned int [4B]: offset to part 2
unsigned int [4B]: offset to part 3
unsigned int [4B]: offset to part 4
unsigned int [4B]: offset to part 5
unsigned int [4B]: file size (or offset to EOF)
Part_header? (xB - first header can be used to estimate the size of part_header):
unsigned short [2B]: offset to the first entry from the start of part_header offset
repeat_for( offset to the first entry / 2B ) {
unsigned short [2B]: offset to the X entry from the start of part_header offset
}
Entries:
ID-flags system/XOR encoded string/???
But the obfuscated string doesn't get me inspiration...
This an exemple of an entry found in the file (front_TXT):
FA B6 E0 AE EF A2 E7 B8 FB CA 95 D9 EB B7 E5 A0 EE AA EF B5 E3 AC F9 AA 8A C5 8B AB E9 A8 FA B1 F9 BC EF A7 A7 8D
I thought, at first, that there could be another system of indices/flags between the "letters" and the fonts located in another directory.
If anyone has an opinion on this...
from rerogue.
front_TXT, this string starts at file offset 210. Changing a single byte changes two characters, so there's some bitpacking or compression going on.
Edit: it's not compression, rather some kind of scrambling: looks like the file starts with strings beginning with '\LVNAME_' (\LVNAME_C1_L1\AMBUSH AT MOS EISLEY etc., I took a look at memory dump), yet bytes of every string are different.
from rerogue.
I came to the same conclusion last night, but thanks for this tip on 0x210 (I had managed to isolate a bigger piece on the DATA.DAT directly on the pause menu), it will save me from having to restart a level each time... I haven't tried to change the memory on the fly yet but I don't know if the game would support it properly.
I've seen that some compression techniques are redundant, where the next data is determined by the previous value(s)... I don't know if the case applies here.
I'll try an empirical approach by testing different bit combinations on a restricted area (0x210 of front_TXT seems perfect to me) and see if there is a way to extract something by deduction.
I'll post the test table if anyone sees anything.
from rerogue.
Note that the string starts before that offset - the right offset is determined by "offset to the X entry from the start of part_header offset" as you found out. However changing the part that contains numbers in LVNAME part causes crashes though, as the game can't find the level name anymore. I also think that the decoded strings are zero terminated - when I modified end of the level name, the next level name was joined into it.
And good luck - I tried modifying the data around that offset in a hex editor, repackaging the files and launching RS a bunch of times, but I wasn't able to figure out what's going on.
from rerogue.
The datas should act as a string tree I suppose... If we change the value in the "path" it's broke the game (no errors handling).
To make test, we need to modify only the ending for comparison.
Maybe if I can find the asm text algo code of RS when it's parse data from file... It can take a long time, and luck yes! Thx for the infos 👍
from rerogue.
Okay okay, I've some inputs datas:
A9 1010 1001 \ | FA 1111 1010 \
E5 1110 0101 L | B6 1011 0110 L
B3 1011 0011 V | E0 1110 0000 V
FD 1111 1101 N | AE 1010 1110 N
BC 1011 1100 A | EF 1110 1111 A
F1 1111 0001 M | A2 1010 0010 M
B4 1011 0100 E | E7 1110 0111 E
EB 1110 1011 _ | B8 1011 1000 _
A8 1010 1000 C | FB 1111 1011 C
99 1001 1001 1 | CA 1100 1010 1
C6 1100 0110 _ | 95 1001 0101 _
8A 1000 1010 L | D9 1101 1001 L
BB 1011 1011 1 | EB 1110 1011 2
E7 1110 0111 \ | B7 1011 0111 \
A6 1010 0110 A | E5 1110 0101 R
EB 1110 1011 M | A0 1010 0000 E
A9 1010 1001 B | EE 1110 1110 N
FC 1111 1100 U | AA 1010 1010 D
AF 1010 1111 S | EF 1110 1111 E
E7 1110 0111 H | B5 1011 0101 Z
C7 1100 0111 | E3 1110 0011 V
86 1000 0110 A | AC 1010 1100 O
D2 1101 0010 T | F9 1111 1001 U
F2 1111 0010 | AA 1010 1010 S
BF 1011 1111 M | 8A 1000 1010
F0 1111 0000 O | C5 1100 0101 O
A3 1010 0011 S | 8B 1000 1011 N
83 1000 0011 | AB 1010 1011
C6 1100 0110 E | E9 1110 1001 B
8F 1000 1111 I | A8 1010 1000 A
DC 1101 1100 S | FA 1111 1010 R
90 1001 0000 L | B1 1011 0001 K
D5 1101 0101 E | F9 1111 1001 H
8C 1000 1100 Y | BC 1011 1100 E
8C 1000 1100 | EF 1110 1111 S
A6 1010 0110 | A7 1111 0111 H
| A7 1111 0111
| 8D 1111 1101
The datas seem aligned with the "entries", header description can be partially confirmed.
I can't found a "null" terminated char or else, but instead I remark that all entries finish with 2x the same byte +/- 1 byte for pading or calcul correction.
Need to investigate more...
I tested different combinaison of bits in the first and second chars of the displayed string in mission selection "BARKESH" (* = means space or empty char). I touch only one byte at a time:
DE -> ** | 9E -> **
DF -> ** | 9F -> **
E0 -> W* | A0 -> EN
E1 -> VA | A1 -> DO
E2 -> UB | A2 -> GL
E3 -> TC | A3 -> FM
E4 -> SD | A4 -> AJ
E5 -> RE | A5 -> *K
E6 -> QF | A6 -> CH
E7 -> PG | A7 -> BI
E8 -> OH | A8 -> MF
E9 -> NI | A9 -> LG
EA -> *J | AA -> OD
EB -> *K | AB -> NE
EC -> *L | AC -> IB
ED -> ZM | AD -> HC
EE -> YN | AE -> K*
EF -> XO | AF -> JA
F0 -> GP | B0 -> U*
F1 -> FQ | B1 -> T_
F2 -> ER | B2 -> W*
F3 -> DS | B3 -> V*
F4 -> CT | B4 -> QZ
F5 -> BU | B5 -> P*
F6 -> AV | B6 -> SX
F7 -> *W | B7 -> RY
F8 -> OX | B8 -> *V
F9 -> NY | B9 -> *W
FA -> MZ | BA -> _T
FB -> L* | BB -> *U
FC -> K* | BC -> YR
FD -> J* | BD -> XS
FE -> I* | BE -> *P
FF -> H_ | BF -> ZQ
I can probably confirm the idea of "linked" bytes, when we change one byte, you change the first letter AND the next one, move the next byte, and repeat...
I'm not sure for now what operation is done exactly to get the "value" of char. It's sure it isn't a compression, the size of string correspond... But why? Security feature against corrupted datas? Maybe an unknown feature to make the font display "great"?
Somthing to try: replace only ONE char in the string...
from rerogue.
Related Issues (8)
- Hello, i'm looking for command to use this discover ... and can it work too for Rogue Squadron 2 and Rogue Squadron 3 on PS2 ?? games are from factor 5 too, and the same struture folder HOT 6
- HOB format: remaining unknown fields HOT 1
- Correct Method of Compiling & Running Documentation? HOT 9
- Speech MORT format codec parsing/decoding HOT 17
- Need help with hmp2obj HOT 10
- Use DAT files directly in all tools HOT 4
- Python bundle (un)pack; opkg files; craft animation/weapons config? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rerogue.