L Aerospace KSP/R&D Division

Welcome to the Research & Development Division from L Aerospace.

Please vest your blast helmet and suit: Area subject to Uncontrolled Landings and Rapid Unplanned Disassemblies, usually followed by Incredibly Fast Air and Heat Expansion With Debris events.

Support

The following states the current status for the Supported KSP versions:

• Fully Supported (exceptions when documented the Add-On's .version file)
  • 1.3.1 (Ongoing Guaranteed Support)
    • Support for 1.3.1 is currently work in progress, some Add'Ons already support it but it will take some time to catch up with everything...
    • It's the last Unity5 KSP version, and it's the best option for some potato machines (mainly the machines affected by the Intel's magnificent blunders Spectre and MeltDown, those mitigations crippled Unity 2017 and 2019 KSPs).
  • 1.4.3 (Guaranteed Support)
    • It's the last version with the older PQS system.
  • 1.7.3 (Guaranteed Support)
    • This is the last Unity2017 KSP version, and it will be supported "forever" as it performs better on some machine than the newer KSP versions!
  • 1.10.1 (Guaranteed Support)
    • Most (if not all - still to be realised) of the worst problems from 1.8 and 1.9 are fixed on this version. Until further notice, this is the preferable Unity2019 KSP to be used.
  • 1.11.2 (Ongoing Guaranteed Support)
    • We have a huge batch of problems introduced on the 1.11.x series.
    • Things will take some time to settle (way more than I had pla), I recommend sticking with 1.10.1 for the time being.
      • But brave Kerbonauts willing to risk their savegames for the Kerbalkind are welcome to test things! :)
    • KSP-Recall is needed for ALL add'ons that uses IPartCostModifier (as Fuel Switches and TweakScale) on Career mode.
• Maintenance only
  • 1.4.1
    • Unless really needed otherwise, add-ons are compiled against this set of libraries, but it is not used for testing.
  • 1.5.x
    • There're not really too much changes (from the code point of view) from 1.4.5 to 1.5.1. But there're not that much neither from 1.5.1 to 1.6.1, so it's kind of pointless to fully support 1.5.1 - almost every 1.5.1 user can switch to 1.6.1, and the few that can't, will be served by 1.4.x series add'ons.
  • 1.6.x
    • I really don't see a good reason to target the 1.6 series, as anything that works on it will work fine on 1.7.3, that are way more stable and are formally supported.
  • 1.8.x
    • The 1.8 series was problematic, but most problems were tackled down. Yet, some others may exist, and it's not probable that I will be able to handle all of them.
  • 1.9.x
    • The 1.9 series is terribly problematic. The breakage are deep and extensive. A lot of problems were solved or worked around, but yet more are expected.
    • KSP-Recall is needed for most add'ons that customise resources (as Fuel Switches and TweakScale).
• Research In Progress
  • 1.1.3
    • No real work will be done on it, but something may be back-ported to it as a proof of concept. Keep an eye on KSPAPIExtensions /L.
  • 1.2.2 (Incepting Guaranteed Support)
    • Supporting 1.2.2 is currently work in progress, some Add'Ons already support it but not all add'ons will be backported to 1.2 as some are terribly troublesome to do so.
    • Don't hold your breath, however - most efforts will be directed to supporting 1.3.1

Internmediary KSP versions (1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.4, 1.4.5, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0) usually works, but are seldom tested against and so contraindicated. They are usually unstable anyway. :)

There are no plans to support any other KSP versions at the moment.

Understanding the Different Teams on the Repository

In order to prevent confusion and misunderstandings, and to make my life easier by grouping projects by support level, every project of mine is tied to a Team, and not to myself directly:

• net-lisias-ksp
  • These are projects that I effectively Maintain, Develop and Support.
  • I accept responsibility and act properly when any of these projects breaks or cause breakage
  • I fix bugs no matter they affects me or not.
  • I create features, and/or improve existing ones.
  • Eventually (but I try hard to avoid) it become incompatible with previous versions.
  • Some are Officially under my Management on Forum (i.e., I withhold Copyrights and TradeMarks on the Historical Versions). These are the "New Management" forks. They are Mainstream.
    • All of them has '/L' on the naming.
  • Others are parallel forks, that should not be confused or mistaken with the mainstream ones. These, are not on the "New Management" status
• net-lisias-kspu
  • These ones I forked and adapted to some special needs of mine.
  • They should be considered Experimental and Unofficial.
  • These has "/L Unofficial" (abbreviated to "/L-U") on the name
  • I do not accept any kind of responsibility on them, does not claim official statuses of any kind and I don't provide support for it.
    • You use it at your own risk
    • But I try to help in issues as the time allows.
  • I add some new features that suits me, but avoid deviating from the mainstream ones (unless that feature is horribly broken and it's the reason I decided to fork the thing).
  • I only fix bugs that I introduced, or fix bugs that annoys me.
    • I am not the Maintainer of the thing.
  • Now and then one of these is "promoted" to the net.lisias-ksp Team, as I became the Official Maintainer of it (see "New Management" above)
• net-lisias-kspw
  • There are direct forks from the Mainstream (or even some parallel forks) where I apply patches and submit to the upstream.
  • I gladly do the same on the net-lisias-kspu ones, but this one is intended specifically to this.
  • No releases are issued. No customizations are done. It's essentially a place where I fork things to then apply pull-requests to the upstream.
• net-lisias-ksph
  • Where I keep Add'Ons mirrored for historical reasons, and absolutely no modification is issued.
    • Some of them don't even allow it on the licensing terms
    • Think on is as WebArchive with some curation, as I usually explode the releases so we can easily track down changes over time. This is insanely helpful on tracking down resurrecting bugs.
    • Pay attention to the licensing terms if you choose to fork them.
  • It also plays a hole as "backups".

Development Process

For the sake of curiosity, here is how I handle things here:

1. Development is done on a branch called dev (or dev/x.xx or even KSP/x.xx for KSP version specific development).
   1. Unofficial Forks usually has a merge branch. But don't take this as written on stone.
2. New Releases are committed to the dev branch, and the binary package is also committed to the Archive branch for historical reference
3. A tag in the formante RELEASE/x.y.z.b or PRERELEASE/x.y.z.b are issued on the dev branch.
4. The whole shebang is uploaded to the remote repository.
5. The Release is created and committed to the DEV branch.
   1. Binary is committed into the Archive branch
   2. A GitHub Release is created.
6. When the thing is ready for the masses, the master is reset to the Release commit for broadcasting announces
   1. When applicable, the binary is uploaded to CurseForge and Spacedock.

This modus operandi prevents triggering any tools that monitors the .version file on the master before the thing is ready to be downloaded - this allow me to test things on different machines (from different users) without the need of a secondary download mechanism.

Contact

Send your questions to <support at lisias dot net> . You can also create issues on the Project's Repository page.

Add [KSP:<plugin_name>] to the subject, to prevent the automated filter system from filtering out your message to the trash bin. Thank you.