[Mechanic] Disabled Self-Repair

[Azure3141]

Feature

This PR addresses the feature described in issues #7266 and #4678 (sorta kinda) and requested by @Ebreus on Discord.

Summary

This adds a new attribute, disabled recovery timer (name TBR) that allows disabled ships to repair themselves after a counter reaches the value of disabled recovery timer. It also adds attributes to apply a cost of energy or fuel (which must be met in order for a ship to repair itself) and apply any of the various damage types in a single burst upon a ship self repairing.

Usage examples

My testing ship was a Hawk, which I shot up until it was disabled (took a couple tries to not instantly kill it).

ship "Hawk"
	sprite "ship/hawk"
	thumbnail "thumbnail/hawk"
	attributes
		category "Interceptor"
		"cost" 670000
		"shields" 2500
		"hull" 500
		"required crew" 1
		"bunks" 4
		"mass" 110
		"drag" 2.1
		"heat dissipation" .8
		"fuel capacity" 300
		"cargo space" 20
		"outfit space" 200
		"weapon capacity" 50
		"engine capacity" 70
		"disabled recovery timer" 180
		"disabled recovery heat" 500
		"disabled recovery energy" 100
		"disabled recovery slowing" 100

In this case, the Hawk had to have at least 100 energy in order to repair itself, which was subtracted upon the repair actually happening, as well as the addition of 500 heat and 100 slowing.

Testing Done

Did the aforementioned Hawk abuse. Probably still need to test energy/fuel requirements actually being able to restrict the repair from happening.

Save File

N/A

Artwork Checklist

N/A

Performance Impact

Likely none.

[Azure3141]

Kindly ignore the map rework stuff that was accidentally pushed to master a month ago and then reverted (unless someone wants to merge it in which case I'm all for it)

[Ebreus]

Thanks for the awesome mechanic!

[Zitchas]

When did the timer start? When disabled? Or when last hit? Personally I would prefer from last hit with a possibility of overriding it to from when disabled. I can think of story situations where I would want the later, but most of the time I think from last hit post being disabled is better.

I do believe there is a conversation on GitHub somewhere for this, too.

[Azure3141]

When did the timer start? When disabled? Or when last hit? Personally I would prefer from last hit with a possibility of overriding it to from when disabled. I can think of story situations where I would want the later, but most of the time I think from last hit post being disabled is better.

I considered using last hit but I think that might work out to be much more frustrating from a player user experience perspective, where random stray shots around the system can already end up killing you when disabled with nothing you can really do about it.

[EjoThims]

Just a minor typo.

[Zitchas]

I am ambivalent about using "last hit" for the player. I think it is better, but not strongly. I do think it is much better for NPCs, though, because we don't have to worry about their feelings, sand having repair work reset by the player or other enemies hitting it makes more sense. Only the biggest and toughest of ships should be successfully recovering from being disabled while they are actively being shot.

Actually, even better would be to have a 'disable recovery reset chance' attribute that survivors what the chances are. Old reliable so like the Firebird? Low chance of disable recovery being reset by a hit. Some fancy delicate rescuing Flivvr? Really high chance of reset.

But honestly, the more things can be put into the player's hands and not just a dictated way the game works, the better. Meaning of they don't bother investing in tools to improve their recovery, then they recovery slowly and increase the risk of a stray hit keeping them disabled for longer. Even better if ways to reduce the chance each hit had of resetting the timer.

Having A timer is good, but only marginal improvement as most will probably still reload. The more we can make it something that players can actively plan for and make decisions about, the more it becomes just another part of the game to be experienced as part of the player's story.

[quyykk]

Should this be tied to hull repair in some way (or use a new hull repair attribute) instead of a timer? Having a small hull ship self-repair just as fast as a large hull ship seems weird.

[Azure3141]

Should this be tied to hull repair in some way (or use a new hull repair attribute) instead of a timer? Having a small hull ship self-repair just as fast as a large hull ship seems weird.

I see it as being more analogous to the way ships can repair each other (which doesn't have any kind of size dependence) than the sort of repair system used by hull repair outfits.

[Hurleveur]

I dont think it matters, instant repair is just good gameplay and thats always the focus. We can always find things to justify the gameplay we want (in repair case its just standard for all ships bigger than a fighter to have a repair mechanism)
I'd say you got it reversed; first we find good gameplay then ways to justify it.

Back to the matter at hand, I think big ships should have to equip more repair outfits to have it be as fast as small ships. Mb just base it on mass or smth

[Zitchas]

I would prefer to have the base repair timer specified as a ship data point, with the capacity to have outfits that modify that by percentage, fixed amount, or override.

While I generally agree that bigger sis should take longer, I consider this to be in the same category of data as "big ships have more shields." Which is generally true, but subject to so many other factors that it can only be decided by creators, not by automated game mechanic.

[quyykk]

So my last comment was so crazy it doesn't even get a response

@Hurleveur did address it: Gameplay over Realism. We have this conversation a lot of times, and people fall on different sides, but usually people can agree that we cannot make everything hyperrealistic (I'm not sure if that's what you were implying, so I apologize if not). I also apologize if it feels that ideas from the "out-group" always get shot down, this is absolutely not the case.

If you get disabled there should consequences in the form of having to wait.

This suggested change already includes a timer, unless you're talking about the instant repair when you ask a ship for help. In that case, the time it takes for the ship to dock you is already kinda a timer already. I'm not sure if adding another timer on top of that is a good idea from a gameplay perspective.

[Azure3141]

I would prefer to have the base repair timer specified as a ship data point, with the capacity to have outfits that modify that by percentage, fixed amount, or override.

While I generally agree that bigger sis should take longer, I consider this to be in the same category of data as "big ships have more shields." Which is generally true, but subject to so many other factors that it can only be decided by creators, not by automated game mechanic.

I like the idea of this. I'm not sure whether we'd want to implement this across the board for ships, to create a variance in repair speeds (even independently of this PR, which I'd be in favor of), but I can definitely see the use of this attribute even just for special cases.

[Azure3141]

I know it's pointless but, I still maintain it can't feel like magic. If it is made instant it's basically the same as making a ship unable to be disabled in the first place. Being invincible is bad game play. Here is the current suggested game play scenario.

you fight and get disabled
poof! your not disabled

It'll only be instant if you set the repair delay attribute to 0, which is just bad content design. It's exactly the same as giving a shield generator 100 million shields/frame; that doesn't mean the concept of shield generation itself is flawed.

[Azure3141]

This is why I said, it needs to be tied to something. Not just a simple timer. Different ships do need different timers and should be handled in this PR. Why add only half a solution just to go back and re-due it again latter? Like I said tie it to the hull and crew or outfit space stats. Just anything that would be a contributing factor as to how long it takes to repair to a non disabled state. That's assuming you want it to make sense instead feeling like magic. Your choice, except the challenge or keep it simple.

Again, this is how repairs work in the current version of the game. A ship can repair a drone or a superheavy warship in the same amount of time, even ignoring the size of the ship doing the repairing in the first place. Whether or not this should be different, such as with a ship-specific repair time attribute used for both self-repair and external repairs as suggested by Zitchas, is a different debate (and probably could be a different PR independent of this one).

I would also appreciate it if you were less aggressive in your responses to other people in this PR, as it's creating unnecessary friction that isn't relevant to the discussion.

[xX-Dillinger-Xx]

I deleted my content as my attitude was not appreciated. Do not take it as done in a fit of rage. I'm sorry if my form of criticism is considered aggressive. I forget some people can't handle criticism.

EDIT: This wasn't a result of what Azure3141posted. I was contacted by somebody else.

[Hecter94]

I deleted my content as it was not appreciated. Do not take it as done in a fit of rage. I'm sorry if my form of criticism is considered aggressive. I forget some people can't handle criticism.

We appreciate all kinds of feedback, including constructive criticism.

However, please remember to maintain a professional and respectful tone while sharing your thoughts. GitHub is a hub for professionals actively involved in development, and we expect everyone using the platform to contribute to creating a constructive and productive environment.

As long as you follow the guidelines, please continue to provide valuable feedback. Our ultimate goal is to make Endless Sky the best product possible, and player feedback is crucial to achieving that objective.

[petervdmeer]

I've read through #4678, through #7266 and through the thread here; this PR seems to be doing exactly what was requested. (There were a lot of "out of scope" and "unrelated" discussions, but they can go to their own tickets.)

This PR also seems safe for merging; the only time when it is active is when the condition if(isDisabled && attributes.Get("disabled recovery time")) is true, and the attributes are only visible when used. The PR is also quite small.