NOTE FOR KSP 1.0: This mod has only recently been updated for KSP 1.0. There are still some inaccuracies and problems with its 1.0 implementation, like the following:

• Solar panels are complicated in 1.0, and their output depends on part temperature. At the moment, part temperature is not simulated in the background, and parts are assumed to not change temperature in the background. This will lead to slight inaccuracies in solar power output
• Fuel cells will not function in the background, nor will ISRUs. They're a work in progress that will have to wait until I figure out what to do with stage-priority resources.

BackgroundProcessing is a small and simple mod that performs some processing for vessels 'in the background' - probes or manned craft that have been left orbiting while the player is in the Kerbal Space Center or piloting another vessel.

Installation

• Download the BackgroundProcessing.zip file from here
• Extract it to your GameData folder

I'm a player. What does BackgroundProcessing offer me?

BackgroundProcessing will allow craft to gain and lose ElectricCharge while you're off doing something else. This doesn't actually happen in stock KSP - try building a spaceship made up of an empty battery, an RTG, and some wheels (to get it off the launchpad). Move it off the launchpad, check resources, notice that it's gaining charge over time. Then leave it and go back to the space center and speed up time. Check the craft again, and it won't have gained or lost any charge. That's a minor realism issue, but its nice to have fixed.

The other thing BackgroundProcessing provides is support for other mods that might want to do something while a craft is in the background. A scanner, something that produces a mod-specific resource, anything like that. Because of the way BackgroundProcessing is designed that other mod doesn't have to include BP, and it doesn't have to use its features, but if that mod has implemented BP-compatibility, BP will detect it and use it.

I'm a mod author. What does BackgroundProcessing offer me?

If you have a PartModule that should do stuff even while a craft isn't the actual active vessel - like a scanner, or a solar-wind collector - you can get background processing just by implementing a couple of functions. BackgroundProcessing has already implemented a lot of the boilerplate required to get this working. Your PartModule can do anything in the background that can be done with a ProtoVessel - which is quite a lot - and BP provides some mechanisms for producing or consuming resources easily. BP also allows mods to indicate that some mod-specific resource should be handled in the background, and then any ModuleGenerator or ModuleDeployableSolarPanel that produces that resource (with no resource consumed) will produce it in the background. Additionally, any ModuleCommand that consumes that resource will consume it in the background. All of this can be done without reference to the BackgroundProcessing assembly, so your users can choose whether or not they want background handling, and you don't have to package BP with your mod.

BackgroundProcessing is MIT-licensed, so there aren't any license worries.

What specific things are handled?

Any Part using the ModuleGenerator or ModuleDeployableSolarPanel to produce ElectricCharge with no inputs, any Part using ModuleComand to consume ElectricCharge. At present ModuleDeployableSolarPanel output charge takes into account the location of Kerbol, planetary shadows, panel efficiency and panel orientation, including tracking solar panels.

Mods can instruct BackgroundProcessing that particular PartModule classes should be considered to produce or consume some resource at a given rate. They can also have BackgroundProcessing handle ModuleGenerator/ModuleDeployableSolarPanel/ModuleCommand that produces/consumes resources other than ElectricCharge. Finally, their background handling code can consume or produce any resource they please.

How do I get BackgroundProcessing support in my PartModule?

Implement some static functions in your PartModule.

public static void FixedBackgroundUpdate(Vessel v, uint partFlightID, ref System.Object data)

public static void FixedBackgroundUpdate(Vessel v, uint partFlightID, Func<Vessel, float, string, float> resourceRequest, ref System.Object data)

These two functions are the 'simple' and 'complex' background update functions. If you implement either of them, BackgroundProcessing will call it at FixedUpdate() intervals (if you implement both, only the complex version will get called). The function will only be called for unloaded vessels, and it will be called once per part per partmodule type - so if you have more than one of the same PartModule on the same part you'll only get one update for all of those PartModules. Vessel v is the Vessel object that you should update - be careful, it's quite likely unloaded and very little of it is there. partFlightID is the flightID of the part this update was associated with. resourceRequest is a function that provides an analog of Part.RequestResource. It takes a vessel, an amount of resource to take, and a resource name, and returns the amount of resource that you got. Like Part.RequestResource, you can ask for a negative amount of some resource to fill up the tanks. The resource is consumed as if it can be reached from the entire vessel - be very careful with resources like liquid fuel that should only flow through crossfeeds. data is arbitrary per-part-per-partmodule-type storage - you can stash anything you want there, and it will persist between FixedBackgroundUpdate calls.

public static void BackgroundLoad(Vessel v, uint partFlightId, ref System.Object data)

This function will be called once prior to FixedBackgroundUpdate, and it gives you a chance to load data out of the ConfigNodes on the vessel's protovessel into the storage BackgroundProcessing manages for you.

public static void BackgroundSave(Vessel v, uint partFlightId, System.Object data)

This function will be called prior to the game scene changing or the game otherwise being saved. Use it to persist background data to the vessel's ConfigNodes. Note that System.Object data is not a ref type here, unlike the other times it is used.

public static List<string> GetInterestingResources()

Implement this function to return a list of resources that your PartModule would like BackgroundProcessing to handle in the background. It's okay if multiple PartModules say a given resource is interesting.

public static int GetBackgroundResourceCount()

public static void GetBackgroundResource(int index, out string resourceName, out float resourceRate)

Implement these functions to inform BackgroundProcessing that your PartModule should be considered to produce or consume a resource in the background. GetBackgroundResourceCount() should return the number of different resources that your PartModule produces/consumes. GetBackgroundResource() will then be called with each index from 0 up to one less than the count you indicated, and you should set resourceName and resourceRate to the appropriate values for the index-th resource your PartModule produces. resourceRate is the amount of resource your part should produce each second - if your part consumes resources, it should be negative. If your part only consumes or produces resources in some situation, it's better to implement the complex background update and use the resource request function.

How do I distribute a mod that uses BackgroundProcessing?

Having multiple copies of the BackgroundProcessing DLL in a GameData directory is fine - only the most recent version will run. If your mod absolutely needs BackgroundProcessing present to be useful, consider including the BackgroundProcessing DLL in your mod's zip file, the same way ModuleManager is handled.

If BackgroundProcessing isn't central to your mod, feel free not to distribute it at all. If players don't have this mod installed, they just won't get your off-rails features.

Are there any caveats when writing code that uses BackgroundProcessing?

BackgroundProcessing works optimally with PartModules that are present in prefab parts. The list of modules that has BackgroundProcessing handling is constructed by walking all the AvailablePart objects in PartLoader.LoadedPartLists at the main menu. If your partmodule isn't in that set, very little will work. Similarly, if your PartModule is added to a part's module list after part instantiation, and isn't present in the part's prefab module list, resource handling will likely not work. This is all only relevant if your PartModule is added dynamically to parts, after construction. It isn't relevant to PartModules that are present in config files, or to PartModules added by ModuleManager (which appropriately modifies prefab parts). The takeaway is that if you intend to dynamically add PartModules to parts, and those dynamically-added PartModules should have BackgroundProcessing behaviour, make sure you add them to the appropriate part prefab before the main menu, like ModuleManager.