.obj -> .sur converter

You can use this for parts with only 1 mesh in them.

http://www.gamefront.com/files/20193523/SURSpliceForOBJCon.rar

But if it’s a complex mesh like the rings in that model there, then you will have to do it by hand. That model I posted, every part except the 2 donut shaped rings where just a single mesh. So all I done was make 2 simpler SURs to start with only a single mesh and then replaced them myself with the more complex ones.

Nice, thanks!

The only difference between the two versions (sur_splice by Devast8or and SURSplice by anonymous) is the HPID tag - sur_splice always adds an empty list; SURSplice always removes it. I’ve made an update that defines the hardpoints in the input file itself. It’s not clear, but the hardpoints work per part. Not having the original example model (not that it really mattered, I guess), I didn’t update the input file, so perhaps someone would like to contribute a new example (and perhaps update the doc describing the process, if necessary). I also haven’t mentioned it in the readme, but this version determines the “bits” radius and scale values automatically (and assumes the center is already right).

After Sushi posted the video of his turret issues, i decided to do a test myself on a custom asteroid base model i’m using where i made a sur using the OBJ converter. No hardpoints added on this model and can confirm the turrets (standard vanilla base turrets) are taking hits with the base parts also taking seperate hits.

Certainly seems on bases at least, no hardpoints required for the sur.

Can post video if required

WOW.

I’ve been gone for 6 months and we are still on this?

Looking good though, it must be if StarTrader is ok with it

Waiting with bated breath for the next release.

Could change me back into a cuddly rabbit…

… or into a dynosaur meaner than the croc!

You’ll have to wait and see…

StarTrader wrote:
Waiting with bated breath for the next release.

Could change me back into a cuddly rabbit…

… or into a dynosaur meaner than the croc!

You’ll have to wait and see…

I call shenanigans!

FriendlyFire recently found out a fatal flaw in the .sur creation tool, sadly. I had added all the hardpoints of each ship into the HPID portion. With mass testing underway on our mod, we were getting these very odd CTDs. Before the CTD, in our fw-tow-client log we have setup, we would have this error:

[25.05.2011 00:43:50] void __thiscall IServerHook::SPObjCollision(const struct SSPObjCollisionInfo &,unsigned int)

We also noticed that when players collided, there was a tremendous amount of lag created. Sometimes freezing the screen for 5-10 seconds or crashing the game immediately.

FF had a hunch it might be related to the HPID. I removed them from all the hitboxes and we don’t have this issue anymore. There is no longer any delay when ships collide.

Can anyone else confirm this?

To add to this, my thinking is that most of our guns have no SURs whatsoever, which could make FL bug out when the gun is collided with. The HPID collision sphere would get triggered, but when looking for a full SUR for what’s attached to the hardpoint, the game would find nothing, which would make it bug out.

So is the problem the sur tool, or the lack of an sur for the weapons in your mod?

Probably the latter, but Schmack might still want to look over again to make sure it’s indeed properly implemented, just to be on the safe side.

The HPID collision sphere would get triggered

If I’ve not missed anything crucial, Schmacks tool does not (yet) actually add any HPID collision geometry as discussed earlier in this thread.

So I guess you’ll make sur files for your guns, test again, then tell us whether it’s totally screwed or not Hope you kept a backup of all those surs you’d made, just in case it’s the guns.

SVN

w0dk4 wrote:
If I’ve not missed anything crucial, Schmacks tool does not (yet) actually add any HPID collision geometry as discussed earlier in this thread.

Question. Why would it? Surely a custom turret or any other addon to a model should have that defined seperatetly? I’ve always added custom surs to any turret models or whatever i’ve made. My point is a simple one after all this, why should the obj converter need to take this into account? Make each part a seperate model and make a sur accordingly. I’ve not had any errors so far in this department.

Adding the CM, Mine and thruster to the HPID section are the only hardpoints i add to each sur file made and even then only on ship surs. All sweetness and light so far with no crashes.

Schmackbolzen wrote:
Well, I plan to continue working on the tool in the coming weeks. It would be nice if you could report your results until then. If I really need to include the geometry I would first have to read the .cmp files for the hardpoint names and locations. Mulitpart would have to wait then.

Maybe there is also another way to get the coordinates and names, just make your suggestions.

Good news i have already sent you one of my model and don’t know if the model is buggy or if there is a lack on the current ersion on the tool…

Good luck anyway

Gibbon wrote:

w0dk4 wrote:
If I’ve not missed anything crucial, Schmacks tool does not (yet) actually add any HPID collision geometry as discussed earlier in this thread.

Question. Why would it? Surely a custom turret or any other addon to a model should have that defined seperatetly? I’ve always added custom surs to any turret models or whatever i’ve made. My point is a simple one after all this, why should the obj converter need to take this into account? Make each part a seperate model and make a sur accordingly. I’ve not had any errors so far in this department.

Adding the CM, Mine and thruster to the HPID section are the only hardpoints i add to each sur file made and even then only on ship surs. All sweetness and light so far with no crashes.

“Earlier in this thread:”

w0dk4 wrote:

FriendlyFire wrote:
I’m guessing that Schmack is right and that this really is just used to speed up calculations, whereas if you just don’t specify them the game reverts to the actual, more complex turret SURs.

Does make me wonder whether those turret SURs are used at all if you list them in the hardpoints list. Maybe they get used for calculations if and only if the simple turret is hit?

I think it works this way: If a beam is inside the general sur radius, the overall sur gets checked. Now, every hardpoint “rough” geometry is checked. If the beam intersects one, the actual sur of the equipment mounted at that hardpoint is checked.

So, if all your equipment is simply a sphere or a very simple geometry, I think there is basically no speed-up. But as soon as you have a lot of equipment that is rather complex, I think there can be quite a speedup.

Hey Schmackbolzen, thanks a lot for the tool; it makes complex .sur creation really easy!

Edit number 2: The rest of what I had had to say was even less useful than that, and I removed it. I’ll be thrilled to see the finished product. That is all.

(Sorry to double post.) Schmackbolzen, as a group splicer this tool works excellently. Your suggestion of making convex shapes in place of the actual model shapes works well. When using the convex shapes, there’s very few issues with passing through ship geometry.

If (or when) you get around to having the converter generate hardpoint shapes, perhaps you could have an option to either use standard FL hardpoint geometry or to make specially named shapes in your model. That way if a ship has set weapon geometry, for example, you can have the weapons hittable properly rather than using FL weapon shapes only. If this is even possible, that is.

Anyway thanks again!