shape = BOX will work for creating an exclusion for asteroids inside a nebula, but actually excluding the nebula itself means you MUST use shape = SPHERE instead for the exclusion zone. You will likely find a reference to a non-spherical exclusion zone for a nebula in flspew.

Might be more useful to post the OBJ files which you are generating the SURs from Jolly… And add the CMP as well, if you’re doing a multipart SUR, the names must match up with the groupnames in the CMP, with a _lod1 suffix added. That’s a common oops for not getting a collision detection going.

I’ve noticed the same problem (also with the Biodome models which also can carry a loadout) BUT: They DO start to fire on players who are hostile to the faction the object’s reputation belongs to. I think the only way to get them to reliably fire rightaway is by defining these objects as weapon platforms (and surpressing their shape), then parenting them to the base.

Discovery uses this configuration:

[Solar]
nickname = mplatform
LODranges = 0, 1500, 3000, 12000
ids_name = 60213
ids_info = 60214
type = SATELLITE
DA_archetype = solar\dockable\manufacturing_platform_lod.cmp
material_library = solar\Solar_mat_misc01.mat
material_library = fx\envmapbasic.mat
envmap_material = envmapbasic
mass = 10000.000000
loadout = mplatform_red
solar_radius = 600
shape_name = NNM_SM_MPLATFORM
hit_pts = 999999961690316250000000000000000000.000000

[Loadout]
nickname = mplatform_red
equip = infinite_power
equip = ge_s_scanner_02
equip = mplatform_animate1
equip = sfx_rumble_platform
equip = Small_station_turret02, HpTurret_S1_01
equip = Small_station_inferno, HpTurret_S1_02
equip = Small_station_inferno, HpTurret_S1_03
equip = Small_station_turret02, HpTurret_S1_04
equip = Small_station_turret02, HpTurret_S1_05
equip = Small_station_turret02, HpTurret_S1_06
equip = Small_station_turret02, HpTurret_S1_07
equip = SlowLargeWhite, HpRunningLight01
equip = SlowLargeWhite, HpRunningLight02
equip = SlowLargeWhite, HpRunningLight07
equip = SlowLargeWhite, HpRunningLight10
equip = SlowLargeWhite, HpRunningLight11
equip = SlowLargeWhite, HpRunningLight17
equip = mplatform_smoke_red, HpExhaust01
equip = mplatform_smoke_red, HpExhaust02
equip = mplatform_smoke_red, HpExhaust03

And an instance of such an object, attached in this case to Java Station:
[Object]
nickname = Bw08_mplatform_01
ids_name = 0
pos = 1050, -22, -15699
rotate = 0, -90, 0
archetype = mplatform
ids_info = 0
reputation = gd_im_grp
behavior = NOTHING
difficulty_level = 16
pilot = pilot_solar_hardest
parent = Bw08_03

```The above example will not fire if the player isn't hostile to IMG, but it will fire on objects hostile to IMG, including NPCs.

I could see this useful in simulating a continuous battle - 2 solars exchanging fire forever.

Are the two NPC factions you have listed hostile to eachother? IE do NPCs of these factions attack eachother when meeting?

If docking is not an issue, move the HpMount on the ships that exhibit this behaviour 200m below the ship, as suggested earlier in the thread. This will cause the ship to undock 200m above the base, likely well clear of it.

If you had been using FlHook, the “moors” plugin by Adoxa is an option - it makes capital ships using medium and large moors undock in reverse, like the vanilla transports do.

What’s the recommended limitations on hitboxes though? In DiscoveryGC we’ve got some issues with lag once we hit 150+ players and get a couple of groups fighting eachother - and I’m half wondering if the hitboxes are the issue.

Method used for creating hitboxes:

• Import CMP into Milkshape
• Reorganize the model into more or less convex shapes which follow the model skin.
• Use ConvexTool to wrap a convex shape around each group. This ensures that every group in the hitbox is convex. Delete the original groups afterward
• Export the entire model as OBJ.
• Use Obj2Sur by SmackBolzen to convert it into a hitbox. The only hardpoint we list is the HpMount one for ships - for equipment, we use none.

This results in SURs of about 10-60 KB in size, with group counts ranging from 8 to 60. All groups are assigned to root, we don’t use destructable or moving components at this time. I have searched, but can find no recommended limits on SURs. Only “try to keep them as simple as possible”, which is not helpful.

Small addendum as the one who set those double docking points on the jumpholes (I was attempting to allow convoys to jump with more then one ship at once): It will only fail if you set multiple docking points that service the same ship types. So you can, for instance, set a “berth” and “medium moor” simultaneously, but not two “jump” type docking points.

The error also broke a jump timer we had on the holes, so I guess this is experiment failed on my part

It appears the links in the opening post are now dead…

This tool has seriously cut down on the time it took to track down a number of system bugs in the Discovery 4.86 release. Simply seeing which zones are where was enough to figure out some zones just weren’t where they were supposed to be. Props.

I’m impressed with that seeing object shapes teaser. If that can get implemented even in a beta stage, I’m interested. It will make arranging bases SO much easier if the object geometry is painted (textures is a nice bonus, but geometry alone would suffice).

Well, here’s a minority thanking you for your work Smackbolz. DiscoveryGC 4.86 is coming along smoothly on the modeling side, and most non-multipart models have been given a new, tight-fitting SUR using Milkshape and your tool.

We’ll hold off with the dockable and animated ones that still need a better fit, until your tool has functionality for that. Old clunky spliced surs until then - just means you can’t use many parts.

Okay, for the Discovery mod I’ve used this tool to rehitbox 205 custom ships (and counting). So far, no problems, although hitbox testing is still ongoing. Some thoughts:

Someone mentioned shield bubbles. Those are seperate SURs assigned through the shiparch and the corresponding shield entry in select_equip. Would be outside of the scope of this, although I see no reason why this tool should not be able to create a hitbox of a very simple egg shape. Point being it’s a seperate model entirely, and not part of the ship itself.

Being able to assign named components so destructable models and hitboxes moving along with animations can exist, would definately be a plus. That’d make bases with animated bay doors possible.

I’ve fed the tool clusters of convex shapes (basically, when supplied a model, I manually break it up into pieces, use Milkshapes convex tool to wrap a convex untextured shape around them, and delete the original shape). Noticed if I don’t check the box to use convex hull instead of splicing, the SUR tends to get a lot larger. Not sure why.

Sweet. Let me know if you need someone to test that functionality - still got quite a bit of work to do on the SUR side. But for now the 228 preexisting models that need to be converted over will keep me busy for a while…

Another thing you may wish to include is an option to generate a shield bubble (using perhaps, a preset distance from model X, Y and Z radius, offset by the model center?). I unfortunately have no idea how you tag a group as shield.

This. This here tool? This will make the 4.86 hitboxing for Discovery a LOT easier. As one of the guys who primarily does this, I’ve found that this works infinitely more easy then sursplicing. There is just one feature missing:

Is it possible to include a feature to match certain pieces of a hitbox to a specific component name in the CMP? When using the SUR splicer I was previously using, this was possible. This is neccesary in order to support SUR components tied to animated parts, such as docking bay doors.

I’ve been yanking a few of our static models though this tool and so far, no problems. I -strongly- recommend anyone using this tool to create convex shapes around your ship and removing the original parts before exporting the shape to an OBJ for this tool. Especially if you use this for improving server performance. Reason being that you get a bloated SUR filesize, which I imagine is also more complex.