Background Processing 0.4.4.0 [KSP 1.1.3]

[Kerbas_ad_astra]

I don't know about dtoxic, but I've just noticed lots of NREs like his that are being triggered by this mod trying to do background processing on a flag (the only one in that particular save, but I can see what happens in a new save with more than one flag).

[jamespicone]

I don't know about dtoxic, but I've just noticed lots of NREs like his that are being triggered by this mod trying to do background processing on a flag (the only one in that particular save, but I can see what happens in a new save with more than one flag).

Aha, that I could reproduce. Looks like EVA kerbals / flags? don't have a modules list on their protopart. Bug squished. KerbalStuff is currently down, so I can't upload a new version, but I will when it's up and/or Ludum Dare is over. Thanks for the report. Hopefully this is what dtoxic is running into.

[dtoxic]

Aha, that I could reproduce. Looks like EVA kerbals / flags? don't have a modules list on their protopart. Bug squished. KerbalStuff is currently down, so I can't upload a new version, but I will when it's up and/or Ludum Dare is over. Thanks for the report. Hopefully this is what dtoxic is running into.

yeap same thing flags!

i cant upload my log i am not on my main pc will do when i get back home

[jamespicone]

yeap same thing flags!

i cant upload my log i am not on my main pc will do when i get back home

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

[dtoxic]

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

working like a charm thx man

[jamespicone]

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.

[Sinsis]

Heya,

Seems like I'm getting errors with my installation, as mentioned here: http://forum.kerbalspaceprogram.com/threads/102453-Terrible-performance.

Details, some of the errors:

ArgumentNullException: Argument cannot be null.

Parameter name: key

at System.Collections.Generic.Dictionary`2[system.String,BackgroundProcessing.Addon+UpdateHelper].ContainsKey (System.String key) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.GetVesselData (.Vessel v) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

BackgroundProcessing: Getting data for vessel Sputnik IV

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

BackgroundProcessing: Ran out of modules before finding module ModuleAeroReentry

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

ArgumentNullException: Argument cannot be null.

Parameter name: key

at System.Collections.Generic.Dictionary`2[system.String,BackgroundProcessing.Addon+UpdateHelper].ContainsKey (System.String key) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.GetVesselData (.Vessel v) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

BackgroundProcessing: Getting data for vessel Sputnik IV

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

BackgroundProcessing: Ran out of modules before finding module ModuleAeroReentry

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

ArgumentNullException: Argument cannot be null.

Parameter name: key

at System.Collections.Generic.Dictionary`2[system.String,BackgroundProcessing.Addon+UpdateHelper].ContainsKey (System.String key) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.GetVesselData (.Vessel v) [0x00000] in <filename unknown>:0

at BackgroundProcessing.Addon.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

Full file:

https://www.dropbox.com/s/z6952qerkqzmp5q/output_log.txt?dl=0

Any thoughts?

EDIT: Looking back at my installations (the mod list is in my thread), I'm actually doubting if any mod is using backgroundprocessing at all and if I should cut it out...is it an issue if I leave it in without a mod making use of it? Not sure how it got into my mod folder haha.

EDIT2: I am actually using SCANSAT so I figure I shouldn't just cut it.

Edited December 11, 2014 by Sinsis

[xEvilReeperx]

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.

Careful. The way ModuleManager works is deceptive. Its latest-version code technically doesn't do anything. The magic sauce that makes it appear to work is the KSPAssembly attribute. KSP will instantiate the correct type from the proper DLL among several choices if they're in the same folder and then goes by last-loaded in a breadth-first search. This will let you name them out of order and still get the correct assembly. But it breaks down if you have assemblies in different folders.

I looked at your source and you could replace all that recent assembly code with a simple static bool flag assuming you follow a naming convention that would result in the latest assembly being loaded last, or added the KSPAssembly attribute to your dll. As long as your DLL is being distributed the same way in every case, this will do the job.

As an example, if you have a user with this structure:

GameData/ModuleManager_1_5.dll

GameData/ModuleManager_1_6.dll

GameData/ModDistributingMM/ModuleManager_1_4.dll

Then version 1.4 will load every time because it has no competition and it's the last loaded. I thought I'd created an issue about this in case sarbian wasn't aware but apparently not

Edited December 11, 2014 by xEvilReeperx

[jamespicone]

Sinsis said:

Heya,

Seems like I'm getting errors with my installation, as mentioned here: http://forum.kerbalspaceprogram.com/threads/102453-Terrible-performance.

Details, some of the errors:

Full file:

https://www.dropbox.com/s/z6952qerkqzmp5q/output_log.txt?dl=0

Any thoughts?

EDIT: Looking back at my installations (the mod list is in my thread), I'm actually doubting if any mod is using backgroundprocessing at all and if I should cut it out...is it an issue if I leave it in without a mod making use of it? Not sure how it got into my mod folder haha.

EDIT2: I am actually using SCANSAT so I figure I shouldn't just cut it.

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:

xEvilReeperx said:

Careful. The way ModuleManager works is deceptive. Its latest-version code technically doesn't do anything. The magic sauce that makes it appear to work is the KSPAssembly attribute. KSP will instantiate the correct type from the proper DLL among several choices if they're in the same folder and then goes by last-loaded in a breadth-first search. This will let you name them out of order and still get the correct assembly. But it breaks down if you have assemblies in different folders.

I looked at your source and you could replace all that recent assembly code with a simple static bool flag assuming you follow a naming convention that would result in the latest assembly being loaded last, or added the KSPAssembly attribute to your dll. As long as your DLL is being distributed the same way in every case, this will do the job.

As an example, if you have a user with this structure:

GameData/ModuleManager_1_5.dll

GameData/ModuleManager_1_6.dll

GameData/ModDistributingMM/ModuleManager_1_4.dll

Then version 1.4 will load every time because it has no competition and it's the last loaded. I thought I'd created an issue about this in case sarbian wasn't aware but apparently not

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.

Edited May 7, 2021 by Snark
Link to defunct website removed by moderator

[Sinsis]

jamespicone said:

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.

Hey, thanks for helping out No dice though, still getting errors:

"[Warning]: [EFX] [EFX] EvaOrderController: Object reference not set to an instance of an object"

I've added the log:

https://www.dropbox.com/s/z6952qerkqzmp5q/output_log.txt?dl=0

Cheers!

EDIT: I removed it from my gamedata and I am still getting the same error so your update might have fixed it and this might be something else entirely.

[jamespicone]

Hey, thanks for helping out No dice though, still getting errors:

"[Warning]: [EFX] [EFX] EvaOrderController: Object reference not set to an instance of an object"

I've added the log:

https://www.dropbox.com/s/z6952qerkqzmp5q/output_log.txt?dl=0

Cheers!

EDIT: I removed it from my gamedata and I am still getting the same error so your update might have fixed it and this might be something else entirely.

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?

[Sinsis]

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?

Not sure what "EFX" is actually, can't find a mod installed with that name but I'll look into it. Regarding Modulemanager, don't know really. I've only just started out with mods haha, so no idea how I would actually use ModuleManager like that

[Lechuza]

Is this working on 0.90?

[jamespicone]

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

[a__gun]

Is there a list of mods that use/support this?

[jamespicone]

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

[Dexter_D]

Hello,

are you aware of the ckan/netkan problem, that the BackgroundProcessing.dll is not recognized anymore after version 0.3.5 because it now has an included version-number? As far as I understand from the ckan-thread, we can only update this mod with ckan if you kindly would change back the name to BackgroundProcessing.dll and keep it that way in future versions. I know I could install it manually, no problem, but I won't mess up the ckan-install or rename the .dll by myself because that wouldn't be the solution.

Edited February 7, 2015 by Dexter_D

[jamespicone]

Hello,

are you aware of the ckan/netkan problem, that the BackgroundProcessing.dll is not recognized anymore after version 0.3.5 because it now has an included version-number? As far as I understand from the ckan-thread, we can only update this mod with ckan if you kindly would change back the name to BackgroundProcessing.dll and keep it that way in future versions. I know I could install it manually, no problem, but I won't mess up the ckan-install or rename the .dll by myself because that wouldn't be the solution.

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.

[Dexter_D]

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.

That would be nice, but no rush, I just wanted to let you know about this.

Have a nice weekend

EDIT: Updating via CKAN was successful today. That was quick, thank you.

Edited February 9, 2015 by Dexter_D

[mindstalker]

I discovered a bug in BackgroundProcessing. It will drain resources from locked tanks.

[Mulbin]

Does this work with 1.0 ?

[Mapoko]

Does this work with 1.0 ?

I am trying to use the one from 0.90, but is there a way to check and be sure on 100% ?

[jamespicone]

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.

Edited May 13, 2015 by jamespicone

[linuxgurugamer]

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.

I got a notice that you published 0.4.1.0 today.

does this fix the problems you describe in the previous post?

[jamespicone]

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.