Jump to content

Alan Wake 2


michalss

Recommended Posts

On 10/30/2023 at 7:35 PM, Crazy31139 said:

Hi, @AmrShaheen61 and DKDave working on tool, right now, beta version is currently available, maybe it will be useful to someone

https://github.com/amrshaheen61/Alan-Wake-2-RMDTOC-Tool

Yes. I successfully extract bin table with names-values for subtitles with this tool. But how can I extract voice data files with it?

Link to comment
Share on other sites

10 hours ago, Metro33 said:

I have used the provided tool to extract game files. I am able to open texture files with IrfanView, but I am unable to open '.binfbx' files. Would it be possible for someone to assist me?

I wonder if we can use control's binfbx to fbx blender plugin to open this? @DKDave

Link to comment
Share on other sites

 

Can you tell me how vertex indices are encoded?

For example, the file AWSTREAM0\\humans\\alan_brightfalls_noplaid_publish_physx.binfbx.

It looks like the vertices are in the range 0x21d269d - 0x259585d. 32 bytes per vertex, that's 123278 vertices.

The vertex indices (triangles) are located 0x259585d - 0x2786b85. The maximum index is 155357 (more than the number of vertices ???). That is, it seems that the numbering is not continuous, but is different for each submesh.

But where are the boundaries of these submeshes, should the reference points be somehow given in offsets, or in record numbers relative to the beginning of the arrays?

There is also an incomprehensible buffer at 0x20df985 - 0x21d269d, it looks like 10 bytes per write and a small block 0x20df709 - 0x21d269d -maybe these are the submeshes I'm looking for?

Thank you.

 

001.jpg

Edited by erik945
  • Thanks 1
Link to comment
Share on other sites

Hello, I'm trying to extract the big rmdblob files (stream0-generic-xxx.rmdblob, base-generic-xxx.rmdblob) but I keep getting this error:

Spoiler

  offset           filesize   filename
--------------------------------------

Error: incomplete input file 0: E:\QuickBMS\stream0-generic-008.rmdblob
       Can't read 3 bytes from offset 000000002433bda6.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file 0     0%   60         244922770  . offset 000000002433bda6

Last script line before the error or that produced the error:
  34  Get MISC1 Threebyte
  coverage file 0     0%   60         244922770  . offset 000000002433bda6

Am I doing something wrong? The small rmdtoc files extract with no problems. Any help would be appreciated.

Link to comment
Share on other sites

13 hours ago, erik945 said:

 

Can you tell me how vertex indices are encoded?

For example, the file AWSTREAM0\\humans\\alan_brightfalls_noplaid_publish_physx.binfbx.

It looks like the vertices are in the range 0x21d269d - 0x259585d. 32 bytes per vertex, that's 123278 vertices.

The vertex indices (triangles) are located 0x259585d - 0x2786b85. The maximum index is 155357 (more than the number of vertices ???). That is, it seems that the numbering is not continuous, but is different for each submesh.

But where are the boundaries of these submeshes, should the reference points be somehow given in offsets, or in record numbers relative to the beginning of the arrays?

There is also an incomprehensible buffer at 0x20df985 - 0x21d269d, it looks like 10 bytes per write and a small block 0x20df709 - 0x21d269d -maybe these are the submeshes I'm looking for?

Thank you.

 

001.jpg

The max face index value should match up with the total number of vertices.

Note that there are multiple LOD sections for each model, with their own vertex and face sections.  The highest LOD model is near the end of the file.

There is a submesh table for all LODs before all of the vertex data.  Each submesh info block can have different sizes, here's an example from "alan_default_dirty_02_no_satchel_publish_physx.binfbx".  I've highlighted in yellow the start of the first 2 submeshes.  For the first one, you have 0x03, which is the LOD level, 0x68bf which is the total vertex count for this block of data, 0x377 which is the triangle count of this submesh, 0x02 which is the size of each face index entry, followed by 0 which is the starting face for this submesh (first one is always 0, second is 0xa65).  All of the lowest LOD levels are first, up to the highest.  The faces are indexed to the whole vertex buffer, so you only have to read that once.  There are lots of unknown data blocks before the vertex data ...

image.thumb.png.a4da77aecd585626b64f7497b1c56445.png

 

 

  • Thanks 1
Link to comment
Share on other sites

Yes, I just messed with the array offsets. There is the usual continuous numbering without any jokes. Sometimes sleep really clears your brain (especially on the second day of being awake he-he)

 

DKDave - thank you very much for the tip on the table. I’ve just  only manually found the buffers, and the bones are quite clear at the beginning.

alan.png

Edited by erik945
Link to comment
Share on other sites

Counter hint - a large array before of the vertices buffer stores UVs. In my case this code worked (maxscript)

fseek f 0x20df985 #seek_set  
Print ("UV Start @ 0x"+((bit.intAsHex(ftell f))as string))

for i = 1 to vertArray.count do (
    u = ((Readshort f #unsigned) as float)/65535
    v = ((Readshort f #unsigned) as float)/65535
    u1 = ((Readshort f #unsigned) as float)/65535 * 16
    v1 = ((Readshort f #unsigned) as float)/65535 * 16
    append UV_array [u1,-v1 + 1,0]

)

Print ("UV END @ 0x"+((bit.intAsHex(ftell f))as string))



"UV start @ 0x20df985"
"UV end @ 0x21d0c7d"

"vertex start @ 0x21d0c7d"
"vertex end @ 0x259585d"

 

 

What a pair of u and v is is not yet clear. I thought that are other UV channel, but something doesn’t look like it.

alan2.png

Edited by erik945
Use Code Tag next teim
Link to comment
Share on other sites

On 10/30/2023 at 1:35 PM, Crazy31139 said:

Hi, @AmrShaheen61 and DKDave working on tool, right now, beta version is currently available, maybe it will be useful to someone

https://github.com/amrshaheen61/Alan-Wake-2-RMDTOC-Tool

 

On 11/1/2023 at 4:16 PM, DKDave said:

Baesd on my initial observations, it seems like a different format to Control, so it'll need a new script.

 

 

Can you guys check if the Hex for the Pre Order Bonus are in the game files?

It seems that Remedy went with Control route and hid the files for the Ornate Revolver and Survival Resources Pack in the game, and you can unlock them by changing the correct values like they did with the PS4 Pre Order Bonus for control on PC.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...