Err, guys, maybe I fatally misunderstood something here, but the way I see it, there is no need to make it quite that difficult. Though I have not worked on this for a while, I managed to get a complete Basilisk's (the one from SL) SUR to work a while ago. Of course it didn't have destructable parts, something this new approach seems to be able to achieve, but that's not the point anyway.
When building the SUR for the Basilisk, I had the detailled CMP model loaded into 3ds max and built tight boxes around it, but always making sure the boxes themselves are convex. Now the Basilisk, at least the way I grouped it, is very concave at the rear, so what I did was just to start a new box where-ever the model was concave. When It came to exporting both CMP and SUR, I had one root part in the CMP, but the corresponding group in the SUR was made up of four boxes. And while each box was convex, the entirety of the root group was concave at various points. It was the same for both engines, which naturally are very concave. You still there?
Anyway, the three overall very concave groups (root, engine left, engine right) worked perfectly, even though I just put all the boxes of one part into one group, equalizing the number of SUR and CMP groups and thereby making any boxes like ZOMG...whatever unnecessary.
Now my suggestion, based upon the ISD of Dev's original example. I would create the boxes exactly as he did, but I wouldn't make eight SUR groups out of it, but one. This seems to work when every single box is convex. So you would only have one SUR group and only one CMP group, saving all the little boxes to make up for the additional SUR groups. Perfect!
Now, you could just as well do that for multi-component CMPs and SURs. Using Dev's tool, we should finally be able to create working multi-component models -- the "very streamlined way".
Unless of course, I am terribly wrong and all my talk was rubbish. If so, you are cordially invited to inform me of that. As I said, I was just reporting my experiences with the Basilisk model.

Ah, and just a quick question: In vanilla Freelancer, did the shots hit a "skin-tight" shield or a bubble? I just don't know right now. I ask because the shield is the only thing we'd have to fix, at least for those wanting a shield bubble. If it so happens, that in vanilla FL, shields were skin-tight as well, I am happy.

Edited by - Manhattan_Guy on 7/5/2006 11:00:44 AM

Ships in vanilla Freelancer all have some shield surface that lies outside the hull; fighters generally use a shield bubble, and capital ships use a shrinkwrapped shield. If you refer to the second post in this thread, there is an easy way to put a shield bubble on your ship even though it is not part of the ship's .sur.

Yeah, but the shield bubble SUR would be the same for all the ships with that particular shield mounted, right? So, you'd have problems with ships of very different sizes.

No, the shield bubble is related to the shield_link = line in shiparch (and the corresponding definition in select_equip), not the actual shield you have mounted to your ship.

hmm i have the following problems:

i have spliced a sur together from 6 singel surs, the first is assigned to the root the other 5 are assigned to dummygroups like described in the readme ... i also imported the confix data into the proper leef of the cmp ... and in hardcmp evrything looks brilliant ...



the input ini:

y-wing.sur
y-wing_cons_fix.dat
12
90 90 90
y-wing_sur-cockpit01.sur Root
y-wing_sur-hull01.sur sw_y-wing_sur-hull01
y-wing_sur-hull02.sur sw_y-wing_sur-hull02
y-wing_sur-hull03.sur sw_y-wing_sur-hull03
y-wing_sur-leftengine01.sur sw_y-wing_sur-leftengine01
y-wing_sur-rightengine01.sur sw_y-wing_sur-rightengine01

than i set the needed hardpoints started the game and the first problem was that the model dont appear at the ship- and equipment-dealer, ok nothing to care about that moment since undocked from the station the ship seems to apear correctly in space. ...

than i tested the the ship flying a mission and tried to ram it into other objects than projectiles like asteroids and stations ... the sur seems not working properly, only the first part that is connected to the root works fine the others wount be checked properly for collisions by the game even if they are shown in hardcmp.
Both projectiles and stationary objects are only checked for collision with the root-sur ...

the server trows some warning messages:
C:\work\builds\dalibs\dalibs-build\build\Src\EngBase\Engine\engine.cpp(905) : WARNING:General:Joint Root<->sw_y-wing_sur-hull01 not found!
C:\work\builds\dalibs\dalibs-build\build\Src\EngBase\Engine\engine.cpp(905) : WARNING:General:Joint Root<->sw_y-wing_sur-hull02 not found!
C:\work\builds\dalibs\dalibs-build\build\Src\EngBase\Engine\engine.cpp(905) : WARNING:General:Joint Root<->sw_y-wing_sur-hull03 not found!
C:\work\builds\dalibs\dalibs-build\build\Src\EngBase\Engine\engine.cpp(905) : WARNING:General:Joint Root<->sw_y-wing_sur-leftengine01 not found!
C:\work\builds\dalibs\dalibs-build\build\Src\EngBase\Engine\engine.cpp(905) : WARNING:General:Joint Root<->sw_y-wing_sur-rightengine01 not found!

i checked again the .cmp but evrything seems to be like described in the readme or in this topic, is there anything else to teel feelancer to get the additional sur-parts working?

Edited by - Holzbein on 11/23/2006 5:27:10 AM

are your object/filenames different? they should be..

i know i overlooked this one many times; the dummy .3db groups should be named differently like part_lod1random#'s.3db and the Object Names identical to those in the .ini file (eg, plain like part_lod1) - you can rename the Object Name (strip the _lod1) and match it in the sursplice.ini, or rename the .3db nodes and their matching Part->filenames, but either way they must be different.

if that is already the case, try increasing the radius/inertia values, and building your SURs differently (they need to be based on primitive shapes to work consistently)

also, station collisons just don't work, only the root will collide consistently. so if that's a massive problem, design the main portion of your SUR to cover most of the ship- generally it's not, since hiding a wing in the station is not going to give enough cover hit detection has not been a problem for me, you may be interested in my tutorial, which covers a couple more topics and a different way to implement these multipart SURs without dummygroups (the 'vanilla' freelancer way, which allows for destructible groups) - its more involved, but the result(mod ships that work just like stock ships) is worth it IMO

thx it was _lod1 thingy

for the collisions with stationary objects like based i have made an rootsur that approximatly fits the dimensions of the ship as good as possible i wiill also test more complex ones but i think that will failure due the limitations of a single sur



what about the ship to ship collision??? does they also work just on root or do they work n all parts betweens custom spliced surs?

if they work it would bee no problem cause i plan also to replace all bases by bases simmilar to these ones seen in x-wing alliance ...

your tutorial is great i will use it for bigger ships, disarming an capital ship by destroying several destructeble pieces arund the ship might be very cool ... like in Empire at war with appart ripped pieces ^^

Edited by - Holzbein on 11/23/2006 8:36:40 PM

the new SURs like each other fine, I know for a fact part-to-part collisions work, as I have converted a mod capship to destructible parts and tried ramming in to it with stock and mod ships w/ new multipart SUR construction. just remember that NPCs have always been able to fly through capships... new station SURs seem to work 100% of the time with new ship SURS, not always so well with the old SURs though.


Edited by - Cold_Void on 11/24/2006 11:48:10 AM

well i have started over again whith an Imperator-class Star Destroyer based on the one the tutorial is about, it come to my attention that some of the boxes could be merged cause the space between them is covered by another, this way some dummy-groups could be saved. nontheless the count of 18 groups the cmp-exporters allow u to create is for an 1200 units long ship with lots of emplacements and details where each could hide more than a fighterscale vessel, not enough... so how i add more dummy-groups (via utf editor), is it just simple copy and rename or does it need more? does the splicer suppoert more groups? are more backdraws of an increased count of surparts beside that the collisiondetection need more cpu-time? (this could be countered by more simple parts)

the reward might be:
-surparts could be more simple
-stations dont need to breaked in parts to cover more complex structures

the next ship i like to make is the xts container-transport but it need more parts:
6 boxes for the containers
6 boxes that connect the the containers to the mainhull
6 boxes between the containers
here we reached 18!
1 long box for the mainhull
4 boxes for the drives
2 boxes for the cockpit

so i need a total of 25 surparts, considering that i work on a large scale transport to make the sur that way that escorting and attacking players in fightercrafts can only collide with and hit what they see.

even if i make the containers as mountable parts i would still need 19 groups in the cmp for the ship

there are also more complicated ships in starwars, at the moment i cant think of covering a whole moncalamari-cruiser with the most of its big bubble like attachments ...

Edited by - Holzbein on 3/9/2007 11:39:57 PM

And the thread is now officially a zomgbay.

First off, the ISD is 1600 meters... I'm sorry, I just had to say it. Anyway, the splicer should handle any number of parts. The limitation is the number of groups that the .cmp exporter will let you have, which is 18. Working around this by hand using the utf editor to add extra parts is probably not an enjoyable process (I will admit that I have not tried it). Each part will need to know what triangles in the vmeshdata belong to it, so if you go beyond 18 parts you will have to do calculate these by hand. However, the game might allow you to assign the same triangles to multiple parts, in which case this process becomes a lot easier (just copy-paste the relevant info from another part). If not, you will have to calculate the needed offsets by hand. I also would watch out for a limit on the number of parts that an FL ship can have; I wouldn't put it past the game designers to hard-code some limit.

thx for the info and fast reply devastator
1600 ok i need anyway to make a new cmp for that ...
i will try to make all parts by hand using a cmp with just one VmeshPart and copying the information from the Root-part

just one more question to go:
in the 'Cmpnd'-node there are the Root-part:

filename says what 'VMeshPart' -+-> 'VMeshRef'(ference) is used.

index is also clear - need to be alterated for a new part, right?

but what is the 'Object name' ? is that the name of the proper named sur-part that will be attached by the groupname given in the input.ini for the sursplicer, or is that also a refference what 'VMeshPart' will be used?

Edited by - Holzbein on 3/10/2007 12:25:56 AM

"but what is the 'Object name' ? is that the name of the proper named sur-part that will be attached by the groupname given in the input.ini for the sursplicer"

Yes. Also, if you refer to the part elsewhere (for example, with collisiongroups on a ship in shiparch.ini), this is the name that you care about.

Iam glad to report my master, we have archived major improvements to our fleet of Imperator-class Carriers ... it works! it works!!!!!!! IT WORRRRRRRRKS!!!

I have tested it without any dummy-group and 2 sur-parts, the second part in the cmp reffers to same VMesh-Data as the Root does, to make sure its the same, and save some writing and cliks, u may export the 'File name' and import it on all parts u add. 'Index' and 'Object name' need to be alterated for any new part.

If u have no parts exported with the cmp-exporter u also have to add the Cons -+-> Fix nodes to get the fix-data from the splicer in there ...

THX alot devastator for the help!

Is there anything worse about using the same VMesh-Data twice or more? Will it be loaded more often? Anything else known on this?

Edited by - Holzbein on 3/10/2007 4:35:35 AM

I would try this myself if I had more time to right now, but this is how you tell:

Give a position offset to your second group (in cons.fix). If you see two copies of the ship's model in-game, you know that it is duplicated. If you just see one copy, you know that it is not, and furthermore you know which part gets the model.