"what did u mean with position offset in the fix-data?"

There was a thread on this... somewhere. Basically, if you look at cons.fix in a hex editor, you will see Root at byte 0, the name of your part at byte 64, and mostly a bunch of 00 elsewhere. However, you can put other interesting stuff in there, such as position offset, scale and (presumably) rotation. The position is set at the following locations:
128: X offset
132: Y offset
136: Z offset

If you have more than two parts in your ship, the next part in cons.fix will have the same format, i.e. with Root at the beginning, etc.

So, basically... y'all finally solved the SUR problem, but the solution involves massive drudgery, and there still isn't a simple end-user tool that does this in an automated fashion. That's a pity.

I spent about 6 hours Saturday going through the process of creating the SUR I made for the LI_CRUISER with the older exporter, and the new exporter kept screwing up the geometry, whether or not I turned DirectX optimization off, so I'm not messing with it any further... this was one of the big issues that finally pushed me over the edge, frankly, so it was a very unpleasant trip down Memory Lane

Hi Bud , you back for a while or just paying a visit.

Everything just gives us partial success, we can get destructable components with the splicer, but the double layer of damage detection in the vanila SUR's isn't there, meaning parts pass through other objects without touching.

The version of the SUR Exporter that you uploaded for us can give us the full damage detection, but I still can't get it to do destructables.

Milkshape doesn't recognise the 1.2 exporter, so unless Colin's fixed the new version since the last time I checked, I'm surprised you can get it to work.

*heads of to see*

**shuffles off with a new headache**

I'm just visiting, really. I just used the 1.3 version from EOA's website. Haven't tried the 1.2 version again... it really seemed to work, and I dunno why the 1.3 version is doing so many terrible things to the meshes. I'll maybe try the 1.2 version in the latest MS3D and see if it's crashy or not... it's the only version I used that actually produced good multimesh, one-part SURs... some of the time, with certain limitations, mainly the problem with the shield-bubble not being pushed out far enough to ensure that all hitboxes would be checked.

Y'know... for models that don't need to be multipart, where you don't care about objects breaking off... I think I may have just found a solution... lol... after all this time...

Hire an Italian, a Russian, and a 3 year old Chinese girl?

Nope. It's actually so simple, that I'm surprised nobody else thought of it, actually.

Okay I'm a little confused here, v1.1 is the one you uploaded for us, v1.2 is the one on the EOA site, so where did you get v1.3 from and can I have a copy please.

I take it you compiled your copy of v1.2 beta3 from the source code, as the compiled DLL that's available is either corrupt or totally bogus as no version of milkshape likes it. I'll email Colin again but as a fellow AOL user I know that important emails can sometimes disappear from thier pathetic system.

**shuffles off with a new headache**

It doesn't matter... in the thread where I discuss this, I'm using 1.1. 1.2 doesn't work right for me, no matter what.

Well it took me another few hours of searching, but I finally found Argh's topic on sur files for single mesh ships...

http://www.lancersreactor.com/t/forum/topic.asp?topic_id=45717

Thanks Argh

Edited by - StarTrader on 7/29/2007 6:07:25 PM

To save some of you some of the time I spent, here are my findings...

I needed a simple .sur with no shield bubble for the plain old Enterprise 1701, it's a complex shape and as it's a large ship, a shield bubble would make it unmissable.

None of the tutorials I chased down helped with this shape. There are snippets of info all over the place, and it cost me an awful lot of hours of browsing instead of working on the project.

Argh's way didn't produce a working .sur file for me, no offence to Argh as I accept I have proably done something wrong. Firstly I couldn't weld my sur shapes together in Milkshape. Because I had used cylinders and squashed them into the shapes I wanted, where they met I couldn't get in close enough to insert vertices to weld to the cylinder that was joining the face there. No I can't (won't) use boxes and cubes, I want a good-looking .sur file, not a bunch of stacked crates!! Sorry Argh, but I didn't like your model's sur at all, I'm very fussy!

Anyway, continuing to use Argh's remaining way it produced the close-fitting .sur files surrounding the ship, plus a huge shield bubble, and all looked well and bright white in HardCMP. But my ship passed through absolutely everything and only the saucer pylon detected any hits, with the shield up or down!!

Dev's way worked. It was long-winded and tedious, and I was never really sure at any point of what I was doing, so I had to read and reread several times, and finally just followed blindly - sorry to Dev but the tut is missing some readability and explanations. I had no idea of what names I could / should use that would make sense, for a start - zomgxxx is absolute nonsense and I refuse to use it. I finally used EntA_Hull, EntA_SaucerTop, EntA_SaucerBot, EntA_LeftEng, EntA_LeftEngPylon, etc. so I won't have problems with other ships using the same names either.

I ran out of groups the first time, since the ship already had 14 groups in it. So I did it all over again and regrouped the main ship into 4 groups, crossing my fingers that it would not destroy the texturing as I have no clue as to how that is done or how to recover it if it went wrong. I followed the basic sense of keeping the parts that used different materials separate from each other and just regrouped the groups using the same materials.

But it went OK, and produced a nice close-fitting sur file, just as I had designed it. However, in HardCMP only the fuselage sur showed in bright white, the rest of the sur components (the saucer, engines and pylons) showed in grey wires like the rest of the ship, and I can't understand the reason for this - can anyone explain why please?

But it worked, I could target all parts of the ship and hit each one all over its surface - saucer, engines, fuselage, and the 3 pylons, and each hit gave damage.

Sadly, only the saucer detects collisions with other ships and bases.

Important note:

A nice thing happened using Dev's way - the inertia seems good now, the ship doesn't bounce off all over the universe when it did actually (finally!!) collide with another ship! It did bounce around like a leaf before with a converted .sur file.

For those who are unaware of this, the sur file contains the mass of the ship, FL uses this value from the sur files of all objects involved in the collision to calculate the reaction of each object from the collision.

When you do adapt a standard .sur file to fit your ship, the ship mass will be different because FL Model Tool doesn't have a facility to fix it to suit your ship. If your ship is significantly bigger / heavier than the original file's ship then it will react like the original ship - hence my Enterprise at mass = 1,450 was bouncing around like a ship with mass = 60!

You can change the inertia values in the sur file with a hex editor:- Open the .sur file with a hex editor and addresses 0044 to 0047 = x-inertia; 0048 to 004B = y-inertia; 004C to 004F = z-inertia. Change them all to your own ship's mass but as a Floating Point value. Your hex editor may have a built-in function to help with this, I use Marcin Dudek's Hexplorer 2.6 (http://hexplorer.sourceforge.net) - if not then there is a converter here: http://gregstoll.dyndns.org/~gregstoll/floattohex/

But if you do this then remember the converted number you get has to be byte-reversed... for example if you get FAE9D8C7 then you must enter it as C7D8E9FA in the file, because for us we read left-to-right as high-byte to low-byte but our editors show it left-to-right as low-byte to high-byte because they start at address 0 and go up. Don't worry, just do it like this, but don't put in the value I show here, its a nonsense number just to clarify the sequence of numbers.

If you can't be bothered then try:-
<pre><font size=1 face=Courier>
Mass Floating (reversed already)
50 0000 4842
100 0000 C842
200 0000 4843
500 0000 FA43
1000 0000 7A44
2000 0000 FA44
3000 0080 3B45
4000 0000 7A45
5000 0040 9C45
6000 0080 BB45
7000 00C0 DA45
8000 0000 FA45
9000 00A0 0C46
10000 0040 1C46
12000 0080 3B46
14000 00C0 5A46
16000 0000 7A46
18000 00A0 8C46
20000 0040 9C46
</font></pre>
Remember to set all 3 inertia values to the same.

I have no idea what is the limit but I think there is one - when I used a mass of 2,500,000 for my Borg Cube, it still bounced around like a leaf!

Hardpoints:

Somewhere in the forums someone emphasised VERY strongly that the ship hardpoints have to be put into the model in MilkShape or otherwise hull hits wouldn't be detected - I couldn't do this to get the hardpoints exactly where I need them so I didn't do it at all, and I added my hardpoints later in HardCMP which is an awful lot easier - but it was NOT necessary to add them in Milkshape for hit detection in any case, as my sur file works exceedingly well for hits, so this is incorrect info.

Whoever wrote that, don't be offended, this is how it worked out for me. Adding hardpoints in Milkshape is a pain, in HardCMP it's a doddle.

Help needed please:

When using boxes to make the sur files then grouping them into a single sur file and exporting it, did anyone find that it worked for all hits even though the whole model was not convex?

And in this case did collision detection work for the whole model too?

When I reopened the model of the Enterprise that I had imported and saved as .ms3d, the bottom of the saucer in the 3D view was very shiny and reflective, and looked like a mirror. As I move the model, the reflections swing around the saucer like water in a bowl - very very nice effect indeed and I would like to reproduce it if I can for some other model, but can anyone tell me why it happens now when the Enterprise texture is grey matt and some lettering and two spikes?

I also found that the CMP importer does not import the hardpoints set in by HardCMP - It would cut out a lot of after-work if it does. Any ideas or help on this please?

Finally can anyone shed some light on what to try next to solve the collision detection problem when the first sur file component can't cover most of the ship, as in the case of the Enterprise?

Thanks guys, splendid work Argh and Dev.

Edited by - StarTrader on 7/31/2007 4:25:58 AM

Edited by - StarTrader on 7/31/2007 4:28:33 AM

Best thoughts go :

FL cap ships (vanilla) dont have shield bubbles, but are 'shrinkwapped' with one mesh that just covers the most extreme vertices. perhaps making this appen to your enterprise would solve the problem.

Whether it would have bearing i'm not certain, but possibly making all parts of the ship sur be named ROOT could help. Certainly the renaming would be easier.

+++ out of cheese error - redo from start +++

"However, in HardCMP only the fuselage sur showed in bright white, the rest of the sur components (the saucer, engines and pylons) showed in grey wires like the rest of the ship, and I can't understand the reason for this - can anyone explain why please?"

your SUR parts, your exported cmps .3db parts, and the object names are all the same. this is INCORRECT as i have repeated again, and again, and again. if you read my tutorial closely you would know that this is because the original exporter was written to just export models, and that was enough to make people happy - now several years later it has finally caught up on multi-parts but it had a minor flaw in that does not conform to the object-name rule, and because the EOA released a multipart SUR exporter that will produce a good SUR that will not work with the models the multi-part export puts out, there -will- be frustration as a result. maybe Louva could pass on this info to Colin, if they're still talking. trust me, your model and sur are almost certainly good, as good as any that Argh didn't make that is

so, open your UTF editor, go to the Cmpnd node, open each Part_ node and change the filenames there. add the CRC of the ships name to the end, sign it with a date, a lucky number, your zipcode, whatever - point is, if the object name and the .3db part name are exactly the same your SUR parts will appear grey in preview and won't detect hits. once you've renamed the cmpnd>part>filenames do the same thing to the actual .3db nodes, making sure they are correct. the only reason your root shows up is because this is the only Part_ that the exporter treats correctly (naming its object name differently than the .3db!)

alt method, rename the objects in your sursplicer file if using it, so that they are different than the exported .3db names, then go in and correct the object names in your cmp instead of the file names. either way is the same amount of work really.

now your subparts should be registering damage, and they should be able to collide with all NEW surs, and -SOME- of the original SURs. if not, and using sursplicer, try increasing the radius value. now, don't get upset but your subparts will -not- collide 50% of the time on old objects, particularly the stations - if this is upsetting you, you can perhaps expand your root file to cover more of these, just make it a little smaller so it is inside the part and not outside, this will allow you to get damage on the part and still collide consistently.

yes adding HP's in MS3D to your sur is not required to get weapons damage- in fact it is probably a -bad- idea because you're un-necessarily complicating a complex file we still don't fully understand - also, lots of people complain about how much damage missiles do to weapons, not using the SUR boxs around the points may help reduce the splash-over damage. you can make your own hardpoints in milkshape or you can download the hardpoint template file for the borderworld sabre somewhere(i've forgotten).

adding hardpoints in MS3d should not be a pain - it should be easy if you do it like i do. i like to use MS3D to do it because #1 hardcmp cannot add the physical model for a weapon to visibly sit on and #2 once you have a good hardpoint template (model + hp polygon) that gives consistent orientation you can import/duplicate them as many times as you need for more Hardpoints. the actual form of it is easy enough; one polygon named /Hp/Fixed/Hpname -> although the shape of the polygon must be precise! an oddball non-isosceles will give you a flat or warped looking weapon! and #3 it is much easier, when you may have to export your model several times to get it right, to have all the hardpoints in your shiparch file all-ready for testing after export.

"the Enterprise texture is grey matt and some lettering and two spikes?"
your models texture mapping has been f'ed up? i don't know. the reason your ship is 'all smooth and shiny' is auto-smooth is enabled in ms3d. a good modeler knows to disable this and smooth their models with groups, so as to get a more aesthetic mix of flat angles and smooth curves. Freelancer does -not- smooth as well as ms3d, and your ship will most likely not look the same. my general, plucked-from-the-air rule (excuse me) is if the angle is too acute or too obtuse, it will not smooth - I am not a modeling expert, and i suck at geometry so i can't specify the angles persay so figure out what works for you

cubes should work flawlessly in my experience, but they can start failing when you begin weld them together, my rule of thumb:the less primitives you use the better, and its better to stretch a vertex to fit than to add another primitive - a little distortion of a primitive cylinder, sphere, lego-type-cube-model, etc is fine but too much twisting, turning, pulling etc will break it. i have used cubes for lots of stuff and they are much more consistent at detecting hits than cylinders or spheres at least in my experience.

big SURs are a more complicated animal - hint: work your model small, and then scale it up before export. this way you can zoom in easily to make sur hardpoints are flush, parts do not have gaps, geometry is uniformly symmetrical and gives good shading results, etc etc

P.S. we now have an LOD export feature that works like a charm -> if your model is high poly, like a large capship with a rounded disc, you might want to -use- it and glean a little extra-smooth performance when it is on screen with various other star trek ships. reducing the polycount for lower ordered LODs is simple now too, with recent Milkshape versions featuring the DirectX Mesh tool (which is also used to import .x files) it is as simple as selecting the parts to decimate and dragging the slider, then applying and exporting. the lowest ordered LOD will also make a perfect VMESH references for wireframes, because it should be a very simple shape that captures the essence of the ship's outline. this wireframe will look like a model wireframe view, but in my opinion its not distracting or out of place and the benefits of being able to see how much damage parts have and the orientation of the ship outweighs a very small aesthetics problem

Edited by - Cold_Void on 7/31/2007 11:14:04 AM

Very many thanks guys, much appreciated.

Cold Void:

OK I thought I had understood it, and I did make sure the Object name is different from the File name:- the File name is the same as the part node (branch?) further down the tree, and the Object name is the same as the Surpart name I gave (not zomgbayxxx!!!!) and they are correctly typed - but maybe I misunderstand still.

Did I get it in reverse, should the File name be the Surpart name and the Object name be the branch name?

Maybe the cons_fix file may be incorrect, but it's hard to tell as it only shows the "Root" name in string, as int array a lot of numbers show up but I can't interpret them into meaningful names. When I open the cons_fix file in an editor it appears to have all of the part names I used.

But as I said, this .sur file detects hits at any point on the whole ship, so I'm very happy about its hit detection - so the query here is why only the hull part is bright white and the rest of the sur parts are still grey in HardCMP when it appears to be working as far as hit detection goes?

Here's what I have in my .cmp file, please tell me where I have it wrong...

In Cmpnd I have the following:
-Cons
--Fix = Root (only "Root" is visible in "interpret data as string", but as "int array" many other node values seem to be there too)
-Root
....FIle name = EntA_MainHull_lod1.3db
....Index = 00 00 00 00 00 00 00 00 <== Note 00 - ??
....Object name = Root
--Part_EntA_LeftEng_lod1
....FIle name = EntA_LeftEng_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = LEng
--Part_EntA_LeftEngPylon_lod1
....FIle name = EntA_LeftEngPylon_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = LEngPyl
--Part_EntA_RightEng_lod1
....FIle name = EntA_RightEng_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = REng
--Part_EntA_RightEngPylon_lod1
....FIle name = EntA_RightEngPylon_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = REngPyl
--Part_EntA_SaucerBottom_lod1
....File name = EntA_SaucerBottom_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = SBot
--Part_EntA_SaucerHull_lod1
....File name = EntA_SaucerHull_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = SHull
--Part_EntA_SaucerPylon_lod1
....File name = EntA_SaucerPylon_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = SPyl
--Part_EntA_SaucerTop_lod1
....File name = EntA_SaucerTop_lod1.3db
....Index = 01 00 00 00 00 00 00 00
....Object name = STop
-EntA_MainHull_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
--Hardpoints
---+Fixed (These are all correct, not shown to save space here)
---+Revolute (These are all correct, not shown to save space here)
-EntA_LeftEng_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_LeftEngPylon_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_RightEng_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_RightEngPylon_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_SaucerBottom_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_SaucerHull_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_SaucerPylon_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef
-EntA_SaucerTop_lod1.3db
--MultiLevel
---Level0
----VMeshPart
-----VMeshRef

Many thanks in advance.

PS - A big "Thanks!" to Argh, I tried again and managed to get a couple of good hit-detecting single-mesh surs using his procedure, where I didn't need to weld cubes together, for the Borg Cube and Pyramid. But the shield gets in the way for collisions, the bubble is too large. He insists to NOT use shrink-wrap when exporting and I did it like that.

Roleplay: - the art of self-deceipt!

Edited by - StarTrader on 8/1/2007 2:50:12 PM