Project

General

Profile

Bug #18895

quirks in implementation of ModuleAnimateGeneric.CrewCapacity will lead to incorrect behavior

Added by cake-pie almost 6 years ago.

Status:
New
Severity:
Low
Assignee:
-
Category:
Plugins/Add-Ons
Target version:
-
Start date:
05/14/2018
% Done:

0%

Version:
Platform:
Linux, OSX, Windows
Expansion:
Core Game, Making History
Language:
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

Forum thread has details / plugin code / log excerpts:
https://forum.kerbalspaceprogram.com/index.php?/topic/174065-working-with-crew-capacity-changes-by-moduleanimategeneric-inflatableairlock/

A couple of issues with the way dynamic crew capacity is implemented in ModuleAnimateGeneric that leads to issues for addons that care about crew capacity.

Test cases are based on the inflatable airlock in Making History expansion but observations should hold in general for any stock/mod part making use of the new (1.4+) ModuleAnimateGeneric.CrewCapacity setting.

1.
When retracting the part, Part.CrewCapacity does not update until a couple of frames after the animation has started playing.
This can lead to incorrect and buggy behavior.

e.g. If Part.AddCrewmember(kerbal) is called within those couple of frames, KSP will happily comply and put the kerbal into the part (whereas it would fail if there was no space available)
Consequently, we have a kerbal sitting inside the retracted airlock, which then has crew capacity = 0 and crew count = 1.
Due to the presence of crew in the part, it cannot be deployed -- animation is disabled thanks to a check that was intended to prevent retraction of an occupied airlock.

To be safe, crew capacity should be set to zero before retract animation starts.
Conversely, only set nonzero crew capacity after deploy animation ends.

2.
When deploying the part in editor, Part.CrewCapacity is not yet updated (still zero) at the point that ModuleAnimateGeneric.OnStop is fired; it is necessary to wait until end of frame to obtain the correct value. Works correctly in flight mode.

In order for OnMoving / OnStop to be useful to addons that want to listen for crew capacity changes, the following behavior is desired:

Deploy:
OnMoving: Part.CrewCapacity = 0
OnStop: Part.CrewCapacity = 1

Retract:
OnMoving: Part.CrewCapacity = 0
OnStop: Part.CrewCapacity = 0

Otherwise, a better mechanism for addons to be notified of crew capacity changes would be appreciated -- perhaps via GameEvents.OnCrewCapacityChanged, indicating the part and before/after values for crew capacity.

Also available in: Atom PDF