We should sort out the 'double duty' that engineers do when a rocket is being both integrated & rolled out

[ppboyle]

Either integration should pause, or rollout & integration should be slower, or engineers who do integration shouldn't be busy when a rocket is rolled out by no rocket is being integrated (we'd have to implement a maintenance fee for a rocket on the pad in a separate way)

[FioraAeterna]

I think integration should pause during rollout and pad cleanup. Currently, because it doesn't, you effectively "lose money" if you're not building during either of these stages, which is a bit of a weird incentive IMO.

[Codelet]

It feels a bit inconsistent that if we pay the salary to the engineers during rollout, why rollout also costs extra on top of that? If rollout cost is a cost we pay to someone else to do the job and then engineers should not take their full salary during rollout. Or there should be no extra rollout cost if we pay our engineers for that and then it makes sense to block them from integrating of course.

[NathanKell]

Because launch costs are above and beyond salary & integration materials. They involve range clearance and operations, extra support staff, etc.

[Codelet]

So launch costs could be a bit higher to not bother integration ppl with it and let them integrate as much as they need to :) Just thinking out loud.
I agree that blocking integration would solve the problem when the game punishes you for not queueing new rocket while rolling out, but it feels like a potential problem for heavy rockets where roll out can take considerable amount of time.

[Clayell]

it feels like a potential problem for heavy rockets where roll out can take considerable amount of time.

I think that's a reasonable problem to have, as you only have a limited amount of engineers, and your engineers can't be focused on rolling out a rocket and building a new one at the same time

[lpgagnon]

On the one hand, people focused on rolling out a rocket and the people building a new one will not generally be the same people - there maybe some overlap, but not complete. It seems perfectly plausible that the subset of staff involved in rollout is mostly disjoint from the subset involved in the initial phase of integration and both can happen concurrently.

On the other hand, it's also true that the entire set of people involved in a rocket's integration won't all be active all at once, and PLC doesn't attempt to model that, so it is peculiar that it sort of models it for integration vs rollout

[Clayell]

On the one hand, people focused on rolling out a rocket and the people building a new one will not generally be the same people - there maybe some overlap, but not complete. It seems perfectly plausible that the subset of staff involved in rollout is mostly disjoint from the subset involved in the initial phase of integration and both can happen concurrently.

On the other hand, it's also true that the entire set of people involved in a rocket's integration won't all be active all at once, and PLC doesn't attempt to model that, so it is peculiar that it sort of models it for integration vs rollout

True, but considering how plc currently models rollout times based on engineers, then I think my point still stands

[isturdy]

One argument for blocking integration during rollout regardless of realism: it greatly streamlines the gameplay loop for anyone who won't feel bad about losing a few minutes of engineering time during launch (for sounding rockets and LEO contracts where success can be determined quickly, which is quite a few) but would care about wasting a few days during rollout. If the launch fails, you can build a replacement immediately without needing to resort the build queue; if the launch succeeds, you can see the contract parameters of the next stage of a repeatable without reading the game configs or test against the actual contract implementation without save/cheat-complete/load. The advantages fall off as mission times increase, but I think it could help accessibility in the sounding rocket era.