Just a thought. How about tie the crew/training mechanics to readiness? So new ships gets produced at 100% readiness, player can decide the level of readiness which impact on minerals, so a 10% readiness will consume 10% of minerals and operate at 10% efficiency on anything you want, old crew mechanics, or even impact on deployment and so on. When player increases readiness it increases slowly to the new target. Reduction should decrease at 2x or 3x respect to increase. Training could speed up readiness.
1 Like
I think a “no MSP consumption at maintenance locations” starting option would cover most mothball use cases.
Steve created a system which supports having vessels active and patrolling because that’s how he likes to play. Unless I’ve completely misunderstood the maintenance rules (I’ve certainly never checked the math to see if I’m paying what I think I should) a vessel that spends four years patrolling and one year in overhaul will consume only four years worth of MSP (plus maintenance failures), a 20% discount compared to the same vessel parked at a maintenance location for those five years. That’s a little unintuitive.
A lot of people would probably like vessels at port to be cheaper to maintain than vessels away, but also don’t want to give up on maintenance entirely, so mothballing comes up. This leads me to “no MSP consumed at a maintenance location” as be a simple (to implement?) rule in-between normal maintenance and no maintenance.
You’ve misunderstood the math.
Overhaul consumes maintenance supplies at 4x the rate of sitting in port. That means that if a ship goes out and sails around for 9 months, then goes into overhaul for 3 months, the overhaul consumes the same amount of MSP as if the ship had been sitting in port being passively maintained for 12 months. This is in addition to any MSP consumed by maintenance failures while out on maneuvers, so the net result is that sitting in port is always better (or, at best, equally good) for conserving MSP than going out and coming back for an overhaul.
Is it possible to create a ship that uses less MSP when out at space than in port? Maybe with an arbitrarily low IFR/AFR?
It’s possible if you stack a lot of engineering bays and never overhaul the ship until it collapses from maintenance failures, but it’s extremely debatable if this is actually useful in practice, since the upfront spend to deploy so much engineering capacity is rather steep.
I went back to check because I refuse to believe that Steve has been misleading us above maintenance and overhauls over all these years, and I will reiterate that the outcome is not intuitive. So unintuitive that you misunderstood it, presumably because the outcome doesn’t make sense so you assumed the outcome was wrong.
Correct, and this matches Steve’s description of overhaul maintenance in the C# changelog: “While a ship is being maintained, it requires total MSP per year equal to Class Cost / 4. A ship undergoing overhaul requires total MSP per year equal to Class Cost.”
We also know that on overhaul, the maintenance clock rewinds at 4x speed (I can’t find this written down in the changelog but it’s common knowledge and easily tested), that is, 4 time units (months, days, years, whatever) away require 1 time unit in overhaul to rewind.
Not correct. The outcome is exactly as I described it initially: a vessel that never sits at a maintenance facility but just returns for overhauls gets to exist for 5 time units (4 away and 1 and overhaul) while consuming only 4 time units worth of MSP during the subsequent overhaul. That’s a 20% discount compared to sitting at the maintenance facility the whole time, where 5 time units requires 5 time units worth of MSP. Discounting the MSP required for maintenance failures of course (Main Engineering and Admin Commands can mitigate those to a degree).
This means that if you want to minimize MSP usage with vessels sitting at a maintenance facility you should give them set of cycling orders to go to a nearby location (i.e. the Moon, from Earth), delay a short time (maybe 30 or 60 days or so) so the clock can’t tick up very high and start causing lots of failures, and then enter overhaul again. If your maintenance failures are low, you can approach that optimal 80% of normal MSP consumption.
You could also exploit the Effective Maintenance Rate rules to make overhauls take forever at an overloaded maintenance location; ships in overhaul never experience maintenance failures so you’ll get extremely close to the optimal 80% of normal MSP consumption in this manner. This is effectively be the “in-game” Mothball option, as you have to abandon the overhaul to make it end and then depending on how much maintenance clock you collected you might have to go do a real overhaul.
I wont comment on the math as that is a different topic I never liked, therefore while I know the general rules, I am not into these calculations. It is good though that some are so that we can keep improving or fix inconsistencies.
I would say though, regardless of the math, I believe that “moving the fleet” still have the following possible outcomes:
1- An attack we cannot fully handle due to our fleet be in overhaul
2- an unlucky RNG roll causing maintenance to kick in so more maintenance points are used making it more expensive than expected (discussed already and perhaps negligible)
3- Fuel consumption, unless of course you moving just enough to use only a few thousand litres (you addressed that saying Terra to Luna)
Let’s see what the math ends up to be, I am still more inclined to do not move the fleet regardless. But that is just me.
This part is incorrect. One month in overhaul rewinds 3 months on the maintenance clock, not 4 months. I believe this has been true since the VB6 days, which is why you can’t find it in the C# changelogs.
Given that, a worked example may be helpful. Consider two ships of the same class with a build cost of 1600 BP. One ship remains in port at a maintenance location for 12 months (annual MSP consumption 400 MSP/yr). The other ship goes out sailing without incident for 9 months and then enters overhaul for 3 months (MSP consumption = 0.25*1600 = 400 MSP). Since 1 month in overhaul restores 3 months of maintenance clock time, after 12 months both ships will be identical condition.
The resulting MSP consumption, not counting maintenance failures, is thus:
| Time elapsed | Ship #1 MSP used | Ship #2 MSP used |
|---|---|---|
| 3 months | 100 | 0 |
| 6 months | 200 | 0 |
| 9 months | 300 | 0, enters overhaul |
| 12 months | 400 | 400 |
Of course, ship #2 is likely to experience one or more maintenance failures on deployment, consuming additional MSP, but even if it does not then Ship #2 can only, at best, break even with Ship #1 in total MSP consumption.
One may note, with some cheek, that Ship #2 may save quite a lot of MSP if it gets blown up by Precursors before it can return for overhaul. 
I encourage you to test it yourself as you clearly don’t believe me. Load a test game, run a maintenance clock up to 1.00, then see how long it takes in overhaul to get back to 0.00.
I pulled up my current game and found a ship with 1.66 years on the maintenance clock (about 20 months). With the ship in overhaul, I ran the game from 3 January to 15 July of the same year before the maintenance clock hit zero, about 6.5 months.
Since 6.5*3 = 19.5 months, which is pretty close to the 20-month rough figure I gave above, we see that each month in overhaul has a net effect of rewinding 3 months of maintenance clock time.
Note that if you watch the overhaul process in smaller time increments, you will see the clock tick up a bit in between large steps down towards zero. I believe (Steve would need to confirm) that this is because a ship in overhaul still accumulates maintenance clock time (since it is not being maintained) and the gross effect of overhaul is a 4-to-1 reduction. Adding these effects together gives the net 3-to-1 reduction rate that we observe over longer times. This may be a source of confusion regarding the 3:1 vs. 4:1 rates of return.
On my machine, both in my current campaign (1 day construction) and Example Game 270 (5 day construction), 360 days of maintenance clock requires 90 days in overhaul to rewind. At the end of that overhaul, 100% of vessel BP have been consumed in MSP at the maintenance location compared to 125% of BP in MSP for an identical vessel sitting at another maintenance location for those 450 days. The only source of confusion is at your rigorous testing achieving different results than mine.
In that case, you should report a bug and attach your DB file in the bug report thread. What you’re observing is not how the mechanic is intended to work, so it is a bug.
It’s 1 day or 1 day minus 1 second?
You may causing your own problems with a construction cycle out of phase, you should try checking the same issue on a basic 5 day cycles and 1 true day.