Akira_R

Ah ok, I havn't used KK before because of the issues with rescaling, and I never could bring myself to take the time to dig in and figure out KKtoSD... Now that you have gone ahead and done it I may have to take a look and see what it's all about ;p Thank you sir o7 your contributions to the community are greatly appreciated!

What has changed with the most recent SigmaD that requires changing in the configs? The change-log for SigmaD on git doesn't have anything that immediately jumps out at me. I ask because I usually make my own rescale cfg and I just started building my 1.3 install a few days ago and SigmaD was the last major thing I was waiting on.

Thank you sir/madam, your ongoing work for the community is greatly appreciated!!

@Sigma88 In case you weren't aware it seams the latest Kopernicus update broke SigmaDimensions, do you need logs and such?

The new release makes me moist *Gasp* you said the forbidden words..... "MK4 spacplanes" eeep..

This is so cool, gonna get me a swizzle stick sticker

OOOOooooooooo.... Watching this space intently

I would love to see some procedural adapter parts, or have procedural adapters integrated with the proc tanks instead of the current ones!!!

D'oH!! I totally forgot about that, I have even used it numerous times lol. I blame my month long camping/road trip for the memory lapse.

Gotcha that is what I was wondering and that makes sense, thank you.

Not just modded parts, modded parts that use a whole new custom collider that is added to the game by the mod KSPWheel

This is soo cooooool!!! I don't know what I am going to use it for but it's definitely going in my install. probably help with all kinds of design issues that result in wonky explosions and Kraken summoning dances. @DefiantZombie I am assuming this will handle any Unity collider? Even custom ones like the ones @Shadowmage KSPWheel mod adds?

Neeto!! So on the UI the distances are from the sensor?

Hey @Jimbodiah I made a patch integrating Station Science into SSTU parts (also does one BDB part at the moment) that you are welcome to include on here if you so desire, link can be found in my sig and in the linked post. EDIT: I just got back from a month long camping trip and forgot that a new KSP version and SSTU versions are out, patch was made on latest 1.2.2 build, so as long as no part naming conventions were changed it should still work fine

lol indeed, I love KK and KSC++ is so awesome, but between issues with rescales and such I have never actually used it in a real play through. The only one of my installs (I am currently running 3 separate installs, not counting the old versions that I haven't played in awhile lol) that has it is a stock size Kerbin system that I use for faffing about with BDArmory and making cool planes.

I have zero problems playing with KSC switcher and SD on a 3.2x rescale.

Just an FYI if you install KSC switcher while in the middle of a career game and you are using KCT your save will get pretty borked, it can be fixed by doing some manual save file editing but if you don't really know what you are doing and aren't careful you will bork it up even more. If you start a new save though KSC switcher and KCT work just fine together.

Nice! I really wish the forum supported sub threads, would be nice to have one for this kind of thing, maybe someone could start a thread that shadowmage could link in the OP?

I'm sure it's on the ToDO list but some more specifics as to how this works in the OP would be nice. I have used interstellar before but that was back in the .24 days and i never actually got to the warp drives so I'm not really sure how it behaves. Some things that would be nice are: What do all the various stats in your UI mean/do? What changes those stats and what kind of effects do changes have on the behavior of the drive? How do we generate EM? Is there a "bubble" like the USI warp drive that will destroy parts outside of it if the drive is activated? If so can we overlap the bubbles with multiple drives to allow for larger ships? This looks really cool and I definitely like the fact you can time warp with it, that always drove me a little nuts with the USI warp drive. Thank you!!

Wow this looks awesome! Yet another mod that I suspect will become part of my "stock" ksp build. Thank you!!

I don't really understand exactly what the problem you are having is.... BUT I can tell you that if you want your fairings shells to jettison you have to use the "payload" fairings. If you use the other fairings (I think they are called structural fairings) they do not have a decoupler and will not jettison, they are meant to create permanent hollow shells. I usually set up an action group that jettisons the shells and decouples the top node and I have never had any issues with the interstage fairing part. Also in regards to your earlier questions regarding dV readouts if whatever tool you are using there behaves anything like KER then anything that has to be decoupled manually will do that, basically if staging doesn't detach the parts then your dV utility won't know that those parts will be detached and it will calculate your dV as if those parts are still attached. I know that I have this issue with the SSTU interstage decouplers since they use a custom decouple module that jettisons the bottom node and then a few seconds after the ullage motors burn out it jettisons the top node. @yobeeb That is not the correct way to do that. what you want is multi adapter attached to upper fuel tank, engines attached to that, then the interstage adapter attached to the middle attach node on the multi adapter, and then the big orange tank attached to that. You may need to use the offset tool to get the adapter and everything sunk down into the fairing but it should work just fine.

WOW..... These look absolutely amazing.... I'm going to have to come up with some head canon as to why all of our stations need to be scraped so I can install the update. Maybe something about faulty coatings on the modules not protecting the metal from degradation due to ionizing radiation resulting in potential structural weakness that could lead to catastrophic rapid decompression, that sounds good.

@Tau137Just a wild theory here. So while the GPU doe the main work of rendering what you see, the CPU still has to tell the GPU what to render and how, from my limited understanding these are draw calls and they can be very CPU intensive and usually make up a fair chunk of the CPU load in a game. My theory is that the added graphical mods increase the number of draw calls, now I know that for a single object if it is affected by multiple lights it will have multiple draw calls for that single object (4 lights 1 object 4 separate draw calls). Based on how KSP handles things I suspect that each part is essentially an object and that maybe the graphical mods are not just increasing the number of draw calls but increasing the number of draw calls per part which from my understanding will have a huge impact on performance. Another possible scenario is that with a high part count ship the CPU is already being taxed and the added draw calls from the graphical mods results in a loss of performance, but when you have a low part count ship the CPU is under far less strain and so the added draw calls have little effect on the performance. Just spit-balling some ideas here based on my limited understanding of how these things work and applying a little bit of logic. If I am making some wrong assumptions here or if my logic is flawed I would love to here some feedback as to how and why. I am at work right now so i can't give you any performance numbers for my set up but I will see what I can do when I get home

I'm pretty sure the aggressive version also down-scaled most of the texture files as well, doesn't change the fact that with nearly identical mod setups I will crash out with full RAM in post 1.0 but pre 1.0 with ATM it loaded and ran fine (fine here being relative lol) @Norcalplanner, this actually wasn't with GPP, I'm not really sure how KSP manages VRAM currently. In the past if you forced OpenGL or DX11 it was supposed to reduce your system RAM usage because they would properly fill up the VRAM first and then start using system RAM while DX9 wasn't doing this properly, at least that was my understanding from reading other people talking about it, I don't actually know if that is accurate or not. I do know that in old pre 1.0 versions using OpenGL did reduce my RAM usage on my laptop even though it doesn't have a discrete GPU so no VRAM sooooo....?

It's at times like this (when I'm playing on my laptop not my super computer) that I miss the good old days with Active Texture Management, a (nearly) identical mod load out from pre 1.x would run ok on my laptop but will use up all of the available ram and crash out in 1.2