[1.1.3] BackgroundProcessing

[ShotgunNinja]

29 minutes ago, JPLRepo said:

pretty sure we fixed that...

Indeed. Maybe it is possible that he's not using the sun_dir / sun_dist returned from the raytracing functions for the solar panel calculations. Another option may be that the workaround stopped working in 1.1.3, or even that it work 'most of the time'. As this GetWorldPos3D() business is fundamentally a SQUAD bug, I'm creating a test case and submitting a bug report to the SQUAD tracker, lets hope they fix it for 1.2...

[garwel]

On 8/27/2016 at 11:42 PM, Bombaatu said:

There's an issue that I've isolated to this mod; if you have it installed & leave the Kerbin SOI, then when you switch vessels the NaN Kraken strikes. The only way I was able to resolve this was to uninstall BP & reload a save prior to leaving KSOI. Some comments in the linked thread indicates a vessel's mass is being set to zero which causes divide-by-zero errors, if that helps.

 

I confirm this.

[jamespicone]

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'.

[JPLRepo]

5 hours ago, jamespicone said:

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'.

I'm pretty sure I know exactly where it's occurring. I'll do a test today and get back to you.

[Djohaal]

So I went in the chase for my NaN error and it seems to be the background processing issue. I tested with both 0.4.4.0 versions (from spacedock and JPLR's git with no sucess). Any news on a fix? I'm managing to re-create the bug consistently, so I can provide logs.

[JPLRepo]

30 minutes ago, Djohaal said:

So I went in the chase for my NaN error and it seems to be the background processing issue. I tested with both 0.4.4.0 versions (from spacedock and JPLR's git with no sucess). Any news on a fix? I'm managing to re-create the bug consistently, so I can provide logs.

It is a known bug. A fix is known. but we are waiting for @jamespicone to return to the scene.

[jamespicone]

On Saturday, 17 September 2016 at 0:07 PM, JPLRepo said:

It is a known bug. A fix is known. but we are waiting for @jamespicone to return to the scene.

There's a known fix?

[ElGazo]

Hi. Wery cool plugin! However don't working with Kethane. :(((   How fix it?

Sorry for my bad English.

Edited September 23, 2016 by ElGazo

[Jiraiyah]

sigh i hope james come back to scene soon and this mod gets some love for 1.2 :/

[jamespicone]

2 minutes ago, Jiraiyah said:

sigh i hope james come back to scene soon and this mod gets some love for 1.2 :/

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

[Jiraiyah]

hmm well, considering that your mod is one of those that tweak basic functionality, it was expected, just knowing that you will work on an update is more than enough for my thirst to sit and wait with tongue out of mouth and watery mouth sir

[jamespicone]

1 minute ago, Jiraiyah said:

hmm well, considering that your mod is one of those that tweak basic functionality, it was expected, just knowing that you will work on an update is more than enough for my thirst to sit and wait with tongue out of mouth and watery mouth sir

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)

[Jiraiyah]

3 minutes ago, jamespicone said:

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)

don't be afraid of reflection, i can say, it's faster than many people think it is, specially if you make it work properly, like cache the assembly and member info in private variables and just use them in update so that getting to them won't happen in every update

[JPLRepo]

No reflection is required. The EULA prohibits reflecting non public properties, etc anyway. You do not need to access the config node any more. There's an easier way. There are also easier ways to get to resources etc as well.

[msnbcorp]

Plz, i'm here to bargain you to create a 1.2 version of your mod.

Your mods is clearly one of those that complete several missment to the stock game. Without it and without any other mods that do the same thing it would be a severe missing of a core fonctionnality of majors mods ... :sad:

[jamespicone]

15 hours ago, msnbcorp said:

Plz, i'm here to bargain you to create a 1.2 version of your mod.

Your mods is clearly one of those that complete several missment to the stock game. Without it and without any other mods that do the same thing it would be a severe missing of a core fonctionnality of majors mods ... :sad:

Waiting on some API info from some people in Squad

[msnbcorp]

Ok

[Jiraiyah]

@jamespicone

Hi sir, no news i guess from squad part? Damn this mod is a must have for heavily modded ksp playing :/

Edited November 28, 2016 by Jiraiyah

[Guest]

Hi all.

After some investigation in the source I have noticed that there is a function defined in solarPanel.cs to get the vessel position but not used.

		public static Vector3d VesselPosition(Vessel vessel) 

There are two functions in this file using GetWorldPos3D() instead of this function:

public static bool RaytraceBody(Vessel vessel, CelestialBody body, out Vector3d dir, out double dist) 

public override HashSet<ProtoPartResourceSnapshot> HandleResource(Vessel v, VesselData data, HashSet<ProtoPartResourceSnapshot> modified) {

 

If you change them to use the defined function then the calculations are done using getPositionAtUT and the problem disappears. At least for me. I have it working in 1.2.1 heavy modded career.

 

 

Edited December 2, 2016 by Guest

[Ketatrypt]

On 12/2/2016 at 5:47 AM, bice said:

Hi all.

After some investigation in the source I have noticed that there is a function defined in solarPanel.cs to get the vessel position but not used.

		public static Vector3d VesselPosition(Vessel vessel) 

There are two functions in this file using GetWorldPos3D() instead of this function:

public static bool RaytraceBody(Vessel vessel, CelestialBody body, out Vector3d dir, out double dist) 

public override HashSet<ProtoPartResourceSnapshot> HandleResource(Vessel v, VesselData data, HashSet<ProtoPartResourceSnapshot> modified) {

 

If you change them to use the defined function then the calculations are done using getPositionAtUT and the problem disappears. At least for me. I have it working in 1.2.1 heavy modded career.

 

 

 

 

Is this the fix for leaving the SOI? (specifically for 1.1.3)

 

Would you be able to upload the compiled fixed version? I really love the mod but the SOI bug is killer

 

Thanks

Edited April 12, 2017 by Ketatrypt

[buttercookie42]

Good news: I've managed to recompile this for 1.2.2 myself and am just in the process of making sure this not only compiles, but actually works as well. So far I've found one issue with the OX-STAT panel, where for some reason (a genuine stock data bug?) no transform matching the raycastTransformName is existing. Falling back to the pivotName in that case seems to work, though.

Other than that, I just want to verify the SOI NaN-issue myself and then hopefully this should be good to go.

[N3N]

Hey,

Nice mod!

 

Which 1.2.2 compatible mods do use this or used it in older releases?

It would be nice, if the "Planetary Logistics" in MKS and USI-LS would use this.

 

And will the 1.2.2 compatible version be available on CKAN, too?

 

 

 

Sorry for my english, but it's only my third language.

[buttercookie42]

On 3.5.2017 at 0:04 AM, buttercookie42 said:

So far I've found one issue with the OX-STAT panel, [...] (a genuine stock data bug?)

On closer investigation, no. It seems that the raycastTransformName has simply been superseded by the secondaryTransformName. Regarding the NaN issues, I've also read through the history of this thread and it looks indeed like the helper function suggested here was added to the code, but never properly hooked up. I hope it's working properly now - I've given it a quick test and didn't see anything out of the ordinary.

In any case, for the time being the source is here and the compiled DLL here (Edit: Now available on Spacedock). As for CKAN, I'll wait a while for @jamespicone first...

Edited May 4, 2017 by buttercookie42
new version now officially released

[N3N]

17 hours ago, buttercookie42 said:

In any case, for the time being the source is here and the compiled DLL here. As for CKAN, I'll wait a while for @jamespicone first...

Hey buttercookie42,

Great work!

Thank you!

 

 

Is there somewhere a list with compatible mods?

[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.