Eric S

I wouldn't expect the level of improvements that 1.1 brought, but the new Unity should at least help the garbage collection issue (pauses while playing).

It depends. I usually have some idea of where I want to go with any given career save. Some times (usually right after a KSP update or mod that radically alters the tech tree), it's just complete the tech tree. Sometimes it's build a huge space station around X. Do a mothership mission to Y. Take advantage of some new mod I've installed. When I reach the goal, encounter some bug that makes the save unplayable or goal unreachable, or do something so stupid that I'm offended, I ask myself if there's any learning-related low hanging fruit left in the save, and if not, start a new career mode. I usually don't delete them until the next version of KSP is released, as I like being able to refer back to the craft I designed in previous saves.

Only if the mod itself is designed to allow it, which is why it depends on the mod. So no, specifically what you're asking doesn't exist to the best of my knowledge. Originally, all modules had to be tied to a part. Not a specific part, but a part that referenced the module. At some point, Squad changed it so that modders could make modules that didn't have to be referenced by a part. If a mod is written to take advantage of this ability, then the only way to block this ability is if the mod allows it to be blocked.

That would depend on the autopilot mod.

The mod is old enough that it probably still uses the ongui UI stuff, which isn't great for performance to begin with. The first time I had the clock go yellow every time I opened Haystack, just to have it go back green as soon as I closed the window, I decided that if I ever get around to doing KSP modding, a Haystack/Targetron-inspired mod would be one of the first three that I do, written to be more efficient. Of course, it will be a learning experience for me, so if and when it happens, there's no guarantee that it'll be as efficient as I want it to be. :-)

Actually, my return rates are even higher with FMRS than with SR, though that's because I have more precise control over where I land with FMRS. The two things that SR doesn't simulate that makes it easier than FMRS are: 1) Can the craft keep it's heatshield prograde? 2) Will the craft slow down enough to safely deploy its parachutes before it's too late? It fudges reentry heat, but I think the actual parachute results are fairly accurate baring these three things. I switched from FMRS to SR for two reasons. First, I got tired of manually flying in for landings. Unlike my landing capsules, doing a flyback with a booster actually requires me to pay attention, and it takes long enough to get monotonous, especially when you're doing it one to three times for every launch. Second, FMRS isn't compatible with Tourism Plus, if the tourists die when you're using FMRS to time travel back and land the boosters, the contract gets flagged as failed, and that propagates to your non-time travel save.

KSP's too CPU-intense for most phone/tablets. Simple Rockets is about as close as you'll come to KSP for your typical phone.

In addition to that, if you switch to the craft, the orbital parameters get translated to a velocity. Then, when you switch away from the craft, the velocity gets converted back to orbital parameters. Which really just means more opportunity for rounding errors.

Same here. Not complaining (much), just letting you know it's not just you.

OK, I anticipate that the answer will be to file an issue on github, but before I get distracted and forget (this is quicker, I've barely used github so it will be a learning experience), I just wanted to check and see if anyone else is seeing wrong fuel levels in the MKS inflatable storage module when set to ore/fuel/oxidizer. It looks like the liquid fuel and oxidizer amounts got flipped around. Then again, this could be intentional for balance reasons (so that people like me don't try to use them as fuel tanks on large interplanetary craft, for example).

Well, I finally got around to spending the few hours, and while I'm not happy with the hexcore yet, here's my quadcore. It uses the Lynx service bay and gives you four places for Universal Storage wedges, as you probably guessed from the name. It requires the Lynx, Universal Storage, and ModuleManager. I had to slightly scale down the US QuadCores so that they weren't obviously bigger than the space they were put in. The wedges, when installed, will slightly clip into the floor and ceiling. Something that's niggling at me, despite using mirrored coordinates, one pair of nodes appears closer to the floor than the other pair (hard to see the difference before you install wedges, so it could be the wedges that are out of balance). I haven't tweaked the cost or mass of the part, and I'm not sure I really need to for balance purposes. Create a directory under GameData, paste this into a .cfg file within the directory, and restart KSP. +PART[Lynx_ServiceBay] { @name = LynxUSQuad @author = Original part authors Nils277 and Paul Kingtiger & Daishi, merged by Eric S @title = Lynx Universal Storage QuadCore // Nodes for Universal Storage nodes node_stack_rightUS.1C10.Wedge.Quadcore1 = -0.466, 0.194, -0.16, -1, 0, 0, 0 node_stack_rightUS.1C10.Wedge.Quadcore2 = -0.466, -0.194, -0.16, -1, 0, 0, 0 node_stack_leftUS.1C10.Wedge.Quadcore3 = 0.466, 0.194, -0.16, 1, 0, 0, 0 node_stack_leftUS.1C10.Wedge.Quadcore4 = 0.466, -0.194, -0.16, 1, 0, 0, 0 MODEL { model = UniversalStorage/Parts/US_1C10_Wedge_Quadcore/model position = -0.3, 0.194, -0.16 scale = 0.95, 0.95, 0.95 } MODEL { model = UniversalStorage/Parts/US_1C10_Wedge_Quadcore/model position = -0.3, -0.194, -0.16 scale = 0.95, 0.95, 0.95 } MODEL { model = UniversalStorage/Parts/US_1C10_Wedge_Quadcore/model position = 0.3, 0.194, -0.16 scale = 0.95, 0.95, 0.95 } MODEL { model = UniversalStorage/Parts/US_1C10_Wedge_Quadcore/model position = 0.3, -0.194, -0.16 scale = 0.95, 0.95, 0.95 } MODULE:NEEDS[KIS] { name = ModuleKISPartMount sndStorePath = KIS/Sounds/containerMount allowRelease = true MOUNT { attachNode = node_stack_rightUS.1C10.Wedge.Quadcore1 allowedPartName= US_1M110_Wedge_ScienceBay allowedPartName= US_1P110_Wedge_Fuelcell allowedPartName= US_1P120_Wedge_Elektron allowedPartName= US_1P130_Wedge_Sabatier allowedPartName= US_1P140_Wedge_WRS allowedPartName= US_1R110_Wedge_KISContainer allowedPartName= US_1R210_Wedge_Liquidfuel allowedPartName= US_1R220_Wedge_Monoprop allowedPartName= US_1R310_Wedge_CarbonDioxide allowedPartName= US_1R320_Wedge_Food allowedPartName= US_1R330_Wedge_Hydrogen allowedPartName= US_1R340_Wedge_Oxygen allowedPartName= US_1R350_Wedge_Waste allowedPartName= US_1R360_Wedge_Water allowedPartName= US_1R370_Wedge_WasteWater allowedPartName= dmUSAsert allowedPartName= dmUSGoo allowedPartName= dmUSMat allowedPartName= dmUSGoreSat allowedPartName= dmUSImagingPlatform allowedPartName= USRPWS allowedPartName= dmUSMagBoom allowedPartName= dmUSScope allowedPartName= dmUSSoilMoisture allowedPartName= dmUSSolarParticles allowedPartName= dmUSPresTemp allowedPartName= dmUSAccGrav allowedPartName= dmUSAtmosSense } MOUNT { attachNode = node_stack_rightUS.1C10.Wedge.Quadcore2 allowedPartName= US_1M110_Wedge_ScienceBay allowedPartName= US_1P110_Wedge_Fuelcell allowedPartName= US_1P120_Wedge_Elektron allowedPartName= US_1P130_Wedge_Sabatier allowedPartName= US_1P140_Wedge_WRS allowedPartName= US_1R110_Wedge_KISContainer allowedPartName= US_1R210_Wedge_Liquidfuel allowedPartName= US_1R220_Wedge_Monoprop allowedPartName= US_1R310_Wedge_CarbonDioxide allowedPartName= US_1R320_Wedge_Food allowedPartName= US_1R330_Wedge_Hydrogen allowedPartName= US_1R340_Wedge_Oxygen allowedPartName= US_1R350_Wedge_Waste allowedPartName= US_1R360_Wedge_Water allowedPartName= US_1R370_Wedge_WasteWater allowedPartName= dmUSAsert allowedPartName= dmUSGoo allowedPartName= dmUSMat allowedPartName= dmUSGoreSat allowedPartName= dmUSImagingPlatform allowedPartName= USRPWS allowedPartName= dmUSMagBoom allowedPartName= dmUSScope allowedPartName= dmUSSoilMoisture allowedPartName= dmUSSolarParticles allowedPartName= dmUSPresTemp allowedPartName= dmUSAccGrav allowedPartName= dmUSAtmosSense } MOUNT { attachNode = node_stack_leftUS.1C10.Wedge.Quadcore3 allowedPartName= US_1M110_Wedge_ScienceBay allowedPartName= US_1P110_Wedge_Fuelcell allowedPartName= US_1P120_Wedge_Elektron allowedPartName= US_1P130_Wedge_Sabatier allowedPartName= US_1P140_Wedge_WRS allowedPartName= US_1R110_Wedge_KISContainer allowedPartName= US_1R210_Wedge_Liquidfuel allowedPartName= US_1R220_Wedge_Monoprop allowedPartName= US_1R310_Wedge_CarbonDioxide allowedPartName= US_1R320_Wedge_Food allowedPartName= US_1R330_Wedge_Hydrogen allowedPartName= US_1R340_Wedge_Oxygen allowedPartName= US_1R350_Wedge_Waste allowedPartName= US_1R360_Wedge_Water allowedPartName= US_1R370_Wedge_WasteWater allowedPartName= dmUSAsert allowedPartName= dmUSGoo allowedPartName= dmUSMat allowedPartName= dmUSGoreSat allowedPartName= dmUSImagingPlatform allowedPartName= USRPWS allowedPartName= dmUSMagBoom allowedPartName= dmUSScope allowedPartName= dmUSSoilMoisture allowedPartName= dmUSSolarParticles allowedPartName= dmUSPresTemp allowedPartName= dmUSAccGrav allowedPartName= dmUSAtmosSense } MOUNT { attachNode = node_stack_leftUS.1C10.Wedge.Quadcore4 allowedPartName= US_1M110_Wedge_ScienceBay allowedPartName= US_1P110_Wedge_Fuelcell allowedPartName= US_1P120_Wedge_Elektron allowedPartName= US_1P130_Wedge_Sabatier allowedPartName= US_1P140_Wedge_WRS allowedPartName= US_1R110_Wedge_KISContainer allowedPartName= US_1R210_Wedge_Liquidfuel allowedPartName= US_1R220_Wedge_Monoprop allowedPartName= US_1R310_Wedge_CarbonDioxide allowedPartName= US_1R320_Wedge_Food allowedPartName= US_1R330_Wedge_Hydrogen allowedPartName= US_1R340_Wedge_Oxygen allowedPartName= US_1R350_Wedge_Waste allowedPartName= US_1R360_Wedge_Water allowedPartName= US_1R370_Wedge_WasteWater allowedPartName= dmUSAsert allowedPartName= dmUSGoo allowedPartName= dmUSMat allowedPartName= dmUSGoreSat allowedPartName= dmUSImagingPlatform allowedPartName= USRPWS allowedPartName= dmUSMagBoom allowedPartName= dmUSScope allowedPartName= dmUSSoilMoisture allowedPartName= dmUSSolarParticles allowedPartName= dmUSPresTemp allowedPartName= dmUSAccGrav allowedPartName= dmUSAtmosSense } } } If you're curious about the hexcore issues, basically, there's way too much clipping involved and you can't reach the two middle nodes easily outside of the VAB. I can ignore the latter, but I'll probably need to either leave out the quadcore models, leaving it with nodes floating in the air (or lack thereof), or come up with a custom model of the bracket in order to get rid of the clipping. There's just not much room left if you try to fit six wedges in a "Lynx Cargo Bay (Small)" and leave the four outer wedges facing the doors. And yes, if there's interest and no objections, I'll probably package this up as an actual mod somewhere.

Hmmm... good point, I'm hitting the Mun first, and it's a 16 day transfer from the Mun to Minmus at minimum delta-v, so the time I cut off coming back from Minmus is probably made up for by that transfer. Could definitely shorten that trip by spending more delta-v, but I think the extra fuel would outweigh the extra life support consumables. As for Tourist Plus contracts, I do the minimum necessary for Stage Recovery mod recovery, when you're earning 3-4M roots for a mission that cost less than a quarter million to launch, spending more time than necessary to do that mission to minimize the overhead doesn't feel time-effective. When I start bumping up the difficulty, I may change my tune, but not for now. EDIT: Double checked, my current Tourist Bus designs run from 260K for 30 up to 313K for 50 tourists (I could probably trim that a bit, the 30 passenger version is a bit overbuilt). OK, technically 29 and 49, since the reward mentioned depends on having a non-tourist along for the ride. I'll also double check the rewards next run. I remember being surprised by the total payout, but it adds up and might even be a bit low. Figure X tourists to the hotel, X tourists home from the hotel, Y tourists to visit the station, and Z tourists to low Kerbin orbit, all tripled thanks to Pilot Focus III.

I do the Minmus->Solar SoI a little differently. Instead of leaving Minmus prograde to Kerbin's SoI limit (to minimize delta-v expended), I leave retrograde+radial out (in reference to Kerbin, but still within Minmus' SoI). This basically kills so much of my horizontal velocity that when I duck back into Kerbin's SoI, I'm probably going to have to raise my periapsis to aerobrake rather than lower it. Makes for a short trip, which is nice when you're playing with life support. And yes, Tourism Plus is fun.

The closest you can come to that is changing the model in a Module Manager config file, that way you're not altering the original part's config file, but that still requires a .cfg file.

HGR_Redux (part of HGR) has a 1.875 fairing that works just like the stock fairings. It looks like they're using a custom model rather than rescaling the stock fairings, though they are using the stock textures. You could either use this or look to see how this differs from your tinkering. For what it's worth, I use HGR extensively for 1.875m parts.

True, but I honestly expect the part to take a few hours at most, and most of that is learning, so even if I only use it for one save, it's worth it.

I'm thinking of going one step farther and setting up a lynx part that has room for some Universal Storage slots. I can probably pull it off without designing any new parts, just combining one of the Lynx parts with a few of the 4-container bases. Not that many of the other science parts would need dedicated parts since they can fit in the Lynx science bay, but it opens up a few more options.

If the craft get smaller because the payload gets smaller, I'll agree. However, they're mostly getting smaller because I'm not getting stuck with having 10 times the TWR and three times the delta-v I want. Early stock probes are like crushing walnuts with a sledgehammer.

Heh, don't mind, had already downloaded it, just haven't installed it yet. I'm actually fine with the status quo, I was just explaining why priority by itself couldn't fix the problem.

That already happens, because the stage the part is in affects the priority, so any part that stages causes this effect. It still doesn't fix the issue in all cases because once the radial tanks are drained, radial engines will feed off of center stack fuel tanks (or any other fuel tanks that aren't empty). On the rare occasion that I still use cross-feeding or even more rare, asparagus staging, I still use fuel lines specifically to prevent this, as the engines cut out when the fuel tanks they're attached to empty, giving me a very solid "time to stage" effect that I don't get if I depend on enabling fuel flow across the radial decouplers.

Well, two trick pony, really, it's also insanely handy for those "splashed down" part tests. Though I have to admit, that's about the biggest point of disagreement I have with you. Every part pack I have that isn't about functionality is about filling in gaps. 1.875m and 0.625 tanks/engines, 2 kerbal command pods, stuff like that. I agree with much of your analysis of the tech tree as well, and would like to add one gripe. We shouldn't be getting 0.625 engines/tanks at the same tech level as 2.5m ones. I don't think we need to go full on "sounding rockets first, then 1.25m parts" but I think most of the 0.625m parts should be introduced along side the corresponding 1.25m parts at the latest, except where it could be argued that the part is complex enough that miniaturization could be an issue. So sure, high tech probe cores can come to 1.25m first. But miniaturizing engines and tanks to 0.625m shouldn't be an issue, and I shouldn't have to resort to tweakscale to get something as simple as a 0.625m aerodynamic nosecone. Heck, having 0.625 decouplers/seperators come after the 1.25m ones is a royal pain at times.

Yes, and if you activate them through the right click menu, you can later stage them to run the test, so the engine itself can be used to get the engine into the situation it needs to be tested in. Or at least you could last time I needed to do that.

Yes. In fact, the above discussion about the parachute issue I was having lead me to figure out the basics about this, since the MM config above makes the Mk16 parachute as overpowered as the default Mk26 parachute is. Basically, copy the part directory that you want to have unmodified from the Squad directory into a different directory and then edit the cfg file within that directory to change the name and title parameters. You have to change the name, otherwise KSP will only keep one of the two parts, and you should change the title parameter so that it's easier to tell which is which in the VAB or when you're mousing over the part in flight. If you want more details, feel free to ask, I'm just skimping on the details because I'm still waking up and not thinking well yet.

I will confess that on my "when I'm not so busy with work" todo list, you'll find, somewhere after "learn KSP modding," an entry for "something to trigger Gravity Turn a given amount of time before in phase/plane with craft's target." Making something seperate that hooks into GT makes sense to me, since you're right, it really isn't in scope for GT. Then again, when creeping featuritis sets in, I start thinking of winding up rewriting all of GT as part of a larger project I'm considering. I have way more plans than time.

On my last career save, I had no problems with MechJeb's "land at target." This time? I've had it try to land me consistently almost half a world away, even when I use "pick a spot on the map" rather than entering lat/lon. Hmmm... I should try it again, to see if it puts the red target crosshairs in the right place or the wrong place.