jamespicone

Are you getting the "Debug.Log("BackgroundProcessing: Running assembly at " + Assembly.GetExecutingAssembly().Location + " (" + Assembly.GetExecutingAssembly().GetName().Version + ")");" debug output? What does it say?

Yeah, the 'ref' keyword here is the equivalent of & in C++ (which I also program in primarily, incidentally!) 'out' might have been more appropriate for the load function, but I'm already using ref for FixedBackgroundUpdate (where it does make sense - you need to take the passed value and possibly mutate the reference), so I figured for consistency I'd use 'ref' for load. I'll duplicate the KerbalStuff explanation into this post. The reason it's a System.Object is because the API for background processing is entirely reflection-based - people using it don't need to include a reference to the DLL, and their code will work fine without it being present, it just won't do background processing. Because they can't refer to me, and I can't refer to them, a generic box is all we've got.

I just hook game scene changes (via GameEvents.onLevelWasLoaded) and game state saves (GameEvents.onGameStateSave). I *think* changes to the protovessel config should be persisted in those situations. If it isn't, I'll have to come up with something else.

There's a new version of BackgroundProcessing up on KerbalStuff, with data persistence changes. The big change is that now FixedBackgroundUpdate takes a System.Object by reference: public static void FixedBackgroundUpdate(vessel v, uint partFlightId, ref System.Object data) (and similar for the resource-handling version). That object persists across FixedBackgroundUpdate calls. Also there's two new functions you may implement: public static void BackgroundLoad(Vessel v, uint partFlightId, ref System.Object data) Guaranteed to be called once before FixedBackgroundUpdate, gives you a chance to load whatever data you want out of the config nodes (you can also use a null 'data' as a flag in fixedbackgroundupdate for the same purpose) public static void BackgroundSave(Vessel v, uint partFlightId, System.Object data) Called during savefile creation, lets you persist background data to config nodes.

This has no association with RSS. EDIT: Okay and I just realised why you might think that. Consider it a poor name choice. I'll have a chat with NathanKell at some point about whether he minds before either changing the name or adding a disclaimer.

I can't find the source for Science Revisited so I can't comment on technical differences, but I would strongly recommend *not* using this mod right now if you're happy with whatever other mod that alters solar panel curves. This thing is still very beta, and I wouldn't be surprised if there are potentially game-breaking bugs (like the NaN bug mentioned above, that's potentially very serious) or serious incompatibilities with other mods.

I just copy out the relevant information - for solar panels, charge rate, power curve, position and orientation, the normal that defines the 'live' side, the pivot axis, and whether or not it tracks. I cheat with tracking - I assume it always tracks fast enough to be in the optimal position (and that it can do that without intersecting other bits of the craft) and just pump out as much power as it would in that situation. Compromises, etc. Only if the stored vessel data were written into the ConfigNode. If you were keeping a static collection of some kind with the data around, it wouldn't be restored, and you don't get a call you could use to save it. Unless you hooked a GameEvent I guess, but that's not a very clean solution. Whereas my addon will get a Save/Load, and I can call a function on your partmodule type to get you to save/load it. I guess the data could be stored per-partmodule type-per-part, like FixedBackgroundUpdate is currently called. That seems sensible. I'll look into implementation today.

There's a big difference between the resource module data that I store and providing a generic per-module data store for other users - the resource module info isn't really associated with a given partmodule once I've made it. If I was storing per partmodule data for modders, I'd have to guarantee that they were getting the same data with the same module, and there's no good identifying features for ProtoPartModuleSnapshots. Mapping the data to an individual ProtoPartModuleSnapshot across a save/load is ugly. I *think* I could do it by using the index into the module list as a key, but that's not a very stable solution under, for example, someone saving the game, removing a mod, and then loading the game. It has to persist across save/load because someone can close the game while a vessel is in the background and then open it again with the same vessel in the background. Although now that I think about it, partmodules on an unloaded vessel won't get the opportunity to read from the persistence file, which means the "let them sort it out" option has some problems... I'll look into it. Incidentally, as of right now FixedBackgroundUpdate isn't called once per PartModule on unloaded vessels. It's called once per PartModule type per part. So if a Part has two PartModules of the same type that both implement FixedBackgroundUpdate, FixedBackgroundUpdate will only get called /once/ on that partmodule type with that partFlightID. That's another one that's a result of trying to sidestep how tricky it is to keep ProtoPartSnapshot module lists in sync with Part module lists.

Much simpler. At the moment, stock solar panels have a charge rate, a piecewise linear curve giving falloff with distance, and the sun's AOA. Output is chargeRate * curve.evaluate(distance) * cos (sunAOA). I just replace the piecewise linear curve with 1/r**2, by changing charge rate every tick to r**2 / curve.evaluate®. It's setup so that solar panels output the same amount of charge at Kerbin as they would in the stock model.

This is a quick little hack to make solar panel output vary with distance-from-kerbol-squared, instead of a four-segment piecewise linear approximation of r**2. It works by using ModuleManager to add a special module to every part with a ModuleDeployableSolarPanel. That special module varies chargeRate on the ModuleDeployableSolarPanel dynamically to get the right numbers into the flowrate. It's not pretty, but it seems to maybe work? This is not very well tested. Consider this a beta release for people who might be interested. Mod on KerbalStuff: SolarPanelFixer Source code: https://code.google.com/p/solar-panel-fixer/

AFAIK you really have to compile against .net 3.5 for KSP to load you properly, although that might have changed in 0.90. Good to see it was a simple problem though, and you helped me find a legitimate bug in my code. Debug log spam should be substantially lessened in the source control head, I just haven't made a release of it. I've been pretty terrible at release management, and occasionally some stuff I left in there for debugging is still there.

Debug log would be most relevant. I assume it's crashing in the same place - during load? I just double-checked my own multiple-parts-with-the-same-partmodule-with-background-update test, and it's definitely working over here. I'm currently in #kspmodders on Espernet if you'd prefer a more real-time chat. EDIT: Of course you're doing something more complicated than that, duh. Ignore the below: Incidentally, background processing already does electric charge consumption for ModuleCommands with electric charge in inputResources, so unless you're doing something more complicated than that (or replacing that) you might be able to get away without a callback.

All of my prior tests had only one part with a given partmodule that had a FixedBackgroundUpdate, so I hadn't noticed that I was handling each partmodule once for each part that contained it. And the handling includes calling Add on a dictionary, so that's a crash. Should be fixed in 0.3.5.2, which I just pushed to KerbalStuff and source control. Sorry for the mistake, thanks for the catch.

I might just pipe in with a couple of the limitations of BackgroundProcessing as it stands at the moment: - It only handles electric charge for ModuleSolarPanels, ModuleCommands, and ModuleGenerators that have no input resources. AFAIK the only things that generates/uses electric charge and doesn't follow those rules in stock are consume-on-use like antennas, or are liquid fuel engines generating electric charge (and you can't have them on when you offload a vessel). But this does mean that any mod you're using that adds something that generates or consumes electric charge and doesn't fit into those rules won't work. For example, a hydrogen fuel cell that consumes a hydrogen resource to produce electric charge. A scanner module that consumes charge over time to scan and doesn't do it using a ModuleGenerator that produces negative electric charge. They can be made to work, but it requires people to specifically take into account background processing, and as far as I'm aware nobody does that yet. - It doesn't work for vessels that are prelaunch. This usually isn't a big deal. The reason is that vessels sometimes exist in a weird transient state when going from VAB to launchpad, and the easiest way to detect that state was to rule out all prelaunch vessels. - I've had to essentially reimplement the resource generation code, as JDP notes above. I wouldn't be very confident it's an exact match to what Squad is doing. You may notice some differing resource consumption/generation rates backgrounded in some situations. I don't know of any off the top of my head, but I'd be very surprised if they weren't there. I guess one big example is that solar panel tracking speed is ignored - I assume they've tracked to perfect position every 'tick'. A ship that was spinning fast enough that they couldn't do that would be an example then, I guess. Solar panels that don't have tracking don't have that behaviour, of course. - Keeping track of what partmodules are on a vessel when its been unloaded and is essentially just a ProtoVessel is a goddamn nightmare. If you've changed your mods around with a vessel in the background, expect some stuff to not quite work right. I think I've written defensively enough that nothing should explode, but you might, for example, end up with only some of the resource producers/consumers on the vessel being active. - I think the way I allocate resources to resource containers doesn't match what KSP does. Also I assume all resources can flow to all resource containers. That's true of electric charge, but if another mod decided to use background processing for something where that's not the case, there's a realism hole. That one is fixable, I guess, but it'd be a lot of work. - BackgroundProcessing is very new, and I'm quite new to KSP modding. There are almost certainly bugs I don't know about in it. JDP found one today that made background resource consumption/processing rates wrong.

As far as I'm aware, right now there are no mods that use or support this.

It should be. I haven't done a huge amount of testing on 0.90, though.

There's no good way to do this. There are a lot of nasty hacks. The game loads a set of ConfigNodes into GameDatabase at startup from the ScienceDefs file. You could find and modify those ConfigNodes prior to the ResearchAndDevelopment class starting up - MainMenu, something like that. ModuleManager might have some hooks to do that, I'm not sure. GameDatabase.Instance.GetConfigNodes("EXPERIMENT_DEFINITION") should get all of them, IIRC. That would involve a KSPAddon with startup set to Instantly or MainMenu, and is probably the cleanest solution. ResearchAndDevelopment is the class that does a lot of the science stuff. You could theoretically use reflection to mess with its internal database of ScienceSubjects and ScienceExperiments. This is incredibly ugly, possibly violates the EULA (which may well be legal where you live, and probably is, but will lead to Squad not posting your mod on the forums), and is technically hard. You could hook the various events fired when science is generated. OnScienceReceived might work, but I'm not sure if it's called in all situations that are relevant. This will be very fiddly.

Edit GameData/Squad/Resources/ScienceDefs.cfg and/or the PartModule definitions for ModuleScienceExperiments on parts.

As far as I can tell, ConfigNode parsing tokenizes on newline, followed by removing any token that starts with "//" and removing parts of tokens following "//", then it tokenises on "{" and "}", then it splits tokens into two around the first "=" character, and finally it trims whitespace on either side of the token. I don't think it strips "_" or ",". How are you actually getting the ConfigNode?

That error isn't coming from me - that one sounds like it's a mod named EFX. You've also got some NREs from RealChutes, and a few other mods. Not quite sure what's up there. Looks like your Sputnik IV vessel has an empty PartModule with a null name in it for some reason. Interesting. Good to know that can happen, I'll have to figure out why. Maybe happens when using ModuleManager to remove a module from a part?

I don't think ScanSAT actually uses my code for anything - I don't think anyone does right now. The biggest benefit you're going to get is the resource consumption behaviour, which only works for some modules. Probably not the ScanSAT ones. That particular error seems to suggest a null moduleName or a null resourceName on a part, which would be a bit strange. I've made a very quick-and-dirty patch, BackgroundProcessing . Hopefully with that version installed, you shouldn't get NREs, and should instead get one log message saying that there was a null moduleName/resourceName and dumping some info about it. If you'd be kind enough to dump the relevant log info after trying with that patch, that would be really handy. Thanks. EDIT: I'd prefer not to break down in the multiple-folders case, but thanks for the note - got me to check things in more detail, and I think the way I was doing things wasn't quite working - I think the static property I was using might not have been null by default. Or something like that was happening. It does seem to be working now... I'd also prefer not to rely on KSP's loading behaviour too much, or the dll name. A few lines of code doing stuff with Assembly seems a small price to pay for a bit more robustness.

I've now implemented the only-one-version runs behaviour of ModuleManager, so this mod can basically be treated like ModuleManager when distributing other mods - include it if you really want it, don't include it if you don't really want it but provide some extra features with it, doesn't really matter because only one version will ever run and it'll always be the most up-to-date. Also: Fiddling with the way PartModule scanning works, I've come to the conclusion that some mods are going to cause "Ran out of modules before finding X" warnings and there's not much I can do about it. If a mod dynamically adds PartModules to something and doesn't modify the prefab part, or if a ModuleManager config gets changed such that a part that was created against an earlier MM config no longer matches the prefab part, you'll get some warnings. It shouldn't crash KSP, or the mod. That'd be a bug. In the case of changed ModuleManager configs, it might result in partmodules that provide background handling not working, or parts that I handle resources for not working, on that particular vessel. In the case of stuff just adding PartModules on top after a part gets loaded (like FAR), it'll just result in the dynamically-added PartModule not getting background handling, which usually doesn't work. I might have to add a config file so that users can disable warnings, but hopefully it's not too irritating to have a couple of "Couldn't find this" messages in the log file for each vessel.

I don't make any attempt to maintain orientation or anything like that. It does work on non-active ships, but as a user, and with close to zero mods using this right now, the only change you'll notice is that electric charge will be consumed by command modules and generated by solar panels and anything using ModuleGenerator (The PB-NUK in stock, maybe some mods).

That particular error message isn't super important - it's in there because it's good for me to know about, but it shouldn't break too much. It happens when I can't find a PartModule for a given unloaded Part in a vessel - in this case, it looks like FAR creates some PartModules on all parts when they're created, but doesn't modify the part prefab, so I can't find an actual instantiated instance of the FAR modules. That means I won't do background resource handling for those modules, but given that FAR's inserted modules don't contain or consume resources anyway that shouldn't matter too much. I'm looking into ways of improving this behaviour, but it's kind of tricky to get some of the information I want for a PartModule from its ProtoPartModuleSnapshot.

Okay, there's a new update on KerbalStuff that should fix that issue.