Difference between revisions of "Legacy Modes"

Latest revision as of 16:00, 22 January 2020

This page is an orphan, as no other articles link to it.

Kerbal Space Program is a program that is currently under development, updates are released periodically and sometimes contain small changes to a few systems, but also sometimes contain huge sweeping changes to lots of systems. Frequently changes are enacted by replacing the outdated system with a new one, because of time constraints and work budgeting the old system is often left 'functional' and in place. This is referred to as a Legacy Mode, outdated systems that have been replaced but can still be used. In the greater world legacy modes are a feature that allows new systems to behave in such a way that allows them to interact with old systems that may be impossible to replace for cost or security reasons. In KSP legacy modes are you being allowed to follow outdated guides to do things in ways that are no longer considered correct. This is usually because you didn't know better.

Legacy Modes should be avoided because frequently in this context they're the result of the developers not having bothered to remove unused code yet, which does not mean they still work correctly.

The Information Lifespan of KSP Modding

KSP updates typically one to three times per year but most of these updates don't impact a lot of things. Some key updates were 0.15, 0.18, 0.20, and 0.22

• 0.15, May 17^th, 2012 Added the basic groundwork for most of what we think of today as KSP, everything plane related, the ability to rotate parts, part modules
• 0.18, December 1^st, 2012 Introduced PartTools, Resources, Maneuver Nodes, Docking. 18.3 patch updated KSP to run on Unity 4. This depreciated the .DAE method of loading mesh assets in favor of using PartTools and the Unity Editor to prepare .mu files
• 0.20, May 21^st 2013 Introduced the GameData file structure and PART{} .cfg node, the name of files no longer matters so long as it ends in .cfg and are located somewhere within ./KSP/GameData/
• 0.22, October 16^th, 2013 Added Science, Subassemblies, and revamped how flights are ended

Following each of these updates significant amounts of code changed or was added, so documentation predating them should be considered dangerous. Testing may prove that the old ways still work, but it may be a Legacy Mode. Most of the time it's not difficult to locate the new way of doing things.

List of Legacy Modes

• .DAE Replaced by .MU, .DAE is still possible as of 0.23 but has no advantage whatsoever and is significantly more difficult to make work correctly. As well .MU are able to contain setups for more complex parts, such as Jettisons and animations
• .JPG Never used, Unity allows for .JPG files to be loaded, and KSP passes that on to us for some reason, it's not really clear why. .JPG texture files are prone to very high artefacting and offer no in game benefit, despite any apparent savings from disk space due to how textures are loaded.
• KSP.IO, In one of the 2013 updates, not sure which, System.IO was derestricted, allowing for direct interaction with the file system using C#.NET's native capacity. KSP.IO still exists and it's suggested that you make use of it where there is no clear advantage from System.IO "To promote compatibility with future Mod sandboxing plans"
• PART{module=}, Not to be confused with PART{MODULE{}}, module= was previously used to assign functionality to a part. Starting in KSP 0.15 PartModules began to replace all Modules. As of KSP 0.23 the only remaining Modules in use are StrutConnector, FuelLine, and Winglet (used for static lifting bodies, not ctrl surfaces). All other parts whould be module=Part.