Thanks Adoxa!

Schmackbolzen
First of all, you need to create the correct information about the parts in .cmp, before parsing by .obj -> .sur converter. There are problems with other exporters, if part is ‘Rev’, ‘Rris’, or chained over other (not ‘Root’) part.
Also, I have implement the automatic connect hardpoint meshes from separate .ms3d file.
I try to exclude such routine work.

I write a complete solution, without any clicks, with automatic binding of all vertex, parts, hardpoints offsets in .cmp and .sur files.
I need the ability to quickly correct any problems, and make new features without waiting for the another developer.
The only complexity moments for me were - bits-section and convex hull.
I would be grateful for the help by source code, primarily msSURExporter V1.3.

I’m writing a command line converter in C++, which using more model fixes, and .ini files for best usability.
Now supports - import from .cmp/.3db/.mat/.ms3d, export to .cmp/.3db/.mat.
Also, i’m need for fully correct .sur files, i’m working now for this.
I would like a good understanding, for what is needed and how they must be made the opposite triangles, for create correct code.

Please tell me, how to properly search “Opposite” triangle in convex hull mesh?
Now i’m looking for the intersection from barycenter, in the direction of the inverted normal, and it seems to work.
I have found differences in the choice of opposite triangle, in different exporters.
1. Vanilla exporter, work approximately as my, but sometimes it hits in the neighboring triangle.
2. msSURExporter v1.2 seems looks for a triangle, with the maximally oppositely normal, without position check.
3. May be i’m most to draw a line, from the barycenter, through the center of the mesh, and find the intersection with this, i‘m doubt it.

“GLS workaround” servers list updating is worked?
My server, many days is listed in
gun.fllistserver.com
and
http://www.flserver.de/topservers.htm
as “RUSSIAN FREELANCER”, and not listed in
http://www.freelancerserver.de/serverips.txt

In this code, [ebp + 0x32c] contain archetype ID of the ship .
I made hook, for some fixed scale, depending on ship class.

adoxa wrote:
freelancer.exe 1855C0 74->EB = scale ship to fill the preview ~adoxa

Hm…, only Root part of the ship is used, for scale calculation?
Some ships , I see not fully.

It seemed to me that the median is used as well for the calculation of the center of each part?
Because of this, I point out manually center for all parts that would avoid the problem of explosion and problems with moving parts.
It would be very convenient to have ini-files, describing the properties of parts for the converter (type, coordinates, parental part), for easy modifying .sur later.

I have a problem with the automatic center calculation.
Missiles / torpedoes / mines, guided by converter calculated center, and if it is too far from the geometric center of model / part, the explosion does not cause damage to ship, due to the fact that the geometric center misses the explossion radius of the munition.
I would not want to increase explosion radius, as it would be too damaging smaller ships, and I have to manually enter the coordinates of the centers.

I yet not completely have understand problems of the centres, while I can show one example.
I see strange automatic calculation of the centre for crosshair, it not the centre of mass, not the centre of symmetry, and not the centre of coordinates.
Possible, this place of crossing of parts, or so has coincided.

Yes.
This two little and very simple examples:
surtest.cmp/sur, contain four cubes, located in two planes, and worked fine.
surtest2.cmp/sur, contain eight cubes, located in three planes, and worked bagged, sometimes you can walk through cubes.
What here wrong?

Revised bugs information.
1. “Automatic” coordinates calculated correctly for single chunk “Static” and “Moveable” parts, and incorrectly for multichunk “Static” and “Moveable” parts.
2. Different coordinates required for chained parts. First .sur part, used as part of ship, should have coordinates, relative of a parental group. Secondary .sur part, used as debris, should have absolute coordinates (concerning the centre of model).
3. If parts are located in one or two planes, all works correctly. If parts are located in three planes, it is possible to fly by through sur. Is that problem, which I described earlier. One more example of incorrectly worked sur, you can fly out of dock through a wall.

In addition, I ask about adding ini-files support, with settings for sur chunks, it would be very convenient.
Possible, the author publish source code of the converter, for independent modifications by the interested persons?

“Automatic” center calculation worked incorrectly, but for “Static” parts and “crosshair”.
I select part in Milkshape and look center of selection in model statistics.
After export to .cmp by P1p3rs plugins, i check coordinates of part in “Fix data” section by UTF-editor, and see same (correctly) coordinates.
I check .sur file by surdump, and see another (incorrectly) coordinates of part.
This made AIM and damage issues, for large (100+ meters) multiparted ships and solars.
If i input manually negative parts coordinates, and set 0, 0, 0 for crosshair, all worked fine.

freelancer.exe + 0x0011417A
0x01 -> 0x00
Don’t cache HpLeftLane and HpRightLane effect position.

I tried shift, resize, and rotate sur, this not fix a problem.
Small experiment, the problem seems in parallel parts.

Updated:
I make sur from two parallel parts of this sample (without central part), not all collisions detected.

Many collisions not detected, especially from the inside.
It happens that the sur does not detect any collisions for several seconds at a time (sur may be “offline”?).
msConVexTool.dll has not contain information about the version, file size is 110 592 bytes. I not found another versions.

Updated:
Another version ConVexTool from page 22 of this topic, same result.

No.
I tried, no effect for this sur.

I tried to use MilkShape ConVex Tool:
1. Load prepared .ms3d, Ctrl+A, ConVex Tool, Del, Export to .obj.
2. Convert .obj to .sur, without checking second checkbox.
It’s easy and worked fine with “newgate” sur (big tube), but it does not work with this sur:

One my computer with Windows 7 and bad videodriver, has casual crashes at launch from Monkey planet, with and without FlHook, binary patches and addition mod DLL.
On another computer with Windows XP and Windows 7, no crashes any time.
Some players has same crashes occured, other players no crashes any time.
I have found out that the pointer dword_674AA0 is equal to NULL in crash time, I do not know why so occurs, there Adoxa can be help…

Thanks!
I import “newgate” and ship sur’s back to MilkShape, remove outer “bubble”, and reassembly sur’s. After that, >99% collisions detected.
I repeat this operation with “newgate” sur more times, while the amount of vertexes has ceased will decrease. After that, I have not fly through a surface.