Progress Tracking for Release 0.8.40.149

• ETA - KSP-1.4 release (no guarantee)
• It is possible that some items on this list will get pushed to future releases, it is only a rough outline of plans.
• Items may be added/removed arbitrarily. If you want to make sure something gets addressed, open an issue ticket on it (if one does not already exist).

DONE

Needs Verified

TODO

• Cleaner handling of texture sets across modular and non-modular uses of models. Allow for root-level texture sets to be defined and 'linked' into the ModelDefinition
• Create singular ModularPart PartModule
  • Would be used by MFT, MSC, MSM, MUS, MB parts
  • Optional support tank setup, with RCS fuel type integration
  • Nose
  • Body Upper
  • Body Intertank
  • Body Lower
  • Mount
  • Solar
  • Upper RCS
  • Lower RCS
• Figure out model layout / position handling
  • In what 'space' are the positions defined?
  • How to allow for 'generic' layouts that can be easily re-used between models/modules/etc?
    • Define positions in an 'abstract' base -- 0-infinity, scaled by an input value from the owning part-module?
  • Need to load/store these layouts somewhere. Where are they currently loaded? (are they even loaded/parsed?)
• Solar-panel equipped modules need to include the contract-objective interface, and properly return "Generator"
• RCS Fuel type - support tank integration
• SolarModule support
  • GetInfo() support - EC/s, tracking speed, deployable, non-retractable
• AnimationModule development work
  • Drag-cube updates
    • with method to disable them, for part-module level updating.
  • unfocused range support
    • Scale-able models need to add a multiplier to this to account for difference in scale
    • Read from config, needs to be applied in GUI
  • Action Group handling -- where should the 'default' action group for an animation be specified
  • Add Airstream Shield integration -- can trigger shielding when in specified state -- can be set to enable shielding on either 'retracted' or 'deployed'.
    • How to determine what the shielded bounds are, just from the animation module?
    • More likely, the animation module needs to only state IF it interacts with shielding (and if it enables on retract or deploy)
    • The actual shielding bounds need to be taken from the ModelDefinition -- can have pre-configured 'per-model' shielding bounds. Multiple potential shielded areas per model. Each area defines if it interacts with an animation, and at what states it is enabled/disabled.
    • How to handle shielded interaction on parts using standard animation setup? Seems like bounds need to be defined in the part itself (in Airstream Module, or animation module), and shielding module enabled/disabled based on config defined toggles in the ANIMATIONDATA block.
  • Add support for breakables. Examine dynamic pressure and g-forces.
  • Better defined handling for animation layers
  • Integration of 'looping' animation types.
    • Will likely need additional enums added to AnimState to properly handle looping animation state.
    • Alternatively, could handle them at the Unity AnimationClip / AnimationState state WrapMode.
    • Should support both wrap and ping-pong wrap modes for looped animations.
  • 'Compound' animations that have both deploy and loop clips
  • Animation module linking - secondary animation that requires specific state on primary (e.g. drill's 'drill' animation should only play after 'deploy' has been ran)
  • Single-shot animation handling. This really should be supported at the lowest level (AnimationModule), and as such the 'hasRan' state should be persisted with the animation state.
• Adapt SSTUAnimateEngineHeat
  • Compile engine heat emissives into an actual animation
  • Add capability to add a 'light' to the engine exhaust transform
  • This module needs an external refresh capability that can be triggered from SSTUModularEngineCluster

SSTUModularPart

• Allow for 'body variant' type setup, e.g. current MFT tanks -- single part with multiple (minor) aesthetic variants..
  • When 'variant' mode is enabled, the main 'core' model selection is hidden, replaced with a 'variant' selection GUI control.
  • Variants work alongside a 'length' specification for the 'core' models. Each 'core' model specifies its 'variant' and 'length', with the GUI sliders for the core option switching between core models on these specifications.
  • Variant modes will now track what adapters are valid options based on the per-model-valid-adapter specifications from the model definitions.
• Specification of what slot engine thrust is derived from (if any)
• Specification of what slot engine transforms are present in (if any)
• Diameter control in GUI controls the diameter of the 'core' model.
  • Model scaling chains based on the diameter of the core model. 'Upper' model will have its scale determined by the 'upperDiameter' of the core model, and the 'Nose' model will be scaled based on the 'upperDiameter' of the 'Upper' model.
• Model slot selection for attachment of upper and lower RCS. Allow the part config to define what slots are valid selections for the RCS models to be attached to.
  • RCS valid options and positioning are defined in the model definition.
  • Vertical offset - base position relative to model origin
  • Horizontal offset - horizontal offset of the RCS ports, defaults to model diameter
  • Vertical Adjustment - the range of +/- through which the RCS port may be adjusted on the model.
    • Need to specify an 'angle' to use for non cylindrical parts?
  • How to handle cases of both upper and lower RCS being assigned to the same 'slot' (e.g. core?)
• Model slot selection for attachment of solar panels. Allow the part config to define what slot(s) are valid selections for the solar panels to be attached to.
  • Requires additional GUI control to determine what slot panels are attached to.
  • Solar panel valid options and positions are defined in the model definition.
  • How to ensure that solar panels and RCS don't interfere?

ModelDefinition

• Specify intended orientation of the model
• Specify axis to use when inverting model for non-base orientation (e.g TOP model used in BOTTOM orientation)
• Specify height, diameter, volume, mass, and cost.
• Specify 'upperDiameter', 'lowerDiameter' -- used in model scale chaining operations.
• Track what other models are valid 'upper' and 'lower' options -- used in model selection GUI controls