Design Goals

  • High level of encapsulation
  • Swappable data interchange points (serializers, data providers)
  • DI/Configuration friendly
  • Thread Safe

General Design

To make serialization easier JSON.NET is used rather than spending much time parsing the raw KSP file. KSP format files are converted using a neutral text processor that is only interested in cleanly creating a JSON version of the document. From there I use JSON.NET to handle the heavy lifting of serialization and data management. Because all the data objects are based off JSON.NET JObjects, JTokens and JArrays all JSON.NET functionality is available on any de-serialized model (cloning, deep compares, etc). JSON.NET also has Linq libraries allowing use of lamda based functions like .Where() .Select(), .Join() etc.

Once loaded as JSON.NET objects the data can be manipulated directly or the higher level data API can be used. This API is KSP install aware, simply point it at an install path and it will make available any relevant data (still adding classes here) using a lazy loading pattern to not eat up memory/cycles.

At the very top level a user can easily access any desired data:

// Use your own install path
var kd = new KerbalData(@"C:\KSP");

// Load a save file using the same short name provided in the game UI
var sf = kd.Saves["testing"];

// One of many helper methods, this one re-fills all ships
sf.Game.FlightState.FillResources();

// Setting the title of the save game, this will change in-game name display (still need to wire in dir name change)
sf.Game.Title = "I AM IRON MAN";

// Another helper method, this clears all vessels marked as debris or unknown vessel types.
sf.Game.FlightState.ClearDebris();

// Grabbing a vessel from the game
var sat = sf.Game.FlightState.Vessels.Where(v => v.Name.Contains("Beta Geo-Sat")).FirstOrDefault();

// Changing the orbit (currently defaults to 100km above target)
sat.Orbit.Change(Body.Bop);

// Save file, includes data backup of original file
sf.Save();

The API curates the data providing a number of helpful methods along with:
  • Data change tracking -The API tracks data changes and marks instances that have changed (currently at the file level)
  • Revert changes - A copy of the original data is kept on hand ready for easy reversion.
  • Configurable data source and parsing - All parsers and data loading is handled via common encapsulation patterns (mainly Repository, Factory and Serializer). This means that you can configure data to read/save with a file system, a web service or anything you like. Also when Squad updates their file formats KerbalData will be able to change out the underlying parsers as needed to accommodate changes. Multiple parsers can be used together in order to create an upgrade path from one version of KSP data to the next.
  • WPF and multi-thread friendly (upcoming) - Dealing with data binding to your UI can be a pain, when data changes one places getting all the right values to change can be challenging and time consuming. The data classes in KerbalData will be developed to be thread safe for WPF and other multi-thread uses. Further additional properties will be available allowing the use of properly observable collections (through ObserverableCollection<T>). Combine with the upcoming watcher capabilities and watch game state update everytime there is save/autosave.

For more info on how the serialization works check out the code repo under src/KerbalData/Serialization/

API Layers

Last edited Jan 19, 2013 at 6:18 PM by Manitcor, version 5

Comments

No comments yet.