Can i get some hitbox help?
-
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.
-
-
StarTrader wrote:
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.
So as a small ship you use what number in mass? I’ld like to try this and see if it worked.
ALSO i have made a sur file that WORKS and is for a huge uber big ship. using this example. From center of ship to the frount is -650 and from center to the rear is 600, so i think it is 1250 units from frount to back and center to both sides it is 250 so its 500 units across.
The one thing i dislike is when a npc gets under the nose of my ship and still trys to go up. It doesn’t spin my ship but it does lift up the frount, or if they get stuck then they will spin the ship till they get unstuck. Something I wish the bigger ships will allow ships to pass though them. I have a picture of a untextured model sitting next to baltimore shipyards and it is nearly the same size if not more. It was a bad angle and i had a bunch of hostiel npc heading my way.
-
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 cmphttp://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.jpgi 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.
-
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 -
i tested just to see … if i can give a hand
- The Export settings are as follows…. * Filename: name of ship.SUR * Orientation: Front to Back * Scaledown Value: 1 * Ship Mass: (See shiparch) * Disable Direct X Mesh Reduction checked off * Number of Groups: 1
are you sure it doens’t miss the shrink wrapped option ?
the test : tie_fighter
the boxes in milkshape after LithUnwrap do his job :
and the result :
we can see my boxes and also the bubbles …
normal or not ?i’ll test tomorow the ship, now it’s time to sleep ^^
-
Thanks Mirkha.
Yes I used the shield Bubble option to export, because it is for a small ship. I tried both as 1 group and as 5 groups. I tried for different ships too, both 1 group and 3 groups for others.
The ship and sur look fine in HardCMP, but when resizing in FL Model Tool as scenery (type 2) the FL Server crashes almost immediately, less than 1 or 2 minutes. When resized & saved as ship (type 4) it crashes within 3-20 minutes, with my original spliced surs or a resized standard ship sur it runs for hours without crashing.
For testing, I am using the sur for NPC ships attacking one of my base ships which destroys hundreds of them. I am friendly to all, and observing in a different ship type, to be sure my ship is not interfering.
At the same time, Forsaken tells me that on his PC, Freelancer automatically reconstructs a deleted path file, on mine it does not!
-
which path file ?
the : My documents \ my games \ freelancer \ accts \ singleplayer??
if yes i think you just need to start the singleplayer one time and save
so i maded a test
mount the new tie as a base in Kuat
and it seems to work
i don’t know what is the difference if using like a npc …
but in my experience i don’t have seen any ships/bases who work in a system don’t work with npcthe only difference with the Forsaken tutorial is that i use th 1.1 sur exporter because i cannot use the 1.2 on my milkshape -____-
sorry to ask, maybe i don’t understand or miss the information in this thread but if you want a bubble for the small ship, why don’t take a freelancer bubble one and change her shape with flmodeltools ?
you can scale axes by axes so you can change the shape… -
Thanks Mirkha.
I mean the path files between systems, in \data\universe folder - my mod does not reconstruct them when they are deleted, but standard FL does when you start FLServer.exe, very strange, I will find out what is causing that in my mod.
OK I can create the .sur files but when the ships using them get destroyed the FLServer crashes. Testing just by wearing one on your ship is never enough, I had many problems in the past 2-3 years that I have been making them and it often took several tries to get a fuilkly working one.
I am also using exporter v1.1, because v1.2 makes bad surs very often and other people advised to not use it.
This method is simple but I have not been able to make even one fully working sur file, they can take many kills before they fail, indicating something is “almost right” but not 100%.
Of course we don’t put all the sur components into our sur files that FL standard surs do have.
Yes I can either resize a standard FL ship sur, or even just resize a shield bubble like li_freighter_shield.sur only, but I do have pride in getting my own sur files into the game for each ship! Unfortunately I am a perfectionist in some ways.
I appreciate your helping out with this guys, it seems my own PC or setup is faulty somehow, I am not sure where to start but I will try making the sur on another PC - and maybe also reformat this PC’s hard disk and install windows and everything again.
