ContractConfigurator
ContractConfigurator copied to clipboard
Parameters aren't being properly checked in sequence
I've run into an issue with how parameters are checked. Relevant code for context. A lot of the parameters are intentionally redundant in a failed effort to work around the bug.
PARAMETER { name = p1 type = HasCrewCapacity minCapacity = 2 completeInSequence = true } PARAMETER { name = p2 type = HasCrew minCrew = 2 completeInSequence = true } PARAMETER { name = exploitprevent1 type = ReachState targetBody = Mun completeInSequence = true } PARAMETER { name = flyby type = ReachState title = Fly By the Mun situation = ESCAPING disableOnStateChange = true rewardScience = 4.0 rewardReputation = 25.0 rewardFunds = 50000.0 completedMessage = hooray completeInSequence = true
PARAMETER { name = exploitprevent2 type = HasCrew title = Need 2 Crew minCrew = 2 completeInSequence = true }
}
In this contract, it should be absolutely impossible to complete the final parameter (which is entering the Muns Sphere of Influence on an escape trajectory) without possessing 2 crew members on board the vessel.
If I load into a vessel in orbit around Kerbin with 2 crew members on board, the first 2 parameters, p1 and p2, are checked off and nothing else. This is exactly what we expect to see, so far so good.
Then I switch to a different vessel (from map mode or space center to tracking center, doesnt matter). This vessel is a probe currently on an escape trajectory within the sphere of influence of the mun, with 0 crew capacity, and 0 crew. It should fail to progress any of the parameters, especially the last one. Whatever the bug is, its causing the final parameter in this scenario to successfully complete when it never should, my best guess is because the preceding parameters aren't being checked again after a vessel switch IF each check on the path to the final parameter passes.
I say IF because if I switch to a vessel that is in a completely different situation (lets say to a probe landed on Duna) BEFORE switching to the probe doing a fly by of the mun, then the parameters seem to properly cycle back to checking the condition of the first parameter after the exploitprevent1 and flyby parameter checks fail. From that point, none of the parameters are marked as "complete" and switching to the Mun probe doesn't progress anything as expected.
All these parameters should get wrapped inside a VesselParameterGroup. Otherwise the completed state for some parameters will carry over from previous flight and depending on the order, can cause the entire contract to get completed before they are re-evaluated.