Star Wars - The Old Republic - Beta

[TRDaz]

Well, that's weird... I extracted that whole tor file and got nothing, even extracting the textures/gr2 alone and I still got nothing... maybe I did something wrong? :/

EDIT: Nevermind, re-tested, randomly works now lol. Thanks for checking though

[luke9511]

just thought i would post and say so far everything is working great but like someone else said alot of textures dont get extracted so alot of models are missing sometimes one or two textures or all of them and some models wont load in the noesis viewer it pops up with an error but thats for a different thread

[swtor miner]

just thought i would post and say so far everything is working great but like someone else said alot of textures dont get extracted so alot of models are missing sometimes one or two textures or all of them and some models wont load in the noesis viewer it pops up with an error but thats for a different thread

This is something that I'm working on. Unfortunately none of my code is quite ready for you guys just yet.

I also discovered (at least haven't seen it posted anywhere) how the game stores the heightmap for areas. In the Room Specification .dat files the heightmap is stored in the .VertexData property as a zlib compressed hex string in one of two encodings.

If it starts with "78 9C" it's a regular zlib stream. If it starts with "1F 8B" it's compressed with gzip encoding. Here's a small piece of the uncompressed data to look at:

Code: Select all

00000000h: 09 40 00 00 00 40 00 00 00 33 33 33 41 9E EF A9 ; .@[email protected]žï©
00000010h: 40 CD CC E2 42 00 D0 44 90 3F 1C C9 84 3F D0 44 ; @ÍÌâB.ÐD?.É„?ÐD
00000020h: 90 3F E3 83 85 3F D0 44 90 3F B2 EA 82 3F D0 44 ; ?ヅ?ÐD?²ê‚?ÐD

I've been meaning to analyze them, but just haven't had the opportunity.

[swtor enthusiast]

Hi all,

I apologize in advance for the rather novice questions, I tried to do a bit of searching through this thread and several others but may have missed the answers to these rather basic questions.

First, when I load up Noesis with the SWTOR plugin that swtor miner posted, I can view extracted .gr2 models, but they are without textures (all white). I've tried placing the texture files in the same folder as the .dds model I'm trying to view, but cannot seem to get it to display with the texture. Is there something I need to be doing to assign a texture to the .gr2 model before viewing/exporting?

Lastly, I'm not having much luck locating the icon images used for vehicles, weapons, and so on in the game. Do you know offhand which directory I might find those located in?

Thank you very much for your time and sorry for the beginner-level questions.

[Alianin]

Lastly, I'm not having much luck locating the icon images used for vehicles, weapons, and so on in the game. Do you know offhand which directory I might find those located in?

Look at the 6th post down by SWTOR Fan on page 9 on this thread and there's a list and description of the tor archive files. You're looking for swtor_main_gfx_1.tor which has all the GUI icons.

[swtor miner]

First, when I load up Noesis with the SWTOR plugin that swtor miner posted, I can view extracted .gr2 models, but they are without textures (all white). I've tried placing the texture files in the same folder as the .dds model I'm trying to view, but cannot seem to get it to display with the texture. Is there something I need to be doing to assign a texture to the .gr2 model before viewing/exporting?

First off, here's an updated test version of the Noesis .gr2 Plugin. You'll want to rename/delete the other plugin if you decide to try this one. This is one contains A LOT of test code, and some ugly hacks till features are fully implemented. This version also has the debug log enabled, so that might be annoying. I might port it to a native plugin, but that's pretty far down the to do list.

If a model's textures aren't loading look for the "MaterialName:" lines in the debug log. These are what the model textures should be named. So, that can be a way to fix some models. The proper way to load materials/textures would be to look up the dependencies of the specified .gr2 model in the global.dep file, or one of the many index.xml files. Then you can then read in the textures and other settings for that material, and apply that to the model.

Given their fragmented nature in the game files, loading a .gr2 file properly without context is very difficult. So, I'll probably have to create a fork of my personal SWTOR tool to package the dependencies for each one to ensure they view properly.

That might be a while, as I've decided to play more SWTOR. (GSF is addictive) Well until they release a new PTS build, and that should be sometime this week or next.

[jpreston84]

Hey all! I know I've been silent for a while -- I've been pretty busy, playing SWTOR (finally leveled a char to 55, heh), dealing with life, and working on SWTOR dev stuff as well.

In any case, I've been deciphering the conversation nodes, and inside each actual conversation, one or more of the nodes can have the list of affection recipients (your companions) and the list of how much affection they can receive from your choices. These numbers correlate to the tables found in qstrewardsaffectionData, but I'm having a problem converting the labels to match what NodeViewer does (which is how I found the correlation -- poking around until I saw the same numbers somewhere).

So, for example, in NodeViewer, when I view the node qstrewardsaffectionData, there are several data tables (listed under qstRewardsPerLevelData), labeled as follows in NodeViewer:

-530180456931428419
-4783781478483316801
-4591313547948601546
-4560859075783160276
-1761015921176014301
-1279836118038687359

These correlate to (based on the numbers in each of their data tables)...

high loss
high gain
medium loss
medium gain
small gain
small loss

However, when I extract the data using my own software, the labels come out as...

13144940616778123197
13662962595226234815
13855430525760950070
13885884997926391340
16685728152533537315
17166907955670864257

I have checked and verified these manually. For instance, the hex for the first label is 0xCFB66C35D898AA07BD. As best I can understand, the CF indicates a positively signed integer with a representation 8 bytes in length, with the next 8-bytes representing (as big endian) the value, which is 13144940616778123197. This means of converting numbers works throughout the nodes in many places, including the label for qstRewardsPerLevelData, which is stored only a few bytes before the labels I'm having trouble with.

All that said, I do believe NodeViewer's interpretation is correct, because its labels match the values of conversation affection gains found in the conversation nodes themselves (and, I'm able to translate the values in the conversation nodes exactly the same way NodeViewer does -- the hex values are different than the labels for this table). What I can't figure out is how they start with 0xCFB66C35D898AA07BD, and end up with -530180456931428419 rather than 13144940616778123197.

Can anyone familiar with the node structures give me a hand?

[swtor miner]

I have checked and verified these manually. For instance, the hex for the first label is 0xCFB66C35D898AA07BD. As best I can understand, the CF indicates a positively signed integer with a representation 8 bytes in length, with the next 8-bytes representing (as big endian) the value, which is 13144940616778123197. This means of converting numbers works throughout the nodes in many places, including the label for qstRewardsPerLevelData, which is stored only a few bytes before the labels I'm having trouble with.
...

What I can't figure out is how they start with 0xCFB66C35D898AA07BD, and end up with -530180456931428419 rather than 13144940616778123197.

The 0xCF byte tells you the length of integer, 8 bytes in this case, not the sign. Byte-wise the values are identical, and it's about how you're choosing to type the value.

0xB66C35D898AA07BD = -530180456931428419
0xB66C35D898AA07BD = 13144940616778123197

Pages 4 and 5 of this thread have information on determining the type of the value. The relevant information is that the byte right before the 0xCF byte tells you the type. If it's 0x01, it's an unsigned integer (likely a node id). If it's 0x02, then you got a signed integer (likely a value or id looked up in a prototype node).

[jpreston84]

I have checked and verified these manually. For instance, the hex for the first label is 0xCFB66C35D898AA07BD. As best I can understand, the CF indicates a positively signed integer with a representation 8 bytes in length, with the next 8-bytes representing (as big endian) the value, which is 13144940616778123197. This means of converting numbers works throughout the nodes in many places, including the label for qstRewardsPerLevelData, which is stored only a few bytes before the labels I'm having trouble with.
...

What I can't figure out is how they start with 0xCFB66C35D898AA07BD, and end up with -530180456931428419 rather than 13144940616778123197.

The 0xCF byte tells you the length of integer, 8 bytes in this case, not the sign. Byte-wise the values are identical, and it's about how you're choosing to type the value.

0xB66C35D898AA07BD = -530180456931428419
0xB66C35D898AA07BD = 13144940616778123197

Pages 4 and 5 of this thread have information on determining the type of the value. The relevant information is that the byte right before the 0xCF byte tells you the type. If it's 0x01, it's an unsigned integer (likely a node id). If it's 0x02, then you got a signed integer (likely a value or id looked up in a prototype node).

Okay, so I'm slightly confused then. Until now, I've been operating on the assumption that the 0xC prefixes for integers worked like this...

Bits 0 - 4 are always 1100 (0xC)
Bit 5 is a sign bit (0 negative, 1 positive)
Bits 6 - 8 are the length-1 (in bytes) of the integer value (000 is 1 byte, 101 is 6 bytes, etc)

In fact, in the cnv.* nodes, for the cnvRewardAffectionRewards, the negative values are definitely stored with the 0xC7 prefix (I just double-checked this fact). Here's an example...

In the cnv nodes, we will see 0xC7187062A66980EDDD, so we convert 0x187062A66980EDDD to a positive value of 1761015921176014301. Then, per the negative sign bit in 0xC7, this becomes -1761015921176014301.
On the other hand, in the qstrewardsaffectionData node, we see the value 0xCFE78F9D59967F1223. We convert 0xE78F9D59967F1223 as a signed integer of -1761015921176014301.

So, are we effectively saying that there are two different ways of signing the integers depending on context?

Yay for "quality" software.

[swtor miner]

I have checked and verified these manually. For instance, the hex for the first label is 0xCFB66C35D898AA07BD. As best I can understand, the CF indicates a positively signed integer with a representation 8 bytes in length, with the next 8-bytes representing (as big endian) the value, which is 13144940616778123197. This means of converting numbers works throughout the nodes in many places, including the label for qstRewardsPerLevelData, which is stored only a few bytes before the labels I'm having trouble with.
...

What I can't figure out is how they start with 0xCFB66C35D898AA07BD, and end up with -530180456931428419 rather than 13144940616778123197.

The 0xCF byte tells you the length of integer, 8 bytes in this case, not the sign. Byte-wise the values are identical, and it's about how you're choosing to type the value.

0xB66C35D898AA07BD = -530180456931428419
0xB66C35D898AA07BD = 13144940616778123197

Pages 4 and 5 of this thread have information on determining the type of the value. The relevant information is that the byte right before the 0xCF byte tells you the type. If it's 0x01, it's an unsigned integer (likely a node id). If it's 0x02, then you got a signed integer (likely a value or id looked up in a prototype node).

Okay, so I'm slightly confused then. Until now, I've been operating on the assumption that the 0xC prefixes for integers worked like this...

Bits 0 - 4 are always 1100 (0xC)
Bit 5 is a sign bit (0 negative, 1 positive)
Bits 6 - 8 are the length-1 (in bytes) of the integer value (000 is 1 byte, 101 is 6 bytes, etc)

In fact, in the cnv.* nodes, for the cnvRewardAffectionRewards, the negative values are definitely stored with the 0xC7 prefix (I just double-checked this fact). Here's an example...

In the cnv nodes, we will see 0xC7187062A66980EDDD, so we convert 0x187062A66980EDDD to a positive value of 1761015921176014301. Then, per the negative sign bit in 0xC7, this becomes -1761015921176014301.
On the other hand, in the qstrewardsaffectionData node, we see the value 0xCFE78F9D59967F1223. We convert 0xE78F9D59967F1223 as a signed integer of -1761015921176014301.

So, are we effectively saying that there are two different ways of signing the integers depending on context?

Yay for "quality" software.

You got in a nutshell.

There's also two other cases I've run into:

Bits 0 - 4 are 1101 (0xD)
Bits 5 - 8 are 0000 (0x0) or 0010 (0x2)

I haven't fully investigated these cases, and treating them as single byte values appears to work. How else they should be handled I'm not certain.

[jpreston84]

You got in a nutshell.

There's also two other cases I've run into:

Bits 0 - 4 are 1101 (0xD)
Bits 5 - 8 are 0000 (0x0) or 0010 (0x2)

I haven't fully investigated these cases, and treating them as single byte values appears to work. How else they should be handled I'm not certain.

Yeah, there are actually many cases I've noticed where a label or value is a single-byte value. It seems that 0xC8 (which I've seen in a few cases) is basically unnecessary.

Thanks for the insight.

[zaramot]

Hi swtor miner! Have you managed to figure out bones in SWTOR? I stuck with them a bit, so if you have some info on them I'll be very greatful if you share this info with me. Thanks in advance

P.S. Problem solved - I've got the bones import:)

[TRDaz]

Bones and weights? If so, any possibility of sharing that?

[swtor miner]

Credit to SWTOR fan for this:

If you come across a 0xD2 byte when reading a number, skip the 0xD2 byte and try to read the number again. I haven't confirmed it as the only case, but it only seems to show up on look up lists. It's probably a flag of some kind.

Here's my latest hashlist.
And my latest gom type names for my updated Nodeviewer

[vertalius]

I would like to know about bones export too...How did you do that? All the bones are weigted? Mesh is skinned?