Jump to content
COMBATSIM Forum
mikew

Interpretation of SSD files

Recommended Posts

From another thread:

On 3/4/2018 at 2:49 PM, Krycztij said:

Terrain collision information *should* be generated automatically from the visuals. If you desperately need to override it, you could insert an object group with a special name, e.g. starting with COLLISION_, I guess.

I first assumed you'd done this with TFXplorer since you can derive the physical world from the visual.

 

Looking at COLLISION_BOXES again, I see that TFXplorer code (at least from Dec 2016) can be tidied up somewhat in this area. I just need to finish working out the rules...

What I am having trouble with is seeing how the COLLISION_BOX coordinates tie up with those of the .3 shape.

For rig_1.ssd that uses oilrig.3, the visual model is over twice as big as the collision box assuming a common scale.

There is no 'scale factor' in Block 6 for this object, so I assume the scaling is defined somewhere in the .3 file. Does anyone know?

Share this post


Link to post
Share on other sites
8 hours ago, mikew said:

I first assumed you'd done this with TFXplorer since you can derive the physical world from the visual.

 

TFXplorer doesn’t for two reasons:

  1. It’s hard. There is no path through a .3 shape that draws all triangles; it’s always branching on viewer position (which does not exist with physics) and so you always miss triangles. If you explore all branches, you’ll have overlapping/duplicate triangles, which is just as bad (triggers duplicate collisions, so a ball will bounce off the ground twice as fast). I never had the energy to find a good solution.
  2. I designed TFXplorer to follow ADF/TAW behavior as close as possible (after all, we wanted to speed up TAW 2.0 modding!), and this would have been a major difference.

Remember that one mountain in EF2000 where physics and visuals don’t match? We never solved that one :)

 

8 hours ago, mikew said:

Looking at COLLISION_BOXES again, I see that TFXplorer code (at least from Dec 2016) can be tidied up somewhat in this area. I just need to finish working out the rules...

 

Yes please! The code was a rushed-down combination of copy-pasting your Python code and hacking in TFX 2 compatibility. It’s full of crashes and security issues. It needs a full rewrite, I’m afraid … keep me informed on anything you find.

 

8 hours ago, mikew said:

What I am having trouble with is seeing how the COLLISION_BOX coordinates tie up with those of the .3 shape.

For rig_1.ssd that uses oilrig.3, the visual model is over twice as big as the collision box assuming a common scale.

There is no 'scale factor' in Block 6 for this object, so I assume the scaling is defined somewhere in the .3 file. Does anyone know?

 

Should be the 0030 opcode:

Quote

// 0030 <unit length>
// Scale the following transformed positions by 1 ÷ <unit length>.

 

Every shape has one, and they are often nested …

Share this post


Link to post
Share on other sites

Thanks for the technical details of why you'd want to split the collision info from the visual. I hadn't really thought it through and was wondering why there was seemingly redundant information taking up space in the data files. It probably also helps to split the artists from the programmers.

 

oilrig.3 does indeed have a 0030 opcode, but I was erroneously looking at TFX1's oilrig1.3 which doesn't. I really need to sort out my files...

On the plus side, oilrig1.3 has a 0052 opcode where I'd expect the 0030 to be, so it may have a similar function. We can worry about that later when we try and find out why those TFX1 runway numbers are in the wrong place.

 

All I wanted to do was add an object to a tile,  but that's not trivial even for a purely decorative object as the whole ssd file has to be remapped. It's even worse when adding a new collision box.

The whole process becomes much easier if we can break down the ssd into its component parts** whether we use them or not.

Once we get to that point, we can either recompile the ssd (or produce some other format like VRML) with the new object and the other parts we need.

 

At least that's the current plan for the TFX3 terrain ssds only. :)

 

**The components themselves may need to be broken down further and understood. For example, I don't know whether the collision box information takes into account any rotation defined in Block 6. I'm guessing it does as all the collision box coordinates relate to the tile.

 

Share this post


Link to post
Share on other sites

In TAW, there are 1016 different tiles present in redsea.lst although not all of them are accessed by redsea.env. Anyway, I've considered all 1016 tile ssds, of which 251 contain objects with collision boxes. Adding up all the objects gives 4467 that need to be analyzed.

Over 99% of them conform to the rules that I wrote a few pages back in this thread. The rest can be handled if the bytecode handler is constructed in a certain way.

It's taken me 3 attempts to create a 'machine' to handle everything, but still have to hard code a few exceptions. The 4th attempt would be perfect, but I can't be bothered to write it. :)

 

The information each COLLISION_BOX contains:

A 'header' containing offsets to the start of bytecode for each damage level>0 The pointer for each undamaged state comes from Block 4.

Each damage level then contains:

A set of dimensions for the new box

Actions to be performed.

 

There are only 3 types of 'action':
1.Describe how the damage is displayed by updating each shape's 'parameter 7'

2. Associated with 1. is a '4F00' subroutine which contains the 'Block 3' coordinates of the object and a number. Damage levels 1,2&3 have the same number and the 'dead' damage level 4 has another number which usually (and maybe always) differs by 1. This subroutine is not called in aswan_q

3. aswan_q has an extra opcode for explosion effects, by updating the shape's 'parameter 0', so this may give a clue to what the '4F00' block is for.

 

This information should help TFXplorer from crashing as it may be that the bytecode is mixed up with data at the moment.

 

If I ever get to the point where I'm creating a tile from scratch. I'll try and make sure it has the same format as the 99%.

Once we know the size each shape's bounding box at each damage level, we can use the Block3 and Block 6 data to construct the COLLISION_BOX section automatically.

When looking at the ssd data from a tile design point of view, some parts, eg Block2, become quite useful.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, mikew said:

This information should help TFXplorer from crashing as it may be that the bytecode is mixed up with data at the moment.

 

Thanks, I’ll try soon! If you want to see the crashes in person, fly to Aden. Fly to the tile with the large airport tower. Shoot at the buildings. You’ll see that the collision boxes don’t match the visuals and eventually, it’ll crash. I suspect it’s something about the order of collision boxes …

Share this post


Link to post
Share on other sites

I see what you mean. :)

 

I suspect something is going wrong with the pointers. That tile has a lot of data but it seems 'well behaved' in its construction.

 

At least for the terrain, I think we have a fairly good understanding of the ssd bytecode system now. There are still plenty of data blocks like 'routes' which may or may not be of use to TFXplorer, but we know where they are.

Share this post


Link to post
Share on other sites

Looking in more detail at the hardened hanger model (HDHA_180.3) collision boxes that I recently extracted, we see why there are multiple sets of coordinates for this model which is nearly square.

 

HDHA_180
[147, 50, 20, 28, 62, 96, 130]

Dimensions: Damage Level 0

(-88, -109, 380, -69, -100, 398)
(-82, -109, 376, -73, -100, 404)
(-92, -109, 387, -64, -100, 396)

 

There are three of these at Luxor, and the one above is positioned at (-78, -100, 390) according to Block 3.

 

So, normalizing and plotting out, we get something like this:

hdha180.png.6bc8f452e4aed82c1be973d6d78f062b.png

At Luxor, these hangers are rotated by 41 degrees, so instead of rotating a single collision box, it looks like they are taking a cruder approach...unless they are using the coordinates in a different way.

Share this post


Link to post
Share on other sites

Thanks! You've even got Luxor with rendering slightly better than mine. :)

I was hoping to 'simply' derive the bounding box from the .3 file vertices, but it doesn't seem so trivial. :(

 

Share this post


Link to post
Share on other sites

I'm now fairly convinced the '4F' opcodes relate to debris/explosions.

For some reason, these are all grouped together after the COLLISION_BOX blocks with two of these per object. As these are called from the '1B' opcode, it would make more sense for them to be part of the object's collision block.

Damage levels 1,2&3 usually point to the first 4F line, and Damage level 4 the second.

 

I've seen some correlation between the number at the end of the 4F line with the different levels of explosion effect described in 'coll.dat'.

For buildings, debris is thrown around depending on whether the explosion is classed as soft, medium,hard or volatile plus 'extra explosions' for some objects.

I don't know the exact numbering, but could probably work it by analyzing all objects...if we haven't done this before. :D

 

Here's 'rig_1.ssd' which is the most basic example.

coll_4f.png.6016c3de86a296fc97fe2d1c0b5328eb.png

Share this post


Link to post
Share on other sites
On 3/20/2018 at 4:01 AM, mikew said:

I'm now fairly convinced the '4F' opcodes relate to debris/explosions.

 

I've seen some correlation between the number at the end of the 4F line with the different levels of explosion effect described in 'coll.dat'.

For buildings, debris is thrown around depending on whether the explosion is classed as soft, medium,hard or volatile plus 'extra explosions' for some objects.

I don't know the exact numbering, but could probably work it by analyzing all objects...if we haven't done this before. :D

 

 

 

Your statement about 'debris/explosions' I agree with but I'm not thinking it's collateral. What we have done before generated statements in my notes suggesting that the 4F opcode lines, in addition to defining the coordinates, gives a lookup value for the specific index in the list of explosions found in the explosions section of the redxxxx.txt files.

 

0  0      ex_l_1    
1  1    ex_l_2   
2  2    ex_l_3   
3  3    ex_l_4   
4  4    ex_l_5   
5  5    ex_w_1   
6  6    ex_hit1  
7  7    ex_hit3  
8  8    ex_hit5  
9  9    ex_can_l
10 a    ex_smk_1
11 b    ex_smk_2
12 c    ex_smk_3
13 d    ex_smk_4
14 e    ex_smk_5
15 f    fx_hit   
16 10   fx_miss  
17 11   ex_can_w
18 12   ex_lcrsh
19 13   ex_wcrsh
20 14   ex_vol_1
21 15   ex_vol_2
22 16   ex_vol_3
23 17   ex_vol_4
24 18   ex_vol_5
25 19   ex_acrsh
26 1a   ex_ls1   
27 1b   ex_ls2   
28 1c   ex_ls3   
29 1d   ex_ls4   
30 1e   ex_ls5   
31 1f   ex_smks1
32 20   ex_smks2
33 21   ex_smks3
34 22   ex_smks4
35 23   ex_smks5
36 24   ex_vols1
37 25   ex_vols2
38 26   ex_vols3
39 27   ex_vols4
40 28   ex_vols5
     
  If that is correct, it would indicate that the explosions referenced for damage levels 1,2 &3, for rig_1.ssd   is ex_smks2 and that for damage level 4 is ex_smks1. The 5 ex_smks ssd files are nearly identical with the basic difference being a gradient of scale (block 6).
  

 

Share this post


Link to post
Share on other sites
6 hours ago, DrKevDog said:

  If that is correct, it would indicate that the explosions referenced for damage levels 1,2 &3, for rig_1.ssd   is ex_smks2 and that for damage level 4 is ex_smks1.

 

Great analysis :thumbsup:

Share this post


Link to post
Share on other sites

Indeed! That makes much more sense. :thumbsup:

...although I succeeded in bringing DrKevDog out of retirement. :)

Share this post


Link to post
Share on other sites

I've been trying to create a terrain ssd file from the ground up in order to apply what we've learnt about the format.

The first goal was to pick use a tile shape (tluxor) and put one object (tent_3) on it, then calculate appropriate COLLISION_BOX info and all the offsets needed to produce a viable ssd file at least as far as TFXplorer is concerned. Once the file was produced, the world files needed appropriate editing to put the new tile next to where we spawn in TFXplorer.

One mistake I made was assuming that all airbase tiles are at 800 ft altitude like Luxor, but Gondor's (gen_1rwy.ssd, and where we spawn in TFXplorer) is at 640 ft which means I can't just taxi there from Gondor, but the COLLISION_TRIANGLES seem to work as I've landed near the tent.

testtile.png.1657c1317f71b503069a4630d83f3a55.png

 

I can't destroy the tent with cannon fire though, so either my COLLISION_BOX info is wrong, or I need to 'activate' the target in some way similar to how it's done in TAW (by editing campaign.trg IIRC).

Is there anything else I need to consider?

Share this post


Link to post
Share on other sites
2 hours ago, mikew said:

Is there anything else I need to consider?

 

I have been working on a similar SSD project only not as ambitious as yours and in Tfx3.
I had hoped to find data to help me understand the line in the World Info file: "TARGETSPACE 8276".

It seems to me there ought to be a way to differentiate Target space from non-target space in the world.
I have not, and that said, most simple, flat tiles do not have Target Area data so perhaps that presence is necessary. In a TFX3 target tile SSD, there are 3 things I would examine:


1. TARGET_AREA_DATA  for correct target-tile type
2. TARGETS for individual targets Strategic Value and correct position
3. COLLISION_BOXES for Strategic Value and correct position
 
I would also look at the Campaign.trg as you eluded to...

I am very interested in your creating a viable SSD and look forward to the details of your success.:thumbsup:

Share this post


Link to post
Share on other sites

I haven't yet included the TARGET_AREA_DATA or TARGETS sections since I don't think TFXplorer uses them...but maybe it does.

 

This whole process isn't much fun as there's a lot of pointers to calculate. One mistake and nothing will work. :(

Share this post


Link to post
Share on other sites
On 4/5/2018 at 8:16 PM, mikew said:

Is there anything else I need to consider?

 

TFXplorer once had code to display the collision boxes, but I suspect I’ve deactivated it for a long time … maybe I’ll resurrect it this weekend for you (don’t know how much spare time I get :( ) …

 

 

22 hours ago, mikew said:

I haven't yet included the TARGET_AREA_DATA or TARGETS sections since I don't think TFXplorer uses them...but maybe it does.

 

This whole process isn't much fun as there's a lot of pointers to calculate. One mistake and nothing will work. :(

 

TARGET_AREA_DATA … I don’t even know what it’s for. TARGETS … not sure.

Share this post


Link to post
Share on other sites

It would certainly be nice to see the collision boxes.

 

TARGET_AREA_DATA consists of two words, eg from 'luxor.ssd',

;TARGET_AREA_DATA Starts 10138 Length.4

8400 1800

0x84=132 decimal and ties up with the 'colour' parameter in campaign.trg

; Target File Created by WorldEd 95 V1.0
; colour(0-255), x, y, rot, shapename, targetname
..
..
rem "Airbases_EGYPT"

127 92 373 0 "Hurghada"
132 67 344 0 "Luxor"
etc
etc

and that number can be considered an ENUM to this list that DrKevDog found:


CUSTOM
ARMY_BASE
COMMUNICATION_BASE
OIL_FIELD
DESALINATION_PLANT
EWR_SITE
INDUSTRIAL_COMPLEX
NAVAL_BASE
OASIS
COMMERCIAL_PORT
OIL_REFINERY
OIL_RIG
SAM_SITE
SECRET_BASE
SUPPLY_DUMP
TANKER_TERMINAL
TOWN
VILLAGE
ASWAN_DAM
DAM
MARIB_DAM
ABU_SIMBEL
ABYDOS_TEMPLE
AMADA_TEMPLE
LUXOR_TEMPLE_OF_AMUN
BEIT_EL_WALI_TEMPLE
DARA_PYRAMID
ELEPHANTINE_ISLAND_TEMPLES
EL_KULA_PYRAMID
EL_SIBU_TEMPLE
HATHOR
TEMPLE_OF_HATSHEPSUT
TEMPLE_OF_HORUS
KALABSHA_TEMPLE
VALLEY_OF_THE_KINGS
TEMPLE_OF_KOM_OMBO
PHILAE_TEMPLE
TOMBS_OF_THE_QUEENS
THEBES
TUKH_PYRAMID
ZAWYET_EL_MAIYITIN_PYRAMID
ADEN_1
ADEN_2
ADEN_3
ADEN_4
ADEN_5
ADEN_6
ADEN_7
ADEN_8
ADEN_9
AL_MUBARRAZ
ASMERA_1
ASMERA_2
ASMERA_3
ASMERA_4
ASWAN_1
ASWAN_2
ASWAN_3
ASWAN_4
ASWAN_5
ASYUT_1
ASYUT_2
ASYUT_3
BUR_AYDAH
BUR_SUDAN_1
BUR_SUDAN_2
BUR_SUDAN_3
BUR_SUDAN_4
CITY
DJIBUTI_1
DJIBUTI_2
DJIBUTI_3
DJIBUTI_4
DJIBUTI_5
DJIBUTI_6
DJIBUTI_7
DJIBUTI_8
GONDER
HARGEYSA_1
HARGEYSA_2
HURGHADA
JEDDAH_1
JEDDAH_2
JEDDAH_3
JEDDAH_4
JEDDAH_5
JEDDAH_6
JEDDAH_7
JEDDAH_8
JEDDAH_9
OMDURMAN_1
KHARTOUM_1
KHARTOUM_2
KHARTOUM_3
OMDURMAN_2
KHARTOUM_5
KHARTOUM_6
MECCA
MEDINA
MITSIWA
RIYADH_1
RIYADH_2
RIYADH_3
RIYADH_4
RIYADH_5
RIYADH_6
RIYADH_7
RIYADH_8
RIYADH_9
RIYADH_10
RIYADH_11
RIYADH_12
RIYADH_13
RIYADH_14
SAN_A_1
SAN_A_2
SAN_A_3
SAN_A_4
SAN_A_5
SAN_A_6
ADEN_AIRPORT
ASYUT_AIRPORT
AT_TAIF_AIRPORT
KING_ABDUL_AZIZ_INT_AIRPORT
DISPERSAL
DJIBOUTI_AIRPORT
GEN_1RWY
GEN_2RWY
BARIN_AIRBASE
JEDDAH_OLD
KHAMIS_MUSHAYT_AIRBASE
KHARTOUM_AIRBASE
LUXOR_AIRPORT
KING_KHALID_INT_AIRPORT
RIYADH_MILITARY
CROSSING_POINT



 

The second number (0x18) is somehow related to the number of entries in the following TARGETS section, but there are still some unknowns.

Share this post


Link to post
Share on other sites
On 11/13/2011 at 1:17 AM, DrKevDog said:

The magnitude of the 'BBBB' values seem to suggest a transformation type value, perhaps rotation :popcornsmilie:

It's taken a while (!) for it to sink in, but it turns out he's right. :thumbsup:

...well, mostly. If I try and cross-reference the coordinates in the TARGETS section with the Block3/6 etc information, we see some of  the angles not tying up with the rotations defined in Block 6, although those angles seem valid for other objects.

There are some other inconsistencies as well with the AAAA/Type numbers plus the 'extra' lines in the TARGETS section.

 

Here's some analysis of Luxor.

Luxor.ssd

Block6						CBOX	Block3					TARGETS
Object	Scale	Rot.	Shape		Block2	TYPE	Hex Coord.	X	Y	Z	TYPE	Hex Coord.	BBBB	Angle

0	-4 	20.0 	RWYEND02 	01	N/A	3eff9cff6cfe	-194    -100    -404
1	-4 	-160.0 	RWYEND20	01	N/A	78009cffcc01	120    	-100   	460
2 	-2 	20.0 	ADIS1P90	00	N/A	a1ff9cff3afe    -95    	-100    -454
3 	-2 	32.0 	ADIS2180	08	2e	07019cff5eff    263    	-100    -162	2e	 07019cff5eff 	2000	32
4 	1 	20.0 	_1WH90		08	2d	f5fe9cff8cfe    -267    -100    -372	2d	 f5fe9cff8cfe 	1400	20
5 	1 	20.0 	_2WH_180	08	2d	3eff9cff51ff    -194    -100    -175	2d	 3eff9cff51ff 	1400	20
6	1 	20.0 	LUX_H_90	08	32	defe9cfff7fe    -290    -100    -265	32	 defe9cfff7fe 	1400	20
7	1 	24.0 	KHA2HA90	08	32	0eff9cffa1ff    -242    -100    -95	32	 0eff9cffa1ff 	1800	24
8 	1 	20.0 	KHA1H_90	08	32	d2fe9cffb6ff    -302    -100    -74	32	 d2fe9cffb6ff 	1400	20
9 	2 	33.0 	LUX_T180	08	38	f2fe9cffa900    -270    -100    169	38	 f2fe9cffa900 	2100	33
10 	1 	33.0 	LUX_C180	08	30	90fe9cff3600    -368    -100    54	30	 90fe9cff3600 	2100	33
11 	-2 	0.0 	LUX_RADR	08	37	3e009cff80ff    62    	-100    -128	37	 3e009cff80ff 	0000	0
12 	1 	38.0 	FIREH180	08	35	05019cff9dff    261    	-100   	-99	35	 05019cff9dff 	2600	38
13	1 	20.0 	LIG_CD5B	00	N/A	e7fe9cff7bfd    -281    -100    -645
14	1 	41.0 	HDHA_180	08	32	b2ff9cff8601    -78    	-100    390	32	 b2ff9cff8601 	2900	41
15	1 	41.0 	HDHA_180	08	32	8aff9cff5701    -118   	-100    343	32	 8affa6ff5701 	2900	41
16	1 	41.0 	HDHA_180	08	32	9fff9cff6f01    -97    	-100    367	32	 9fffb0ff6f01 	2900	41
17	1 	20.0 	_2WH_180	08	2d	4bff9cff74ff    -181   	-100    -140	2d	 4bff9cff74ff 	60ff	-160
18	1 	20.0 	LUX_H_90	08	32	f1fe9cff2bff    -271    -100    -213	32	 f1fe9cff2bff 	1400	20
19	1 	110.0 	_1WH90		08	2d	fefe9cffa6fe    -258    -100    -346	2d	 fefe9cffa6fe 	6e00	110
20	1 	-160.0 	LIG_CD5B	00	N/A	d1009cffc002    209    	-100    704
21	-2 	20.0 	ADIS1P90	00	N/A	8eff9cff06fe    -114    -100    -506
22	-2 	20.0 	ADIS1P90	00	N/A	97ff9cff20fe    -105    -100    -480
23	-2 	32.0 	ADIS2180	08	2e	30019cff43ff    304    	-100    -189	2e	 30019cff43ff 	2000	32
24	-2 	32.0 	ADIS2180	08	2e	1d019cff4fff    285    	-100    -177	2e	 1d019cff4fff 	2000	32
25	-4 	20.0 	RWYMID01	01	N/A	faff9cff7100    -6    	-100    113	33	 faff9cff7100 	1400	20
26	1 	20.0 	TAXI_LUX	01	N/A	10009cff2500    16    	-100    37
27  	N/A	N/A	TLUXOR		01	N/A	N/A		N/A	N/A	N/A
28	1 	20.0 	LI2_LUXO	00	N/A	10009cff2500    16    	-100    37

;TARGETS Starts 10142 Length.480

54415247504f53000000 2e00 07019cff5eff 2000
54415247504f53000000 2d00 f5fe9cff8cfe 1400
54415247504f53000000 2d00 3eff9cff51ff 1400
54415247504f53000000 3200 defe9cfff7fe 1400
54415247504f53000000 3200 0eff9cffa1ff 1800
54415247504f53000000 3200 d2fe9cffb6ff 1400
54415247504f53000000 3800 f2fe9cffa900 2100
54415247504f53000000 3000 90fe9cff3600 2100
54415247504f53000000 3700 3e009cff80ff 0000
54415247504f53000000 3500 05019cff9dff 2600
54415247504f53000000 3200 b2ff9cff8601 2900
54415247504f53000000 3200 8affa6ff5701 2900
54415247504f53000000 3200 9fffb0ff6f01 2900
54415247504f53000000 2d00 4bff9cff74ff 60ff
54415247504f53000000 3200 f1fe9cff2bff 1400
54415247504f53000000 2d00 fefe9cffa6fe 6e00
54415247504f53000000 2e00 30019cff43ff 2000
54415247504f53000000 2e00 1d019cff4fff 2000
54415247504f53000000 3300 faff9cff7100 1400
54415247504f53000000 fe00 0dfe9cffaafd 0000
54415247504f53000000 fe00 78019cffb800 0000
54415247504f53000000 fe00 5b019cff8d00 0000
54415247504f53000000 fe00 e1019cff7500 0000
54415247504f53000000 fe00 e7fd9cffd1fd 0000

Anyway, the bottom line is that I could try to produce a TARGETS section from other object information, but there may not be much point.

 

 

Share this post


Link to post
Share on other sites

 

On 4/8/2018 at 7:05 AM, mikew said:

There are some other inconsistencies as well with the AAAA/Type numbers plus the 'extra' lines in the TARGETS section.

 

 

Testing the collision boxes problems should work just as well for any test platform, as long as the TARGET_AREA_DATA / TARGPOS formats

are identical. I think it is important to consider the progression of changes from tfx2 to tfx3 in the analysis of the target data

features. A significant question for me is are the tfx2 and tfx3 data read differently? There are a number of obvious questions, for

example, tfx3 has a unique campaign mode which is tied intricately to the target area data throught the AWACS mode GUI much differently  

than in tfx2.
There is a lot here to re-consider from the 2011 analysis, when that target type list was discovered. Take for example the columns you

have listed as "CBOX TYPE" and TARGETS TYPE", I would ask you to take a look at the "STRATVAL.txt" document in the F22DATA directory. It

is clear from the values in your 2 lists that the values in those 2 columns are identical and if you compare the target types in the

list you eluded to, you will find that it does not jibe as an ENUM to the list I found previously and is more reasonably explained as a

stratval type-pointer. This may suggest a connection to target values and, potentially, campaign score value assignments. Looking in the

executable there are 3 stratval errors which may be of some value in understanding the scope of these values. They state that, on some

level, strategic values can be identified as Static, Flight and/ or Group.
First, however, I think we need to declare our objective. If it is just to add a target type to the TFXplorer project, it probably isn't

necessary to confirm that "stratval" is or is not involved in these SSD functions.  

I have decided to proceed in this analysis for the TFX2 and 3 knowledge base objectives. I don't know if you received the updated

TFXplorer so I decided to look at what I do have that might be of some benefit.

There is a mechanism I use in EF2K to turn on the collision boxes which may be of good help in answering some of your questions;

capture_001_22042018_121622.jpg.452f5b27aef4e4b92dcc0783f7e25b8c.jpg

EF2k-col-Bx-21042018_223238.jpg.92f42fe7628d67b02ff9f037dd9e01e1.jpg

capture_002_22042018_123236.jpg.74109de4de8185b3e2a82bd8c73c8467.jpg

 

I can also turn on the terrain collision triangles and other trackers.

To summarize on the original question regarding:
TARGPOS000000AAAAXXXXYYYYZZZZBBBB.

I believe that AAAA is the Stratval number and I agree that BBBB is rotation as you deciphered it but

is that also true for tfx2 as it is for tfx3?

Share this post


Link to post
Share on other sites

Yes, AAAA can be considered as an ENUM to the list in stratval, but the same list is also in coll.dat and baked into the exe.

TFX2 probably has a similar system although I haven't really looked for an AAAA list.

 

Here's part of the EW site (early1.ssd)

 

 

 

 

 

 

 

 


;Block6 Starts 142 Length.178

05000000ff0302000000ee0e0000; Object 0 Scale 2 Rot X 0.0 Rot Y 21.0 Rot Z 0.0  DISHES
05000100ff030300000000800000; Object 1 Scale 3 Rot X 0.0 Rot Y -180.0 Rot Z 0.0  DISHES
05000200d3020100000000400000; Object 2 Scale 1 Rot X 0.0 Rot Y 90.0 Rot Z 0.0  BASE5
03000300fe03; Object 3  DISHES2
03000400fd03; Object 4  B_GLOB_1
03000500fd03; Object 5  B_GLOB_1
05000600ff030300000000400000; Object 6 Scale 3 Rot X 0.0 Rot Y 90.0 Rot Z 0.0  DISHES
05000700f8030200000000400000; Object 7 Scale 2 Rot X 0.0 Rot Y 90.0 Rot Z 0.0  HQ
0500080000040200000000800000; Object 8 Scale 2 Rot X 0.0 Rot Y -180.0 Rot Z 0.0  COMMSBUI
0500090000040200000000400000; Object 9 Scale 2 Rot X 0.0 Rot Y 90.0 Rot Z 0.0  COMMSBUI
05000a0000040200000000800000; Object 10 Scale 2 Rot X 0.0 Rot Y -180.0 Rot Z 0.0  COMMSBUI
05000b0000040200000000800000; Object 11 Scale 2 Rot X 0.0 Rot Y -180.0 Rot Z 0.0  COMMSBUI
05000c0000040200000000800000; Object 12 Scale 2 Rot X 0.0 Rot Y -180.0 Rot Z 0.0  COMMSBUI
03000d002704; Object 13  EWRMOUNT
05000e000204feff000000400000; Object 14 Scale -2 Rot X 0.0 Rot Y 90.0 Rot Z 0.0  LIG03

;TARGET_AREA_DATA Starts 5262 Length.4

0000 0d00

;TARGETS Starts 5266 Length.320

54415247504f5300 0000 0200 effd12fdf7ff0000
54415247504f5300 0000 0200 c0fe12fd0bff0000
54415247504f5300 0000 0300 d0fd12fdf9ff0000
54415247504f5300 0000 0100 bffd12fd82ff0000
54415247504f5300 0000 0100 bffd12fd99ff0000
54415247504f5300 0000 0200 98fe12fd64ff0000
54415247504f5300 0000 0400 3efe12fd59ff0000
54415247504f5300 0000 0900 e6fd12fdb8ff0000
54415247504f5300 0000 0900 97fe12fd4eff0000
54415247504f5300 0000 0900 c9fd12fdd7ff0000
54415247504f5300 0000 0900 c9fd12fdbaff0000
54415247504f5300 0000 0900 e5fd12fdd5ff0000
54415247504f5300 0000 ffff 32ff12fd05ff0000
54415247504f5300 0000 ffff 50fe12fdbdff0e01 ;angle 270
54415247504f5300 0000 ffff eefd12fdb9ff5a00 ;angle 90
54415247504f5300 0000 ffff 5cfd12fd36ff0000

 

Similar problems can be seen to TFX3 in that the BBBB numbers don't stack up with the Block6 rotations, and the second word of TARGET_AREA_DATA doesn't correspond to the number of TARGETS.

 

I still don't know which part of the game these are used for.

 

ps. Awesome work enabling the EF2000 debug info. 🎆

 

Share this post


Link to post
Share on other sites
10 hours ago, mikew said:

Yes, AAAA can be considered as an ENUM to the list in stratval, but the same list is also in coll.dat and baked into the exe.

TFX2 probably has a similar system although I haven't really looked for an AAAA list.

 

 

ps. Awesome work enabling the EF2000 debug info. 🎆

 

 

Okay I now see that there are three to which this static target list applies and has common namespace. In tfx3 in IDA, the off_6652C8 enumerates that list and in tfx2 (superw.dat) the AAAA list may be the one at DGROUP:0056BC40.

 

thanks about the EF2000 debug, I find it much more useful than that in tfx3 although I seem to recall Krycztij eluding to a dual screen process which I have not yet discovered.

There are still some things I wish to improve upon in the use of the process, for example: initially I could not get the collision boxes to remain stable for viewing. somehow I discovered that if I get the camera in a position of displaying an unstable CBox and I pressed the "C" key, all the boxes became stable. Do you know anything about that?

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

×