Jump to content

Recommended Posts

Posted

If you have PC version of the game, find the location of the exe of the game and then find the big archive file(s) of this game and then open one up with a hex editor and then make a screencap of it.

  • Like 1
Posted

This is as far as I got with it, after some edits.  The small sample archives were deceptively simple, so I've amended it slightly, still not sure if it works 100% as there seems to be a few extra things in the file table I might need to work out properly.

 

 

aw2.zip

  • Like 4
  • Thanks 1
Posted
5 minutes ago, wssdude said:

Could you upload it to Scripts/Utilities as per this post please? 🙏

As is explained there, you can easily version them and update them there.

Yeah, I can do - just wanted to make sure it works properly first!

  • Like 1
  • Thanks 1
Posted

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?

Posted
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

Posted
12 minutes ago, bladers said:

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

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

 

Posted (edited)

 

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
Posted

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.

Posted

Thanks for the help. I tried it with all the scripts @DKDave posted. (aw2.txt, aw2_v2.txt and Alan_Wake_2_TOC-BLOB.bms) but all of them gave the same error. Are there any other scripts?

Posted (edited)

Why others? Use the script for rmdtoc, it will unpack everything - rmdtoc and the corresponding rmdblob

Edited by erik945
  • Like 1
Posted
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
Posted (edited)

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
Posted (edited)

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
Posted
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.

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...