Damage textures

using damage textures with new ship models -> trek.exe basics; support/discussion/questions

Moderator: thunderchero

User avatar
Turner
Ensign
Ensign
Posts: 31
Joined: Fri May 09, 2008 2:00 am

Damage textures

Post by Turner » Wed May 26, 2010 1:51 pm

One of the things I miss at most in boft-mods are the missing little explosions and damage textures during the battles with new added ships.

As a first little step to bring them back into the game, I've found a small code segment in trek.exe, which controls the maximum number of damage textures per shipclass (usually 12 for the vanilla ships). Its located by the phaser slots and is 1 byte long (here the vanilla Sovereign):
48 48 33 00 04 00 00 00 01 00 00 00 10 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 66 66 26 3f 1a b8 19 11 11 15 14 16 28 29 29 21 21 25 25 24
Trying to set this the value higher than 0 by the most of the new ship models will crash the game at the moment the model is loaded. However there are some ships where this does not happen. At least not immediatly. In my case there were 2 cardassian models (kirol and gildron), which could be loaded with enabled damage textures. Unfortunately the game crashed in that moment when these ships were hit by enemy weapons with this entry in crash.log:
ST:BOF Wed May 26 00:56:41 2010

Version Under Test: 72
File: object.cpp, Line: 495, slotNumber <objData>TotalObjectSlot
Initialize State: 31
Player Empire: 0 Starting Seed: 1274828025
Galaxy shape: 1 Galaxy Size: 0
Turn State: 20
Turn Number: 10
Possibly more investigation in ship models like that, which don't let the game crash immediatly could be useful to solve this problem and let us find a way to add the damage textures to the new models.

Dr_Breen
Commodore
Commodore
Posts: 889
Joined: Wed Apr 30, 2008 2:00 am
Location: Zurich, Switzerland
Contact:

Post by Dr_Breen » Wed May 26, 2010 1:54 pm

that's a problem we're trying to solve for years. you'd become godlike if you can solve it
Public BotF / EF2 Teamspeak 3 Server: 83.169.13.55

User avatar
Turner
Ensign
Ensign
Posts: 31
Joined: Fri May 09, 2008 2:00 am

Post by Turner » Wed May 26, 2010 2:09 pm

Unfortunately I think there is nothing more I can do at this time, because I think we already must consider the damage aspect in the time of model developing. I just hope the fund of models, which don't let the game crash immediatly, gives the 3d-modellers here a little hint to find a way to improve their models.

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6058
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Thu May 27, 2010 12:07 am

I looked into adding damage texture some time ago, and looked at it a little more tonight.

your example above code from trek.exe phaser slot "0C" is not how many damage spots on model. I do agree is may be part of code for damage textures though.

I just ran a test on Miranda model it has max 6 damage spots and uses this phaser code;
48 4C 32 00 01 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 33 33 33 3F 11 14 18 21 28 24 00 00 00 00 00 00 00 00 00 00
it also uses the "0C" code.

But from what little I understand about HOB files it is a miracle that the new ship models even work.

here is why,

The vanilla hob file
***_a.hob (main hob most polygons has data for gif files)
***_b.hob (secondary hob approx 50% lower polygons no gif data)
***_c.hob (unknown file possible damage texture location info 1 polygons very small)

new models hob files
***_a.hob (main hob most polygons has data for gif files)
***_b.hob (main hob most polygons has data for gif files)
***_c.hob (main hob most polygons has data for gif files)
all 3 hob files are exact same

If bold code is in phaser slot data other than "00" will cause game to freeze with new models.

48 48 33 00 04 00 00 00 01 00 00 00 10 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 66 66 26 3F 1A B8 19 11 11 15 14 16 28 29 29 21 21 25 25 24

so any or all those bold data locations could be part of damage texture data

What I do know is phaser slots are extra polygon that are seperate objects with special names and coded in hot file or flt file before conversion. If a normal polygon is used as a phaser slot it will appear as a hole in model (no texture on polygon).

From the test I ran tonight each damage spot was a different shape and or size and from overlay of hob file they were not in the center of polygons of the model so they must be seperate polygon added at some point during conversion just like phaser slots are added.

what we need to know is how to add them, what to call them and how to activate them.

thunderchero

User avatar
Tethys
Past Administrator
Past Administrator
Posts: 2065
Joined: Fri Jul 18, 2008 2:00 am
Location: Your mom's bed ;)
Contact:

Post by Tethys » Thu May 27, 2010 12:42 am

Good god... if your right this could mean that all the ship models need to be (or should be) redone... 8O
Not for the weak of heart...
Image
GALM <--- GALM/Galaxies Mod

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 1:14 am

I searched trek.exe for any occurrence of "slot" since that designation is used for phasers. In sub_53C900 and sub_53CA40 I found near the "slot" mention of "anim". It could be this is the magic name used for damage points. Another is "slotvar", no idea what that would be about.

EDIT:
Turner wrote:Unfortunately the game crashed in that moment when these ships were hit by enemy weapons with this entry in crash.log:
ST:BOF Wed May 26 00:56:41 2010

Version Under Test: 72
File: object.cpp, Line: 495, slotNumber <objData>TotalObjectSlot
Initialize State: 31
Player Empire: 0 Starting Seed: 1274828025
Galaxy shape: 1 Galaxy Size: 0
Turn State: 20
Turn Number: 10
Possibly more investigation in ship models like that, which don't let the game crash immediatly could be useful to solve this problem and let us find a way to add the damage textures to the new models.
I checked the above error. It's thrown in sub_53A710 when edx is equal or greater than esi register value. The edx value is read from address [eax + 24h] and 32 bytes is incidentally the offset of phaser points data in phaser data slot.

Code: Select all

43 48 31 00 01 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 9A 99 99 3F (12 04 05 09 08 00 00 00 00 00 00 00 00 00 00 00)
The data in brackets are the phaser points. I suspect those are object indexes of the objects used for phasers. So 0x12 is compared to total number of objects, but wait, there are only 5 phaser slots not 18. I would guess the rest of the unknowns are also object numbers for shield animation, damage textures and explosions. This would total the objects number to 1+1+5+12 = 19 objects.

Checking if esi is 19 (0x13) and edx is 18 (0x12) in sub_53A710 on first test for vanilla model CH1 would test the above asumptions. Anyone have a working IDA debugger? ;)

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 3:48 am

thunderchero wrote:The vanilla hob file
***_a.hob (main hob most polygons has data for gif files)
***_b.hob (secondary hob approx 50% lower polygons no gif data)
***_c.hob (unknown file possible damage texture location info 1 polygons very small)
I thought those are for close/medium/far view. It would explain the polygon count difference. And the b and c versions of the textures are used for the b and c hob files.

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6058
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Thu May 27, 2010 9:49 am

DCER wrote:
thunderchero wrote:The vanilla hob file
***_a.hob (main hob most polygons has data for gif files)
***_b.hob (secondary hob approx 50% lower polygons no gif data)
***_c.hob (unknown file possible damage texture location info 1 polygons very small)
I thought those are for close/medium/far view. It would explain the polygon count difference. And the b and c versions of the textures are used for the b and c hob files.
here is little test I just did
all images are from same battle scene

vanilla model used hh3 (Sovereign)

close hh3_a.hob + hh3_a.gif




medium hh3_a.hob + hh3_b.gif



far hh3_a.hob + hh3_c.gif



very far hh3_b.hob + ?
hh3_b.hob was replaced with rh1_b.hob (warbird renamed to hh3_b.hob)
strange thing I think the palette is part of b.hob since color went to the proper green of warbird Itried to edit all 3 rh1 gifs but no change.



interesting huh........

thunderchero

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 10:31 am

thunderchero wrote: very far hh3_b.hob + ?
hh3_b.hob was replaced with rh1_b.hob (warbird renamed to hh3_b.hob)
strange thing I think the palette is part of b.hob since color went to the proper green of warbird Itried to edit all 3 rh1 gifs but no change.

...

interesting huh........
Yeah, interesting.

The last one just looks all green to me, maybe it's not using a texture at all, maybe the model is just green.

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6058
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Thu May 27, 2010 10:45 am

DCER wrote: Yeah, interesting.

The last one just looks all green to me, maybe it's not using a texture at all, maybe the model is just green.
here is hh3_b.hob (before replaced) view X2
you can see other colors on the hob but if zoomed in any closer it goes to hh3_a.hob with hh3_c.gif



so each polygon may be given it own color?

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6058
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Thu May 27, 2010 11:11 am

DCER wrote:I searched trek.exe for any occurrence of "slot" since that designation is used for phasers. In sub_53C900 and sub_53CA40 I found near the "slot" mention of "anim". It could be this is the magic name used for damage points. Another is "slotvar", no idea what that would be about.


also funny you posted this, I read though the "how to" on hot to hob files here is what I found about "anim"
10. Object Slot:

This is a feature to insert object into a slot defined in another object. This
slot is defined by naming an object bead as slotn where n is the slot number.

Functions available:
- glInsertObjectInSlot (objectID, slotno, anim);
where: anim is the instance animation structure
objectID is object to be inserted (i.e. missile)
slotno is the slot number the object to be inserted (start from 0)
Use this function to insert object into another object slot

- glRemoveObjectInSlot (slotno, anim);
where: anim is the instance animation structure
slotno is the slot number the object to be removed (start from 0)
Use this function to remove object in the slot

- glSetObjectSlotMatrixVar (slotno, anim, mat);
where: anim is the instance animation structure
slotno is the object slot number (start from 0)
mat is the object orientation matrix
Use this function to define the object orientation matrix (which default to
identity matrix)
Note: If you need to use this function, you have to define the constant in
file rendbead.cpp (SLOT_USE_USER_DEFINED_MATRIX). It is undefined by default.


- glSetObjectSlotScaleVar (slotno, anim, scale);
where: anim is the instance animation structure
slotno is the object slot number (start from 0)
scale is the object scale
Use this function to define the object scale (default to 1)

- glSetObjectSlotAnimVar (slotno, anim, slotanim);
where: anim is the instance animation structure
slotno is the object slot number (start from 0)
slotanim is the instance animation structure for the object
Use this function to define the animation structure (default to none)
now if I just understood this..... it would help

thunderchero

User avatar
Turner
Ensign
Ensign
Posts: 31
Joined: Fri May 09, 2008 2:00 am

Post by Turner » Thu May 27, 2010 11:58 am

thunderchero wrote:your example above code from trek.exe phaser slot "0C" is not how many damage spots on model. I do agree is may be part of code for damage textures though.
Indeed I have to correct myself. It is the number of damage spots botf uses from the model subtracted by one (if it is not equal with zero).
thunderchero wrote:I just ran a test on Miranda model it has max 6 damage spots and uses this phaser code;
48 4C 32 00 01 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 33 33 33 3F 11 14 18 21 28 24 00 00 00 00 00 00 00 00 00 00
it also uses the "0C" code.
I've testet the vanilla Miranda and Sovereign today and the damage spot value works as it should be. Every value between 00 and 0c works fine and delivers the expected amount of damage spots. Higher values will crash the game at the moment the model is loaded.

Here are some screenshots:

Sovereign with value 0c (Hitpoints 10/260):


Sovereign with value 04 (Hitpoints 10/260):


Miranda with value 0c (Hitpoints 4/76):


Miranda with value 04 (Hitpoints 4/76):


thunderchero wrote:If bold code is in phaser slot data other than "00" will cause game to freeze with new models.

48 48 33 00 04 00 00 00 01 00 00 00 10 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 66 66 26 3F 1A B8 19 11 11 15 14 16 28 29 29 21 21 25 25 24

so any or all those bold data locations could be part of damage texture data
It seems to be, that these other two values have no significant influence on the damage textures. Here is the part of the phaser slot from the vanilla warbird:
52 48 31 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 cd cc 4c 3f 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00
The damage textures works fine on the vanilla warbird, so I think only the 0c-value has the control about the number of damage textures.

We have the mechanism to activate the textures, but we still need the models, which supports these feature :(

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 12:12 pm

thunderchero wrote:so each polygon may be given it own color?
No idea if this is true for botf, but in general yes.

I'll have a look at the how to.

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 12:14 pm

Turner wrote:We have the mechanism to activate the textures, but we still need the models, which supports these feature :(
Half way there is not so bad :)

User avatar
DCER
Code Master
Code Master
Posts: 683
Joined: Sat Apr 26, 2008 2:00 am

Post by DCER » Thu May 27, 2010 1:14 pm

Things of interest:
6. Convert HOT files to HOB files (Binary format)

...

Note:
- All ANS files must be located in the current directory, if not the animation will be disabled.

...
7. Create Objects List

Use RegisObj tool to create objects list file. Object List file is used by
the 3d library internally to create 3d object id table.


...

Object List output format: (in BINARY format)
-------------------------
maxobjectid+1
objectid
objectdescription
objectradius
maxdof maxswitch maxslot maxanim maxdynamicvertex
totallod

switchdistance flag objectname
:
:
-1
III. ANimation Script

- Each ANS file must have Data block, Init block, and Code block in that order.
- ANS file has a similar syntax to 'C' language.
- // is comment. All characters that come after // in the current line will be
ignored.
- Characters are not case sensitive --> ANSCode is equal to anscode, etc
- Space character is ignored.

...
Followed by two examples.

It seems you can have one script per ans file.

Maybe the listed functions can be called from the animation script. Otherwise I don't know how you'd make an animation with it.

Post Reply

Return to “using damage textures with new ship models -> trek.exe basics”

Who is online

Users browsing this forum: No registered users