Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Uomoz]

I think repairing ships during battle would make players artificially prolong battles to make sure all ships are full HP, hence breaking the repair cost mechanic.

[Magician]

Good point. But what if you can't repair more than 50% armor (even if you have 45% armor you will repair up to 50%, not 95%) and activating repair costs somewhat similiar to what it costs at the station?

[Borgoid]

You don't need to create artificial mountain of penalties and complications just to balance "Thule Armor Repair Module".

You don't HAVE to, but it's more interesting to do so and easier to balance as a result of the options available.

Zero armor? You're not replacing brake pads

In all seriousness though if you're looking to replace shields the sky is the limit when it comes to strength, so long as there are sufficient drawbacks.

[Thule]

I guess the reason why i am opposed to the idea of having the ability to repair armor/hull is, its a bit "boring". And don't get me wrong, i havent disposed the idea as a whole.
The existing defense systems are designed in a way that requies a certain amount of skill. in the case of shields its the way you front, or the direction of omnidirectional shields, you have to consider the time the shields need to raise.
Same with the phase shields, it's to a certain degree quite playful, you can "do" stuff with it.
I would like to mimic this kind of feel. A simple repair ability would not quite hit that nerve imo. and it would have to be elegant in a way that it doesnt burden you with penalties not understandable in an instance.

What i mean by that is the shields for example. You raise them and if they get hit your ship generates flux. if you go into q-space your ship generates hardflux. Both times it has to do with 1.flux and the implicated tactical managment with this kind of resource (i would like to keep that mechanic going on) 2. movement and the implications thereof. with raised shields your top speed bonus is reduced to 0. with phase shields you can move through any object till your flux runs out.
What it doesnt change is the inevitability of taking damage and blowing up as a result of it. Any mechanic which would allow to repair in combat would take that away. Even if you would cap it to a certain percantage it would always feel quite forced imo.

The proposed system with the speed bonus would provide a somewhat alteration of the movement the ship is capable of by the cost of generating hardflux.
Furthermore it would reduce incoming damage with the apllied slow down AOE around the ship. And to be honest i am not quite certain or statisfied with this part of the concept.

As far as the design of the concept goes i try to achieve something similar to shields and or phaseshields with all indications to tactical decisions concerning flux managment and the ability to have something
skill involved (where you can get better over time, concerning timing, placement, awareness of surounding and so on)

I don't know if i am too biased concerning repairabilities in combat but imo it would not work with the intended mechanics mentioned before.

[Borgoid]

What it doesnt change is the inevitability of taking damage and blowing up as a result of it. Any mechanic which would allow to repair in combat would take that away. Even if you would cap it to a certain percantage it would always feel quite forced imo.

That really depends on the implementation.
A shield pits the damage capacity of the opponent against the flux capacity of the user, self repair could be used in the exact same way if it generates flux.

Balancing it is another question entirely but I don't think it's incompatible with the current game from a design standpoint.

[Thule]

But would'nt it change a constant (hull/armor) to a variable (flux getting vented/ flux dissipation)?
Imo this is the crux of it.
Even if the system would generate flux and prevent you from putting these resouces into offensive measures the outcome would still be different.
The only means of defeating someone with a repair ability would be overpowering their capabilities to regenerate.

To make this balanced you would have to remove flux at all.

I have to further think about it.

[Ember]

how about making the repair ability only work if the ship has zero flux? or at least fairly low

[Uomoz]

I think such ability would be too good when the enemy is retreating.

[Magician]

(I am talking about system which Thule mentioned on page 24 )Well, what if.. activating this system will give a little higher bonuses, but also will apply negative effect right after turning off this system? Something along the lines of debuff to your flux vents or flux generation and engines. This may increase dynamic of ships combat behavior and also increase reward and punishment for using system.

[Borgoid]

But would'nt it change a constant (hull/armor) to a variable (flux getting vented/ flux dissipation)?
Imo this is the crux of it.
Even if the system would generate flux and prevent you from putting these resouces into offensive measures the outcome would still be different.
The only means of defeating someone with a repair ability would be overpowering their capabilities to regenerate.

To make this balanced you would have to remove flux at all.

I have to further think about it.

Interestingly this is exactly how Beam weapons currently work. A Medusa for example with 4 forward facing small and 2 forward facing medium energy mounts, with nothing but beam weapons (Tacs and Gravitons) generates 300 energy dps and 200 kinetic dps ( 700 total not including flux-> energy damage) which is pitted against the shield's damage->flux ratio and flux dissipation.
In short the only way for that Beam based Medusa to kill its target is for its damage to exceed the flux dissipation of the target.

A repairing hull/armor system works exactly the same way except it converts all weapons into beams in the sense that Damage>Flux Dissipation = Death

You either have to kill the target in one big chunk ( Torpedoes ect ) or out dps the repairs.

All that said it's not the only way to implement repairing.

[etherealblade]

I guess the reason why i am opposed to the idea of having the ability to repair armor/hull is, its a bit "boring"

Wait...I think I get it. Modders need to be the one to get the most out of thier own mods. I get it that you want something to change and you want a little more zing and challenge in your own faction. You've been really polite and open minded to receive all our opinions on the matter even though in the end you want something to change. In that way it's possible to make a compromise. Your argument about keeping in the mechanic about flux build up makes sense. If you wanna add shields, how bout using the shields as a means to repair. Meaning that, your can't repair unless your shields are up and having them raised means to build up flux. If you're getting bombarded than it will be a gamble....will i be able to repair in time?, will my shield collapse and leave me a sitting duck? or even if i do repair in time ill still have to vent all this flux. This way repair in battle can only in the most optimal situations, is when the ship in question is not being attacked or near the battle.

It could even be set up as the rune ship power. When activated, cut power auto raises shields, repairs are made. If duration of time passes, without shields breaking, repairs are applied. If shields are broken before the time frame, repairs fail, sitting duck time. Also add a cooldown after the power is used.

Now you have something that works, is unique, and requires thinking on when and where to use.

[valefore]

I'm so excited with what the end results would be with all this discussion.

But I also agree that simple armor/hull repair can be boring. Not only in the idea, but also the implementation since it wouldn't show anything exciting in terms of movement or activity. Not to mention a lot more thought has to be put in to balance it. But coupling with shields or other systems sounds interesting. Maybe you could make it as a byproduct instead of the main effect itself?

I can't seem to think of any ideas of my own. Maybe an activated tractor field that pulls other ships towards you and builds hard flux (someone may have said this)? Personally, I'd like to see those space harpoons used in Sword of the Stars 2 that force 1:1 combat, but dunno if that's feasible.

[Vayra]

Just noticed a nasty little incompatibility here -- the Thule Legacy, Blackrock Driveyards, and Uomoz's Sector all use a data.scripts.plugins.CombatUtils. Only thing is, the Thule Legacy's isn't the same as the one used by the other two, so if it loads first (or last and overwrites it in the game's memory? not sure which is happening but it doesn't really matter) the game will crash and you can't play with the Thule and either BRDY or Uomoz's Sector running together.

Admittedly this is pretty minor concern, but you might want to rename yours to ThuleCombatUtils or something of the like as long as it's packaged with your mod and change the references accordingly so we can have the best of both worlds? Alternately, I suppose you could update it to include the functions that the others have, or someone could pester LazyWizard to include something like the complete version in Lazylib so that mods don't have to include one at all (I notice that yours is headed with a comment stating it's originally written by him, not sure about the longer other two versions). I'm posting this here instead of in one of the threads for the other mods because the other CombatUtils contain all the functions that the Thule Legacy uses plus some extra, so they don't crash the game if they're loaded instead. :v

[LazyWizard]

There's a more up-to-date version of CombatUtils in LazyLib. The data/scripts/plugins version is LL's extremely outdated predecessor (and LazyLib becoming a separate mod was purely to avoid situations like this). Since all three of those mods have LazyLib as a requirement, it would be better if those mods deleted CombatUtils and switched the imports to LazyLib's version (org.lazywizard.lazylib.combat.CombatUtils, although getDistance() and getDistanceSquared() are now in org.lazywizard.lazylib.MathUtils).

[Vayra]

There's a more up-to-date version of CombatUtils in LazyLib. The data/scripts/plugins version is LL's extremely outdated predecessor (and LazyLib becoming a separate mod was purely to avoid situations like this). Since all three of those mods have LazyLib as a requirement, it would be better if those mods deleted CombatUtils and switched the imports to LazyLib's version (org.lazywizard.lazylib.combat.CombatUtils, although getDistance() and getDistanceSquared() are now in org.lazywizard.lazylib.MathUtils).

Ah, that'd be that, then.