jamespicone

I've accepted @buttercookie42's pull request against my repository, rebuilt the mod against KSP 1.2.2, did a basic works-on-my-machine test and put it on SpaceDock. I don't really know about CKAN; probably a good idea for somebody else to do that. Thanks Buttercookie42, as should be obvious I'm not really maintaining this any more. It'd probably be ideal if somebody else took over; don't really mind who. Happy to hand stuff over in a semi-official way if necessary.

Waiting on some API info from some people in Squad

I wouldn't go so far as to say I was working on an update; I only looked at it just then. But yeah the way modules say what resources they use has changed and the way unloaded vessels store their resources has been slightly tweaked; figuring it out is going to take some reverse engineering on the assumption that documentation for KSP internals is still lacking. For those of you following at home, ModuleCommand and ModuleGenerator no longer have an inputList/outputList/inputResources, ModuleDeployableSolarPanel handles tracking differently, and ProtoPartResourceSnapshot has been changed so the ConfigNode storing the resource data is now protected (hopefully I can get at the data I need in there; otherwise I'm gonna have to reflect on it)

Gave it a quick look and it looks like it won't just rebuild; there've been relevant KSP changes.

There's a known fix?

I am reading this; I've done a quick check and the SolarPanel.cs code is definitely using the sun_dist returned by the raytracing reimplementation. I am using FlightGlobals.Bodies[0].GetAltitude(partPos) to get the distance from the sun for power-curve stuff, which might be causing the problem (assuming there's a power-curve solar panel on the dying vessel). There's a few points where a NaN could be occurring. I don't actually currently have KSP installed; not sure when I'll be able to fiddle with this, once again. Sorry. If I can get a couple of hours together to just sit down and code it shouldn't be too hard to find though. One thing that could be helpful - can someone who can easily duplicate this (say, @garwel?) reproduce this with the debug level set high? BackgroundProcessing reads a PluginConfiguration file, and if you have an entry setting DebugLevel to ALL, we'll get a lot more useful data. Something like this: <config> <string name="DebugLevel">ALL</string> </config> Don't know off the top of my head what the filename is, but if you've got any other mods that do something similar with an XML file, it'll be the same rule. Probably 'BackgroundProcessing.xml'.

The BitBucket repo should be up to date with the changes in @JPLRepo's github.

Edited the first post to note 1.1.3 compatibility

Committed all your changes into the BitBucket repo, uploaded a build to SpaceDock, and IIRC SpaceDock should propagate to CKAN. Don't know when there will be new dev effort on my part. I guess the obvious next pieces of fruit are: - Ability for players to specify 'interesting' resources in the config file. - Resource converters and fuelled generators (Problem: Mimicking proper behaviour for resources that aren't whole-ship like electric charge) - Emulating temperature effects on solar panels

Confirming that I've seen this and will get around to fixing things on my end Soontm . Probably tomorrow night.

Yes, and that would be amazing if you could. Probably an hour of work in at least though, just as a warning. https://bitbucket.org/j_picone/background-processing Haven't checked whether your fork has the updated solar panel handling either...

It's really unfortunate that your fork was before a bunch of the refactoring I did to make things a bit cleaner. :/. I haven't forgotten about this, but I've essentially been on the go continuously for a month. Won't be able to get to things until after the middle of July at the earliest.

Yes, when I can get to it, which might not be soon. Work's rather busy at the moment and it's sucking up most of my programming juice. I will eventually get to merging the fixes and updating spacedock.

Sorry, I appreciate I've been terribly lazy. Thank you for maintaining things. @bice: The 'interesting resources' list is for things ModuleGenerator, ModuleDeployableSolarPanel, or ModuleCommand might care about other than electric charge. So if 'dust' was added to the interesting resources list, the ModuleDeployableSolarPanel you posted would generate dust, but the hoover wouldn't because I don't handle resource conversion (due to issues with figuring out how it's meant to work and also resources that aren't whole-ship like electric charge). It'd be fairly easy to adjust it so that you can specify in the config file a list of interesting resources. But then only some of the dust stuff would work. This does look like I'd have to make resource conversion work before it'd be useful; the mod author can't do much with it because none of these are new PartModule types. I may - and I make no promises - look into some of this. I've been doing a bunch of other things and haven't played KSP for quite a while now.

We have to iterate through the modules regardless of the log level.

The code is attempting to match up modules in ProtoPartSnapshots with the associated module in the prefab part. We need both of them to do background processing properly, and there's no easier way to figure out which one of them is which than walking both lists finding which ones match up. Those debug messages should only be printed if the lists are out of sync - they should be giving you indexes. That'll happen if the prefabs PartModules don't match the ProtoPartSnapshot's PartModules, which is usually caused by things adding PartModules at runtime. The messages are there so that if someone has an error caused by PartModules being added at runtime I'll be able to figure it out. The messages should be printed at WARNING level; you can turn them off in the config file.

That's my intended fix.

ScaledSpaces: can you explain that one? I haven't seen any issues in prior releases, but I haven't looked into later-than-1.0.2. SolarLuminosity initialisation: My in-dev code has a fix in the works. Single-instance behaviour: Noted, will fix.

I haven't tested against versions of KSP more recent than 1.0.2, but I've been told that it functions with 1.0.5. It probably won't blow up your save, but maybe backup just in case.

>_> Jeez, you stop paying attention to a mod for a few months and KerbalStuff goes down. I've put BackgroundProcessing on SpaceDock. I haven't tested against versions of KSP later than 1.0.5. I've not been following KSP for some time, so I'm not sure what the changes are. If JPLRepo thinks it works, he's probably right. I can't imagine they've changed solar panel behaviour significantly in a few point releases. The thermo stuff might matter, I guess. Thanks for rehosting the mod @JPLRepo . Any leads on the bug, and was the problem something to do with PhysicsGlobals not being loaded until you go to a flight scene at least once? I have some uncommitted code on my HDD where it looks like I was looking into that.

I haven't tested against either of those mods. Some people above apparently have, and I don't think they were having any problems. I don't want to remove the debug code in release versions. It's turned on or off by a configuration file, with the point being that if someone is having a problem I can have them turn on logging info and then tell me what is output.

Debugging info is pretty important, not dumping debug info at incredible rates into everybody's logs is also important (and actually firing the logging info is much slower than a /single boolean test that almost always fails/). The 'inside-out' version where I have different versions of the same function depending on the logging level is worse for maintainability and readability. I consider the no-orientation and no-temperature paths to be 'not the main line', and as a result the code ended up being written so that they were spurs off the main path instead of testing for orientation/temperature relevance before doing the calculations. I honestly don't think the performance impact here is relevant. This code isn't cycle-counting levels of performance critical.

Premature optimisation is the root of all evil. This is all constant-factor stuff, barely worth caring about from a performance perspective, tbh. I'll move the orientationFactor stuff, because that at least takes two-digit amounts of floating point. The temperature factor stuff is almost unnoticeable - it's a single floatcurve.evaluate(). I feel pretty confident noting that all of this should have next to no noticeable performance impact.

ModuleDeployableSolarPanel.panelState, and ModuleDeployableSolarPanel.Extend()/Retract()/breakPanels(). Un-breaking panels is probably nontrivial.

Yes, variation is calculated and applied continuously - if you leave a vessel in the shadow of a planet, when it's out of shadow it'll start receiving power. "Just make Kerbals consume/produce resources" isn't an atomic action - looking into it briefly it looks like vessels have a list of crew attached to them, so I can just loop over that list and consume resources for each one, maybe. I'm not sure how EVA kerbals are handled. I don't know under what circumstances KSP will do something stupid with that list that makes it look like there's more or less crew than there should be - what happens when you go IVA for example? I don't think it's hard, as such, or even particularly tricky, just sufficiently annoying and out-of-scope that I don't want to do it. . So far I've managed to make BP usable by other mods without them having an explicit reference to my assembly anywhere in their code - they can support it, and if it's there they get processing in the background, and if it's not you don't. Building life support in directly with some plugin-setup might compromise that, but I'll think about it. Snacks doesn't appear to be using Background Processing the mod, although it does look like they're trying to do processing in the background for snacks.