[1.1.3] BackgroundProcessing

[FlowerChild]

When I came back to the craft though, it was facing in a random direction. It was pretty much at right angles to the Sun still (within a reasonable limit, since I was eyeballing the angle during warp), but it could be left, or right, or towards, or away. It's main axis was still in the ecliptic plane.

It's the ecliptic part that is rather worrying to me, as if you're off the ecliptic visiting a body with any significant orbital inclination (or say trying to intercept an asteroid), then you won't be aligning your solar panels to it.

If that means there's no way you can align your craft to keep tracking panels aligned, then it's potentially a rather large problem as it could mean ships dying off with nothing the player can really do about it. If not, it may be rather confusing, but shouldn't have all that much impact in practice.

Ships with fixed panels are a whole other story mind you. If you can't point them at the Sun and switch to another vessel for a shortish amount of time without knowing they'll be pointed vaguely in the same direction when you get back, or while they're being updated in the background, then that's also a rather large issue.

An additional question I have about this is whether the shift in orientation happens only when the vessel is made active again, or if it applies to the background updates as well. I'll likely setup some debug output to test that.

Edited February 13, 2015 by FlowerChild

[Renegrade]

It's the ecliptic part that is rather worrying to me, as if you're off the ecliptic visiting a body with any significant orbital inclination (or say trying to intercept an asteroid), then you won't be aligning your solar panels to it.

I'll have to test a heavily inclined orbit to see what happens; all of my tests were orbits in the ecliptic, and in solar orbit. Just to be clear: the direction was only random WITHIN the ecliptic - the test satellite I whipped up had tracking panels above and below (technically left and right, but I rolled it right ninety degrees.. I wonder if that has something to do with it?) and they were always in a good position to reorient themselves after jumping back in the craft - it's only the heading within the ecliptic that was wonky.

I did a new battery of tests just now, and here's the results:

- Staying WITH the craft through a full orbit didn't result in any wonkiness.

- Not reorienting the craft towards the sun didn't help either (it started pointing at the sun. ninety degrees later.. still pointing at the sun. ninety degrees later... the sun is on it's RIGHT somehow? ninety degrees later.. the sun is about 45 degrees ahead and left.. ???)

- A 45 degree test moved the sun in the wrong direction by 45 degrees >.<

- Warping with different planets as focuses in the Tracking Center didn't help

- Warping with the vessel as focus in TC didn't help either

- Jumping in and out with different camera angles didn't seem to affect anything (without warping)

However, my last test was to warp ahead short jumps - I noticed that the sun moves noticeably in only 6-12 hours when I'm in the TC during the warp (like upwards of 15 degrees), but if I stay on the ship, it barely changes it's navball heading at all in a similar span.

Could it be that the game IS properly tracking the motion, but that it's being multiplied wrong?

An additional question I have about this is whether the shift in orientation happens only when the vessel is made active again, or if it applies to the background updates as well. I'll likely setup some debug output to test that.

That's a good question. I'm currently testing pure, pure pure pure stock (it's my special install I use to isolate stock bugs from mod bugs). BTSM is the only place I'm testing BP at this time ; I didn't see anything die unexpectedly, except that one that had it's panels closed (user error, heh). They all had tracking panels though. All of the fixed-panel units had been landed for surface science and usually lost a good deal of their panels in the process (and didn't have enough energy storage to survive a local night anyhow).

[FlowerChild]

Could it be that the game IS properly tracking the motion, but that it's being multiplied wrong?

Yeah, or maybe a sign is getting flipped somewhere. The more you describe all this, the more I'm wondering if this might just be a bug in stock that no one has ever really noticed or complained about since it's largely irrelevant there. I'm taking some amusement out of this actually as I've always found it interesting to ponder how in our physical universe position is relative while rotation seems to be absolute, yet here in KSP, the reverse seems to be true

I'm not really in a good position to test right now as I still have the various bits of the resource processor code strewn about my garage and I'm trying to get those back together before moving onto this next part

[Renegrade]

Yeah, or maybe a sign is getting flipped somewhere.

I'm closing in on the 'sped up' theory as being the most likely suspect. It could also be backwards, when I was doing the 1-kerbal-day tests (6h increments; this install doesn't even have settings modified), I didn't note if the direction was the wrong way, but it clearly was moving a lot faster than it should.

In my next set of tests, I'll check the direction too. If it's massively sped up though, that would explain the "random" facing -> when I warp 90 degrees, it's more like "80-100 degrees" as I'm not using KAC or anything.. So if it's sped up by say a factor of 8 (using the A-P method for that multiplier), that would be a total turn of 640 to 1000 instead of 80 to 100... or a complete circle of randomyness.

The more you describe all this, the more I'm wondering if this might just be a bug in stock that no one has ever really noticed or complained about since it's largely irrelevant there.

Definitely 100% this. Even when I'm playing BTSM where energy and orientation really matters, I do NOT remember which direction my ship is facing when I leave it, other than "the panels are up and down relative to the ecliptic".

Oooh I wonder if the guys who did that mod that keeps ships rotating noticed? I should read through their thread.. and if all else fails, talk to the kOS people as Gaiiden suggested (I'm a bit afraid, I'm not sure I want to learn KSP's coordinate system. There's a non-zero chance that I might actually make my own RenSpaceProgram game from scratch, and I wouldn't want some terrifying coordinate system messing up my thought process )

I'm taking some amusement out of this actually as I've always found it interesting to ponder how in our physical universe position is relative while rotation seems to be absolute, yet here in KSP, the reverse seems to be true

Hehe! Good point

bring the kOS devs in on this - they'll be able to fill you in on just how whacky the reference frame is. You're right, is is pretty messed up from what I understand. There's a ton of helper functions in kOS so you can just point your ship the way you want without wanting to pull your hair out

This is a good suggestion, although I'm rather afraid of what KSP is using internally

[FlowerChild]

@jamespicone: Earlier today someone reported in the BTSM thread that if you toggled the flow state of resource containers off, that wasn't being respected during background processing. I just came up with the following modification for GetVesselData() within BP that changes things to take that into account:

                    foreach (ProtoPartResourceSnapshot r in p.resources) {
                        if (r.resourceName == null) {
                            Debug.LogWarning("BackgroundProcessing: Null resourceName.");
                            Debug.LogWarning("BackgroundProcessing: Resource values: " + r.resourceValues);
                            continue;
                        }

                        // FCMOD: Code added to check flow state of resource
                        bool bFlowState;

                        if ( bool.TryParse( r.resourceValues.GetValue("flowState"), out bFlowState ) )
                        {
                            if ( !bFlowState )
                            {
                                continue;
                            }
                        }
                        else
                        {
                             Debug.Log( "BackgroundProcessing: failed to read flow state" );
                        }
                        // END FCMOD

                        if (!ret.storage.ContainsKey(r.resourceName)) { ret.storage.Add(r.resourceName, new List<ProtoPartResourceSnapshot>()); }
                        ret.storage[r.resourceName].Add(r);
                    }

Modified code marked with comments, surrounding code listed for context. Feel free to do whatever you wish with that if it's helpful to you. Some limited testing indicates that it works well. I also tried accessing resourceRef within ProtoPartResourceSnapshot directly previous to that to get the flowState, but that was predictably set to null for background vessels.

I'll likely be shipping a slightly modified BP .dll with BTSM to take into the account the above, and also to disable orientation as a consideration on solar panels due to all the stock issues with it that we've been discussing over the past couple of pages, as well as suppressing some debug output about missing modules that tends to spam with Deadly Reentry installed as we previously discussed. I'll try to stick as closely to your version numbering scheme (including in the assembly) as possible to avoid messing with your versioning system in cases where a player might have multiple BP .dlls installed. I'll also of course be happy to share any changes I make where they might be beneficial to a non-BTSM specific audience and be including a copy of your license along with the download.

Edited February 14, 2015 by FlowerChild

[Drew Kerman]

This is a good suggestion, although I'm rather afraid of what KSP is using internally

This may be relevant

[Renegrade]

This may be relevant

I think that's mostly referring to live rotations; although Steven's comment about CelestialBody fills me with fear... :/

I just so happen to be playing around with kOS here and there, I might see what I can do about debugging this issue.

[Drew Kerman]

although Steven's comment about CelestialBody fills me with fear... :/

Yes that's what caught my eye

[jamespicone]

@jamespicone: Earlier today someone reported in the BTSM thread that if you toggled the flow state of resource containers off, that wasn't being respected during background processing. I just came up with the following modification for GetVesselData() within BP that changes things to take that into account:

                    foreach (ProtoPartResourceSnapshot r in p.resources) {
                        if (r.resourceName == null) {
                            Debug.LogWarning("BackgroundProcessing: Null resourceName.");
                            Debug.LogWarning("BackgroundProcessing: Resource values: " + r.resourceValues);
                            continue;
                        }

                        // FCMOD: Code added to check flow state of resource
                        bool bFlowState;

                        if ( bool.TryParse( r.resourceValues.GetValue("flowState"), out bFlowState ) )
                        {
                            if ( !bFlowState )
                            {
                                continue;
                            }
                        }
                        else
                        {
                             Debug.Log( "BackgroundProcessing: failed to read flow state" );
                        }
                        // END FCMOD

                        if (!ret.storage.ContainsKey(r.resourceName)) { ret.storage.Add(r.resourceName, new List<ProtoPartResourceSnapshot>()); }
                        ret.storage[r.resourceName].Add(r);
                    }

Modified code marked with comments, surrounding code listed for context. Feel free to do whatever you wish with that if it's helpful to you. Some limited testing indicates that it works well. I also tried accessing resourceRef within ProtoPartResourceSnapshot directly previous to that to get the flowState, but that was predictably set to null for background vessels.

Thanks for the catch and fix, I'll incorporate it in the next release.

I'll likely be shipping a slightly modified BP .dll with BTSM to take into the account the above, and also to disable orientation as a consideration on solar panels due to all the stock issues with it that we've been discussing over the past couple of pages, as well as suppressing some debug output about missing modules that tends to spam with Deadly Reentry installed as we previously discussed. I'll try to stick as closely to your version numbering scheme (including in the assembly) as possible to avoid messing with your versioning system in cases where a player might have multiple BP .dlls installed. I'll also of course be happy to share any changes I make where they might be beneficial to a non-BTSM specific audience and be including a copy of your license along with the download.

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.

[FlowerChild]

Honestly I'd prefer it if you didn't ship a modified DLL.

Oh, that's no problem man, and my apologies if that was out of line. Honestly, I'd prefer not doing that as well, and it was simply a matter of taking your license at face value and doing so for expediency given I had been working on BP support for a couple of weeks straight and was wanting to get this release out the door so I could move onto other things. My intent with that was to readopt the main branch if feasible in the future anyways.

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 your point there entirely, although I doubt it would be an issue for BTSM in particular given it's pretty much a total conversion that runs with a very limited subset of mods. Thus I think the chances that players will be mix and matching various versions in combination with other mods is relatively low.

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?

Yup, absolutely man, and that would be my personal preference as well. The logging verbosity certainly wasn't a big enough issue for me to branch off like that, it was more of a "well...since I'm here anyways I may as well" kinda thing.

I'm not sure what's up with the orientation stuff, I might have a look at that as well.

Yeah, I'm not sure either, but it was apparent from the previous discussion that it was an issue that would take a lot of effort to sort out, and I strongly suspect that it may boil down to a stock issue that we may or may not be able to do anything about anyways.

I opted to disable the orientation stuff on the solar panels, again for expediency and under the theory that I'd rather players not be punished for something that may be entirely out of their control. While I wasn't originally too keen on it due to potential performance drain, I actually became rather fond of the orientation tracking on panels as bringing extra considerations into play in terms of properly aligning your vessels for long term use, so I think my preference would be to keep it if possible.

[Prismatech]

hello nice and very good idee. whisches :

1: list with mod that use backprossing.

2: a mm config to implant self the backprossing in solar stock and mods

3: a mm config to implant self the backprossing scansat and karbonitescan (kethane when updatet too)

[jamespicone]

Oh, that's no problem man, and my apologies if that was out of line. Honestly, I'd prefer not doing that as well, and it was simply a matter of taking your license at face value and doing so for expediency given I had been working on BP support for a couple of weeks straight and was wanting to get this release out the door so I could move onto other things. My intent with that was to readopt the main branch if feasible in the future anyways.

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.

Yup, absolutely man, and that would be my personal preference as well. The logging verbosity certainly wasn't a big enough issue for me to branch off like that, it was more of a "well...since I'm here anyways I may as well" kinda thing.

That'll be the next step then.

[Renegrade]

Yeah, I'm not sure either, but it was apparent from the previous discussion that it was an issue that would take a lot of effort to sort out, and I strongly suspect that it may boil down to a stock issue that we may or may not be able to do anything about anyways.

Well, my testing was done in a completely stock environment, so it's gotta be a stock problem. Not BP, and not BTSM.

[FlowerChild]

Well, my testing was done in a completely stock environment, so it's gotta be a stock problem. Not BP, and not BTSM.

Hence my strong suspicion

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.

Well, I'm sure it's something we could work out even if it's just through a version numbering scheme that say reserves the minor number for spin-off versions or what have you, but if we don't have to do that, all the better, and I'd prefer avoiding having to manually integrate changes to the main branch into my own anyways

Edited February 16, 2015 by FlowerChild

[FlowerChild]

@jamespicone: Just wanted to verify man, given there's already a version of BP I compiled and released out into the wild before we discussed this whole thing, would you object if I were to release another version(or potentially multiple versions depending on timing) of BTSM that contains that exact same version of BP as I included in my previous release?

I'm gearing up for another release of BTSM, and just wanted to run it by you if that would be cool. As far as any potential damage goes, I don't think this would exasperate the problem given that version of BP is already out there and uses the same version numbering as your last official release, meaning that your next one will automatically override it if both are present.

Let me know if it's an issue, and if so I'll hold back on further releases of BTSM until the next version of BP is ready to go. I didn't want to put anything out without running it by you first, as I didn't want to risk it being perceived as me disrespecting your expressed wishes about it.

Edited February 18, 2015 by FlowerChild

[jamespicone]

@jamespicone: Just wanted to verify man, given there's already a version of BP I compiled and released out into the wild before we discussed this whole thing, would you object if I were to release another version(or potentially multiple versions depending on timing) of BTSM that contains that exact same version of BP as I included in my previous release?

I'm gearing up for another release of BTSM, and just wanted to run it by you if that would be cool. As far as any potential damage goes, I don't think this would exasperate the problem given that version of BP is already out there and uses the same version numbering as your last official release, meaning that your next one will automatically override it if both are present.

Let me know if it's an issue, and if so I'll hold back on further releases of BTSM until the next version of BP is ready to go. I didn't want to put anything out without running it by you first, as I didn't want to risk it being perceived as me disrespecting your expressed wishes about it.

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

[FlowerChild]

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

Awesome! Thanks a lot man

[Yemo]

Hey,

that is a great plugin! Very useful for the energy production part of the gameplay!

I m working on an energy consuming part, for which I want to set 2 consumption levels.

One normal energy consumption level, if people have your plugin installed.

And one mini energy consumption level, if people do not have your plugin installed.

To check for the installation of you plugin per MM statements, your plugin has to be inside of a sub folder of GameData (as far as I know).

So eg GameData/BackgroundProcessing/BackgroundProcessing.dll.

So it would be great if you could change the structure of you download file, to have BackgroundProcessing.dll inside a folder called BackgroundProcessing.

Thank you very much!

[Crzyrndm]

You can also do needs for any plugin Yemo, no matter where it's located (eg. there's always a Module Manager pass.)

If it detects a loaded DLL, it assumes it's a mod and creates a :BEFORE, :FOR and :AFTER pass for it.

Edited March 23, 2015 by Crzyrndm

[Yemo]

You can also do needs for any plugin Yemo, no matter where it's located (eg. there's always a Module Manager pass)

Thank you for that info, though the problem with BackgroundProcessing is, that the .dll name contains a version number, thus it changes every update (until KSP-AVC is used instead).

[Crzyrndm]

Using periods (mostly) which dont get used.

IIRC, the needs for the current download would be one of the following

BackgroundProcessing
BackgroundProcessing-0

So it will atleast be stable until a major version change

[Yemo]

Using periods (mostly) which dont get used.

IIRC, the needs for the current download would be one of the following

BackgroundProcessing
BackgroundProcessing-0

So it will atleast be stable until a major version change

Thank you very much, I will try that out!

If the first version works, the MM statement might not even need a reconfiguration, when BackgroundProcessing gets it's own folder!

[Squiggsy]

This looks like a brilliant mod and exactly what I'm looking for for a few parts that I am currently developing for a mod, basically I just want a few generators to consume a custom resource while not being focused on, I have 0 experience with plugin coding, I am starting to look at some C# tutorials but i was wondering if anyone could point me in the direction of some good ksp specifics, or unity specifics, or tell me roughly what is required for me to go about achieving this because I'm pretty clueless at present! thanks!

[Mecripp]

This looks like a brilliant mod and exactly what I'm looking for for a few parts that I am currently developing for a mod, basically I just want a few generators to consume a custom resource while not being focused on, I have 0 experience with plugin coding, I am starting to look at some C# tutorials but i was wondering if anyone could point me in the direction of some good ksp specifics, or unity specifics, or tell me roughly what is required for me to go about achieving this because I'm pretty clueless at present! thanks!

Have you looked here http://forum.kerbalspaceprogram.com/threads/94638-Mod-Development-Links-Compilation-START-HERE

[Squiggsy]

Have you looked here http://forum.kerbalspaceprogram.com/threads/94638-Mod-Development-Links-Compilation-START-HERE

yup that was where I started, I found it amazingly useful for information about modelling/texturing/part development but not so much for the code side of things, I have now found a video tutorial that seems pretty good so hopefully I can get started and learn enough to get this done

edit: nope that tutorial was very out of date and didn't cover what I need anyway, ahh well.

Edited April 20, 2015 by Squiggsy