.obj -> .sur converter

Schmackbolzen wrote:
This is very little info to make any conclusions. Are all the groups static? Who is colliding (player or npc)? What are the simplest models where it occurs? Are there models which don’t have that problem? You should experiment with the simplest model where the problem occurs. If you can’t solve it, give us the .obj and .sur and .cmp so we can have a look at it. After all it might still be a bug in the converter. If you solve it please post what the problem was so Skotty can add it to the tutorials.

To answer your question in order:

1. Yes, all the groups are static.
2. Player to NPC. Player to player also have this problem. NPC to NPC doesn’t seem to lock up the client
3. No, all models have this problem.
4. Already done. Had the same problem. :S

To take a look at the problem, I might have you give both you and Skotty access to the FW:TOW SVN, if that’s OK? I didn’t think about testing the ship in vanilla FL, although I don’t think it’s anything we did to the freelancer.exe.

I’ll add you both to our project on the SVN now and send you links.

The lag is rather obvious. The whole game locks up for many seconds, freezing the whole screen entirely. The lag appears to be purely clientside.

I’ve had a freeze upwards of 20 seconds before it unfroze.

Nice work Schmacks, but, something wrong with the “group belongs to” dropdown menu. Clicking on it doesnt create a dropdown menu of static or moveable parts anymore - just a thicker black line - I had to manually type the _lod1 parts in.

I had a similar problem - for a while just two out of 10 groups appeared and I had little scroll buttons at the side of the drop down menu.
But somehow after opening 2 more times it disappeared and the full menu showed up.

Since then I wasn’t able to reproduce the error again.

odd. XP with SP3 on my design compu. as you can see in the picture, instead of being populated by all the spike0x_lod’s the box is blank. No biggy as I can still type in the value.

thats better have one on me :pint:

Schmackbolzen still around?!

That’s the perfect time to throw a huge “THANK YOU BIG TIME” for your converter into this thread!

Hi guys.

I was looking back for P1p3r’s CMP importer and exporter, the last ones I could find were the ones I put together on that thread on 30th December 2011.

Are those the latest?

P1p3r seems to have disappeared?

StarTrader wrote:

P1p3r seems to have disappeared?

Yes, sadly he did. His exporters and importers are great, but have a few incorrect things that would make it much easier to work with the sur converter.

Thanks for your converter Schmack.
And thank you for your tutes, Skotty, great work.

So are those the latest importer and exporter?

Latest and correct exporter (which I use) is 109 KB (111.616 bytes) sized, modified 26. ‎oktobar ‎2011, ‏‎09:21:34 while importer is 2 days older.

Here they are, P1p3r’s latest importer and exporter, to save people time. They are the same ones as I uploaded on the original thread, but it takes time to find them there.

Does the importer (or exporter) still reverse the harpdoint triangles or was that fixed?

Has anyone heard from P1p3r? It’s worrying, in case something happened to him?

“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.

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?