thunder175

RemoteTech compatible? Or does this impact RT in any way? In other words, if I have RT installed and go into low power mode, will I be able to reactivate with a WAKE UP command or will RT cause a loss of contact with the probe?

@Sigma88 Do you have the pre-release 1.1? Just curious to see if current version of Sigma Dimensions is already 1.1 compatible and/or what the upgrade path will be to get us to 1.1 compliance? Obviously if its going to be a while that means I'll be on 1.0.5 for a while since I don't want to break saves.

Good discussion. A few of you posted things I didn't even consider. My original intent was not to delete parts, but rather label parts to be hidden in the VAB/SPH parts bins. I don't play stock anymore, and with all the parts packs out there the bins get really cluttered especially with mid-tier parts that probably won't be 'in production' any more at the later levels. In other words, I was thinking of a way for Squad to give us a way to hide parts without the need for additional mods or workarounds. I'd never find the parts I need without QuickSearch most of the time, especially in the Misc bin. Hence the post. A few of you mentioned part upgrade. That is a great idea and beyond the scope of my original post. I think that is something that mod creators would be able to take advantage of more than the stock game (where every part seems to have its place). For example, in RLA you get the upgraded probe cores (gold foil versions) which could be scripted to replace the older probe cores in your new builds. I do concede however this would be difficult to implement given the current architecture. Again, thanks for the replies and feedback.

Does the retractable = false setting in the part config file not work for an antenna? I know there were some solar panel mods that were retractable (that should not have been), and I added the above statement after looking at the stock solar panel configs. After that they didn't give me an option to retract once extended.

I was hoping for a much more elegant solution than manually delete or moving files via the operating system...

Pardon me if this has already been suggested or implemented via a mod, but it would be great if there a way to make parts obsolete and remove them from the VAB/SPH. My issue is that in later stages of the tech tree, the parts bins become extremely cluttered with parts from various tech tiers.The problem is compounded by adding all the wonderful parts packs and mods done by the community. Its tedious to constantly scroll thru and pick the only couple I use at any given phase of the game. Some will never get used again. So my suggestion is a way to label parts as obsolete and have them removed from the VAB/SPH parts bins either by user action or via scripting in the parts config. I can envision right clicking on a part in the parts bin on the left part of the interface and labeling the part as obsolete thereby removing from the display. Alternatively this could be done in the R&D building by labeling entire nodes or individual parts as obsolete in the same manner. Obviously this would require an an additional "unhide" button in the user interface. Second, scripting could be used to label parts obsolete. For example how many people still use the Mk1 capsule when they've achieved large craft? If the American space history is a guide, when you get the larger capsules the Mk1 (and equivalent parts) would be heading off to the Kerbal Smithsonian. A way to do this could be if there is script to say basically IF this part available THEN label part X as obsolete (hide). Thanks for your time and consideration!

Thanks! I saw your post in the TK thread. Doesn't look like the author has been on here in six months so who knows. Might be abandonware. I will check out your change to the configs when I get home later and report back. But this is definitely good since you can build a compatible planet pack section to your first post. Do you recommend any other ones that are more current and compliant with SD rescales? I liked TK since it adds more dwarfs waaaaaaay out there. I'm already running your Pluron/Khato set (which is great), although I tweaked the config file to push it out a little further than OPM's Plock since their SMA's looked close. Although now Transfer Window Planner says Kerbin->Pluron will take 177 years at 6.4x rescale... ugh. Gravity assist here I come!!

I almost spit my coffee on my work computer yesterday when I stumbled upon this thread. Been looking for something along these lines that was in active development for a while now. Well done sir! Love the mod! Please keep up the excellent work as I can't wait to get the rest of the probe parts. I was wondering though what the point of the AACS was? Its just a SAS module no? The probe cores already have SAS so it seems redundant, unless I am not seeing something (which is probably the case). I was thinking of adding built in MJ and KER support to the AACS part config to give it more use cases in my game.

@Sigma88 Can you help with this small problem? I tried installing Trans-Keptunian planet pack along with OPM in a Sigma Dimensions rescaled game. The OPM planets were fine and rescaled appropriately, however the Trans-Keptunian did not and remained in 1x scale. I know its a conflict between patches somewhere, but I don't know MM well enough to start making changes.

I don't know if that is possible, hence why I decided on 24 hour vs 6. My OCD would go nuts if I set it to 12 hour days using only a 2x multiplier but the game would count every 6 as a day by default. Mostly because of the above reason. I also just felt that a planet resized that much was spinning a little too fast. Didn't feel the rest of the planets needed changing since a general 4x multiplier on all would make them all spin extremely slow.

I got a wonderful rescale going yesterday that I've been hoping to do all week using the dev version of Dimensions. I emulated Nolnoc's 365 mod using the below settings. I also changed the landscape multiplier from 1 to 0.4. // Base Settings SigmaDimensions { Resize = 3.2 Rescale = 6.4 Atmosphere = 1.2857 dayLengthMultiplier = 1 } Also used a separate config file to spin down Kerbin's rotation to 24 hours: @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Kerbin]] { @PlanetDimensions[3] = 4 } } Everything working fine it would appear with EVE and scatterer on the Linux version of KSP. I may throw SMURFF back into the mix since 3.2x resize is still a little much for stock parts in career mode, but run the multipliers at 0.25 instead of 0.5 as recommended for a pure 64K rescale. Why did I choose 3.2x? I dunno. Just seems different and I don't have access to pre-made delta-v maps. So it literally is trial and error for me. Thanks again Sigma for the wonderful mod and keep up the great work!!

Thanks for the input. I'm traveling on business at the moment but will try 6.4x again when I get home later in the week. Since Im really trying for a solid career mode experience, I was more interested in trying to emulate Nolnoc's 365 mod, which should be a 3.2x resize and a 6.4x rescale. Should make career mode more possible without SMURFF or exotic engine packs. Think I was also going to keep the atmosphere rescale at 1.2857 (the 7 to round closer to an even 90km on Kerbin) as recommended in the 6.4x guide in this thread. Or is that too high given a 1920km vs 3840km Kerbin size? Glad to see the work on SCANSat and RemoteTech configs. Kinda a deal breaker for me without them.

I just wanted to take a moment to thank the author. I've been using your mod recently and it's pretty much replacing all other part packs given its utility, breadth, and completeness. I recently discovered the ability to make 1.875m tanks and fairings using your mod, as well as other various diameters. This is such a welcome addition to the design arsenal. Thanks so much and please keep up the excellent work. I'm greatly looking forward to your additional work.

I got done playing with a Dimensions 6.4x rescaled career using the recommended settings in the first post, as well as SMURFF set at 0.5. FAR is also installed. Started at lower tech levels with several addons, but was mostly building with the excellent SSTU pack and included engines. The delta v requirements described in the original posting seem off, or I'm not doing something right. The recommended 6500-7000m/s requirement was not cutting it to achieve orbit. I went back and pulled up the 64K delta v map which says 7500m/s to LKO. That seemed a little better but it wasn't leaving me much beyond that. Maybe I didn't give the upper stage enough horsepower, as I was blowing past Ap. MJ and Gravity Turn ascent guidance doesn't seem to like what I'm doing here either. Both were coming in way shallow leading to atmospheric overheats (RealHeat installed) despite changing the turn angle to both high and low settings. Played with first stage TWR settings of ~1.2 to close to ~1.5. For career play, I still don't see how at lower tiers you can achieve orbit with the increased delta v requirements with SMURFF at 0.5 utilizing 1.25m rockets., without the use of parts packs. Fortunately SSTU easily allows increasing diameters of its parts, and 1.875m is now easy to do and looks smooth. I know I'm doing something wrong still, or I'm just stuck in stock scale mentality. Would love to see everyone else's tweaks and settings, as well as any recommendations.

Thanks for the reply. I knew I was missing something. I will try Smurff first as recomended. The added complexity of Real Fuels is something I'll take a look at later.

For those using larger sized systems (such as the aforementioned 6.4x refactor) while playing in career mode, what parts packs or other mods are you using at lower tech levels in order to achieve decent suborbital and orbital flights? Reading history on the forums, I think this was the rationale for Nolnoc's 365 mod (3.2x planet scale, 6.4x interplanetary distance) since it is exceedingly difficult at true 6.4x scaling in career mode at lower tech tiers to achieve enough delta v.

Just ordered a new setup this past week. I'll be decommissioning an AMD 1090T Thuban based system w/ 16GB of RAM on an MSI 890FXA-GD70 mobo in the coming week or two, and upgrading to an i7 5820k, 16GB DDR4, on an MSI X99A MPower mobo along with an M.2 Samsung 950 Pro 256GB SSD. I will be keeping my Crossfire'd 7870's for the time being since those are just fine for KSP usage. A little overkill I realize, but upon looking at old receipts I realized that I ordered the components for my current rig on February 2, 2011. It was time... Hopeful with all the rest of you on here that 1.1 will better utilize the resources committed to it.

Be careful if you do this with a saved game. I did that exact thing (replacing Plock) and ContractConfigurator and SCANsat went nuts the next time I launched about Plock being missing and started spitting nasty exceptions. So if you run those mods with a save, just be aware that it probably will cause issues.

Thanks and will do! I think I figured out the issue late last night. It was SCANsat that was generating the problem via a messed up upgragde to OPM 1.8. The config files were calling for height maps that were in the wrong spot or missing. A delete and redownload of a fresh copy of OPM 1.8 solved the issue. Sorry for the post. I was confused as to which mod was causing it given the list of generated exceptions. I added this information to the SCANsat thread in case others are having issues. Thanks so much for the wonderful mods!

I'd like to add the same error messages are flooding my logs as well. Unlike the previous poster, I havne't added any new planetary bodies other than OPM a while back. I'm using the recently 14.2 version. Maybe I'll roll back to 14.1 to see if I get the same messages. [EXC 19:14:43.325] NullReferenceException: Object reference not set to an instance of an object PQSMod_VertexHeightMap.OnVertexBuildHeight (.VertexBuildData data) PQS.Mod_OnVertexBuildHeight (.VertexBuildData data) PQS.GetSurfaceHeight (Vector3d radialVector) SCANsat.SCANUtil.getElevation (.CelestialBody body, Int32 lon, Int32 lat) SCANsat.SCAN_Data.SCANdata.generateHeightMap (System.Int32& step, System.Int32& xStart, Int32 width) SCANsat.SCANcontroller.checkHeightMapStatus () SCANsat.SCANcontroller.Update () EDIT: So late last night I did some additional troubleshooting. I belive what was happening was a recent update to OPM 1.8. Some of the file structure got messed up and SCANsat was looking for height maps that were missing or in the wrong spot. I deleted OPM and installed a fresh download of OPM 1.8 and that has appeared to fix this issue. SCANsat is no longer generating any exceptions. For those having similar issues, check to make sure any planetary addon file structure to make sure the config files aren't calling for files that are either in the wrong spot or missing.

Recently upgraded to 1.7.3 as well as to SCANsat 14.2. I started running Exception Detector to troubleshoot why I was getting so many errors in the debug log in my career mode save, and I'm getting lots of exceptions being generated such as the below. Thanks for the help! EDIT: I don't think its the fault of this mod. I'll check with SCANsat

Having the same issue with my modded game. I haven't isolated as to what is causing it. Our common mods: Community Resource pack JSI KAS KIS Near Future Electrical Near Future Solar Module Manager