-
Notifications
You must be signed in to change notification settings - Fork 215
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
Comments
Look through the game difficulty settings and find the one that refers to "pre-launch ignition failures". |
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. |
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. |
this is going away: KSP-RO/TestFlight#278 |
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. |
@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)? |
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. |
@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: Example of n = 10 and z = 500 would result in rounded: You can see each subsequent failure in the same launch provides less and less untill you hit max. |
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) |
Implemented in #2327 |
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.
The text was updated successfully, but these errors were encountered: