JPLRepo

What mod is this part from? and what is it called? Sounds like AmpYear shut it down - which it should - but it never got restarted, which could be a bug, but I would probably need to do my own testing (once I know what part it is from what mod). Also, it sounds like you should exclude it from ESP processing in the future if you don't want it shutdown by ESP.

Not sure what happened with your timewarp. Are you able to reliably reproduce that problem? and the steps to reproduce it? There was a time EC consumption during timewarp was bugged. Not sure this has recently been fixed or not, so it could be related, or not. I don't understand this... what reactor? is this stock? or a mod? and what percent usage are you referring to? Are you talking about an AmpYear setting? Because ESP functions as per the OP. It shuts down and starts up parts, that's all. I think you are asking for a new feature to be added? To alter the function of a vessel part, for a part that I am not sure is even stock?

Agree. Not only that, but I've picked up on some very distasteful re-distribution sites that have been picking up modders work, re-hosting and re-distributing them, unchanged, without asking or without permission and attempting to profit from modders free work by hosting and distributing them on click farms. Another reason I have been considering how to modify my unrestricted licenses to somehow restrict exactly this. - This may be a little off topic. So I'll stop there.

and therein lies the problem. I do not want to, and in some cases, cannot change licenses to be restrictive (even though i want to ), for this exact reason.

Here-in lies the issue and why "some" mod authors don't support CKAN (including myself). I have no idea what CKAN is pushing to your computer.

Yeah ok everyone. I found the docking ports problem. They are bugged out... I have a fix. Just seeing if I can do anything about the ScienceLab as well first before I put out a fix release.

Hmm. I'll test it out when I get a chance. Probably later in the week. Very busy this week with real work. In the meantime curious to know if others are also having issues

Yes it should be and it doesn't matter what docking port you use they are all the same and should connect same as the stock docking port. Is this in craft construction or actual flight docking? Is anyone else having problems with the docking ports?

@Greythorn032 hmmm.it didn't do that when I tested it, but it doesn't surprise me as landing legs are bugged in 1.1.2. I can only suggest don't extend them and you should be ok. Hopefully 1.1.3 might give us more leg fixes. Otherwise I'll put it on my list and maybe disable them for now until there is a fix

Yes but unless @RoverDude changed his model to have two depth mask meshes it will only use the one in the config file. Which may just be an open top mesh. Her can create a second mesh with the depth mask for just the windows and change the config. The wiki has all the info and examples. and yes, I made that other mod happen. As for the frame issue unless the creator spent time creating a mesh to match you may get different results

I'm assuming you just added the partmodule to the part yourself? Unless @RoverDude has made the necessary changes to his parts model to support this mod's requirements it will appear the same as it would when you toggle the stock overlay mode on. The same goes for any mod's part models and stock part models. This mod does not automagically create meshes for parts. The requirements must be met as outlined in the wiki page for this mod (link in the OP).

On the first question.. I think you are talking about Method overloading. http://www.dotnetperls.com/overload On the second question, depends on what FixedUpdate is doing. I'm not sure I am following what you are asking. Should you split your FixedUpdate processing across the extension classes? or keep it all in the one class?

Rename your part config files from *.txt to *.cfg and it works. 'Cept your green one is black.. Looks like you put the black texture in the green folder.

Hey @jamespicone, great to see you back. Do you plan to update your code (I know you use bitbucket and my fork is on github) and update spackdock, etc? Cheers.

Yes. two posts up. Sarbian's debugstuff mod. It's great.

From the OP: If you are looking for the ION RCS parts that used to be part of this mod go here. With that said, just add your own MM file:

Agree... I use three. All good.

Did a proof of concept on some texture details/occlusion and grayscale settings in flight today. Thanks to @DMagic for some starter code he had already written. Some good results, and still a lot of work to do... Need to figure out how to turn off EVE clouds, Scatterer effects. (I also noticed some strange effect with the water when returning to the space center that I have to figure out). But this gives you an idea of what I am thinking of doing. I'll do some more with say Laythe and other planets a bit later and add to the album. More examples added to album. UPDATE: Got it working in the tracking station and hooked up to ResearchBodies. So most of the ground work is now done. Just have to deal with the EVE clouds and tweaks around the details/grayness for some of th bodies (especially those with water).

Probably just refer it to 8998 since it's already assigned to Mu. "I'm a coder" - So am I. I'm pretty sure I had a bunch of RPM props that had this behaviour when I was fixing my Endurance IVAs for 1.1. I'll go back and get a list.

I just read the Opening Thread. I wish I had time to play KSP. Most of my time is spent modding. I haven't even played 1.1+ yet except for testing and fixing my mods. Let's see what happens with this mod first. I'm not so keen to take on yet another mod in my ever growing empire of mods. I'd rather jamespicone came back. But if he doesn't I will maintain this mod. Adding to it, while I would love to, would take a very back seat.

Whilst they are both using the stock solar panel module to process a resource. They both do not process that resource when the vessel is not loaded. so in theory it means that yes - Dust is processed and calculated the same way as EC from the looks of things. But that one line is a very big difference. The problem here is Dust is not a stock resource. I don't understand how that mod works, it says in its OP that dust generation requires EC to capture dust. Not sure how they are doing that using ModuleDeployableSolarPanel as it only generates a resource. Anyway, best bet is to take it up with them to see if they will develop the change to integrate to BackgroundProcessing.

Yeah that issue with the props location is a bug (assigned to the mighty Mu, and hopefully will be fixed one day) http://bugs.kerbalspaceprogram.com/issues/8998 As for them completely disappearing haven't seen that... @TiktaalikDreaming are you sure it's not just offset like mentioned in the bug report? What you will initially see is just a transform if you are zoomed in to far. Zoom out and you will find your prop offset. The work-around is to make sure you set your prop main transform location to 0,0,0 before you write it out to a mu file. When you spawn it back into Unity it will be aligned to it's transform. @MOARdV I believe if all the RPM props were reset in Unity to 0,0,0 and their mu's re-created that would fix the offset issue hen they are spawned back into Unity for now

Hi. So a few things here... First Yes - this mod could be changed to process every known and unknown resource under the Kerbin Sun. I said could but I believe that is not it's intention. It's intention is to provide background Electric Charge generation (as the stock game doesn't do this), and mod authors are intended to pick it up and integrate to it to process OTHER resources. Read the Opening Post again. I believe the intention here is to keep this mod simple. Other mods can make use of this mod to process resources but it requires them to make changes to allow this mod to handle it. To do what you asked then this mod would need to first understand this resource called "Dust" - which it doesn't, and has no definition for, given it's not part of the stock resources. The code changes required are a lot more than just adding a list of resources.. Adding a list of resources is the first step, and it's complicated further if the resource you are talking about is not stock. It would then have to have all the calculations and processing to handle this resource, so more code. Once you have done it for one resource, the list grows and grows. That is not the intention here. What is intended is the mod you refer to that has "Dust" already defined, and already knows how to calculate it, etc. Makes a couple of easy changes to define a method for background processing of "Dust" and this mod will automatically detect it if it's installed and has these methods and process it. The right answer here is you contact the mod author of your "Dust" collector and ask if they could integrate to this mod (it's two simple methods) and then it will get backgroundprocessing of "Dust".

Published V0.1.1.0. few minor changes. Will look to add emissives and better smoke effects in the next version.

Read the OP: Whilst I agree CKAN is a great mod for those that can't use Zip tools. I take no part, nor am I interested in maintaining the CKAN mod metadata for my mods. Please don't ask me about it but refer to the CKAN mod thread if you are having issues with CKAN or the metadata it maintains.