A .sur File Issue That Has Me Stumped
-
Some sur files were need for some new ships being implemented however I and the others on the particular project didn’t have access to the original files for the ships, just the CMPs (the original modler is exceedingly hard to reach these days). One of the shipwrights tried making new sur files using the CMPs (I’m afraid I forgot to ask exactly what program he used) and one of them had the following issue:
http://img855.imageshack.us/img855/7938/screen271j.jpg
The fighter selected in this picture is obviously not 0 distance away, and the target-box around the fighter that is next to the one that is selected is large and annoying, which I think may be a symptom of the incorrect distance.
The first thing we tried was getting another shipwright to try several times to make new sur files, but there was no change. We copied the sur for one of the other new fighters that wasn’t presenting this issue (they are the ones visible on the right of the screen shot) and replaced the seemingly faulty one with that one and it started showing the same problem. The next test was to use the sur from a vanilla ship and that one did fix the issue.So, I think it’s definitely a sur issue but it seems to be something about the new sur files (again I’m sorry I forgot to ask the shipwrights for more detail as to how they made them) that is specifically reacting to that one ship.
This is the point at which we started really scratching out heads so I thought I’d post here asking if any more experienced people could provide some tips. Anyone? -
FlModelTool should be able to correct this. Just wrong position offsets in the .sur file header. Alternatively you can correct it yourself with a hex editor but I have the offsets not here right now. They are here somewhere in a topic, though.
-
Would it be too much trouble if I asked for a screen shot of a sur open in FLModel pointing out exactly which lines need changing? I’ve never worked with sur files before so when I have the sur open it means virtually nothing to me.
-
Just open the .cmp and after that the .sur file, then click resize, select Automatic (to cmp), save and you should be good to go.
-
Yeah, I already followed the instructions from the second half of this tutorial (ironically by Forsaken, lol):
http://the-starport.net/freelancer/forum/viewtopic.php?topic_id=1002&forum=26It didn’t change anything unfortunately. Would it help if I posted up the text from FLModelTool? Like I said, it’s gobeldygook to me.
-
You’re refering to this information I gleaned from FLModel right?
Bounding box info : x1 4.599092 x2 -4.591620 y1 7.340136 y2 -4.200078 z1 13.898084 z2 -12.793049 Center : 0.003736 1.570029 0.552517 Radius : 15.248461
-
Yes, that is what i meant.
It is similar to the solar_radius = XXXXX from solars , where if you put a high value to a small object you have same problem as you described .
Can you dump your sur and put here some values ?
I suspect the sur radius. Now i know the sur from ms3d exporter and LS sur builder are compact surs and vertices and polygons into sepparate groups; the OBJ_SUR converter its something different : it puts almost each triangle into sepparate sur groups (for now only attached to Root group ), each with its sepparate radius . -
Actually there only is one radius for each surface which consists of the groups you mentioned. Also the center values for such surface usually is the cause for the error he has. FlModelTool should correct this (it says so in the readme and our experience also showed that). Since it didn’t either it did not correct the values or the error is somewhere else.
-
FLMT has an issue where it holds onto the old settings of the CMP, so when you resize a SUR your getting the wrong settings.
If it’s still Anton’s original that’s available then you have to load the CMP, resize it, save it, close the app, restart it, load the resized CMP, then you can resize the SUR to the CMP.
-
I tried what you suggested Bejaymac but it didn’t change anything
This is a limited FLMT extract from the sur file info;
Surface : CenterX : 0.003736 CenterY : 1.570029 CenterZ : 0.552517 InertiaX : 200.000000 InertiaY : 200.000000 InertiaZ : 200.000000 Radius : 15.248461 unknown byte : 0xFA - (250 decimal 11111010 binary) Offset1b : 0x133C (4924) - always identical to surface_header.offset1 padding byte : 0x00 - Always 0 Offset2 : 0x00001320 - Offset to bit header Padding3 : 0x00000000 0x00000000 0x00000000 - Always 0When fired apon the hitbox seems to work fine, each section of the ship registers hits correctly and there are no extra sections that don’t correspond to the CMP. The only two visible issues seem to be the ‘target box’ around the un-selected ships and the ranges that the ships register at so it’s not a critical issue, just a really big pain.
