Krazy1

It was throwing exceptions in 1.11 and it wasn't updated, but it's fine in 1.12? Are there any errors in your log?

Starting a Jool 5.6 which is just a Jool 5 plus 6 survey scans (including Jool). I'm using an SSTO rocket-lander Citadel 3 with crew of 11. I'll use this single vehicle throughout - no docking/ undocking, but certainly needs ISRU. I'm about to do the Kerbin outbound burn after Minmus refueling and Kerbin slingshot. I started an album Are those mod wheels or you built them up?

It doesn't show because I'm on KSP 1.11.2 and it's no longer compatible with AFBW >=1.8.3.5. However, 1.8.3.4 is log spamming like someone else described before. So I rolled back to 1.8.3.3 and it's working. \o/

This is actually old but I successfully rescued a Mk2 cockpit from the Mun with this ungainly rover-ship. PS I brought 4 tourists with me to combine contracts. Got a nice photo of an eclipse reentering.

It's still has 1.8.3.4 on CKAN. Thanks for all the 1.12 updates!

I have several Sentinels and now close to 100 asteroids shown in the tracking station. At about 1/2 of them I have stopped tracking but it takes far too long for them to actually disappear. I think it's contributing to slower scene loading. Is there an easy way to eliminate objects you stopped tracking? Maybe a mod that removes them when you exit the tracking station? I figured out from my savegame file: stopped tracking: DISCOVERY { state = 21 lastObservedTime = 3508083.6512565739 lifetime = 1282076.0472739476 refTime = 1728000 size = 4 } Still tracking: DISCOVERY { state = 29 lastObservedTime = 2426413.4753895206 lifetime = 1124139.6606445313 refTime = 1728000 size = 1 } never tracked: DISCOVERY { state = 1 lastObservedTime = 3790354.3286036993 lifetime = 1132633.2449152297 refTime = 1728000 size = 4 } So you could do something like: if Discovery.state = 21 then set Discovery.lifetime = 1. Then the game should automatically clear them a second later.

Probably obvious... or too late now... I would separate the scanner probe at the edge of Eve SOI and fly that to a polar orbit independently while rest of the ship goes to the equator. You'll spend a LOT less dV than trying to torque the ship over 90 deg. in low Eve orbit. That takes at least 1962 m/s according to wiki. Good with on Eve! She's a witch.

OK... I tried a 3.75m parachute and it seems reasonable (although I was mean to my crew): Based only on physics it must. There is no magic here. The material properties don't change. I'm only assuming that there are no design changes, only direct scaling. OK sure but we're talking about different things now. These are engineering design improvements. So you are saying that there is a significant engineering advantage in scaling things larger and you're including that in the scaling? I'm just thinking about the physics without changing the design features. OK But each square inch is not supported individually. The force on the cone is transferred tangentially across the surface to the root. The circle at the root of the cone where is is supported scales linearly but the surface area scales squared (of course). So there is more force transferred to each linear inch at the root as it scales up. And the average distance from the force to the root is greater. You can basically think of it like a beam. flexural strength So if you double the cone size, it's like doubling L and F (F is proportional to L). So to keep the same strength, you need to double thickness d too.

Thanks for testing the parachutes - I'll try some test too but I'm still on 1.11.2. I just assumed KER is right. I have to disagree about the nosecone scaling. Beams are engineering design optimization, but fundamentally the physics must scale cubic. If a shell structure (open end or closed, it doesn't matter) has internal beams then those beams need to scale too to maintain strength. The walls of the beams and the skin of the shell have thickness and the thickness of everything has to scale. Or the number of beams needs to increase. Or the strength needs to decrease. Imagine you built a little model house out of paper and toothpicks and school glue. You can put beams or trusses or internal walls in- it doesn't matter. It's not very strong but it holds together. Now scale it up to the size of a real house without scaling the thickness of the walls or beams. It will be extremely weak. A small breeze will destroy it. If you don't agree just make it bigger... as big as a mountain. The total density of the house (building material and enclosed space) becomes infinitesimal as it scales up with a squared law. Conversely, start with a real house and try to shrink it down to a small model size without changing the wall thickness or any 1 dimension of the beams or walls. At some size, it will become a solid block. All of the air space will be taken up by building material. The total density will increase as it shrinks and it will be denser than solid wood, or Kerbin, or neutron star if it's microscopic . So I think it should be close to a cubic law... maybe 2.9 or 2.8 but definitely not 2. You seem to agree with me partially because fuel tanks are scaling cubic. It's the same idea. Sorry I'm taking up your time with this. Hope you can sort your hardware issues.

Maybe different than what you were thinking but there's this: Never tried it.

I've been building recoverable SSTO boosters. I built one for a big lander I'll take to Duna. Of course there was a massive explosion involved... Here's the whole story in Imgur album with captions

Also curious what these are. So if they're new... why did they list bugfixes for them in the same release?

I needed to send a Kerbal from Minmus to Kerbin so I made this little rocket chair in EVA construction. 2.4 km/s dV... no problem. I'll pick her up with an SSTO in LKO. Using Texture Replacer for the visor reflection. Note I used the octo2 for "control from here" point because the chair cannot do "control point up" for correct SAS orientation.

Sorry man. At least I learned what atavistic means I going to whine about some minor physics scaling stuff here... please ignore until you get your h/w sorted. nosecones scale with squared law but I think it should be cubed law. It's not just a 2-D sheet. The wall thickness needs to scale too. A scaled-up nosecone would be crushed by aero forces. parachute drag doesn't seem to scale, according to the mouse-click menu in KER. Mk16-XL says "deployed drag: 1/500" regardless of scaling. I think this was brought up before.

KER 1.1.8.4 is log spamming on KSP 1.11.2. In tracking station: In flight: Reverting to 1.1.8.3 fixed this.

Looks good! "That's one small brace for a man, one billion clicks for mankind."

Sorry man... closer but still not quite right. Summary: it is loading the RememEditor.cfg value only the first time when entering the Editor in a KSP session. However, it is correctly saving the sort change in the RememEditor.cfg when the sort order is changed. Steps: Load KSP. Enter VAB. Note it's sorting by mass ascending... good (it's the new default in PluginData\RememEditor.cfg) exit VAB; enter VAB Note it's sorting by name ascending... no good change sort to cost descending; exit VAB; enter VAB Note it's sorting by name ascending... no good Exit KSP check RememEditor.cfg: it has changed corresponding to cost descending: partListSortAsc = False partListSortIndex = 2 ... so it did save the setting but didn't recall it.

Thanks @linuxgurugamer ! BUT it's not working. I pulled out my Rememberer folder from Gamedata and installed EEX 3.4.3 from CKAN. Seems like 2 issues. First, it can't find the config file, and the config file really isn't there. [WRN 21:36:21.369] File 'C:/KSP/KSP 1.11.2 modded/KSP_x64_Data/../GameData/EditorExtensionsRedux/RememEditor.cfg' does not exist [EXC 21:36:21.372] NullReferenceException: Object reference not set to an instance of an object Rememberer.RememEditor.Start () (at <7ecc786bb2bc446292b849f6c96cc99b>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) I put the CFG file where it's looking for it and it correctly loaded the value I had in the file (mass ascending) the first time entering the editor but then it reverts to the stock default (name, ascending) after exiting and re-entering the editor. The CFG file was unchanged. No EXC or new ERR in the log either. I didn't look in your code. I'm assuming it's a simple oops. If not, let me know what you need.

Launch Window: Minmus has an inclination of 6 degrees from the equator of Kerbin. I launch directly into an inclined orbit that's close to matching the plane that Minmus is in. There are 2 launch windows per day, 3 hours apart. To find those times first look at the map, double click Kerbin to center the view on it. Then align the Mun's orbit (no inclination) with Minmus' orbit like this: Remember if Minmus' orbit is at 84 deg as shown above or 96 deg. because you will launch at this angle. Then use the mouse wheel to zoom in. The point in the center of your view of Kerbin is where the space center needs to be when you launch. Use time warp to position it there. Launch: It's a standard launch to LKO except you're targeting 84 deg. or 96 deg. I use Kerbal Engineer Redux (KER) to show the orbit inclination - this makes it much easier. With practice, you should be able to get 6 +/- 1 deg. inclination. Outbound: Now that you're in an orbit that's almost in the same plane as Minmus, it shouldn't be too hard to get an intercept using only prograde burn (assuming you've gone to the Mun already). Aim the maneuver node orbit about 40 deg. ahead of Minmus. It usually takes about 920 m/s deltaV and 8-10 days to get there. Do not try to correct the inclination now - it costs more deltaV. When I do the burn, I use prograde hold, not maneuver hold. It's slightly more efficient but the burn time indicator won't be quite right (it assumes instantaneous burns). Slow the burn way down at the end and focus view on Minmus to watch the orbit. Midcourse correction: Halfway between Kerbin and Minmus, do a tiny correction burn to fix your aim. You should be able to aim anywhere around Minmus with <10 m/s deltaV here. I wouldn't just do flyby... I'd make a relay satellite and put it in Minmus orbit. It would only take around 200 m/s extra to get into orbit - Minmus has weak gravity. Then you'd have a relay for future probes and landers.

Use Kerbal Alarm Clock to set a manual alarm that pauses the game near the end of the burn.

@ValiZockt Great mod! I have a problem though. It does work for ships with RGU probe cores but it's not working for one of my piloted ships. It's a shuttle with a MK3 cockpit containing a L3 pilot and a L2 pilot (and other non-pilots). Also there's a MK3 cabin with L2 and L0 pilots (and other crew). All of the stock SAS modes do show on the navball: maneuver hold, prograde/ retrograde to target, etc. but the 2 docking modes do not show. I didn't change the config file. I don't see anything interesting in the log. KSP log The ship is "Alpha Shuttle". I'm also seeing a problem on several different ships where SAS is left on when I switch ships and switch back to the original ship: SAS "stability assist" indicator is lit on the navball but SAS is clearly not active. I can deactivate/ reactivate SAS and then it works. It also does this on EVA: set SAS on, EVA and reboard, SAS indicator is on but it's not active. I do have many other mods installed. I'll try to do some more testing and report back. Update: With the same mods, I tested several command pods on the launch pad in Career with a 3-star pilot and none of them worked. Tested in Sandbox with 5-star pilot and it DID work. Update 2: I fixed one issue... In SmartDockingAid.cfg you need to change minPilotExperience = 2. Then it is available for 3-star pilots and not for 2-star. I'm still having the issue above in blue.

Yes. It saves the sort method and ascending/ descending in a config file. @linuxgurugamer This is such a tiny mod, I was hoping you would pull it in to Editor Extensions Redux.

A simple quality-of-life mod that remembers frequently used settings that KSP forgets. Presently it remembers the last sort setting for the Editor part list. That's all! It saves the sort settings in a config file, so it works through a KSP restart. Tested with KSP 1.11.2 on Win10. I guess it will work back to 1.8 at least but I can't promise it will. NOTE: linuxgurugamer has pulled this mod into Editor Extensions Redux. Recommend using that mod. Thanks to @HebaruSan for for his help and others dragging me through my first mod.

There I go ASSuming again.

I ASSumed that was a core KSP 1.11 issue. Nice find. BTW Could CTB block the scroll wheel? Specifically when scrolling on KAC (with enough alarms for a scroll bar) it also zooms the camera in/ out simultaneously. When you have nothing better to do... probably never.