This mod is not known to work with the latest version of Kerbal Space Program. Proceed with caution.
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.
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.
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.
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.
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.
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.
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.
Raw stats are from the beginning of time until now. Each follower and download entry represents one hour of data. Uneventful hours are omitted.