Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make a system for pad ignition failures to force some recovery/refresh times #2047

Closed
ppboyle opened this issue Jun 21, 2023 · 10 comments
Closed

Comments

@ppboyle
Copy link
Contributor

ppboyle commented Jun 21, 2023

Per my discussion with NK on stream, he'd like to add this to make pad ignition failures have a penalty, but not a drastic one.

@hallucinogender
Copy link

hallucinogender commented Jun 23, 2023

Look through the game difficulty settings and find the one that refers to "pre-launch ignition failures".

@NathanKell
Copy link
Member

Yes, hence "make pad ignition failures...", i.e. the ones the already exist. The point is on RP-1's side, to make suffering one mean you have to do some minor fixing (a day's delay, say, on a big vessel) without requiring a complete recovery/rollback/etc.

@FNGRenegade
Copy link

FNGRenegade commented Jul 5, 2023

To be honest for me pad failures are already a positive instead of a negative. Yes the scene transitions are annoying however every time an engine fails on the pad it costs me 4-12 days depending on the recovery/rollout times but also ends me up with 1000du of data. Which means engines are less likely to fail in air which usually causes a total mission failure and is much more costly both in time spend and credits. I actually found myself hoping for pad failures when bringing in new engines and my LR89 booster LR105 rocket even started off with 3 pad failures in a row getting me to 2k du for the LR 89s and 1k du for the LR105 in 30 days. If any of those failures happened in air I'd most likely be looking at less data and a bigger recovery time/price.

Maybe if you make it easier to repair on pad issues it at least shouldn't give 1k du or some other way to make sure pad failures don't end up a good result.

@lpgagnon
Copy link
Contributor

lpgagnon commented Jul 5, 2023

but also ends me up with 1000du of data

this is going away: KSP-RO/TestFlight#278

@NathanKell
Copy link
Member

No, the du from ignition failure is not going away. That issue is about making test stands and running engines so far past their rated burn time that they fail--you don't get du from running them normally, but you do get that failure du. And since you can rinse-and-repeat recover them, you can easily max your data.

I should go clarify that other issue.

@NathanKell
Copy link
Member

@FNGRenegade that's a good point, should probably cut the du output at the same time as making the fixing very quick (say 1 day for craft that takes a week to rollout)?

@marsh1832
Copy link
Contributor

I also like pad failures. They add to the tension of engine failures, but without the huge cost of a failed rocket. For example, with an early multi engine rocket, it make take several attempts to get all the engines to light. When you finally get it and the thing launches, it’s a bit of rush, and at the same time, you’re on edge hoping there isn’t a flight failure. Although 1000 du might be a bit much for a pad failure, the fact you get something for your troubles doesn’t make it a huge inconvenience, and that each attempt increases the odds the next attempt will light properly.

@FNGRenegade
Copy link

FNGRenegade commented Jul 6, 2023

@marsh1832 a very fair point and when launching things with a lot of engines indeed very important. Maybe the du max could be a function of the amount of engines trending towards 250 or 500du as to not penalize craft with loads of engines too much like a Saturn or in more extreme cases a N1.

Something like the following would work although you would have to clamp it to prevent going over z:
(Log(x+1)/Log(n+1))*z = y du
x = number of failed engines on the craft
n = number of failed engines required for max du
z = max number of du pad failures should give
y = the du you receive

Example of n = 10 and z = 500 would result in rounded:
1 failure = 145du. 6 failure = 406du
2 failure = 229du. 7 failure = 434du
3 failure = 289du. 8 failure = 458du
4 failure = 336du. 9 failure = 480du
5 failure = 374du. 10+ failure = 500du

You can see each subsequent failure in the same launch provides less and less untill you hit max.

@KEKKJ123
Copy link

I admit that this approach has to some extent disrupted the game balance. The benefits of engine testing can be reduced, but should not be prohibited.(or cheese)
If I don't want my rocket to fail, even if I turn off the rollback function, I can solve it by copying the file, it's obviously meaningless, so Engine testing has become an acceptable solution.

@siimav
Copy link
Contributor

siimav commented Mar 8, 2024

Implemented in #2327

@siimav siimav closed this as completed Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants