Kerbas_ad_astra

When I say "1.2+", I mean including 1.3.1. (I'd have titled it 1.2.x otherwise.) I do have some changes that I need to check and update, but the parts all load and work for me in my 1.3.1 career. What's not loading for you?

SMURFF operates on stock resources only, so it shouldn't interact with Real Fuels at all. (Nor does it need to, to my knowledge -- I understand that real fuels' tanks are already defined with realistic mass fractions.) The only effect left over is making capsules and heat shields lighter (which may still be desirable, since Real Fuels doesn't do that.)

I did use some fairly conservative numbers when estimating LH2 tank fractions, so I'll go over that math again and see what falls out. Thanks for the feedback. Edit: Also, it looks like CryoTanks' tank mass fractions got revised, so I'll definitely have to do some re-figuring.

Simply swapping out the tank setups and engines is not going to produce good performance -- because LH2 is so lightweight (70 g/L vs. 1000 g/L for LF/OX), more tank volume is required to make up for it. The last time I looked at this, the numbers did work out that, when I added more fuel tanks to get the delta-V numbers to match, the LH2 rocket was lighter than the conventional LV-909. (It did, however, cost more funds, which is why I've not been a heavy user of LH2 rockets in my career. The most likely use case I've considered is a cryogenic upper stage for an interplanetary probe to save much more mass on the LFO launcher.)

This is all-in-one.

I aten't dead yet, but this is the first I've heard of docking port issues. (My focus on HGR is on localization and investigating some fit/coverage issues related to the heat shield.) There definitely is an oddity in that the docking ports have a 'probe' animation that extends a collider, but that's beyond my modding ability at this time, so I can only echo @Daniel Prates's advice.

The features that this contract pack depends on were added in a CC version built for KSP 1.2.2. So long as CC retains those features, this pack should remain future-compatible with updates to KSP. Someday I might get around to implementing localization support, which will break 1.2.2 compatibility, and then this addon will be tagged as compatible with KSP "1.3+".

7.20T worth of antennas weighs a lot, if you're just using stock parts.

Interstellar has its own fuel tank mass adjustment patches and fuel tank switching patches that it applies to all parts. I thought I had a patch to adjust those, but it may have changed. If someone comes up with a fix, I might accept a pull request, but I don't use IFS's parts and patches anymore, so it's not a priority for me to get into the weeds to debug.

There's a couple of parts from various mods that I need to figure out how to handle better. Can you get me the errors?

When I say "1.2+", I do mean that it's compatible with the 1.3.x series as well. I've kicked the 'online' version file to pacify AVC. (Eventually, I'll make an update with internationalization support, and it will no longer be compatible with 1.2.x.)

That is correct. All oxidizer-burning modes get their thrust buffed, but the engine mass is decreased if and only if there are no non-oxidizer-burning modes.

Do they burn oxidizer? That's what SMURFF looks for. If Firespitter's engines don't burn that (or solid fuel...) then SMURFF won't touch them.

For anyone else curious, SMURFF and AJE don't really interact. It's not by any intention; it's just that AJE only patches jet engines, while SMURFF only patches rocket engines.

I have one in ConnectedLivingSpace and one in ShipManifest. When I duplicate the one from CLS into the KeepFit folder, everything works. Probably what was wrong is that the one in the KeepFit repo is for an old version of CLS or KSP.

Maybe replacing it with the updated version from the latest CLS release will work?

SMURFF was made to be 'lite' to begin with; I'm not going to make (and support) an even liter version. I see where a divide-by-zero error will occur with setting that lever to zero exactly; I'll see if I can fix it, but in the meantime it should work if you set it to 0.001 or the like.

Hey Rodhern, I've figured out why Keepfit hasn't been working for me in 1.3. You've got an extra/outdated CLSInterfaces.dll in the repo (in GameData/KeepFit). It causes KeepFit to fail to initialize properly (deleting it was all I had to do to get it working again). You should probably grab the most up-to-date CLSInterfaces.dll from the latest CLS download, and definitely store it outside the GameData folder for compiling against it.

I've sometimes thought about disentangling the RO dependencies from RP-0, but it looks like pap's got it covered! I hesitate to add it (or other career/tech overhauls) to the list of suggestions, though, because this one in particular imposes some requirements on the solar system and tech tree, and many nice tech trees are mutually exclusive. SEP (and other packs that add real experiments, like DMOS and NEOS) is definitely going on the list! Thanks for the reminder.

I've managed to finagle a couple of spawnpoints into the runway, by adding two instances to the Spawnmarker.cfg file (inside the main STATIC{...} block): Instances { CelestialBody = Earth RadialPosition = 903881.563,3063169.75,-5512679 Orientation = 0,1,0 RadiusOffset = 43.8 RotationAngle = 43 RefLatitude = 28.737593766954909 RefLongitude = -80.688407361338236 VisibilityRange = 25000 Group = Ungrouped GroupCenter = false RefCenter = 908365.7,3064602,-5512527 LaunchSiteName = KSC Shuttle Landing Facility 33 LaunchPadTransform = Marker_spawn LaunchSiteDescription = A single-piece runway, with no gaps! Faces north. LaunchSiteType = SPH Category = Runway LaunchSiteLength = 1 LaunchSiteWidth = 1 OpenCost = 0 CloseValue = 0 OpenCloseState = Open FacilityType = None CustomInstance = True LaunchRefund = 0 RecoveryFactor = 50 RecoveryRange = 100000 LaunchSiteNation = } Instances { CelestialBody = Earth RadialPosition = 901383,3065841.5,-5511603 Orientation = 0,1,0 RadiusOffset = 45.8 RotationAngle = 223 RefLatitude = 28.764998266320735 RefLongitude = -80.711912085815783 VisibilityRange = 25000 Group = Ungrouped GroupCenter = false RefCenter = 908365.7,3064602,-5512527 LaunchSiteName = KSC Shuttle Landing Facility 15 LaunchPadTransform = Marker_spawn LaunchSiteDescription = A single-piece runway, with no gaps! Faces south. LaunchSiteType = SPH Category = Runway LaunchSiteLength = 1 LaunchSiteWidth = 1 OpenCost = 0 CloseValue = 0 OpenCloseState = Open FacilityType = None CustomInstance = True LaunchRefund = 0 RecoveryFactor = 50 RecoveryRange = 100000 LaunchSiteNation = } Going forward, it would be ideal if a spawn transform or two could be added to the runway model itself, to turn it into a launchpad directly (because of the size of the Earth, and because the positions of statics are stored as single-precision floats, there's some "hairiness" in the actual location of the spawn point when it's a separate static like this). From my testing, I've biased the spawn points to deploy a spacecraft slightly above the runway surface (as opposed to deploying slightly below the surface, which results in catapulting when physics initializes), but that still leads to a bit of a drop, and they're also not quite as well aligned with the runway's centerline or heading as I would like.

No, but you could do it with a patch like this (similar to several constructs within SMURFF): @PART[*]:HAS[@MODULE[ModuleEngines*]] { @MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer]] // Only affect engines that burn oxidizer == rocket engines (not jets, ions, mono) { @atmosphereCurve { @key,1[1, ] -= 20 // Or use "*= 0.9" for a 10% reduction, etc. } } } The idea is that you're calling for the second (computers start counting from zero, recall) key ("@key,1", the one in the atmosphere), and then looking at the second space-separated number in the key ("[1, ]") to do math on it ("-= 20" or , "*= 0.9", etc.).

You could maybe tinker with some of the internal math that SMURFF does (i.e. not just the three 'lever' variables, but the 'factor' variables further down), but you're probably better off just writing a patch for the RLA boosters to make them lighter. You're correct that fuel tanks are adjusted, but nothing else -- air-breathing engines are at about the right TWR, so they don't get adjusted (although the RAPIER and similar multi-mode engines do receive a thrust buff to their rocket modes).

SMURFF can be used in any solar system, and if the 'lever' variables have positive values, then SMURFF will reduce the masses of parts (specifically: engines, heat shields, fuel tanks, and crew capsules, provided they use stock-like resources and balancing). In my opinion, it only makes sense to do this in upscaled solar systems. Stock parts are much heavier than real-world rocket parts (relative to their performance, so mass fractions and TWR), but that's intentional, so that making rockets for the Kerbin solar system is less challenging than in the real world, but not trivial (using SMURFF in the stock solar system would make the game much easier -- too much so, IMO). That balance is maybe suited for systems up to ~4x in size, but starts to break down pretty rapidly past ~6x (RSS is ~10x).

Nope, zero interaction. From my brief investigation, it may be possible for me to figure out which bodies have strategies active and weight them preferentially, but my current method is exactly as I describe it -- assemble a list of inner planets (or outer planets, or gas giants), filter out the ones with more than five relays around them, and then pick one at random (with no weighting). I've released an update which adds limits on how many contracts of each type will be offered at once...I've never seen more than a few of each kind at once myself, but that probably depends on what contract packs you have, how they are weighted, and how many contracts are generated in total. CommNet Relays v2.0.2: De-Proliferation Added 'maxSimultaneous' values for all contracts.

Actually, the bodies are selected uniformly at random, from the set of planets with appropriate parameters (e.g. semi-major axis, gas giant status, number of relays in orbit). As I read you, I don't think that changes your preference, but I want to be clear on how the planets are selected. Trying it out, I agree -- the SI view is much neater. That change will happen whenever Contract Configurator updates (plus some in-game time, while the contracts regenerate).