Sign in to follow this  
Followers 0
mikew

Interpretation of SSD files

101 posts in this topic

Okay, and I do appreciate your patients on this subject. I went back to check TAW because I recalled that the strings matching the missile .ssd files are all in the .exe, however, all the "off -the-rail-models" (fz) do have their .ssd files in the ss directory. None of the "global shape" type weapons have .ssd files.

I agree and also did not find the an225 weapon string, only the name label an225 Mriya. I'm wondering if It would be so helpful if we had a better handle on the Ef2k naming conventions. initially I thought an225 might be a TFX remnant, however, the .3 files are dissimilar :popcornsmilie:

Share this post


Link to post
Share on other sites

Some more musings on TURRET_LAUNCH_POS.

Taking the Nimitz model which has 7 turrets, we can deduce the following...

nimitz_guns_1.png


from nimitz.ssd

;TURRET_NUM Starts 1822 Length.2

0700


;TURRET_LAUNCH_POS Starts 1824 Length.126

;_A____B___C____D____E____F____G____H____I

f7ff fcff 2700 0200 ffff 0200 0300 a6ff 0000 ;1

0900 fcff 2a00 0200 ffff 0300 0200 5a00 0300 ;2

0900 fcff 2400 0200 ffff 0200 0200 5a00 0000 ;3

f8ff fcff caff 0200 ffff 0200 0100 a6ff 0300 ;4

f8ff fcff c6ff 0200 ffff 0300 0200 a6ff 0000 ;5

0800 fcff c6ff 0200 ffff 0200 0300 5a00 0300 ;6

0300 fcff c1ff 0200 ffff 0300 0300 b400 0000 ;7


from gbvtypes.txt

GBV "nimitz" ALL_ROLES 20 40 0 4

NUM_TURRETS 7

TURRET CANNON

TURRET SA6

TURRET CANNON

TURRET SA6

TURRET CANNON

TURRET SA6

TURRET CANNON

Where:

A= X coord of turret

B= Y coord of turret

C= Z coord of turret

D= Unknown

E= Unknown

F= Number of allowed rotation steps in anti-clockwise direction (looking from above)

G= Number of allowed rotation steps in clockwise direction

H= Default turret angle in degrees (0=positive Z-axis)

I= turret type

One issue is that I don't know where the number of degrees per rotation step is defined for each model. For the Nimitz, 1 step =30 degrees, while for a T-80 tank, 1 step = 5 degrees.

Share this post


Link to post
Share on other sites

BLOCK2

The SSD Block2 secrets have remained hidden long enough. Reviewing the previously discarded “animation theory”, motivated me to consider least significant byte, which led to calculations involving animation parameters. Based on the information I have documented below, Block2 will now give me less of a fundamental challenge and more of a detail oriented adventure B)

To illustrate, I ask you to consider the TAW ship file ses.ssd

SES.SSD Block2:

08070707000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

Blk2-ses-ssd_zps347b6eeb.jpg

B2-BPN = Block2 Byte Position Number

B5-SLN = Block5 (Shape List) Index Number

B2-V = Block2 Value = (Parameter Value + 1)

0048-P = Shape file 0048 Parameter #

SSD-Op = SSD Opcode

Byte position number references the index number in the shape list:

The Block2 values are a reference to the parameter run on the referenced shape at the time the game is initially (one-off) run:

Blk2-ShpLst_zpsb12e3723.jpg

Example: The ses.ssd Block2 value at byte position number 2 will activate the 1a00 opcodes with the 1st operand word being 2 (1a000200…), so we look at the Block4 pointer destinations and find:

;Block4_Pointer_92 Starts 1416 Length.50

1a0001000600000001000308feff0500

1a0002000600000001000308feff0500

1a0003000600000001000308feff0500

0000

;Block4_Pointer_93 Starts 1466 Length.50

1a0001000600000802000300feff0500

1a0002000600000802000300feff0500

1a0003000600000802000300feff0500

0000

Consider: 1a0002000600000001000308feff0500

I interpret this as 1a00 shape parameter 6 (00480006) will be manipulated in the object file ib_wake.3, which is at Block5 index position 2. The animation sequence then involves 8 incremental updates of values 0 through 8 then stop and end the sequence.

Pointer 93, however, decrements that sequence and should not be run simultaneously with pointer 92…hmmm :popcornsmilie:

The premise is that the parameter assigned in Block2 is run, at game initiation, on the designated shape object.

Below are screen captures from TAW Take Off Trainer, substituting ses.ssd for dhow.ssd. The first image is with the default Block2 values 08070707…, the second is with the values modified to 08000000…

08070707

Block2-ON_zpsa1d7dd69.jpg

08000000

Block2-OFF_zps08875d1a.jpg

Understanding the Block2 patterns will also help immensely in mapping the Block4 Pointer animations. :)

Share this post


Link to post
Share on other sites

Nice!

I can't say I follow you completely since it's been a while since I looked at this....but are these animations missing from EF2000, which doesn't have a Block2?

Share this post


Link to post
Share on other sites

The devil is in the details and there remain a great number of them to explore and confirm. Suffice it to say, my initial thoughts were to the statement Steve White made:


I hated the Z-buffering problems, planes flying into the terrain and the fact that damaged world objects in the campaign had to be blown up every time the world was loaded. You would appear on the runway and things would be blowing up all over the place, scrambling ASAP to find no one in sight. I complained about that and suggested keeping the screen black for a few seconds while the 'blowing-up' occurred but old Hunty was just too bone-idle ;-). I wish we had stuck to a smaller 'world'

It seemed logical that the block2 animations could be for the 'blowing-up', however, only the 08 values would be involved there and that would leave all the other values to be explained. Another possible explanation would be the fact that Block2 appeared first in ADF which had no Campaign but did have an AWACS platform, or possibly that the Mission Planner (Custom Combat, etc.) animations are linked to Block2 (IIRC EF2k has no animations in it's GUI)...

Share this post


Link to post
Share on other sites

I'm really keen on seeing that 'blowing up' appear in TFXplorer. It would be interesting to see if the state of *all* campaign objects could be held in RAM to avoid that animation.

(I guess that would be ~100 MiB for all terrain objects — 400×400 supershapes with 10 objects and 40 B of state information each, plus some state for the supershapes. More interesting: Seems like TFX's state information is just numbers and offsets, but no C pointers. So, technically, the entire scenario could be held in a 100-MiB memory-mapped file on your hard drive; and with dirty flags, you could save, load, or e-mail any scenario at any frame with exact reproducability. Just dreaming here.)

Share this post


Link to post
Share on other sites

I guess you'd need a lot less space than that, due to there being so few tiles which need to store state. For the second stock campaign for example, I have a .sav file of about 175kB and contains mostly zeroes.

Share this post


Link to post
Share on other sites

Yes, but if you do that, you'll need to replay the 'blow up' animations. (I guess TFX just stores 'is this object damaged?' and if it is, it repeats the animation so it looks exactly like a damaged object has to. I, on the other hand, speak about dumping the entire object state, including animation progress.)

Share this post


Link to post
Share on other sites

For the second stock campaign for example, I have a .sav file of about 175kB and contains mostly zeroes.

Trying to confirm that connection, however, I'm not yet able to understand the .sav file format.

More interesting: Seems like TFX's state information is just numbers and offsets, but no C pointers. So, technically, the entire scenario could be held in a 100-MiB memory-mapped file on your hard drive; and with dirty flags, you could save, load, or e-mail any scenario at any frame with exact reproducability. Just dreaming here.)

Are you referring to the .sav file here?

Share this post


Link to post
Share on other sites
Are you referring to the .sav file here?
No; to .ssd and .3. E.g. for a shape, the entire state is 19 2-byte integers. Writing this to a file and reading it out again is not hard. SSD is more complicated, of course, but from what I've seen so far, it is also just values, indices, and some integer variables. I.e. in RAM it looks exactly like it does on disk, so game state could be backup up on HDD in real time.

Share this post


Link to post
Share on other sites

The .sav file looks like a RAM dump. I've had a quick look at one for the first time in years.......but I have no idea where to start decoding it, despite the extra knowledge that we've now amassed. :(

Share this post


Link to post
Share on other sites

The .sav file looks like a RAM dump. I've had a quick look at one for the first time in years.......but I have no idea where to start decoding it, despite the extra knowledge that we've now amassed. :(

When I ran it through the Disassembler, it spit out an error re: The processor type 'PDP-11' is'nt included in this version..., I am trying to find a plugin for PDP-11's, just to see what shakes out. I did find some .sav binaries from a PDP-11 software program and they do look somewhat similar to ours :huh:

Share this post


Link to post
Share on other sites

Now, that would be something if it turns out the game was designed to run on a PDP-11. ;)

I think you'll find that's a coincidence though.

Just looking through the file with a hex editor, the only recognisable structures are the text strings of the event log. Here it can be seen that when a shorter string overwrites a longer string, we get the terminating zero at the end of the new string....but the rest of the longer string can still be seen. This indicates to me that the .sav file is a 'simple' memory dump.

Share this post


Link to post
Share on other sites

yes, I'm sure it's just a coincidence. I was interested to know what a PDP-11 was so I investigated it and now I know.

Preliminary update on the ship wake issue:

In general, the Ship files Pointer 92 increments to display the wakes and sprays when paused.

In general, the Ship files Pointer 93 decrements to remove the wakes and sprays when UNpaused.


;Block4_Pointer_92 Starts 1416 Length.50

1a0001000600000001000308feff0500

1a0002000600000001000308feff0500

1a0003000600000001000308feff0500

0000

;Block4_Pointer_93 Starts 1466 Length.50

1a0001000600000802000300feff0500

1a0002000600000802000300feff0500

1a0003000600000802000300feff0500

0000

If I simply swap pointers (4102 for 2802 and 2702 for 4002) it facilitates the wakes and sprays unpaused which, IMHO, look much better.

Share this post


Link to post
Share on other sites

Well, before categorizing the files, I've tried running through each file with every 'action code' and handling every opcode as they are encountered. The handling right now only consists of noting the length of the command string and jumping to next opcode.

Anyway, with one exception, the code always encountered a closing 0000, and exited gracefully.

The exception is dam_2.ssd, where for a nomal terrain tile 'Action code 2' usually points to a 0000 and returns, a bit like a NOP.

In dam_2 this 0000 is missing, so the bytecode engine tries to run the COLLISION_BOX data.

These are the opcodes encountered so far, with some conjecture.


0000 Return


0100 Jump (only used in Block7)

0300 Handle shape (Block6 only)

0500 Handle shape with parameters (Block6 only)

0700 Load shape into some list? (only used for Action code 1?)

0800 Load shape with coordinates (only used for Action code 1?)

0a00 Write multiple Local State words

0b00 Write a Local State word

1300 ?? (only used in Block7 aircraft SSDs)


1400 Manipulate Shape parameter 0

1500 Manipulate Shape parameter 1

1600 Manipulate Shape parameter 2

1700 Manipulate Shape parameter 3

1800 Manipulate Shape parameter 4

1900 Manipulate Shape parameter 5

1a00 Manipulate Shape parameter 6

1b00 Manipulate Shape parameter 7


2500 Decision (Jump if Local state variable = )

3a00 Decision (Jump if Local state variable > )

3c00 Similar to 0700 (maybe for non-player planes)

5300 ??

5b00 ??

6b00 Similar to 0800 (maybe for non-player planes)

7c00 Load 2 Local State words, sound related.

8300 Turn sound on (continuous like engines)

8400 Turn sound off

8500 Play sound (one-off like explosion)


8600 Manipulate Shape parameter 8 (F22 only)

8700 Manipulate Shape parameter 9 (F22 only)

8800 Manipulate Shape parameter 10 (F22 only)

8900 Manipulate Shape parameter 11 (F22 only)

8a00 Manipulate Shape parameter 12 (F22 only)

8b00 Manipulate Shape parameter 13 (F22 only)

8c00 Manipulate Shape parameter 14 (F22 only)

9000 Manipulate Shape parameter 15 (F22 only)

9100 Manipulate Shape parameter 16 (F22 only)

9200 Manipulate Shape parameter 17 (F22 only)

9300 Manipulate Shape parameter 18 (F22 only)

There is another level of bytecode triggered by some of those opcodes, where opcode 0700, for example, has a completely different function.

We can deal with that when we decode the individual actions.

As I am working on my Hypothesis, a number of questions have arisen. Where is a Parameter 8 found, ie. in what shape file is the corresponding 0048? The parenthesized "(F22 only)" means the opcode is found only in F22.ssd, something other than that?

Thanks!

Share this post


Link to post
Share on other sites

Ah yes, it seems there was too much exuberant conjecture in that post. Sorry...

I guess that last part should read thus,

8600 ?? (F22 only)

8700 ?? (F22 only)

8800 ?? (F22 only)

8900 ?? (F22 only)

8a00 ?? (F22 only)

8b00 ?? (F22 only)

8c00 ?? (F22 only)

9000 ?? (F22 only)

9100 ?? (F22 only)

9200 ?? (F22 only)

9300 ?? (F22 only)

'F22 only' does indeed mean that those opcodes are only found in f22.ssd.

Share this post


Link to post
Share on other sites

Here is my Block 2 Hypothesis Revision 1:

F22-Block2-Actions_zps74ec18eb.jpg

Parameter 8 has not been found so I threw it out :o and that seems to work.

My F22.ssd index: A work in progress

9c8e77b8-5ad7-44d5-ad59-126325ceb30e_zps86aebc6a.jpg

27de3630-7827-40e5-b0ed-2f324be43b33_zps916b938b.jpg

fa492cdd-357d-477f-b6b4-05bcf93a73f6_zps6c2692f3.jpg

7d2f3b0c-79d1-4db7-828f-6a36505fd915_zps64a64edf.jpg

Share this post


Link to post
Share on other sites

Regarding block 2, could it be that the entry for each shape is one more than the highest ' Parameter XXXX' associated with that shape?

For instance, buildings usually (always?) have a value of 08 in the ssd block 2, and the highest parameter value in the .3 file is 'Parameter 0007' for damage.

EDIT:

No, that can't be right as the Block 2 entry for the Runway ends is 01 and these have 'Parameter 0000' and 'Parameter 0001' in their .3 files.

....oh well, back to square 1.

Share this post


Link to post
Share on other sites

Chaff is a good one to analyze. Fx_chaff.ssd has only one shape in its Block5 index: chaff.3. Chaff.3 has only one parameter: 0000.

fx_chaff.ssd:


;Block1 Starts 0 Length.10

0001e803011dffff0400

;Block2 Starts 10 Length.100

0a000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

00000000000000000000

;Block3 Starts 110 Length.0


;Block4 Starts 110 Length.8

04002b002c002c00

;Block5 Starts 118 Length.6

7a00

0d00; CHAFF

ffff

;Block6 Starts 124 Length.14

050000000d00fcff000000000000; Object 0 Scale -4 Rot X 0.0 Rot Y 0.0 Rot Z 0.0 CHAFF

;Block7 Starts 138 Length.60

1400000009000001000200030004000300020400f9ff

8700000005000000070004000500

01000e00

8500100000000000320001009001000000000000

;Block4_Pointer_1 Starts 198 Length.4

07000000

;Block4_Pointer_2 Starts 202 Length.2

0000

;Block4_Pointer_3 Starts 204 Length.2

0000

;Lab_Block Starts 206 Length.0

The 1400 manipulates the parameter 0000 in chaff.3, which leaves the 8700 opcode. 8700 is basically a gosub to the "chaff_rel" (release) sound pointed to by the 8500. According to my revised index, Block2 0a = 8700.

Run in it's default state, the chaff release is accompanied by the "chaff_rel" sound. If the Block2 0a is changed to 00 the sound disappears. This suggests the Block2 0a runs the 8700 opcode. Still working to figure out the details...

Share this post


Link to post
Share on other sites

Interesting. Any idea what happens if you change the Block2 0a to say, 0b?

Share this post


Link to post
Share on other sites

I'll preface this by saying that the fx-chaff / chaff is included in the executable with hardcoded weapons which may introduce confounding variables, that said:

0 - 8 = No sound

9 - 13 = normal sound

at 14 the scale of the chaff seems to double

and the game begins to be unstable.

The good news is that the double-size chaff seems to be more effective at spoofing missiles :lol:

Share this post


Link to post
Share on other sites

Point of Information: TAW followed upon the EF2000 code, it may be worth noting that EF2000 (efa.3) had only parameters 0 through 7.

Share this post


Link to post
Share on other sites

...and no ssd Block 2.

I think that's the reason I assumed that Parameters 8 to 18 were associated with the 8600 to 9300 opcodes. It seemed reasonable at the time.

Share this post


Link to post
Share on other sites

The quest for clues for the hardware mode has been helpful. When the known extracted components of the hardware mode are placed in an active status within the program and are initialized, a number of error messages are generated. The first of which is that of the game being unable to find "TAXIWAY.TM". The hardware.tm directory does not contain TAXIWAY.TM as does the default redXXXX.tm's, again the question is why? The short answer could be that the hardware mode uses a different texture map ™ for the taxiways or a different taxiway object (.3) file, which does not call TAXIWAY.TM. There is now evidence of the latter. Previously discovered were a number of new supershape and object files for airbases, which do not call TAXIWAY.TM, but instead utilize an alternate means of taxiway implementation. Mybase.SSD is one of those curiosities and uses ATT_BASE.3, for taxiway provision, as opposed to the default taxi_XXXX.3. I was able to modify mybase.ssd to work in the redsea and seaworld environments, however, that was only after troubleshooting the bytecode differences and activating the ppropriate files. The details of those differences may suggest one or more alternate modes and here we will discuss a number of those differences.

The first is the contradiction of our currently accepted SSD rule regarding in-game object initiation. In the standard mode TAW game, when we want to create an ingame object, we need to run the initiation part of the bytecode by addressing Pointer 0 of Block4. In mybase.ssd, we need to address pointer 4 data in order to run the object initiation block.

mybase.ssd:


;Block4_Pointer_1 Starts 954 Length.2

0000

;Block4_Pointer_2 Starts 956 Length.2

0000

;Block4_Pointer_3 Starts 958 Length.2

0000

;Block4_Pointer_4 Starts 960 Length.222

080000000000

080001000100

080002000200

080003000300

080004000400

080005000500

080006000600

080007000700

080008000800

080009000900

08000a000a00

08000b000b00

08000c000c00

08000d000d00

08000e000e00

08000f000f00

080010001000

080011001100

080012001200

080013001300

080014001400

080015001500

080016001600

080017001700

080018001800

080019001900

08001a001a00

08001b001b00

08001c001c00

08001d001d00

08001e001e00

08001f001f00

080020002000

080021002100

080022002200

07002300

080024002300

0000

The second is the different index codes for the TARGET_AREA_DATA. In the standard game at_taif.ssd, the code maps to index position 7a (; "AT_TAIF_AIRPORT"), however, in mybase.ssd, which is also an at_taif area airbase, the code maps to position 71. The standard game returns a .PDL error not finding Taif 1, unless this is corrected. Why does mybase map to 71? :popcornsmilie:

;TARGET_AREA_DATA Starts 10420 Length.4

71001800

The third difference is in the SFXINFO block. As at_taif.ssd has no sound effects associated with it, we can not provide a direct comparison, however, our standard rules regarding the SFX section will assist us here. Although there is incomplete understanding of the details of the SFXINFO lines, we do know that EF2k did not contain this block which is unique to TFX3. In TAW SFXINFO lines, the first 2 bytes give the number of entries, followed by 18 bytes per entry. In mybase.ssd, instead of 18, it has but 9. The lines in mybase contain the coordinate locations for, what I assume, is the point of sound origin:

Mybase-SFX_zpsbd30c912.jpg

The siren should emanate from the huge "HORN" tower which stands in the center of the base and has a large radar dish at the top which rotates perpetually from the Block7 1400 opcode, somewhat similar to the airbase windsock function.

capture_10052013_213613_zps938815a0.jpg

Share this post


Link to post
Share on other sites

...and another important and unique difference is that mybase.ssd contains a Pylon block with 3 pylons and the preliminary effect I experienced in-game, when NME fighters fly over the base is extremely curious :D

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