MechWarrior 2: Resource Forum

I'm trying to use the knowledge about how texturing works in MW2 to create new WTB files (objects in the MW2 sim). Unfortunately, without success.

Here's how far I got: I have created two .OBJ test files and written an algorithm to convert them to .WTB's. I can display them in MechVM, but not in the MW2 sim. So I started doing some experiments: I took other WTB files and edited them. The meaning of byte 4 to 16 in this file type is unclear at this time. Adding one to one byte and subtracting one from the next byte in this part of the header apparently leave the file intact. All other changes I made make the WTB invisible. I'll attach the two files I created so you can experiment with them yourselves (plural in case someone else besides Kell is interested ... ).

sweet.
So do I just pick any type of equal-or-larger WTB file and replace them with these?
I wanna give this a try. Especialy the shadowcat head. I have tried before to make a shadowcat in KAM using maddog legs, a maddog arm, a battlemaster handgun and a firemoth head.

While it's possible that the new objects are present in MW2, and simply invisible due to a texturing or similar error, I doubt that's the case, because MW2's original .WTB files can be made invisible by simply changing single bytes in the header. So, unless we can figure out the meaning of those header bytes, we're stuck. It's possible that these are simple checksums, but which algorithm was used, and what parts of the file went into what checksum?

Any tools? Any documentation I forgot to consult?

Can you repost that WTB test download? I had to format my flashdrive when I left the house to download a microsoft visual studio express .iso file.

Re-uploaded the attachments above. Thanks, MMPD.

np, sorry about that the modifications from the other night changed the folder permissions.

Too bad those forum modifications didn't work, but I'm relieved to see my attachments appear to be the only problem that was caused.

Skyfaller wrote:The meaning of byte 4 to 16 in this file type is unclear at this time. Adding one to one byte and subtracting one from the next byte in this part of the header apparently leave the file intact. All other changes I made make the WTB invisible.

Well, you can cross 8 more bytes from the mystery list: bytes from offset 8 to 15 are the name of the WTB file, without the extension, and with each character *NEGATED* (so, for example -65 represents the letter "A", instead of +65) The same format is used to store names in the TBL files in the TABL directory of the project file. The purpose of storing the name this way escapes me, but the important thing is that we have 8 less bytes of the WTB header to decode

It should be noted that in the ATI version of the WTB format, the name is stored as plain ASCII - no negation (which was how I stumbled across the answer in the first place).

I remember Skyfaller mentioning in another post somewhere that he thought the header might contain some sort of checksum (which is why the geometry vanishes when you try to change vertex/poly data) - I suspect that this checksum is bytes 4 & 5 in the header but can't quite figure out how the checksum is calculated (although adding together the 16-bit words that make up the vertex and poly data and masking it with 0xFFFF gives a value very close to that stored at bytes 4-5 of the header - in smaller files these values aren't off by much, so I'm hoping that means I'm close )

Will post more if/when I find it.

quota4stupid wrote:...bytes from offset 8 to 15 are the name of the WTB file...

Actually, not the name of the file, just a name as it turns out (in the files I initially tested it WAS the filename, but another one I just looked at - "PLANET.WTB" from Mercs - places "frobozz_" here).

Also, it appears that this field is longer than 8 bytes - I can prove up to 12 bytes, but I suspect it may be 16 bytes. The proof is "MECHCNK0.WTB" (again from Mercs), where the value here is "mech-chunk0" (11 characters). Also, in ALL the WTB files from DOS Mercs, the four bytes at offset 20 are always zero, so I suspect they are just a continuation of this field.

So in summary, I believe this field occupies bytes 8 to 23.

wow you certainly have a lot of free time quota every time i've tried to look at the WTBs I somehow end up scratching my head in some way... not realy my field of expertese anyway