Looks good there 😃 Try experimenting with the other material options too; I think Bt or Detail map -something close- gave interesting results, especially on Nomad type materials. Some other funky options are changing the Int array value (it’s 64, 72, 80?). Someone else here can supply the numbers for that, I haven’t got FL installed on the new system yet or I’d provide those. But check in Planet atmosphere entries for one, and maybe the other is in starsphere -sorry for the poor guesses, but its a start ^^. The Nomad stuff has lots of options -not just the ships, but the Dyson Sphere and hrmm Nomad base / mothership, where you’ll also find a handy animated texture entry in the latter. Copying that can be tough, easier to just copy the whole node over and modify the tex name.

Looks like you got the glows set up and lookin’ good, next up, you might try a hand at texture animation. Might look cool for reversed sections (parts of the texture made transparent, so you can see the animated light texture moving behind it on another planar section). Looks rather neat for simulating electricity moving up wires and such. Key to making that look decent is by creating non-uniform “light” bands, otherwise one straight bar looks a bit hokey.

Pretty cool all the stuff you can accomplish with just materials alone.

Heyup.

Well here’s the little info that I know…

Simply…
The name of the sur part is the same as the cmp group that it relates to, so for each part being checked for hits or collision, FL looks for the same name in the sur file. If it is even slightly different, then the sur part will not be matched to the cmp group and there will be no hit or collision detected on that part of the ship.

In more detail…
You will see in a standard .cmp file that the groups are listed in the \Cmpnd node as Root (the main ship group, the one at the top of the Groups list in Milkshape when you export a model) and then a series of one or more Part_shipname_shippart_lod1 formatted entries. Each of these nodes in turn contains the name of the corresponding cmp group that it is indexing - in this case shipname_shippart_lod1.

In the sur file for the same ship, the corresponding sur part is also named shipname_shippart_lod1 but actually using the CRC (Cyclic Redundancy Check) character of shipname_shippart_lod1. If you use FLModel Tool to open the sur file and cmp file, some sur parts are recognised by FLModel tool so you will see the “English” name (because the author worked them out for us), but if it is not recognised then the name will appear as the hex CRC character of the name instead. This code can be easily found by putting the cmp group name (shipname_shippart_lod1) through CRC Tool or one of our other CRC/hash generator utilities, and you can then look for that hex code in the sur file in FLModel Tool.

Note that in the cmp files, the decoded signed CRC character is used, so it can be a negative decimal value! However in the sur files, the hex CRC character is used. Why should DA have set standards, eh?

Example:

The Borderworld Fighter (Dagger) has 7 cmp groups:-
Open the file DATA\SHIPS\BORDER_WORLD\BW_FIGHTER\bw_fighter.cmp in UTF editor then open the \Cmpnd node and you will see all the parts of the model are listed there:-

Root
Part_bw_baydoor02_lod1
Part_bw_baydoor01_lod1
Part_bw_eng01_lod1
Part_bw_port_wing01_lod1
Part_bw_star_wing01_lod1
Each of these nodes is an index into the .cmp file itself, it contains the real name of the cmp group, and the name of the corresponding node that contains the pointers to the model mesh for that group.

When you open one of the nodes, e.g. Part_bw_port_wing01_lod1 you will see a node named Object name. This node contains the name “bw_port_wing01_lod1”. This is the name of the cmp group.

When you open the ship’s sur file in FLModel Tool, and scroll down through it, you will find a mesh named TriangleID : 0xFE3AEE4E - “bw_port_wing01_lod1”.

Hey - Presto!! You can now see the connection that FL is looking for.

NOTE - when you make your own ship and give the groups names, remember that the cmp exporter will automatically place the “_lod1” suffix after each group name, except for the top group, which will be renamed “Root”. This “_lod1” suffix is needed in the .cmp file as you have seen, to match the name in the sur file. If you are going to make your own stitched sur using Sur-Splicer, then if you remember to add “_lod1” to each sur part name before you export them one by one, then you do not need to import the cons_fix data into your new .cmp after that, since this is all that the cons_fix import does.

Back to the cmp file for a little more info…

The node below “Object name” is “File name”, and that contains the name “bw_port_wing01_lod1020911030723.3db”.

This is the name of the node in this cmp file that contains the pointers to the model mesh for that part. You will find this node further down in the cmp file. The pointer to the model mesh is contained in that node in the \MultiLevel\Level0\VMeshPart\VMeshRef node. The second Integer value contained in the VMeshRef node in the case of the bw_fighter is 196713753 - this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod0-112.vms”.

At the top of the cmp file you will find a node named “VMeshLibrary”. Under this node you will find three nodes, named data.ships.border_world.bw_fighter.bw_fighter.lod0-112.vms, data.ships.border_world.bw_fighter.bw_fighter.lod1-112.vms, and data.ships.border_world.bw_fighter.bw_fighter.lod2-112.vms.

Each of these nodes contains a node named “VMeshData” - this is where the model mesh is stored.

The “lod0”,“lod1” and “lod2” in the names mean “Level of Detail” - 0, 1 and 2.

The “lod0” node contains the model mesh for Level0, which is the fully-detailed model that you see from your ship when you are close to the ship.

The “lod1” node contains a less-detailed model mesh of the same ship.

And the “lod2” node contains an even-less-detailed model mesh than the “lod1” node of the same ship.

This is because the model contains one fully-detailed model for close-up viewing, and two more less-detailed, lower “Level of Detail” meshes that are Switched to as the distance of the ship from your viewpoint increases when you are playing the game and looking at the ship.

The defaults for those distances are defined in the Switch node for that part, in this case 0, 100, 1000, 1000000. These values mean that the Level0 pointer set to the model meshes is used from distance 0 to 99 metres, the Level1 pointer set is used from 100 metres to 999 metres, the Level2 model is used from 1000 metres to 999999 metres, and the ship disappears from view completely at 1000000 metres.

But these default values are overridden by those defined in the LODranges = line in the [Ship] section for that ship in the DATA\SHIPS\shiparch.ini if they exist, and in this case in standard FL they are “LODranges = 0, 75, 125, 1000”.

To continue a little further…

Under the bw_port_wing01_lod1020911030723.3db node in the \MultiLevel\Level1\VMeshPart\VMeshRef node, the second Integer value is -423074755 - this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod1-112.vms”.

And under the bw_port_wing01_lod1020911030723.3db node in the \MultiLevel\Level2\VMeshPart\VMeshRef node, the second Integer value is -107778942 - and this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod2-112.vms”.

In fact all of the part nodes contain the nodes \MultiLevel\Level0\VMeshPart\VMeshRef, \MultiLevel\Level1\VMeshPart\VMeshRef and \MultiLevel\Level2\VMeshPart\VMeshRef.

So this is where FL finds where the model mesh is kept for each Level of Detail.

In the case of break-off groups, those group meshes are replaced with the “damage cap” model meshes when they are blown off the ship. Those groups are defined in the shiparch.ini file under the section headings [CollisionGroup] just below the [Ship] section of the ship they refer to, together with their hit points and the name of the damage cap mesh that will be used. In the case of the bw_fighter, there are two wing damage caps (damaged wing stub model meshes) which are ew_dmg_portwing01_cap and ew_dmg_starwing01_cap. These are defined in shiparch.ini in [Simple] sections, as follows:-

**[Simple]
nickname = ew_dmg_portwing01_cap
DA_archetype = SHIPS\border_world\bw_elite\bw_dmg_port_wing01.3db
material_library = SHIPS\border_world\bw_ships.mat
mass = 5
LODranges = 0, 100, 1000

[Simple]
nickname = ew_dmg_starwing01_cap
DA_archetype = SHIPS\border_world\bw_elite\bw_dmg_star_wing01.3db
material_library = SHIPS\border_world\bw_ships.mat
mass = 5
LODranges = 0, 100, 1000**

So the Dagger (bw_fighter) is using the wing stub model meshes from the Stiletto (bw_elite) when its wings are damaged. In the Stiletto’s folder, SHIPS\BORDER_WORLD\BW_ELITE, you will find the two stub meshes bw_dmg_port_wing01.3db and bw_dmg_star_wing01.3db, and each one has its own .sur file with the same name.

Well, I can’t go on more as I don’t know enough about the other pointers in the “MultiLevel\Level0”, “MultiLevel\Level1” and “MultiLevel\Level2” nodes to explain which part of the relevant model mesh they point to for drawing each model group. But I have a feeling someone else has explained those in some detail somewhere?

Sorry for the long-winded story and for jumping around within the .cmp file and between sur file and cmp file, and if I have made any mistakes please let me know to correct this post for “post-erity”. 😄

8-)