CMP to SUR Conversion Tests

No, it really is a 15-bit number:```
mov ecx, [eax] ; retrieve the encompassing dword
shl ecx, 1 ; remove the flag bit
sar ecx, 17 ; strip the low 16 bits, giving the 15-bit signed offset

Erm… sorry to rain on your parade guys…

You haven’t picked up the duplicate sur parts that cover the hull parts and (wings+weapons) parts. These exist in every standard FL ship, and have hashcodes like 00000290, 00000270, 00001b10, 000018d0, 00001e10. The easy ones are the 00001b10, 000018d0 and 00001e10 which are the shield bubble duplicates, and usually these have the “4-digit” numbers as I call them. The “3-digit” ones like 00000270 and 00000290 are wings+weapon surs but have no clear meaning of left/right or function - for example in the bw_elite (stiletto), there are two identical left wing+weapon surs both with the hash 00000270, but of the two identical right wing+weapon surs, one has the hash 00000270 and the other has the hash 00000290 !

In the bw_vheavy_fighter (sabre) there are two wingsets, upper and lower, and these have only 1 wing+weapon sur each - the two upper wing+weapon surs (1 left and 1 right) both have the hash 00000540 ! And the two bottom wing+weapon surs (1 left and 1 right) both have the hash 00000270 !

The 2 bw_freighter hashcodes you haven’t identified cover the front hull of the dromedary and the rear hull, and both have identical duplicates. I am still looking but it will just be a random name someone chose like maybe “dromedary_front_hull” and maybe “dromedary_rear_hull” so they won’t be found easily!!

The odd thing is neither of them match any of the .cmp group names so I don’t see how they can work under the conditions that we have deduced for them to work, but obviously they do work !

Here’s the full listing of the dromedary (bw_freighter) surs as imported by the sur importer, and observations…

M01_Root - covers middle of hull
M02_f00fb9de (HpMount) - the Shield Bubble
M03_HpMine01 - HpMine01
M04_HpCM01 - HpCM01
M05_HpShield01 - HpSHield01
M06_HpThruster01 - HpThruster01
M07_HpWeapon02 - HpWeapon02
M08_HpWeapon03 - HpWeapon03
M09_HpWeapon01 - HpWeapon01
M10_HpTurret04 - HpTurret04
M11_HpTurret01 - HpTurret01
M12_HpTurret05 - HpTurret05
M13_bw_star_eng_lod1 - covers starboard (right) engine
M14_bw_port_eng_lod1 - covers port (left) engine
M15_bw_port_wing_lod1 - covers port (left) wing
M16_HpTurret02 - covers HpTurret02, on top of port wing
M17_bw_star_wing_lod1 - covers starboard (right) wing
M18_HpTurret03 - covers HpTurret03, on top of starboard wing
M19_bw_glass_lod1 - covers cockpit glass
M20_E5A5F5DD - covers front part of hull
M21_0E4ADA66 - covers rear part of hull
M22_baydoor01_lod1 - covers right baydoor
M23_baydoor02_lod1 - covers left baydoor
M24_00001B10 - duplicate of shield bubble, same location
M25_bw_star_eng_lod1 - duplicate of M13 but located near origin. Should be centred on M13.
M26_bw_port_eng_lod1 - duplicate of M14 but centred near origin. Should be centred on M14.
M27_bw_port_wing_lod1 - duplicate of M15 but centred near origin. Should be centred on M15.
M28_HpTurret02 - duplicate of M16 but centred near origin. Should be centred on M16.
M29_00000290 - shape covers port wing plus HpTurret02 but is centred near origin. Should be located on M15+M16.
M30_bw_star_wing_lod1 - duplicate of M17 but centred near origin. Should be centred on M17.
M31_HpTurret03 - duplicate of M18 but centred near origin. Should be centred on M18.
M32_00000290 - shape covers starboard wing plus HpTurret03 but centred near origin. Should be located on M17+M18.
M33_bw_glass_lod1 - duplicate of M19 but centred near origin. Should be centred on M19.
M34_E5A5F5DD - duplicate of M20, same location.
M35_0E4ADA66 - duplicate of m21, same location.
M36_baydoor01_lod1 - duplicate of M22 but centred near origin and rotated 90 degrees clockwise (looking from top)
M37_baydoor02_lod1 - duplicate of M23 but entred newr origin and rotated 270 degrees clockwise (looking from top)

Aha! Thanks Lancer, now light begins to dawn!

So there is only one “physical” mesh of the shield bubble (or wing+weapon) sur, e.g. “HpMount” (f00fb9de) and the second shield bubble is using the same set of vertices as the first shield bubble mesh, by using the offset 00001b10 (which should be where the mesh pointers are located), is this right?

But the wing+weapon sur is defined using only the offset, twice, but likewise with only one set of vertices? (By the way - where are the vertices for that first mesh listed?)

If so then we still need to find a way to make and export these sur entries correctly with their correct structure/format from MilkShape to get complete surs. Is the type code different for these then?

(Yes! Type = 5 for these!)

However what of the anomaly of the stiletto, where one wing+weapon sur has offset 00000290 and its identical duplicate has the offset 00000270?

Is this an error in that sur file?

It looks correct when imported into MilkShape, although only one of them is in the correct location over the wing and weapon, and the other is near the origin.

Good work guys, sorry I can’t be of real help to you but I will keep clarifying with you when I fail to understand.

Thanks for replying to my meanderings!

The stiletto is SHIPS\BORDER_WORLD\BW_ELITE\bw_elite.sur

Yes, the possible problem is exactly this, that I would expect to find 2 x 00000290 meshes and 2 x 00000270 meshes.

Inthe Stiletto one of the starboard wing+weapon surs is 00000270 and its duplicate is 00000290, and the port wing+weapon is 2 x 00000270, so there are 1 x 00000290 and 3 x 00000270 surs in that file. I just spotted that 00000290 has 39 verts and 00000270 has 36.

The surs are mirror images, so is there maybe another way to use the same mesh and specify that it is in reverse order?

I just also confirmed that the dromedary (bw_freighter) has only one 00000270 and one 00000290. So the Stiletto may well have a bad sur file if it needs only 1 x 00000290 and 1 x 00000270?

Oh dear - so I didn’t understand then - each 00000270 has a separate physical mesh in the sur file?

So do we know why these are using an offset instead of a proper mesh name like other sur parts?

And - where is this offset measured from please?

Ok, got that, I’ll investigate when I’m more awake, thanks.

I have to say that your discoveries sound extremely exciting! I hope you can finally crack open this elusive format… That would be an exceptional achievement for sure.

Thanks for all you’ve both done so far!

Right, enough messing around, when is this going to be finished? Some of us have mods to complete rofl

Joking aside, doing a sterling job chaps, can’t wait for a working version. Just wish i knew what you were all on about…

FriendlyFire wrote:
I have to say that your discoveries sound extremely exciting! I hope you can finally crack open this elusive format… That would be an exceptional achievement for sure.

Thanks for all you’ve both done so far!

+1, totally agree. When you guys figure this out, it’s going to be a huge leap forward in mod development. I’m getting giddy with anticipation.

NEXT STEP… .dfm’s

lol… yeah im cruel

I’ve already told you it’s not RGB, but another scale for the radius. Using your notation, it’s something like:

...
radius1 = Radius / 250
if (radius1 * R + something <= abs(CX)) then exit
if (radius1 * G + something <= abs(CY)) then exit
if (radius1 * B + something <= abs(CZ)) then exit
...
```That's pretty much all I can tell you, so I'll leave the rest to you. Oh, I'll just clarify some things.

Next Surface Offset 26836 0x000068D4 + 0x00000038 = 0x0000690C

Dupl Surface Offset 26836 0x000068D4

hey guys, just to let you know there is +1 who appreciates all the efforts put into this, keep it up!