Sign in to follow this  
Followers 0
mikew

Interpretation of SSD files

101 posts in this topic

So, on to collision....

There doesn't seem to be any explicit way to handle this, so we will have to make some assumptions.

What we do know is that there are two words set aside in the 'local state' variables for each target the SSD deals with.

We'll use rig_1.ssd as an example and we have a COLLISION_BOXES section, whose start address is given as one of the ssinfo.lab entries. We can get away without using this value.

In this case 'Block4_pointer_3' tells us what to put in 'local state variable 1', which is the offset to the undamaged collision box coordinates, relative to the start of Block4.

We will have to guess what to put in 'local state variable 0', and I suggest the offset to the pointer for the action to be taken when we go to damage level 1. There are always 4 pointers, which sets the limit on the amount of damage levels, and in this case their values are:

0c00

1e00

3000

4200

....so I suggest using the offset to the 0c00 as the starting value for 'local state variable 0'. The offset can be increased by 2 bytes with each change of damage state. This starting offset will always be 4 words earlier than that given for 'local state variable 1', so in this case we'd use 1a00.

When the change to damage level 1 is triggered, we would then read the value stored in 'local state variable 0', and jump (in this case) 0x0c00 words to the start of the bytecode.

8100af01e2ff7501be0100008c01ffff

1b00010008000000070039000000000000010500

0000

The 8100 (sometimes 8200 for unknown reason) opcode can be interpreted as 'replace the current collision box coordinates with the following'. A 'ffff' signifies the box is complete. An object can consist of more than one box, in which case there is an 0800 opcode separating each box.

The 1b00 line then handles the shape visuals, where we go from Parameter 0007 value 0 to 1 as a little animation 0000->0000->0001. This may be done as a delay since before the animation sequence there is a 0700 GOSUB excursion to a 4f00 block:

4f00b701000085011f00

0000

I have no idea what this does, but it contains coordinates so may be related to a camera position or is part of the debris system.

The process would continue for the other damage states.

It'll take some effort to decide when an object is damaged enough to require a state change, but seemingly the only help given by the SSD file is the second word of the collision box info, 2400 in this case, which identifies the target type.

Here's the relevant parts of rig_1.ssd showing the pointer relationships:

rig_1.ssd

;Block4 Starts 116 Length.8

04000f0014003305

.

.

.

;COLLISION_BOXES Starts 162 Length.196

5300240000000c001e0030004200

af01dbff7501be0100008c01ffff

0000

8100af01e2ff7501be0100008c01ffff

1b00010008000000070039000000000000010500

0000

8100af01eeff7501be0100008c01ffff

1b00010008000001070026000001000100020500

0000

8100af01f0ff7501be0100008c01ffff

1b00010008000002070013000002000200030500

0000

1b0001000800000307000e000003000300040500

0000

0000

0000

4f00b701000085012000

0000

4f00b701000085011f00

0000

0000

.

.

.

;Block4_Pointer_3 Starts 2784 Length.8

0b0001001e00

0000

Share this post


Link to post
Share on other sites

Consider humvee.ssd:

  • Block7 loads the local states and variables:


;Block7 Starts 332 Length.36


0b000000ffff

0b000100ffff

0b000200ffff

7c00030000000000

0b0005000000

0100ea00

  • Lab_Block points to the following data for smoke:

;NB_SMOKE Starts 778 Length.2


0300

0300 = number of smoke variables

;SMOKE_INFO Starts 780 Length.24


000000000000faff

080000000000faff

090000000000faff

1st word is the index number and points to the list in smoke.dat
0000 > DEFSMOKE "SMALLDUST[b]0[/b]"	 ; dust trail

0800 > DEFSMOKE "MEDIUMDUST[b]8[/b]"	 ; dust trail

0900 > DEFSMOKE "LARGEDUST[b]9[/b]"	 ; dust trail
2nd , 3rd and 4th words are coordinates (X,Y,Z) of spawn point on humvee for the “smoke” shape (.dust.3).
;SMOKE0_VAL Starts 804 Length.2


0000
References local state with index # 0, as set up in Block7
;SMOKE1_VAL Starts 806 Length.2


0100
References local state with index # 1, as set up in Block7
;SMOKE2_VAL Starts 808 Length.2


0200
References local state with index # 2, as set up in Block7 The actions on the smoke state are dependent on the User-Options determined in game.cfg, specifically: DUSTTRAILS=X, which determine which Block_4 Pointers are active:
;Block4_Pointer_96 Starts 574 Length.20


0b000000ffff

0b000100ffff

0b000200ffff

0000


;Block4_Pointer_97 Starts 594 Length.20


0b0000000000

0b000100ffff

0b000200ffff

0000


;Block4_Pointer_98 Starts 614 Length.20


0b000000ffff

0b0001000100

0b000200ffff

0000


;Block4_Pointer_99 Starts 634 Length.20


0b000000ffff

0b000100ffff

0b0002000200

0000
The above lines write the options-selected smoke state variables. Smoke.dat allows humvee.ssd to associate with the dtX.ssd to provide the local state implementation: Example:
DEFSMOKE "SMALLDUST0"	 ; dust trail

VIS 1000		

VEL 0,0,0				; initial velocity (m/sec)

SPUTTER 0.2,0,0.2		 ; random sputtering (m/sec)

LIFE 2.0			 ; particle life expectancy (secs)

LIFERAND 0.2		 	 ; random life variation (secs)

RATE 0.4			; delay between particle emissions (secs)

RATERAND 0.01	 	 ; random emmision variation (secs)

BETWEENS 0	 	 ; How many particles to insert for each particle emitted		

VARIABLEBETWEENS 1

UNTIL 1.6 "DT1"

UNTIL 1.2 "DT3"

UNTIL 0.8 "DT5"

UNTIL 0.4 "DT7"

UNTIL 0.0 "DT9"

ROTATE 0

ENDSMOKE

(Note: all dtX (1,3,5,7,9) supershapes call dust.3)

Is this a case of a superobject of one class associating with another superobject of a different class for local state determinations?

Share this post


Link to post
Share on other sites

Good stuff. :)

I tried changing the Block7 values, expecting to see a already smoking vehicle when the game starts.....but couldn't see any difference.

Share this post


Link to post
Share on other sites

I suddenly realize the reasons for many details in TAW. For example, there are needless collision triangles in SSDs (neighbouring quads with the exact same plane): These keep coordinates small, and therefore simplify integer math on collision detection.

Currently, I'm having quite of a problem with efficient collision detection (you, bullet, should collide with that tile and no other), but it's getting better and better. Just so you know I'm still on it.

Share this post


Link to post
Share on other sites

Yes, a flat tile, like the sea, still has 32 collision triangles in TFX3, but not in TFX2.

...and bridges are modeled in exquisite detail from a collision triangle point of view:

rlrvdt_1.jpg

Presumably this is done for traffic reasons, but I wonder if you can fly underneath one.... :)

Share this post


Link to post
Share on other sites

Good stuff. :)

I tried changing the Block7 values, expecting to see a already smoking vehicle when the game starts.....but couldn't see any difference.

The term “smoke” is somewhat of a misnomer here. The term refers to the smoke.dat particle system file. What I believe happens is consistent with your suggestion that Block7 is responsible for setting up the initial actions. It is my belief that the initial actions are immediately overwritten, at game start, by the user defined settings in the game.cfg file. Therefore, modifications of the SSD need to occur at using either "SMOKE_INFO" or Actions 96-99.

For all GB vehicles, the default “smoke” values are “smalldust”, “mediumdust” and “largedust”.

(my configuration settings = DUSTTRAILS = 2):

F222012-12-0810-34-45-14.png

Here I have simply modified “SMOKE_INFO” in humvee.ssd from”

000000000000faff

080000000000faff

090000000000faff

010000000000faff

010000000000faff

010000000000faff

F222012-12-0810-42-34-41.png

F222012-12-0810-41-53-64.png

This changes the index pointers from the dust supershapes to tire tracks:

TRK1:

DEFSMOKE "TRACK1" ; TRACKS

VIS 1000

VEL 0,0,0 ; initial velocity (m/sec)

SPUTTER 0.2,0,0.2 ; random sputtering (m/sec)

LIFE 5.0 ; particle life expectancy (secs)

LIFERAND 0.0 ; random life variation (secs)

RATE 0.2 ; delay between particle emissions (secs)

RATERAND 0.0 ; random emmision variation (secs)

BETWEENS 0 ; How many particles to insert for each particle emitted

VARIABLEBETWEENS 1

UNTIL 1.8 "TRK1"

ROTATE 1

ENDSMOKE

For some reason DID chose to use dust exclusively and never activated the tire tracks in TAW, now we have control of that process in the SSD file ;)

Share this post


Link to post
Share on other sites

I guess the dust looks better in the desert. It would be nice to have some variation though.

It looks like you've about wrapped this up. :thumbsup:

Share this post


Link to post
Share on other sites

Okay, we have gone this far so lets go a bit farther. My "Dusttrails =2" is actually =1. (TAW_opts.cfg defines dust trails as having only one option heading):

FEATURE "DUST TRAILS" HEADING 1

LEVEL "Switch ground dust trails On/Off"

CPULEVEL -1,3 MMX -1,-1 SYSMEM 8192,32768 MODE 0,0 3DSUPPORT 0,0 AGP 0,0 FOG 0,0 ALPHA 0,0

ENDFEATURE

I tested it and the variables that control dusttrails = 0 (off) are assigned by Block4_Pointer 96:

smoke-grid_zps50a204c5.jpg

I ran some tests on humvee.ssd using the Cannon Strafe CAS weapons trainer. In this trainer are 3 humvees; the lead humvee on the road displays "largedust", assigned by Pointer 99. The other 2, descending the hill, have current (at mission start) smoke states using pointer 98.

It appears the variable-determining test is vehicle speed and the 3x3 (excluding the off pointer) configuration facilitates the "in-game" accelerating / decelerating dust trails state. This would explain the exclusion of the tire tracks from the process.

ASIDE: note the brake lights on the humvee have changed from green (previous screenshots) to red. :o

It's still fun to see what can be done by assigning 3 action variables per instance. Below we have 1 tire track and 2 largedust particle systems per humvee:

F222012-12-1422-41-32-15_zps1366dfb1.jpg

F222012-12-1422-41-49-46_zps03e6e9fb.jpg

Note: AGP textures is disabled.

Share this post


Link to post
Share on other sites

Here's a quick look at what happens when I introduce the clouds, in TAW, to the particle system generator:

F222012-12-0823-00-05-16B_zps39d386fa-1_zps141b178f.jpg

Share this post


Link to post
Share on other sites

I’ve been spending most of my TFX time working on what I have designated the “ME-TAZ” project.

MeTaz1_zps9288672e.jpg

It is the hardware modes focus on initializations of texture implementations and explosions, but I digress…

I have popped in to SSD, periodically, to work mop-up duty on some of mikews fine SSD work. There remain a few SSD opcodes and functions to explore.

-5b00??-

-5e00??-

-5a00-

I’ll start with 5b00, which is a sound related opcode and can be interpreted as “load .wav file into a list”. The operand word points to the specific .wav file name in the index “sfx.bnk” located in the samples/sfx directory. 5b00 is used extensively for weapon and pylon supershapes of object type 83’s. When a weapon or pylon object is launched or jettisoned, 5b00 provides the appropriate release sound.

The stereotypical format for the “fz” weapons involves a call from the Block 7 action code:

(fzagm65g.SSD)

;Block7 Starts 150 Length.42

1400000004000700f7000500

0b0000000000

0b000100ffff

0b0002000000

7c00030000000000

01000001

The 1400 opcode calls a GOSUB and jumps to the 5b00 containing pointer:

;Block4_Pointer_12 Starts 650 Length.8

0000

5b000000

0000

…and then returns.

Operand 0000 points to: Sample fx001 , 1,30,7, 0, 0, 1, 0, 5 ; 0 EXPLO_BOLT 0,

[ASIDE: in BMZMISS.ssd there is a 01005b00 in a block 4 pointer, which I believe is a jump. Previously it was thought that 0100 jumps were limited to Block 7. If someone could confirm that, it would be helpful.]

5a00 is a previously undocumented opcode and I bring it up here only because it could prove educational.

5a00 is exclusive to the file “setup.ssd” and is implemented by doing the following: 1.) add [loadsetupsupershape] to the initialization file, 2.) write “setup” under that heading and 3.) place setup.ssd in the ss directory.

The operand contains 2 words (5a0000000a00), where the first appears to turn some function off (initially I thought it to be the fragment shader) and the second is a <color> determinant.

Before setup.ssd:

AC-Shadw-NL_zpsd53a958b.jpg

After setup.ssd:

capture_18122012_215222_zpsd683bdcf.jpg

The rendered vertices are from the respective files 0001 opcode LOD's.

Still working on this and 5e00, does anyone have a list of the 5e00 files?

Share this post


Link to post
Share on other sites
ASIDE: in BMZMISS.ssd there is a 01005b00 in a block 4 pointer, which I believe is a jump. Previously it was thought that 0100 jumps were limited to Block 7. If someone could confirm that, it would be helpful.
You seem to be right, and the count of 5b00 takes us to the end of the block. The 0100 must become a counter opcode at the next level down.

I've done very little with sound, and only really played the .wav file associated with 8500 opcodes.

Share this post


Link to post
Share on other sites

Hmmn, while I've got bmzmiss.ssd open, I notice the first line of Block 7 dosn't fit the expected pattern:

1400 0000 0400 0700 f700 0500

The 1400 opcode would normally cause an action on Parameter 0000 of, in this case, bmzmiss.3.

But, bmzmiss.3 does not use Parameter 0000, and in any case, the following 'jump' opcodes 0400 and 0700 don't really make sense.

Share this post


Link to post
Share on other sites

The 1400 opcode would normally cause an action on Parameter 0000 of, in this case, bmzmiss.3.

But, bmzmiss.3 does not use Parameter 0000, and in any case, the following 'jump' opcodes 0400 and 0700 don't really make sense.

I was aware of that and trying to simply ignore it for the moment <_< however, now it should be addressed. BMZ is actually not a good model to use for this analysis because, IIRC, the BMZ model has never been a functional missile launcher in TAW.

{ It's worth noting that the developers did something conservative here...all ground based, missile objects are identical so the GB missile launching supershapes in TAW (SA_6miss, SA_17miss, chapmiss.ssd, etc) all use the same 3d object: BMZMISS.3.}

I am working on the answer and believe it lies in an understanding of how the weapon launching sequence is initiated and decremented. :popcornsmilie:

The way I read it is:

1400 manipulate parameter 0000 of shape

0000 shape

0400 number of words following in "action"

0700 gosub

f700 jump

0500 end

Which, as you pointed out, beg the question regarding the absence of a Parameter 0000 in BMZMISS.3...

hmmm :unsure:

Share this post


Link to post
Share on other sites

Ah, yes. I misinterpreted the 0400....It's been a while.

It looks like the 0700 Gosub takes us to the 5b00 line in Block4_pointer_12 (although I wasn't that careful counting).

Maybe the 1400 is just used a dummy to hold the Gosub statement, and 1500,1600 etc would work just as well.

That implies that you can't just have a 'naked' 0700 statement.

Share this post


Link to post
Share on other sites

It looks like the 0700 Gosub takes us to the 5b00 line in Block4_pointer_12 (although I wasn't that careful counting).

Maybe the 1400 is just used a dummy to hold the Gosub statement, and 1500,1600 etc would work just as well.

That implies that you can't just have a 'naked' 0700 statement.

The dummy theory has some credibility in that, 1500 also works, however, 1300, 1600 and 1700 are silent and no sound is associated with the launch.

My other theory assumes the action is a launch / jettison and the launch / jettison is actually a spawn and therefore the point of initiation would be in the parent object file (eg. F22usa1.3). My understanding is that the SSD pointer index position links to the specific action, so I'm looking at the pattern of the index positions of actions containing this sound assignment. I'm wondering if the sounds are somehow associated using the 0075 opcodes (weapon spawn) in the parent object files.

Share this post


Link to post
Share on other sites

I would have thought the the object files (.3) are 'downstream' and only have 'control' over textures.

Nothing should be ruled out though...

Share this post


Link to post
Share on other sites

Well yes, however, we have advanced what we do know and perhaps we could update the architectural scheme one of our more intelligent members once diagrammed:

MikewsTAWarchitecture-B_zps9080c5ff.jpg

:)

Share this post


Link to post
Share on other sites

There are a number of processes within the TAW as well as EF2K SSD's which remain elusive. The issue, in EF2k, of the out-of-bounds object indexing as well as the erroneous index numbers continues to require investigation. The current approach to solving these questions involves an attempt at determining associations and understanding nomenclature. I decided to start by tabulating the information in an organized fashion. I have posted a screenshot of the initial AC data, in case it might be of future use:

AC-Type-ef2k_zpseccac9c3.jpg

AC-Type-ef2k2_zpsb49d857f.jpg

Share this post


Link to post
Share on other sites

Okay, so my next step, after tabulating the 5th and 6th byte information for the AC, was to look at the association of the 5th and 6th bytes with the elusive opcodes 1100, 1200 and 1300 for AC and weaponry:

Ef2k-1300-categorized_zps90df3b33.jpg

Ef2k-1300-categorized2_zpsdfaefe5f.jpg

Ef2k-categorized3_zpsb1c14603.jpg

Now a pattern starts to develop, so we create a quick cross referencing scheme and find the following:

Ef2k-1100-Janes_zpsc8064e7f.jpg

These weaponry values, contained within the SSD Block-7 1100 opcode lines, are consistent with the weapon specific weights as documented in Janes. Jane's Information Group (often referred to as Jane's) is a British company specializing in transportation and military topics. D.I.D. took much of the real-world values, implemented in the code for the TFX simulations, directly from Jane's.

Therefore my working hypothesis is that the necessary variables, read in, for lift coefficients and drag coefficients for weaponry physics modelling, at least, in EF2k, are read in using these opcodes... :popcornsmilie:

Share this post


Link to post
Share on other sites

Epic work! :thumbsup:

I wouldn't pay too much attention the EF2000 .ssd files which appear corrupt...because they probably are corrupt.

For example, an225.ssd is one ssd file with an out-of-bound Block5 index, but this file is not not included in ssinfo.fn indicating that it is not used. It is antonov.ssd which is used for the an225 model used in the game.

Share this post


Link to post
Share on other sites

Okay, however, I can't help but be curious about why such a large number of "corrupt" .ssd files. The corrupt files with "Invalid Index" calls on parsing seem to come in 2 flavors: 1.) out-of-bound and 2.) in-bounds but erroneous index pointers (assuming Block6) :

Example 2.)

No-Blk5-Blk6_zps88e56fb6.jpg

A cursory search for all the oob containing files maxed out at y_ecm.ssd (0d07) which is 2000. The patterns beg to know if there are multiple index lists. Since there are multiple versions, are there multiple and dissimilar lists?

Share this post


Link to post
Share on other sites

As far as I can remember, that index is only used as a pointer to ssinfo.fn to decide which .3 file to select. I have not come across any other file which would be an alternative list although we haven't done as much work on extraction of EF2000's did.dat file...so I guess anything is possible.

If they are not used, then I guess the question should be 'why are they being extracted by the game?'....and a possible answer to that is the presence of the 'clump' files which contain a complete list. If these are deleted, I think the game only loads each file on demand.

All conjecture on my part though. :)

Share this post


Link to post
Share on other sites

This discussion reminds me of fwsexpl.spr and fwsexpl1.spr, which are extracted to the SPR directory. I have found at least two object files (explode.3 and explode2.3) which contain ASCII header references to the .spr files. Neither of the 2 object files are listed in ssinfo.fn, so either they are not used or there is an alternate means of accessing them.

Share this post


Link to post
Share on other sites

In TAW, there are .3 files such as the F22 control surfaces (F22_23.3 etc) which are not referenced in .ssd files, and thus don't appear in ssinfo.fn. These filenames can be found in the exe though.

With EF2000, we have these .ssd files with out-of-bound .3 references...and we're not sure whether these files are ever active (although personally I don't think so).

I've only looked in some detail at the EF2000 terrain .ssds to help with TFXplorer, and there all the relatively few files actually referenced from the environment (.env,.lst,.dat) had valid .3 values.

For things like missiles, I can't remember where the ssd file names are defined, even for TAW.

Share this post


Link to post
Share on other sites

In TAW, the exact strings matching the missile .ssd filenames can only be found in the .exe, and I'd guess the same is true for EF2000.

Taking the an225.ssd example which we know has out-of-bound values and searching for an225 in the SEF2000 .exe file results in no exact match, therefore I still think it is not used.

an225 is present in the clump_ss.txt file, which is why it was extracted by the game and therefore why we know its name.

Share this post


Link to post
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
Sign in to follow this  
Followers 0