Can there be a better way to do Trek-style shields?

Hi @BitVenom :smile:

With permission from the Phoenix mod team (thanks Erayser :smile:) Stargazer and I have been trying to wrap our heads around their Stargate mod shield system and create a hybrid with our Star Trek: Continuum shield system. Their shield system is visually superior to ours as it uses a subsystem for the shield itself and (with the use of non-penetration secondary hit fx) allows for different hit fx on the shield and on the ship hull if you have the collision meshes all correct. Our scripting system makes our shields functionally superior to theirs though as we can have the shields drop to 0% health when ships cloak, we only had subsystems to fake a shield health bar.

The main drawback to their subsystem method is that you can have weapons on the ships blocked from firing by the subsystem collision mesh, even though the joints are outside that collision mesh. The trick is that this subsystem collision mesh substitutes for the ship collision mesh to block the weapons from hitting the ship collision mesh and triggering the alternate hit effect, which is the whole point of trying to go down this path.

There is a better way though, can we please have a flag on a subsystem to allow the ship that it’s mounted on to ignore the subsystem collision mesh? So that a ship’s own beams, pulses and torpedoes/missiles will pass through it unmolested?

This will mean that we can simply have the sphereoid shield collision mesh in the subsystem, the non-penetrate fx as the shield hit fx and the hit fx as the hull hit fx. Using the “spawn weapons fire on hit” functionality we can spawn a sphere-burst weapon with no FX to apply the damage to the shields while still allowing the non-penetrate fx to be played correctly when the weapon hits the hull. If the subsystem is set to damageable then the shield will be destroyed, fail and after a short time start to regenerate. Multiple mods would benefit from this simplification of the shield mechanics, the rest of the issue is just attack and armour families :smile:

Allowing effects and animations for subsystems would also allow us to put shield fail FX into a subsystem “events” file directly instead of scripting it in elsewhere, just set the on/off animation to play when the shield system hits 1% health, have the collision mesh for the shield move up 10000m out of the way so the ship’s hull can be hit and you’re covered! Currently we just move the joint that the shield is mounted on, but having this in the subsystem itself could simplify things

So, to summarise, my request distils down to three items:

  1. Flag in subsystem file to allow ship that its mounted on to ignore the subsystem collision mesh and fire any weapon through it without triggering any FX or interrupting missiles

  2. Allow an events file for subsystems in the same fashion as there is one for ships

  3. Allow an animation for subsystems so we can move the collision mesh up when the subsystem health is 0


I approve this message ahah! Would love to know if there’s a better way to do it properly. The way we both did it was pretty messy isn’t it hah :stuck_out_tongue:

1 Like

I can’t make any promises - nor can I work on this right now regardless (kinda busy with that whole HW1/HW2/Formations thing) - but this is noted. Some of this can be done pretty fast. Other things I think maybe can be done a better way, which will be covered once it’s ready to show off :wink:


I’d like to definitely second this request- also having a subsystem’s collision mesh be removed when it hits 0 health would also be very nice to see- instead of moving the joint/mesh.


Thank you @BitVenom! It’s good to know this is on the list :wink:

I agree with @tempest6677, If there’s a flag “NewSubSystemType.IsShield” with a 0 or 1 value to cover the blocking of collisions for the weapons of the host ship and auto-remove the collision mesh when the subsystem hits 0 health that would be fantastic! Two birds with one flag :smiley:

You’d have to assume NewSubSystemType.IsShield = 0 if there’s no entry in the .subs file for it too, so it doesn’t muck up all the other .subs files out there

1 Like

I would be so grateful for proper shield support if it ever comes

The CM based shields were a nightmare and I eventually abandoned them for the current subsystem regen combo

I can come up with dozens of thoughts on how to do shields and what I would need for various scenarios, but if there was any way to integrate the functionality into a ship file rather than a subsystem that would be awesome

We have ship based shields in ST:C @EvilleJedi, have you had a look at our system?

I didn’t think Star Wars ships used shields though? :confused:

This would be really cool. I’m loving the mod possibilities coming out of the community regarding remastered.

They have conformal shields in most cases so really it would be the visual hit effect change when the shield is down rather than a bubble. Most of the ship’s longevity is in the shields and armor is really a last ditch defense. Strike craft ordinance provide the easiest method to damage subsystems and cause earlier shield failure with precision attacks. I would also want a certain amount of bleed through based on weapon class vs a shield class as well as having some weapons ignore the shields entirely/partially.

Without a subsystem collision mesh to allow the “non penetration” alternate hit fx to be triggered I am not sure how you’d go about getting an FX change on the weapons.

It still seems to me like you’d benefit from the same proposed system, you’d just use a much tighter collision mesh on the subsystem.

I would just make it part of the .ship logic, grossly oversimplifying it here


if(hitdamage() && shield >= 0 && ! penetration)
hitfx = ‘shield hit fx’
else if(hitdamage() && shield <=0)
hitfx = ‘hull hit fx’

note: I have written a horribly crappy implementation of ‘AwesomeTriPickRaycastUWlogic’ before and I really mean it when I say ‘grossly simplified’

another reason I really don’t want to use subsystems for the shields is that I have some 19km long triangles that don’t play well with collision meshes as it is and subsystems just make that issue infinitely worse.

I also was hoping to be able to implement shields without resorting to subs. We already have a complicated mess and I didn’t really want to add to it. Having to redo ship and weapons templates for exports would also be a big pain… but good, working shields with different hit effects would definitely be worth the pain of revising the templates.

Just making a “UP” on this topic haha :wink:

Gotta agree, this topic is still on my wish list :smile:

The Original SoA mod (Homeworld Classic) used “fake shields”. There really were no shields, but there was a shield hit effect. We figured if shields were down that the ship would blow up with one, or 2 hits anyway. So we just combined shield, and hull into total hit points.

Hi all, sorry to necro this thread, 526 days after it died, but all the pertinent points are here :wink:

I had a thought on changing the armour family of a ship during a game, and thusly allowing shield AND hull hit FX on demand.

If my thought turns out to be right of course.

Exhibit A:

*\ship\tai_gravwellgenerator\singleplayer\props\default.lua, line 9, “DockFamily = “Controller”,”

Exhibit B:

*\ship\tai_gravwellgenerator\singleplayer\props\default.lua, line 6, “String_Properties_Priority = 1.0”

The Dock Family is set in the string properties section of the file, which means that the armour family could be set there too. Theoretically, anything in the ship file could be set in this section or in the Number_Properties section.
Now, if there is a conflict between this and something else then the section with the highest priority number wins! The big question is can we change this number at will? Say… when a subsystem is destroyed? (Ignoring the fact that ships still can’t shoot through their own subsystem collision meshes).

If the armour family changes a set of weapons with the hull hit FX will then be able to hit the ship and the initial set of weapons that have the shield hit fx would then be unable to hit the ship. One of the ugliest parts of the existing shield solution would be summarily dealt with!

So, can the String_Properties_Priority number for a ship be changed? Or even brought into conflict to force one or the other being applied?


Another step towards figuring something out… :thinking:


So… we could use SG’s starbase in TNG with no weapons for MP games and still have it with weapons for skirmish…

1 Like

I think so! You just have the “canAttack” line in the string properties with it active in one and not the other :slight_smile:

I am running into an odd issue though

Deathmatch props/default.lua

String_Properties_Priority = 2.0

String_Properties = {

HeavyArmourFamily = “HeavyArmour”


Ship props/default.lua

String_Properties_Priority = 1.0

String_Properties = {

UnshieldedArmourFamily = “NoShieldArmour”


Ship file:

NewShipType.ArmourFamily = getRulesStr(NewShipType, “HeavyArmourFamily”, “HeavyArmour”)
NewShipType.ArmourFamily = getShipStr(NewShipType, “UnshieldedArmourFamily”, “HeavyArmour”)


@bitvenom, the higher priority “default” in the rules file is ignored and the hull hit FX are played on the ship, even though the normal Heavy Armour family with the shield hit FX should be in force. :thinking:

I’ve not even got to trying to change the priority value yet :frowning:

1 Like

The issue is pretty obvious -

x = 1
x = 2

What is x? It’s 2. Because that came after. It isn’t clear which one matters. The last one has priority as declared.

Maybe try:

local ruleFam = getShipStr(NewShipType, "UnshieldedArmourFamily", "HeavyArmour")
NewShipType.ArmourFamily = getRulesStr(NewShipType, "HeavyArmourFamily", ruleFam)

In this case, if the rule has a setting, it replaces the one specified by the ship (or lacking both, the default of HeavyArmour is used)… The ship script is lua - you can do ‘real’ work in it… you could make a table in the ship file of armor types, and just have the rule set a value (like an int or enum) that uses the table only in certain cases, etc. Go crazy!