jamespicone

How It Works: At intervals (FixedUpdate to be precise - usually fractions of a second) BP scans all vessels. If it runs into a vessel that is a) unloaded and not currently known to it, it inspects the persistence information for that vessel - the ProtoVessel - to determine what Parts are in it, and what PartModules are in those parts. If those PartModules are ModuleDeployableSolarPanel (the module used for solar panels), ModuleGenerator (the module used for RTGs) or ModuleCommand (the module used for probe cores and command pods) that produce a resource BP has been instructed to care about (only ElectricCharge, by default), then it grabs a bunch of information from the module - the rate resource is generated/consumed, thermal efficiency curves, that kind of thing - and stores it. Finally, for every unloaded vessel that is present and known to BP, it adds/subtracts the amount of resources required by all the PartModules in the vessel that I've found in the current situation (so taking into account distance from sun, atmosphere, temperature, and shadowing for solar panels, for example). Other mods can set themselves up so that BP calls a function for their PartModules if they're in unloaded vessels, and they can register a resource with BP so that if a ModuleGenerator produces it, BP will track it. The problem with extraction/conversion is partially that I haven't looked into it yet, but also partially that LiquidFuel and Oxidiser are STAGE_PRIORITY resources that can only flow through certain kinds of connection, and I haven't written the code to emulate that behaviour yet (and I'm not sure it's sufficiently doable to do - I don't know how accessible part connection information is in unloaded vessels). I'm currently considering implementing handling for LiquidFuel and Oxidiser and just treating them the same as ElectricCharge - resources that just travel ship-wide without limitations - and providing a config file switch to turn off that behaviour if people understandably don't like it. Consider the way an engine can't consume fuel from a fuel tank it doesn't have a fuel line / connection to. It would be moderately easy to have kerbals produce or consume resources in unloaded ModuleCommand parts, probably. I'm not sure how easy determining how many Kerbals are in a ModuleCommand is, and EVA handling isn't quite a thing BP does, but those are probably solvable. The bigger problem is that I don't want to implement full-blown life-support mechanics - kerbals dying when they run out of oxygen and the like - especially given that there are already perfectly good mods for handling this out there, like TAC LS. Resource flow is also a concern, given that oxygen should probably be treated like fuel - only flows between parts specifically attached for it. If there's a way forward here, it's probably either me or TaranisElsu implementing BP support in TAC LS. TaranisElsu is aware of this mod, I'm pretty sure. I think I've briefly talked to him about it in IRC. I don't know what his opinion of my codebase or its utility is - I've briefly looked at TAC LS, and I don't think it'd be too hard to implement BP support, but I might be completely misunderstanding how he's implementing things. *shrug*. It's something I'll think about and I might talk to TaranisElsu about it, but no promises.

I honestly don't know, and it would depend on how large 'decent' is and how many relevant partmodules are on it. I can say that I've never seen anyone complain about performance impacts. Try it yourself maybe?

Solar panels are much improved. They're still vaguely inaccurate, because I'd have to simulate temperature to get it perfect. At the moment it assumes parts don't change temperature when they're in the background, which might cause some problems if you leave a vessel at an awkward part of their orbit (perhaps while they're in full sunlight). I don't know what the normal range of temperature variation for vessels in orbit is, so I can't give a good measure of how much this affects everything. Future plan is to maybe implement very simple modeling of temperature out-of-atmosphere. Fuel cells aren't ModuleGenerator, for some reason, but they still won't work (nor will ISRUs) because I haven't put the work into STAGE_PRIORITY resources yet. I'm not sure I'll be able to fix that. I'm thinking of implementing them and ignoring STAGE_PRIORITY as a config option (so the fuel use/generation will go into the wrong tanks, but it'll be the right amount), and of looking into how much work it would be to accurately emulate staged resources - the biggest problem is that I don't think I have the part attachement graph when vessels are unloaded. I have fixed the bug where resources drain from locked tanks.

Short answer: no. Long answer: This almost exclusively handles resource generation/consumption, not physics. If the game won't let you leave a vessel (because it's under power) this won't help.

I've published an update for 1.02. I'd consider this one somewhat beta - I'm not sure if there are horrible problems I'm unaware of. Solar cells should behave much more accurately in this version, also there's a config file which allows setting which factors affect solar panel output and a fix for locked tanks draining (So BSTM's changed version is now out of date and unnecessary). Fuel cells and ISRUs still won't work in the background, and I'm not certain what to do about them. Neither will resource extraction stuff.

BP has hooks any mod can get into, without necessarily requiring BP is present. That is, TAC LS could be written so that if BP is present it's used, and if it isn't nothing happens, and TaranisElsu can just distribute the same file either way. I don't currently perform processing for EVA kerbals though, so there's that. I should probably publish what's currently in the repository - if you're comfortable building from source what's currently in the repo improves solar panel behaviour in 1.0.

After a more in-depth look, it looks like TAC LS does consume electricity over time in the background, and it's possible it does it on modules that Background Processing tracks usage for. So in conclusion, *probably* this interacts with TAC LS in such a way that command modules have doubled electricity consumption in the background, with one set of consumption delivered in one hit when the vessel is loaded. This mod can track any resource, ultimately, but it's currently only setup to do electricity. Other mods using it can ask it to track other resources though - TaranisElsu could use BP to implement more direct background consumption of water/food/air/electricity as well as background generation of water/food/air/electricity. Basic takeaway - what you're suggesting to TaranisElsu on the TAC LS thread is what this mod already does.

In unloaded vessels parts/partmodules don't actually exist - they won't get OnStart called, won't be forced active, etc. So if the force-active thing is the only thing, this definitely doesn't work on unloaded vessels. Maybe packed vessels - I'm not entirely certain how they would behave. Honestly I think there are better ways of doing it, at the very least ways that have less potential side effects.

Hi, I work on a mod that implements processing / resource handling for parts in unloaded vessels. Someone just asked me whether or not your RTG mod has nasty interactions with mine, so I had a quick squiz at your source code to try and figure out what was likely to go wrong. I can't quite figure out what your module does in the background, though. From what I can see, the forced part activation in OnStart() for flight scene is what's there - which presumably allows for RTG output to fall over time by getting you FixedUpdates but doesn't allow you to actually generate ElectricCharge for unloaded vessels. Am I right in assuming that's what's going on? Thanks. If it is that, incidentally, I know about this neat mod for background processing on parts you might find useful to support...

There can be interactions. Those interactions can be weird. Possibilities include things like resources being generated/consumed twice as fast, or only some resources being generated/consumed twice as fast, as the boring case. The specific mods you've just mentioned: my quick scan of TAC Life Support suggests that it doesn't handle resources in unloaded vessels - only vessels you're not flying that are still close enough to be loaded. Background Processing only handles resources in vessels that are unloaded. There shouldn't be any direct problems caused by the overlap because of that, although some life support stuff probably won't consume in the background. I don't guarantee that, either - this is based on a cursory glance at the TAC source. JDiminishingRTG, the post claims stuff updates on unfocused vessels, but I don't see where that happens with a cursory glance at the source - it's possible I'm missing it. Regardless, it uses its own ModuleDiminishingRTG class that my code doesn't know how to drive, so it's /probably/ okay, but the parts it replaces will be background-updated by its code, not mine.

Sure, that's an easy-enough feature to add. I've moved the source over to BitBucket. I'll edit the first post at some point.

The TemperatureMultiplier value is multiplied with the part's thermal mass, that's how many kilowatts of energy get added to the part. Which implies that a negative TemperatureMultiplier should work fine, but I don't know for sure. There are some other relevant KSPFields here - there's a HeatThrottle parameter that presumably controls whether or not the part slows down as it gets warm (or cold?)

Okay, I've been doing some fiddling. Solar panels are much better in the source tree now. They are still not accurate, but they're nearly as good as they're likely to get. The big problem is part temperature - accurately emulating that would be extremely difficult. At the moment, I assume part temperatures are perfectly static once a vessel goes into the background. The implication is that if your part is warmer - or colder - than normal when you go into the background (Maybe you've just gone through re-entry, for example), then it'll produce different outputs to what it would have in the foreground. In particular, when something is orbiting presence or absence of direct sunlight would be a factor normally, and it isn't right now. In the future I might do this better - perhaps a very simple emulation of part temperature that handles the orbital case. Fuel cells aren't implemented and aren't likely to be for the near future. ISRUs as well. The reason is because they use resources that have stage priority, and I don't want to do the work of accurately emulating stage-priority resources right now. Future work is likely to be either emulating stage priority, or emulating those resources only if you tell the config file that it's okay to have the weirdness associated with treating staged resources like they're whole-ship. Also there's a config file now. Current options include: - Whether or not solar panel orientation matters to solar power or not. This switch is present because there's some indication that vessel orientation during background might not be accurate, and I haven't tried to fix that yet, so you can turn it off. - Whether temperature matters to solar power, for the reasons I gave above re: temperature being hard. - Debug log level. Ranges from SILENT, to ERROR, to WARNING, to ALL at present. ERROR by default. I haven't made a release yet, and likely won't for a little bit (I want to chase up a couple of other things, some stuff probably doesn't respect enable/disable state properly, although I've fixed the flowstate resource tank thing in source). When I do make a release, it won't be on KAN for a bit because I've changed a fair amount of stuff and want to shake out the bugs first.

It might be a while before I get it in fully-working state. There's two major problems I'm aware of right now: - The solar panel revamp has meant that my old code for emulating solar panels in the background is very wrong. New solar panels are quite complicated and hard to emulate (part temperature matters now, and atmosphere alters charge rates as well). It'll be a while before those are at the same standard. - Some of the new parts are implemented using ModuleGenerator with inputs (Fuel cells in particular). Previously, BackgroundProcessing ignored ModuleGenerators with inputs, because 1) there were no such parts in stock KSP, and 2) it wasn't clear to me how they were supposed to function. Now I've got a test case and I can fiddle a bit. That one should be much easier to implement than the solar panels. I've had a bit of a break from KSP modding as well, so I've only started looking into this stuff again recently.

I've been a bit busy of late, sorry I haven't gotten back to this. Solar panels will not work correctly in background in 1.0 with this mod. I'll need to do a bit of work to fix the problem. I'm not aware of any other problems with 1.0 offhand, but let me know if you find any. EDIT: And looking at it, it's going to be Very Difficult to implement solar panels correctly in our brave, new, more accurate future. This may take some time. EDIT EDIT: Fuel cells won't currently work, because I wasn't entirely certain how the mechanics for ModuleGenerator with inputs functioned back when I first wrote the code for that, and there weren't any such modules in the base game. Anther thing to work on.

Go ahead, I'm not too fussed about it.

It's fine, it's not a big problem - and obviously the license does allow it - it's just that the who-runs-first problem is hard to solve with multiple slightly-altered solutions in the same space, so I'd pefer not to try and solve it. That'll be the next step then.

Thanks for the catch and fix, I'll incorporate it in the next release. Honestly I'd prefer it if you didn't ship a modified DLL. What's the best behaviour when a player has the most up-to-date BP dll and your modification of the most up-to-date BP DLL in their gamedata folder? Presumably yours should execute, but I think in practice it would depend on folder structure determining which runs first. And what if a different mod decides they want a modified BP and someone has three up-to-date DLLs with different behaviour? Now it's not even clear which should run. I understand why you want to do it though. If I incorporate the flowstate fix and add a config file that lets you disable orientation for solar panels (so their output is just chargeRate * distance factor) and lets you change logging verbosity, would that be sufficient? I'm not sure what's up with the orientation stuff, I might have a look at that as well.

Sweet. Had a look through the thread, and it's good to hear that it takes significant amounts of stuff before I'm a major performance drag. If performance does become a problem in future, I'll probably look into obviating the linear-time search for the appropriate ProtoPartSnapshot more directly than allowing people to store arbitrary data, and *maybe* some kind of multithreading, although I'm not sure I want to impose threading-related restrictions on people's background updates. Vessel orientation should be taken into account, as should panel location on the vessel, panel orientation, and the panel's ability to track if it's a tracking panel. If one of those isn't being taken into account, it's a bug. Vessels don't rotate in the background, unfortunately - it'll just be whatever orientation the vessel was in when you left it. I can probably fix that - vessels have an 'angularVelocity' vector.

I wasn't aware - I didn't actually put the mod in CKAN, I just gave permission for someone else to do it. I won't change the name back - I need the different names for different version numbers for the only-most-recent assembly handling to work properly - but I'll look into making CKAN play nice with version-numbered DLL.

It should be implemented iff any of your partmodules believes that a resource should be processed in the background by BP from ModuleGenerators/ModuleCommand/ModuleDeployableSolarPanel parts. Say you're writing a life support mod, and part of that mod is that you have some Parts with PartModules that generate "oxygen", you might return List("Oxygen") from GetInterestingResources() and then any ModuleGenerator that outputs oxygen with no inputs will output oxygen in the background. (and any ModuleCommand that consumes oxygen will consume it, but that probably wouldn't happen). It doesn't interact with FixedBackgroundUpdate at all. Passing in the part to those is a good idea. At the moment this background resource handling for non-electric-charge modules is a bit simplistic. Ideally you'd like to be able to return the consumption properties when something goes into the background, the same way I retrieve them for ModuleCommand/ModuleGenerator/ModuleDeployableSolarPanel. I should probably change how those functions work. The intended usage is if you have a PartModule that consumes or produces a fixed quantity of some resource every tick, you can just have it tie into the same system I use to handle electric charge in the background. It's intended to be the extremely-simple background update, I guess.

I'm an idiot, and the test case I was looking at wasn't the complex FixedBackgroundUpdate, which I indeed broke (it was expecting a delegate type thing, not a Func<Vessel, float, string float>). Should be fixed in 0.4.0.1, up on kerbalstuff right now.

That's very strange. I haven't been able to reproduce the problem yet. I assume you're not getting any exceptions in your log - they'd be potentially meaningful. If you're comfortable with compiling BP from source, I can add a bunch of debug statements that might be useful so we can get a feel for where it's falling down. If Deadly Reentry only adds partmodules at the end of the module list it should be fine - you'll get a bunch of messages like "Ran out of modules before finding module SOME_REENTRY_MODULE", but it shouldn't break anything. You should only worry if it can't find ModuleDeployableSolarPanel, ModuleGenerator, or ModuleCommand.

Okay, so prelaunch vessels shouldn't get anything called on them. The reason is because when vessels are put in the launchpad there's a transitory half-initialised vessel created and added to the FlightGlobals.Vessels list that I don't want to do background processing on, and testing for prelaunch caught that problem without too many other problems. My usual testing practice is to attach wheels to the probe core I'm testing and move it a bit - that's usually enough to get it out of prelaunch, as far as I can tell. And yeah, plugins that add modules at runtime, or changing mods change partmodules that are available, can play merry hell. If there's a difference between the PartModules on a ProtoPartSnapshot and the PartModules on the prefab Part, you should expect background callbacks to happen, but you should expect some weirdness with resource handling. That code can probably be improved, but will probably never be perfect.

Well it's at least starting up then... Is the vessel prelaunch? You can tell if it says "Standing by to launch" on the main screen.