Shield Regeneration Rate Mod

[harpy eagle]

This mod attempts to address a balance issue in vanilla combat related to shield regeneration rate.

In vanilla, the amount of shield points each quadrant regenerates per turn is a fixed percentage of the maximum shield points (adjusted for shield generator damage), that is modified by the number of shield regenerators on the ship. As has been pointed out elsewhere, this creates a bit of a balance issue where ships with a lot of shielding are way tougher than is reasonable given their build costs.

I believe that this is because of the fact that regeneration is calculated as a fixed percentage of maximum shield. This causes the regeneration rate to scale up as the maximum shield points of a ship increases. The reason this doesn't work is that while e.g. doubling the amount of shield a ship has will double the amount of damage we need to do to a ship to get past the shields, doubling the amount of shield a ship regenerates per turn has a far more complex effect on ship survivability.

Therefore while the way the maximum shield points increases as we get more powerful ships is (IMO) pretty fair, applying that same progression to shield regeneration rate is not fair at all.

This mod attempts to address this issue by changing shield regeneration rate to be equal to (the adjusted maximum shield points)^ 0.625 (i.e. roughly the square root of the maximum shield). The result is that the shield regeneration rate for a small ship with 40 shield is 10 points per turn (i.e. unchanged from vanilla), while the regeneration rate scales up slower than the maximum shield.

It also changes the effect of shield regenerators so that the regeneration rate is = MIN((base regen)*(# of regenerators + 1), 60%)

[siyoa]

maybe all we need is a dedicated shield slot that accepts shield only and remove ability to put shields into system/station slots ... so you can have only one shield per ship

I must say it was quite interesting to add new hardpoint type, it is spread over 4 files, if I captured everything ? well, finally no errors, so ...

EDIT: I guess there must be at least one more for description

[zolobolo]

Yes, the basic issue is that shields do not scale linearly with size of hull, nor by resource requirement of ship.
A larger ship not only gets 2X the shield base value per shield, but also gets +1 shield module, and thus 4X the Regen amount/Turn

So yeah, restricting shield modules to a single slot might resolve this but could open up a few cans of problem regarding AI ship designs and restricting player freedom

Generally it should not be a problem if a large ship starts out with a much larger base shield capacity as it will generally deal with larger caliber weapons, but the regen rate is off the charts. The calculation seems logical but is probably not intuitive for meat computers (aka humans)

How about a different angle?
What if base regen rate is 0 and each shield re-generator adds an absolute value to the shield scaling with ships size?:
S: +10
M: +20
L: +30
In this concept, shield would act like armor (with advantage that it is calculated per side) and offers the option to be regenerated via regen modules but the regen value would only be dependent on ship size and number of regen modules and independent from the number of shield modules

[siyoa]

I think the problem with shields occupying system slot is that it is incredibly hard to balance ... for big ships you needs to have multiple system slots, so the ship really feels like big ship that can do multiple roles ... but the moment you decide to overload the ship with as many shields as possible all balancing goes out of the window

not sure, if I am explaining it good enough ... let's say we change fighters that they fit to system slots ... or for the matter, ships would have only system slots and anything will go there ... so you can create a ship with only powerful weapons or only shields ... yes one is glass canon and the other just a tank and the trade-off is that you add one or the other ... or you can try to hit middle ground and fill the ship half and half ... the problem is that the extremes (ship full of weapon vs ship full of shields) are so far apart that to balance weapon damage vs shields (and or shield regen) and at the same time to keep that middle ground ship load-out (half shield, half weapons) viable is probably near impossible

I think that the problem now is, you can have way too many shields on the ship, especially big ships ... but to restrict amount of system slots goes against diversity of design ... so the same way we have dedicated weapon slots, I think we may need dedicated shield slot ... it doesn't mean it has to be a single slot, you can add two or more if there is a need

also adding shields right now scales linearly to total shield amount ... I think this is part of the problem, very few things scale linearly with adding the same amount of resources again and again ... you should hit diminishing returns (similar to shield regenerators) ... first shield module should give X shield, second X/2, third X/3 and so on ... or maybe they don't really add more shield, but increase shield density (i.e. shield damage absorption, i.e. part of the damage from each weapon is ignored)

now, there is shield regeneration, inheritingly (is that a word?) shields should have regeneration, otherwise they are just an armor and we can add auto-repair modules ... the problem is that the way shields are implemented right now, it is impossible to balance it ... but I think root of the problem is not shield regen rate, that is just a cause

[harpy eagle]

Well, I already stated my opinions in the OP. If you stack shield modules the increase in total shield proportionately increases the amount of turns (for example, assuming the enemy deals a certain amount of damage each turn) as ship would stay alive in combat. But once the regen rate gets close to the amount of damage it takes each turn, increases to the regen rate massively increase the amount of turns the ship stays alive. At some point the ship is invulnerable.

If everything were linear we wouldn't need to worry about these second-order effects from stacking stuff. But the impact of regen isn't linear, so I still think it's the regen.

I guess bulkheads don't really provide enough armour for them to ever be OP, but if you did mod the game to make them provide a ton of armour... I would bet that bulkheads would only ever be OP as a whole or not, you wouldn't get issues that were related to stacking only.

[zolobolo]

[quote="harpy eagle"]
If everything were linear we wouldn't need to worry about these second-order effects from stacking stuff. But the impact of regen isn't linear, so I still think it's the regen.[/quote
Agreed: giving the regen modules absolute value effect would makes it linear: larger ships still benefit from upscale effect and they would still be able to mount more of them then smaller ones to stack that affect, but this would directly reduce their offensive power and would not be further multiplied by the shield used. Players would be encouraged to use a regen module but would probably not take more then one or two and the regen provided would not be so huge a leap from medium vessels with distinct disadvantages (less PD force for example)

I like the concept of dedicated shield slots but it just seems to affect the game in too many ways: need to redo graphics, hints, AI and guess it wouldn't be backwards compatible with saves

That being said, the mod did help a lot so far to lessen the issue

[siyoa]

If everything were linear we wouldn't need to worry about these second-order effects from stacking stuff. But the impact of regen isn't linear, so I still think it's the regen.

regen is not linear in absolute values, it is in relative values, i.e. percentage ... I guess we have different opinion on this, which is perfectly fine, as the world would be boring if it's not the case

given where the game is now, it indeed is easier to follow the road you guys are going (being save game compatible and all that)

[zolobolo]

Sorry for the confusion, this is what I mean under linear progression: the base regen rate increases linearly with each hull size (literally) - like seen in below graph

The reason I thought this would be beneficial as it is very easy for a human to calculate with, but upon inspection of the graph, the current mod version is the superior one balance-wise.
It is just harder to grasp what it effectively means when designing the ship (like how many hits will it withstand from a Heavy Laser, or what does it actually mean when I add another regen module) since you need to calculate the square root of the current shield load-out, whereas via a linear progression the tool-tip can just tell you: this will add +20 regen per turn

The below graph also clearly shows where the vanilla balance is tipped off as the progression from small to medium hull quite neatly matches the linear max base progression, but ditches this progression in case of large hulls and this is compared to MAX linear progression!

But like I said - the current mod mechanic seems optimal value-wise

The bigger problem now are direction shield segments

[harpy eagle]

It is just harder to grasp what it effectively means when designing the ship (like how many hits will it withstand from a Heavy Laser, or what does it actually mean when I add another regen module) since you need to calculate the square root of the current shield load-out

This is a really good point, and I'll see if I can mod the designer GUI to show the regeneration rate.

The bigger problem now are direction shield segments

That's a bit of a separate issue, and is also more related to helping out the AI cope with shield directionality rather than general balance.

I'll see about playing with ways to make shield directionality "softer" in a separate mod.

[harpy eagle]

This is a really good point, and I'll see if I can mod the designer GUI to show the regeneration rate.

Unfortunately it doesn't appear to be moddable - you have to replace the file in the Lua State\GUI\Designer folder. See the file to replace with below.

I'm not sure why the game doesn't accept changes to this file from a mod... when it loads it should replace gui.DesignerPane, right?

[harpy eagle]

(Just wanted to add that other than this one issue, I think the game is pretty well balanced for early-access. Admittedly I haven't played with late-game techs too much, but after several playthoughs lasting through to the late mid-game and watching many, many battles during the whole process of trying to get the AI to more fully use the gameplay mechanics I haven't noticed anything else that was excessively one-sided yet.)

[sven]

I'm not sure why the game doesn't accept changes to this file from a mod... when it loads it should replace gui.DesignerPane, right?

You appear to have discovered a case where 'naive' modding doesn't work. The issue, basically, is that DesignerPane is actually a sub-component of GalaxyMap. So, DesignerPane.lua creates a function called gui.DesigerPane(_ENV), and that function is called inside GalaxyMap.lua in order to initialize the designer pane. What happens if you include a modded DesignerPane.lua is that

• 1) The vanilla gui.DesignerPane() is defined
  2) The vanilla gui.GalaxyMap uses gui.DesignerPane to create the pane
  3) The mod redefines gui.DesignerPane()

Ideally, I'd have some dependency logic somewhere that would cause the reload of the modded DesignerPane.lua to trigger a reload of GalaxyMap.lua; but, atm, I don't appear to have such logic written up.

Um, I'll add that to my TODO list. Until it's working though, a reasonable workaround is just to copy ~GalaxyMap.lua into your mod folder.

[harpy eagle]

I see. Dependency logic would be cool however it may save you a lot of time just to provide a function that reloads whatever resources need to be refreshed, that modders can then throw at the bottom of their relevant mod files.

[sven]

I see. Dependency logic would be cool however it may save you a lot of time just to provide a function that reloads whatever resources need to be refreshed, that modders can then throw at the bottom of their relevant mod files.

Hrm. It appears this function already exists; it's called "reload_script". So, yes, i think if you include:

Code: Select all

  reload_script [[GUI\~GalaxyMap\GalaxyMap.lua]]

at the bottom of your modded DesignerPane.lua, that may also solve the problem.

[harpy eagle]

It works! I've uploaded a new version of the mod to the OP.