💡 OPEN FEATURE: EF2000 Destroyable Buildings

[Krishty]

You cannot destroy the buildings in EF2000.

That’s because TFXplorer can only process target information for ADF/TAW supershapes. In TFX/TFX Supershape.cpp (1027):

Code: Select all

// For TFX3 SSDs, an array of usage types for each shape follows.
if(28 <= header.version) {
	auto const & types        = read<UInt1B[100]>(remainingBytes);
	auto         toType       = toBeginningOf(types);
	auto const   toEndOfTypes = toType + header.numberOfShapes;
	auto         shapesIndex  = 0u;
	do switch(*toType) {

		case 0: // Decoration (usually trees)?
			break;

		case 1: // Terrain if terrain SSD; ??? if plane SSD?
			break;

		case 2: // Special effect?
			break;

		case 8: // Target?
			targets.toEnd->shapesIndex = UInt1B(shapesIndex);
			++targets.toEnd;
			break;

		default:
			report(supervisor, Error::ssd_unknownShapeType);
			return no;

	} while(++shapesIndex, ++toType < toEndOfTypes);
}

I need to know how EF2000 stores target information in its supershapes. After implementing that, we could have destroyable targets as well.

[mikew]

The EF2000 system looks very similar to that of TAW with Collision Boxes etc.
I didn't do much more than parse the ssd files into blocks of text when I last looked at this in 2012 (!).

[Krishty]

The EF2000 system looks very similar to that of TAW with Collision Boxes etc.
I didn't do much more than parse the ssd files into blocks of text when I last looked at this in 2012 (!).

Similar indeed, but not bitwise compatible.

Things go wrong pretty fast in parsing the COLLISION_BOXES section (which seems to have different opcodes?) and also in the TARGETS section (where f22 uses 20-byte structures, but ef2000 uses something else).

[mikew]

The TARGETS section in EF2000 also uses the same 20 byte structure as far as I can see (only looked at airfld_1.ssd)

I just have a big block of text in the COLLISION_BOXES section, so it would need to some effort to sort it out, although I have some scripts from around 2018 for TAW which could probably help.

[mikew]

..but just checking the data for the first building shows some differences in opcodes and structure between TAW and EF2000 although the 1b00 opcode seems the same.

collef.PNG (26.16 KiB) Viewed 1972 times

[mikew]

Hmmn, I'm having trouble remembering even how the TFX3 COLLISION_BOX system works so will put these links here for easy reference:
https://web.archive.org/web/20220402065 ... es/page/3/
https://web.archive.org/web/20220402064 ... es/page/5/

The biggest issue I'm having is working out which TFX2 collision box relates to which object. TFX3's SSD Block2 helped in this regard.

[mikew]

The collision box for rig_1.ssd is this:
f8ff dbff f8ff 0800 0800 0800
That's the oil rig in the middle of the tile.

...and for the first collision box in airfld_1.ssd:
7b00 fcff 6a00 8a00 0400 7300

These suggest that the bottom of the Collision Boxes are underground.

[mikew]

I see from the cpp file that the indices for COLLISION BOX, TARGETS etc are hardcoded, but the contents of TFX2's ssinfo.lab are in a different order which probably explains why the TARGETS section looks odd.
There must be a list of target types somewhere in the EF2000 exe as the system seems the same, but the individual entries will be different.

[mikew]

The COLLISION BOX blocks are basically the same as for TFX3, with an undamaged state, a destroyed state and 3 intermediate states.
The intermediate and destroyed state are accompanied with some 'Action' bytecode starting with '1b00' or '4f00' whcih control the 'animation' of the visual damage and generate sound effects etc. I don't know if these are actually used in TFXplorer.

[Krishty]

I see from the cpp file that the indices for COLLISION BOX, TARGETS etc are hardcoded, but the contents of TFX2's ssinfo.lab are in a different order which probably explains why the TARGETS section looks odd.

Yes but in my internal build I already adjusted the tag handling to comply with EF2000’s ssinfo.lab. The data is still screwed.
Can’t remember right now which tile loads first but when I looked at it, it should have 20-byte entries under COLLISION_BOXES, yet that section had a size of 190 B (not evenly divisible, i.e. must be different format or we’re missing something). But I’ll check again to be sure!

There must be a list of target types somewhere in the EF2000 exe as the system seems the same, but the individual entries will be different.

Oh right! I’ll adjust this as well.

The COLLISION BOX blocks are basically the same as for TFX3, with an undamaged state, a destroyed state and 3 intermediate states.
The intermediate and destroyed state are accompanied with some 'Action' bytecode starting with '1b00' or '4f00' whcih control the 'animation' of the visual damage and generate sound effects etc. I don't know if these are actually used in TFXplorer.

Very good to know. No, I don’t use the bytecode but I’ll try to adjust my code with this info!

[mikew]

Then it's probably enough to get the undamaged Collision Box coordinates for each object together with a some target ID.
There's a quick way to do that that could probably simplify things by 90% or so.

The biggest problem might be getting the target IDs, In TFX3, the list is in at least 3 different places, two data files (eg stratval.txt) and in the code.
For TFX2, I don't see any useful data files, except to get names to do a string search in the exe. There are bunches of strings that we can probably triangulate the exact indices when we see where the collision boxes appear on a tile.

[mikew]

Indeed, some of the TARGETS sections are problematic, same with TARGET_AREA_DATA.

The COLLISION BOXes can be located without using ssinfo.lab, and the last word in Block4 is a pointer to another Block near the end, like this one for 'airfld_1.ssd' which has 13 boxes:

Code: Select all

;Block4_Pointer_3 Starts 5800 Length.80

0b000400b401
0b0006000302
0b0008005202
0b000a00a102
0b000c00f002
0b000e003f03
0b0010008e03
0b001200dd03
0b0014002c04
0b0016007b04
0b001800ca04
0b001a001905
0b001c006805
0000

The last word of each line is the number of words from the start of Block4 to the first coordinate of the 'Undamaged' section of each collision block 'set'.
Everything for a particular COLLISION BOX can be referenced from there, eg 6 words earlier is the 'type' that should tie up with the TARGETS section.

So, for the first COLLISION BOX in airfld_1.ssd:

Code: Select all

;COLLISION_BOXES Starts 1036 Length.2056

4f00 1e00 0300 0b00 1c00 2d00 3e00 
7b00 fcff 6a00 8a00 0400 7300
0000
7d00
7b00 fcff 6a00 8a00 0400 7300 
1b00 0c00 0800 0700 9f08 0000 0000 0000 0001 0500 
0000
7d00
7b00 fcff 6a00 8a00 0400 7300 
1b00 0c00 0800 0700 8d08 0001 0001 0001 0002 0500 
0000
7d00
7b00 fcff 6a00 8a00 0400 7300 
1b00 0c00 0800 0700 7b08 0002 0002 0002 0003 0500 
0000
1b00 0c00 0800 0700 6a08 0003 0003 0003 0004 0500 
0000

...that pointer would point to the 7b00 entry in the second line which is the first of the 6 parameters defining the box.