Can i get some hitbox help?

Glad it worked for you mate. Lemme know if you have any improvements or observations regarding this method.

Okay i got it , but if i have a ship that behaves like a real freelancer ship , with separable parts (like eagle or titan when u lose a wing , tail bla bla bla) the sur file is made of only one goup/object or the same as the cmp?

I know that this thread is old but i would be thankful if i get some feedback.

A second problem would be about huge cmp’s:I have made the HALO’s Pillar of autumn CMP (used as a station) and the model won’t show up when in game.

I’m pretty sure this simplified method will not work with multi-part surs. Bejaymac I hear is the man when it comes to multi-component ships and multi-part surs. Perhaps you could send him a PM and see if he has any of his old tuts stored somewhere.

I wish I could be of more help to you, but I had(have) no interest in multi-component ships in my mod projects due to the workload required for in my opinion too little of a return.

Forsaken,

Some clarification please…

“Disable Direct X Mesh Reduction checked off”

Do you mean unchecked, i.e. NOT disabled, so it will work and try to reduce the poly count?

Or do you mean “checked (OFF)” so that it does NOT try to reduce the poly count?

Last step (30) Click Resize and use the following settings…

• Scale: To CMP (automatic)

• SUR Type: Scenery <----- IMPORTANT

Really? This will result in a sur type that is different, FL flags are always Ship[ (Type 4).

I am asking because neither method worked for me, so I could not deduce the right way - I tried 6 ships and all 6 surs I produced with this method resulted in jerky graphics for a short time and then an FL Server crash within 1-3 minutes after that…

Using the multipart spliced surs which I had produced some time ago for these ships work fine. But that way is very tedious as you say, so I am always looking out for a faster way! lol

IIRC You should diable directX mesh reduction.

You most definitely use a Scenery type sur tho. I discovered this on accident when first playing with it. I couldn’t figure out how I got one sur to work and the others didnt. I then figured out I must have misclicked and resized as a scenery and that is the reason the SUR started working. Don’t ask me why… but it does.

OK, I’m a gonna keep on tryin’!!

Thanks!

One note…

• Exporting the initial .surs for LithUnwrap as .3ds cuts the group names to 10 characters - if yours are longer, doing it this way will cause naming conflicts if two or more of your .sur group names have the same first 10 characters.

  For example I typically use the format “Excalibur_HullA_sur”, “Excalibur_HullB_sur” etc., so as the first 10 characters of both of these groups is “Excalibur_” then I would definitely have a conflict!!

  LithUnwrap can import MilkShape .ms3d models, but exporting from LithUnwrap as .ms3d does not reset the normals (the .surs are not black) - so don’t use this, we need to have the normals reset (I don’t know yet to what values it resets the normals).

  Exporting in both directions as .obj does the right trick, so I do it this way.

And one omission…

• When exporting the .surs from MilkShape, I use Shield Bubble for small ships. Some of you may prefer to export shrinkwrapped (skin-tight wrapping, with no Shield Bubble). This is your personal choice for your own ship.

Be advised, shrinkwrapped will not work with this method when exporting from the SUR exporter.

To get around the shield bubble and to utilize a skintight shield for ships do not use type = fighter in the shiparch.

Lonestar: I used 40 mass, same as in my shiparch.ini file, for the sur I just made today, it’s very small, about 5m long x 2.5m width and 2m height. (Its .sur is still untested, you sidetracked me!!)

Forsaken: I haven’t tested them yet but I have generated both types of sur just now for this same ship, I’ll get back to you.

But I have just found out how the normals are “reset”: There are two problems!

1. MilkShape’s .obj exporter and .obj importer are both fine. But when exporting from LithUnwrap in .obj format, the normals are entirely removed!! And LithUnwrap also creates a lot more texture vertices (UV co-ordinates) instead!
2. MilkShape’s .3ds exporter exports the .3ds fine. But its .3ds importer does not import the normals!! (Remember .3ds truncates the group names to 10 and texture names to 8 - and LithUnwrap does not support .dds textures, but supports .bmp, .tga, .jpg and .pcx).

So our sur creation via LithUnwrap is just accidentally taking advantage of one of two loopholes, or maybe the normals don’t play any part in the success or failure of a .sur file! (I’ll try other formats to check when I have time).

By the way, LithUnwrap’s Optimise is not necessary, but is useful because it removes any duplicate vertices and faces, but you can also do this in MilkShape using the “Model Cleaner” or “Clean” tools.

or you can just use milkshape or 3dsmax/maya to make the boxes of your Sur
as many as you need, the more simple you can
and go here to learn how to modify the cmp

http://the-starport.net/freelancer/forum/viewtopic.php?topic_id=2017&forum=26

the process is really simple, trust me
i have learned, you can too

obviously if your universe needs bubble shields, not bother to learn it.

anyway it’s a usefull technique for very very big objects
the 18 elements limitations of a Sur is broken, and for example we have done a 582 parts with the Shadow Academy
http://img692.imageshack.us/img692/7279/49169620.jpg

i have also noticed that concave and convex sur parts work for a hull collision
but only the convex one works for a hit (laser/missile) collision
if you not need the hit collision to be seen, don’t waste your time in doing always convex shapes

(Mirkha, I admire your and CzW’s way with convex surs, the boolean method was great - but my ships keep going through the hollow hangar and bay floors and/or walls unless I make separate surs for each surface).

StarTrader reporting back after 3 days of testing…

All of the surs I have made using this method (10-12 so far) have caused FL Server crashes after between 1 and 30 minutes. The test ship and its test sur is used by NPCs heavily attacking one of my heavily-armed base ships. My character is in a different type of ship just observing above the base ship.

I made two brand new surs for this last testing, both using only a box or a cylinder for each group, and exported them as a single group, one shrinkwrapped and one with Shield Bubble.

I first resized and set each one as Scenery exactly as per the tut, tested them one at a time, and both failed (very jerky graphics briefly then FL Server crash) within 1 to 3 minutes.

Then I changed each one’s type to Ship with FL Model Tool, and again both failed but took longer to crash - within 5 to 30 minutes.

I am using Sur Exporter v1.1 not v1.2 and MilkShape v1.8.4 under Windows XP Pro.

To prove this as a sur problem or not, I then used a resized standard FL Rheinland Fighter (Banshee) sur for the same test NPC ship, not my own old sur for it, and it ran almost 8 hours today without crashing at all.

I’ve not long-tested my own old sur for this ship yet, but I will.

I am stumped as to why this easy method works for others but not for me, what have I done to deserve this??!!

Or is it that perhaps you have not tested them long enough, are you suffering from random intermittent crashes that you have thought might be for other reasons?

The other surs that I made for my small ships, which work as planned, I did not export them to LithUnwrap but made them normally using only one scaled single box or cylinder per sur group (not even spheres because although they are surely the most convex shape, they seemed to cause some of the sur files to fail almost immediately - even surs with a single perfect sphere failed, and surs with two or three perfect spheres failed). I also pulled out the ends of all the cylinders a little to ensure convexity, and exported them as multi-group surs with shield-bubbles. Some of the ones I made with 3DS Max and the Havoc Convex Hull Tool and then exported into MilkShape for sur-exporting only, without modification, also worked fine right away, but some failed and I had to remake them from scratch, some several times. (Come to think of it I believe the normals were not imported from 3DS Max either! I need to check that out again sometime).

When I first suspected that the cylinder shapes were causing some of the failures (some had no end-vertices and some which had them were not pulled out, so I sat down for hours and finally worked out in my head, mathematically :D, that maybe FL couldn’t decide if the cylinder’s end was really flat or concave!!), I started pulling out the end vertices and more of them worked first time.

One more note:
When I make a sur file I don’t like to add new dummy shapes named zedohmygodbayxxxs!! In fact I hate this method!

So I always split my ships into the right number of groups, each with its own unique name, and each with sub-parts if needed for different texturing (e.g. Excalibur_LEng, _LEngGrill, LEng_intake etc, omitting the ship name and starting with "" so they visually stand out in MilkShape’s Groups list as sub-parts). Then I name each sur group (no sub-parts for surs!) the same as the main ship group name that it belongs to, (e.g. Excalibur_LEng), so I have the same number of sur groups as I have ship groups (or sometimes less sur groups than ship groups but never 1 sur group), and export exactly that way, so that each sur group has the same name as a ship group.

When I am going to use the sur-splicer for a close-fit sur with no shield bubble, for larger ships, I name the sur groups the same as their ship group but with “_lod1” added to the end of the name (e.g. Excalibur_LEng_lod1) because the sur exporter doesn’t add the “_lod1” but the cmp exporter does add it, and so I don’t need to import the Cons…Fix data into the .cmp file afterwards - this way saves me another step. And when I export the individual sur groups I copy the sur group name and export the sur with the same file name - then when am making the input ini file for sur-splicer the name of the sur file is the same as the sur group and cmp model group name - Excalibur_LEng_lod1.sur so I don’t make a mistake, just change the first group name to Root and for the other groups just copy the file name and remove the .sur extension:-

…
Excalibur_Hull_lod1.sur Root
Excalibur_LEng_lod1.sur Excalibur_LEng_lod1
…

Lazy? Yeah! But I’m old and it’s a good reminder, and it works for me!!

But - guys, enough of my rantings…

Why oh why does this easier method not work for me??

No clue why it’s not working for you bro.

You are making this for a fighter or freighter sized ship right? That’s the only limitation of this method. I’ve made over 100 working SUR’s using this method and it’s not caused any issue. In fact, I replaced most of my SURSpliced SUR’s for fighters by using this method.

You inadvertently missing or revising a step?

Yes it’s just for a small fighter, I’ve been using the Nephilim Manta from our mod as my test-bed.

Well I have really followed every step to the letter each time, only one scaled box or cylinder per group, no spheres because of problems I have had before, export to LithUnwrap as .obj (to avoid the naming problem), optimise & send back as .obj, got the expected black shapes, did two resizes as ship & save, reload & one resize as scenery - even though I thought this is not correct.

And I got the results I described.

Did the same again using .3ds export to LithUnwrap, Optimise and sent back, and got same results - except that as scenery they crash sooner.

Bloomin’ disheartening, I have got the original tutorial somewhere too, so I will give it another go when I get some time, problem is I have some other intermittent FL Server crashes to find in other systems too, I need to troubleshoot those problems first.

If you think of something else do let me know, very saddening.

Export it is a 3ds. That is essential. Remember… the naming thing is irrelevant. You are not splicing the SUR (where naming conventions must be adhered to). Once the SUR parts are exported as one piece using this method, it totally makes names irrelevant.

Use 3ds dude… it removes certain information.

2 days later, many surs, all ways - same, crash!

I followed the tutes exactly each time, both with 1 group and with more (5 groups).

Sometimes with more than 1 group FL Server says there is invalid info in the sur file and it will abort, in red.

But always - Crash!

I also reloaded the sur exporter plugin, same.

Hmmm… I don’t know what the deal is then. It seems myself and a lot of other people are having success with this method. Wish I could help you figure it out.

I won’t give up on this, will try again after I format and re-install Windows etc.

Grrrrrrr……

Just an afterthought…

Would something in constants.ini cause this? I modified it for collisions because I wanted to reduce the ships bouncing around.

Here’s mine, suggestions for improvements are welcome…

[Constants]
COLLISION_DAMAGE_FACTOR = 0.500000
MUSIC_CROSS_FADE_DELAY = 10.000000
MUZZLE_CONE_ANGLE = 40
PLAYER_COLLISION_GROUP_HIT_PTS_SCALE = 3
PLAYER_ATTACHED_EQUIP_HIT_PTS_SCALE = 5
MAX_PLAYER_AMMO = 800
[EngineEquipConsts]
CRUISE_DISRUPT_TIME = 1
MAX_DELTA_FX_THROTTLE = 0.250000
THROTTLE_STEADY_TIME = 0.500000
THROTTLE_ATTEN_MOD_RANGE = 8.000000
DELTA_THROTTLE_ATTEN_MOD_CHANGING = 8.000000
DELTA_THROTTLE_ATTEN_MOD_STEADY = -1.000000
CRUISE_STEADY_TIME = 2.000000
DELTA_CRUISE_ATTEN_MOD_STEADY = -1.000000
CRUISE_ATTEN_MOD_RANGE = 8.000000
CRUISING_SPEED = 1200
[ShieldEquipConsts]
HULL_DAMAGE_FACTOR = 0.500000
[PhySysConsts]
MATERIAL_FRICTION = 0.100000
;MATERIAL_ELASTICITY = 0.900000
MATERIAL_ELASTICITY = 0.100000
DEFAULT_LINEAR_DAMPING = 0.500000
DEFAULT_ANGULAR_DAMPING = 0.200000, 0.200000, 0.200000
ANOM_LIMITS_MAX_VELOCITY = 2000
[CommConsts]
COMM_PLAYER_FAR_DIST = 6000.000000
COMM_PLAYER_FAR_DIST_ATTEN = 0.000000
CHATTER_MAX_DIST = 3500.000000
CHATTER_MAX_DIST_ATTEN = -16.000000
CHATTER_START_ATTEN = -2.000000
COMM_CONFLICT_PRIORITY_CUTOFF = -3
WALLA_MAX_DIST = 3500.000000
WALLA_MAX_DIST_ATTEN = -24.000000
WALLA_START_ATTEN = -8.000000
WALLA_PRIORITY_CUTOFF = -3