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

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!


Oooh! Let me see what I can do with this :smiley:

Thank you!


So, performing logic in the ship file is no good for monitoring and then setting armour families based on health percentage. It seems that the logic in the file is only checked once, on load. Which makes sense. Changing the priority of the gamerule defaults or the ship defaults in the props folder is irrelevant as they will only be checked once on load.

The custom command can do all the same stuff, and it’s checked regularly, but you can’t set the armour family from within the custom command. Pointing the armour family in the ship file at something in the custom command is pretty pointless too, as that is (again) only run through once.

Looks like my lead led nowhere… no changing armour family on the fly with what’s there now :frowning:

Unless I missed something?

No, I think you have it - changing that on the fly was never considered. That data isn’t stored in the ships - it is stored in the ship - the shared type. Promoting that data to a per-ship variable is not hard, though it likely would make old saves angry.

If there are a list of things you wish could change per-ship, instead of per-ship-type, during gameplay - make a new post under the public preview and list them (and explain why). Changing those values is also a bit harder in MP because we have to make sure they change the same way, at the same time for everyone - so it is a bit more effort…


Done! Thank you for the to-do listing :slight_smile: