<span style="text-decoration: underline">The CMP model</span>

You'll see a couple of ms3d files amongst those you've d/loaded, the one you want to look at first is "Ship_A.ms3d".

As you can see the model is nothing more than a sphere for the main body, 2 boxes for the struts, 2 quick and simple constructs for the wings, 2 cylinders for the guns and 2 half boxes for the plates. Even though this model uses only one texture you will notice that I haven't regrouped everything to that texture, that is one of the biggest mistakes you can make if you want a ship to work properly with FL.

In milkshape we have groups but in FL we have components, the two are not the same as a component is made up of one or more groups, and in the case of this tutorial we have nine groups to make into three components.

Select the "Groups" tab and you'll see this:-
To get our groups into their components we need to shuffle the group list.
The "Main_Body" is going to be what FL calls the "Root", this means the heart of our model as everything is centred around it, this is always the first group in the list. Now what other groups do you think should be part of the "Root", if you said the 2 gunbarrels and 2 plates then you got it, but they are no use where they are. Move the gunbarrels up to 2nd and 3rd and the 2 plates to 4th and 5th. That deals with component one, now for two and three, the right wing is made of "Wing_Strut_01" & "Wing_01" and the left of "Wing_Strut_02" & "Wing_02", move them into the correct place in the list so that it looks something like this:-

Now for the big question, how do I convert my model to be like this?

Study your model, see if you can decide which areas can become components, your looking for things like wings, fins, engines etc and start regrouping them. Almost any model can be broken down into components, no matter how unlikely, hell even a Borg cube can be done if you put your mind to it.

Even having more than one texture per component isn't a problem (look at any vanilla ship) as the textures are coded to the vertices and polys and not to the component, so if your wing has 3 textures on it then you make it 3 separate groups, if you have 2 engine grills in one group sharing the same texture but are on different sides of the model, they then become 2 separate groups, if you don't it makes you look a right muppet when one side is destroyed and the grill from the other side disappears leaving a dirty great hole in the model.

In these next two pictures I'm using milkshapes "group colouring" feature to make it easier to see the groups, the model is a freebie that you can find on turbosquid.
From this angle you can't see the bombs or their mounts, but the whole model has 4 groups to match its 4 textures, one for the body, one for the cannons, another for the bombs and the last one is the mounts. Look at the picture and see if you can work out how many components you can get out of the yellow group, believe it or not but there are 8 components in that one group, the cannons group can be regrouped into 3, I removed the other 2 groups and their textures as they were a waste of time and polys.
By the time I'd finished I had 18 groups (12 from the model and 6 added weaponplates) rearranged into 8 components.

<span style="text-decoration: underline">** BIG EDIT</span>

I have a large number of the mods we have available and I was looking through the various shippacks looking for something I could use, I found a nice little ship from 2004 but there wasn't any contact info with it. On closer inspection I realised that there were wide open seams on the model, I imported it into milkshape (I know, I know, that was bad of me) to get a better look at it, only to find that most of the seams were open. Now in a CMP this allows you to see through the gaps between polygons, but in a SUR this will cause nothing but problems, from exporter errors to CTDs on launch, I've had experience of closing the seams on someone else’s model, after an hour I gave up and made them a new model instead as it was quicker and saved my sanity and eyesight.

Edited by - Bejaymac on 10/5/2007 9:42:14 AM

<span style="text-decoration: underline">The CMP Exporter</span>

Once you've got your model sorted out into components it's time to make the CMP, I'm using the newest version (v0.3), you can find it in the d/l's here on TLR or under Colin Sanby's section over on the EOA site.

After all of the work you've put in to organise your model into components please don't export it like this
If you do then please find the nearest brick wall and
Back to Ship_A, start up the exporter and click on the "load settings" button and load in "Ship_A.ces" and you'll see this:-
A little explanation of the different sections of the exporter.

<span style="text-decoration: underline">Export File Option</span>
Self explanatory really, you either make a new CMP or update an existing one.

<span style="text-decoration: underline">Orientation</span>
I always work in back to front, but I believe that the early exporter only did upside down (never used it as v2 was released before I started doing models for FL, so I could be wrong).

<span style="text-decoration: underline">Model Type</span>
A CMPs internal format is not the same through out FL, with this we can export 3 of the formats, but most of you will only ever need the "ship".

<span style="text-decoration: underline">Settings</span>
As you've just found out, this is where you load in a pre made CES file, or save one after you've input your settings into the rest of the UI. Why save it? simple if you don't your scale will not be locked at you preferred setting, and you will be exporting at "92.000000" which makes for a very small model.

<span style="text-decoration: underline">Level Of Detail</span>
Believe it or not but some of us actually use this section. Used with the "update" button this is how you add LOD level models to your CMP, each model needs to have fewer polys than the previous LOD or you’re wasting your time. I have 2 5000 poly models that have 3 LODs and 14 2000 poly models with 2 LODs, if the models poly count is less than 1000 then I don't bother doing a LOD.

<span style="text-decoration: underline">Scale Down</span>
This is a pain in the ass but it's still needed, I work in a 1:1 scale so when I export I always set it to "1.000000". The scale works different to milkshape, if you want to shrink your model then the setting has to be greater than 1, the bigger the number the smaller your model gets, to make it bigger your talking "0.xxxxxx", barmy or what.

<span style="text-decoration: underline">Group Options</span>
This is the part we're after, as this is the part that most of you just don't use.
This section is a little misleading as it should be Component Options (or Part Options depending on your outlook), as I've already said Groups are what you have in Milkshape but its Components in a CMP. "Number of Groups"(Components) is were you define the components for your CMP, in the case of Ship_A that's 3 (body and 2 wings), the "Group Quantities" is correct as this is where you assign the groups from milkshape to the components in the CMP. You start at the top of the group list and work your way down, in this case the first 5 make up the main body or "Root", then 2 each for both wings, on group heavy models it's wise to write these down before you open the Exporter, especially if your like me and can have 30-40 groups going into 7-8 components, all those numbers get confusing.

<span style="text-decoration: underline">Field Of View</span>
This is for Cockpit models only, I've only used this once and I'm sure I got it wrong.
FovX - how much you can see left and right
FovY - how much you can see up and down
Znear & Zfar - to and fro movement when you speed up/slow down (I hope)

Edited by - Bejaymac on 10/5/2007 9:43:16 AM

<span style="text-decoration: underline">The SUR Exporter</span>

Like before once you're happy with your model it's time to make the SUR, for this we use the v1.1 that you can find in the downloads here on TLR, the v1.2 doesn't work so don't use it, and we're still waiting to here from Colin Sanby as to how v1.3 is doing.

One small warning, this only does ship SURs, having recently tried to make a SUR for a station I've discovered that the formats are completely different, my Borg cube works great as a ship but make it a SOLAR and the SUR stops working.

Open "SUR_A.ms3d" and fire up the Sur Exporter, click on the "Load CMP Settings (.ces)" button and load in the SUR_A.ces file. I made this with the CMP Exporter to show what's required, as the CMP model is nothing like the SUR model there is usually no need to make or load a .ces file for the SUR.
Like the CMP Exporter I'll do a little explanation of each section.

<span style="text-decoration: underline">SUR File</span>
Right along the top of the UI is the area that you allocate the save location and name of the SUR.

<span style="text-decoration: underline">Orientation</span>
Exactly the same as the CMP Exporter, if you made your ship "Upside Down" for the CMP then you have to export the SUR in the same orientation.

<span style="text-decoration: underline">Scale Down Value</span>
Works in the same way as the one in for the CMP, but unlike that one you don't have to save it to lock it to your scale, it goes without saying but always match the two scales as there's nothing worse than a SUR that's half the size of the ship.

<span style="text-decoration: underline">Settings Files</span>
This isn't really needed, as your SUR model shouldn't have the same number of groups as the CMP model. The "SUR_A.ces" that I've said to use was made purely as a demo and helper for everyone.

<span style="text-decoration: underline">Collision Mesh</span>
Shield Bubble - creates a double skin bubble around the model, the two layers are for weapon and collision detection, there's one thing to watch out for when using this, depending on the model you use you may get a shield bubble that's enormous and centred behind the model, when I find out the cause I'll update this.

Shrink Wrapped - easiest way to describe this is to take an object, stick it in a polythene bag, add some heat and suck all of the air out, that's roughly what you get with this setting, a single skin layer that's created around all of the outside vertices of the model, it would be great for unshielded capships (sadly everybody adds shields to their capships) or bases but because the exporter doesn't do that SOLAR SUR format it isn't really of much use.

<span style="text-decoration: underline">Ship Mass</span>
Match this to the mass you’re going to give your ship in the shiparch.ini, this is then coded into the SUR and combines in game with the mass and angular_drag from the shiparch.ini to stop you getting spun arse over tit in a collision.

<span style="text-decoration: underline">Disable DirectX Mesh Reduction</span>
Unchecked this gives you a rough SUR that doesn't look exactly like the model you used, some vertices are missed out, but if you check it and keep the poly count to under 500 you get a very well defined SUR that looks just like the model you used, and which fits your CMP very well.

<span style="text-decoration: underline">Mesh Groups</span>
Just the same as the same area in the CMP Exporter, you should have the same number of groups as you did for the CMP, just not as many groups to assign to the "Group Quantities" part.

Every primitive ship SUR I've made in this way has worked very well in game, weapon and collision damage is detected on all components, but to get to this stage has taken me a lot of hard work, hundreds of experiments and every ounce of my patience, so don't expect it to work first time for you, if it does then well done (jammy git), if it doesn't then take a good look at your models and see if you can find where you went wrong and then try again, after all practice makes perfect.

Edited by - Bejaymac on 10/5/2007 9:51:57 AM

<span style="text-decoration: underline">The SUR model</span>

Ah yes the SUR, the release of the exporter was a cause of great excitement amongst us all, until your shields dropped, that's when the b*tching started and most of you classed the exporter as useless, those of you that complained please take a look in the mirror, that jackass that's looking back at you is what's useless. You jumped in with both feet even though you didn't have bloody clue what you were doing, is it any wonder they didn't work, I knew from my own work on SURs that the Exporters SURs were done correctly, I just couldn't figure out why they didn't work. Multiple component SURs have given me my best results, but the Root was always a problem as it just wouldn't register, then about Nov/06 I realised the problem, concave polygons in the Root of the SUR stopped it from working. Are you starting to see why your SURs never worked, yep by exporting the CMP & SUR as single components (Roots) you rendered them useless yourselves, hundreds of concave polygons in each SUR Root made sure of it, I've been saying this for a while now but most of the custom CMPs that we have are useless in their current form, so model makers get your fingers out of you lazy fat arses and redo your models, OR I’LL DO IT AND TAKE THE CREDIT FOR YOUR WORK.


The SUR model needs to be a low poly version of your CMP model, yes that does mean two models folks but that's just for starters as you could have a dozen ms3d's for the one ship (I have 11 for the ship in the above multi coloured pictures, 3 for the lods, 1 SUR, 5 damage meshes, an icon and a cockpit).

I'm using Ship_A again here, if I was to export this as a SUR I would get one of two results, a CTD on launching into space or a Root that doesn't register, why? because the guns and plates create concave angles in the Root, they can either corrupt the SUR completely (hence the CTD) or just stop the Root from working (almost as bad).

Open SUR_A.ms3d instead and you'll notice that there are only 5 groups and no materials, I still have my 3 components but I now only have one group being used for component 1 (Root), I deleted the groups that would give me a broken SUR.
Unfortunately as this model is nothing but primitives it’s of little use in learning how to create a close fitting SUR for your custom models, but don’t discount primitives as they can be used for a SUR if you don’t want to do the extra work to get a close fitting SUR. Take the NCC-1701 ‘Enterprise’ (TOS), a geo-sphere scaled to saucer shape, 3 single stack cylinders for the nacelles and engineering hull and 3 rectangles for the pylons and neck, this will give you a decent multiple component SUR just not a close fitting one.

First thing is load in the model you used for the CMP, now “save as” whatever, so you now have two ms3ds that are identical except for their names, now delete the Materials as you don’t need them with the SUR model. Take a look at the model in the 3D window (flat shaded and wire frame overlay), about two thirds (probably more) of those polygons will be getting deleted, what you will be doing is making a low poly version of the model using some of the vertices from the original, this way you keep the shape of the original but lose most of the polygons.

You’ll have a CMP model that goes from something like this-
Vertices: 1011
Triangles: 1033
Groups: 32
Materials: 12

To a SUR model similar to this-
Vertices: 115
Triangles: 182
Groups: 7
Materials: 0

The “Groups:” part for the SUR is important as you really only want one group for each component in the SUR model, you can get away with a couple but you can sometimes get errant polygons created where the groups meet.

In the above picture you see the Root from my CMP model, there are several groups and a lot of polygons in this, as it just so happens the main body is the only group I need to keep, the rest are built over for the SUR. The RED dots are vertices in the CMP model that are the main edge vertices, these are the ones that I want to use in the SUR.
Now it’s a case of deleting polygons so you can replace them with one or two big polygons, as I have done in this next picture.

As you can see the areas that had dozens of polygons now only have a couple, the Root had several groups but now only has one, and the poly count has dropped from a couple hundred to a couple of dozen. The RED dots are still the same vertices I identified earlier, they just have fewer polygons joined to them now. You will notice that the back of the models in both pictures are different, the first one has a lot of concave polygons that will destroy the SUR, and so you need to “skim over” these areas. I do this in the same way I did the front, I identify the edge vertices at the back of the model and join them up to the other edge vertices at the front with big polygons.

While concave polygons don’t affect the other components, you do need to lower their poly count by about two thirds.

The above picture shows one of my engine components, the top one is from the CMP while the bottom one is from the SUR, as you can see by the RED dots I’ve done the same thing here as I did earlier and selected the main edge vertices in this component. I’ve done exactly the same with this component as I did with the Root, areas between my desired vertices with more than two polys get deleted and replaced with a couple of big polygons. Even though concave polygons only affect the Root, you’ll notice that the engine intakes have been “skimmed over”, this saves polygons especially when you’re trying to keep it to between 300 and 400 polys with 500 being the absolute MAX for a FIGHTER/FREIGHTER similar in size to a vanilla ship.

Don’t expect to do this in an hour as it can take me the best part of a day to get to this stage. It takes me between 2 & 3 hours just to convert the model for the CMP, and a good 3 to 5 hours to do the SUR, and to date only my station SURs have caused me any problems, all of my ships work beautifully using this method.

<span style="text-decoration: underline">**Edit One**</span>

While doing the SUR for the APS Pegasus I took a number of screen shots, I hope they help you to understand my methods.

The CMP model has 14 groups that are combined into 6 components (parts), seven of these groups make up component one (the Root) here they are, I only want to keep some of those polygons, so after a look through each group I find that I only need to keep two of the groups, the other five can be deleted. Now it’s time to decide which polygons stay and which get deleted from the two groups, after a bit of deleting this is what I’m left with, regroup the two into one and your ready to start making faces, after 15 minutes work this is what I have.
Next it’s component two the Engine, it has two groups and after a little poly deleting I have this, the small ring of polygons to the right are all that’s left of group 2, and their reprieve is only temporary as I only need them for the outer vertices, and after a spot of face making I have this, you’ll notice the ring is gone and the end has been closed with a single vertex.
Component three has two groups, the cage and the glass, the glass is the only group I’ve kept, it also doesn’t need any faces added to it.
The fins are three separate components, each having only the one group, the bottom fin like the other two has a lot of polygons, most of which we don’t want in a SUR, so after a little deleting I have this, didn’t leave much did I, eight faces later and the fin is done, I did the exact same thing to the other two fins.
The end result is this, a SUR model that has 6 groups that export as the 6 components (parts).

The CMP model has a poly count of 1820, while the SUR model has 304, but the most important thing is the names of the components in both CMP & SUR.

The CMP model has the following names:
Pegasus_Main_Hull
Pegasus_Hull_Sidewalls
Pegasus_Rear_Panels
Pegasus_Side_Pods
Pegasus_Side_Mounts
Pegasus_Cockpit_Sidewalls
Pegasus_Cockpit_Backwall
Pegasus_Engine_Mount
Pegasus_Engine_Exhaust
Pegasus_Cockpit_Cage
Pegasus_Canopy
Pegasus_Lower_Wing
Pegasus_Left_Wing
Pegasus_Right_Wing
The Bold are the component names that are added to the CMP.

The SUR model has these names:
Pegasus_Main_Hull
Pegasus_Engine_Mount
Pegasus_Cockpit_Cage
Pegasus_Lower_Wing
Pegasus_Left_Wing
Pegasus_Right_Wing
Yes they are the exact same names as the components from the CMP, if they’re not then Freelancer wouldn’t be able to assign the appropriate parts of the SUR to the CMP.

Like I said I hope this helps.


Edited by - Bejaymac on 10/25/2007 8:08:49 AM

<span style="text-decoration: underline">Destructible Components</span>

For this you need the 3DB Exporter, check in the downloads or under Colin Sanby’s section over on the EOA site.

Like the SUR the damage models are built around the CMP model, take a look at your model and decide which of the components you want to be destructible. In the case of Ship_A that’s the two wings, but the Cravic (multi coloured picture) in the CMP section of this tutorial has a Root and seven components, five of which are destructible, I could have made all seven destructible but as each component in a CMP is a separate entity, and I have components attach to components rather than to the Root, I would have needed a fuse to remove four of the components after the destruction of the main components, otherwise the four components would still be there attached to thin air (I’ve already tried it that’s how I know what happens).

With Ship_A I deleted the Root, gunbarrels, plates and right wing, I then “save as” the left wing, I undo to bring back the right wing and delete the left wing this time and “save as” the right wing. With the Cravic I built the damage meshes into the model then deleted the parts that weren’t being used in the damage meshes, I then split the five damage meshes into five separate ms3ds. However you want to work it is fine just as long as you have an ms3d for each component you want to destroy.

Now it’s time to start butchering the components in your new ms3ds, the only decision you need to make is how much (or little) of the component remains undamaged, work with the polygons to remove the bits you don’t want, with the wings for Ship_A I removed the hexagonal parts leaving the two rectangles.
Now it’s time to fill the void you’ve made with polygons, then regroup the new polygons, make a new material and assign it to the new group, the damage texture I supplied looks good in Freelancer, it isn’t mine however, it comes from the SFC series of games. You can either leave the damaged area as it is or you can get a little creative, increase the poly count around the damaged area and start moving vertices around to make it look mangled.
Fig 1 is one of the damage 3dbs for my copy of the ‘Sai’ from starlancer, while fig 2 is one of the Cravic’s damaged tail sections.

<span style="text-decoration: underline">Don’t forget to change the group names as you can’t have the same name in both CMP & 3DB</span>

Now on to making the 3db.

<span style="text-decoration: underline">Materials</span>

This is the only section that’s different to the other exporters, with it you can add the textures to your MAT file or include them in the 3db, or like me don’t bother, I usually add my damage textures to the CMP model so it gets added to the MAT with the rest of the textures.

You’ll notice “save” & “load” buttons, I believe it’s the same as the CMP exporter in that if you don’t “save” then the scale isn’t set, but I haven’t checked as I always save at least one to save time with the other damage meshes.

Hardpointing

Damage hardpoints are pretty straight forward, HardCMP has a nice list of them or you can make your own, as long as it starts with “Dp” then you can use anything you want in the CMP, the 3dbs however need a “DpConnect”, just one thing don’t have numbers after them especially the “DpConnect”.
“Dp” hardpoints are usually assigned to the Root of the CMP, but can be assigned to another component especially if your having to use a fuse to remove a component.
If you’ve built the damage 3DBs per this tutorial then aligning the “Dp” from the CMP with the “DpConnect” is easy, as the component in the CMP and the damage mesh in the 3DB are in exactly the same place all you need to do is transfer the coordinates from the CMP to the 3DB. If you haven’t built it as instructed then aligning the “Dp” & “DpConnect” becomes an absolute nightmare, it’s actually quicker to start again than to try to align them (been there, done it, damaged my sanity as proof ).

<span style="text-decoration: underline">Coding</span>

In the ShipArch.ini you need to add one {Simple} for each damage 3DB you’ve made, they basically can go anywhere and in any order, they are loaded into FL in the same way all of the {Ship} entries are. The {CollisionGroup} is ship specific, they MUST follow directly after the {Ship} their meant for, if you look at a vanilla entry you will see the {Ship} followed by 2 or more {CollisionGroup}, these then have a couple of {Simple} listed below them.

<span style="text-decoration: underline">The {Simple}</span>

{Simple}
nickname = BJM_Sai_wing_port_cap
DA_archetype = ships\SL_Sai\Sai_Port_Wing_dmg.3db
material_library = ships\SL_Sai\SL_Sai.mat
mass = 5.000000
LODranges = 0, 1000

The entries in a {Simple} are basically the same things you see under a {Ship}.

<span style="text-decoration: underline">The {CollisionGroup}</span>

{CollisionGroup}
obj = Sai_Port_Engine01_lod1
separable = true
parent_impulse = 240.000000
child_impulse = 7.000000
debris_type = debris_small_ship
dmg_hp = DpWing_port
dmg_obj = BJM_Sai_wing_port_cap
separation_explosion = explosion_small_ship_breakoff
mass = 5.000000
type = Port_Wing
hit_pts = 200
root_health_proxy = true

These are a little more complicated than a {Simple}.

obj = This is the component name from within the CMP, usually your component name with .lod1 added to it.
separable = true/false, I have yet to see any difference between the two despite having tried several experiments.
parent_impulse & child_impulse = This is how much force is use to separate the Root (parent) and the component (child), it also partially determines how big a thump you get when they do separate, mass and other things are also taken into consideration.
debris_type = This is basically part of an explosion, check the explosions.ini for the complete list of debris types.
dmg_hp = This is the “Dp” hardpoint the damage 3DB will be getting attached to.
dmg_obj = You stick the nickname of the {Simple} you want to use in here.
separation_explosion = This is the other part of the explosion from the “debris_type”.
mass = Works in exactly the same way as every other “mass” in Freelancer.
type = This is what you see listed when you go to get damage repaired, there are nineteen of these and their hardcoded in to the Common.DLL.
hit_pts = Do I really need to explain this one
root_health_proxy = true/false, this has strange properties. Set to false it increases the hitpoints of the ship, the “patriot” has 1300 that get used only by the Root, the {CollisionGroup}’s use the hitpoints you assigned to them, this means the “patriot” has a total of 1626. However set it to true and 1300 is all the “patriot” has in total, the {CollisionGroup}’s leech their hitpoints from the {Ship}, leaving the Root with 974 to play with, you will find that true is what DA used in their {CollisionGroups}’s.

You can add any number of fuses to the {CollisionGroup}, that way you can do special effects or even create loot.

I stick to about 30% of the total {Ship} hitpoints for my {CollisionGroups}’s, that way I still have a little Root health to play with when my destructibles have gone.

Here is the complete list of the component “type”
Starboard_Arm
Port_Arm
Starboard_Side_Panel
Port_Side_Panel
Tail
Spoiler
Bottom_Engine
Top_Engine
Starboard_Engine
Middle_Engine
Port_Engine
Engine
Middle_Wing
Starboard_Wing
Port_Wing
Starboard_Fin
Port_Fin
Top_Fin
Fin

Freelancer is case sensitive so watch your spelling or you’ll get a pile of “Component”’s in the repair list.

Edited by - Bejaymac on 10/25/2007 2:29:00 PM

<span style="text-decoration: underline">LOD Levels</span>

***RESERVED***

<span style="text-decoration: underline">Complex CMPs</span>

***RESERVED***

<span style="text-decoration: underline">Complex SURs</span>

***RESERVED***

<span style="text-decoration: underline">The Cockpit model</span>

***RESERVED***
Just in case anybody wants to know how to make one

why do i get a really bad feeling that your leaving us?

Universal Modding Forums

Bejay - congrats and thanks, you've started to unravel this problem well for me.

Please continue in the same vein, I have tried to follow the other tutorials but in vain, since there are severe holes in my knowledge.

So please bear in mind that I need the explanations as to why I should name this node a particular name, and why the name should be xxxx, or what button I need to click to do something.

I have used Argh's method to make single sur files for 3-4 different Enterprise models, but only 1 of them worked properly, and it still didn't show as all bright white in HardCMP, parts of it are grey but it's the only one that works - the others all show bright white but don't register hits everywhere.

Personally I have no interest in breakoff components, only single surs for complex ships like the Enterprise series.

So please consider this alternative for me as part of your tutorial so I can complete my project and mod in the next month, or my wife is leaving me and that will be on your conscience!!

All the best pal and many thanks for doing this.

Roleplay: - the art of self-deceipt!

@ Cheese, not a chance bud, I'm here for the longhaul, I enjoy moding this game to much, masicist(sp) ain't I

---

DA's CMPs & SURs are built in a multiple component format, this is also the key to making custom CMPs & SURs work properly with Freelancer

---

@ StarTrader, it doesn't matter if you want destructables or not bud, SURs only work right if thier done as multiple components, FL requires it I'm afraid.
when I do a new ship I only do the CMP & SUR for it, I code it into the game and go fly it. I bounce it off everything I can find and from all angles as well, I then let the rogues shoot the crap out of it, watching the weapons fire splash on the hull. Those ships are more than ready to be used in game as they are, the only difference between them and one with destructables is the DpHardpoints, as I haven't added them yet. Remove the collision groups & simples from the shiparch.ini and you'll find the SURs still work properly, you just can't blow bits off the ships any more.

**shuffles off with a new headache**

Right-O pal.

Hanging on your words to come

AWESOME and if you need any help (lol ) we are here