Kerbas_ad_astra

Members
  • Content count

    1404
  • Joined

  • Last visited

Community Reputation

709 Excellent

2 Followers

About Kerbas_ad_astra

  1. 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.
  2. Maybe replacing it with the updated version from the latest CLS release will work?
  3. 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.
  4. 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.
  5. 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.
  6. [1.2.x] Real KSC in KSP Dev Continued

    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.
  7. 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.).
  8. 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).
  9. 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).
  10. [1.2.2+] Contract Pack: CommNet Relays 2.0.2 (2017 Sep 04)

    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.
  11. [1.2.2+] Contract Pack: CommNet Relays 2.0.2 (2017 Sep 04)

    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).
  12. [1.2.2+] Contract Pack: CommNet Relays 2.0.2 (2017 Sep 04)

    Most antennas do not add their ranges linearly -- there's a penalty, described on the CommNet wiki page. For most antennas, that penalty is 0.75, so stacking N antennas only increases power by a factor of N^0.75, not N. To get to 900 Gm, you would need to use 235 RA-15 antennas (which have a power of 15 Gm each), or 19 RA-100s. Or, get DMagic Orbital Science and use one SIGINT antenna, which has a power of 10 Tm (10,000 Gm). The requirement to generate the planet relay contracts is simply to escape the homeworld, yes. I could add a maxSimultaneous constraint to reduce the number of contracts offered at once, or add another constraint that planets must have been visited before contracts will be offered for them; what do you think? As for displaying the power more neatly...that would actually require an update to Contract Configurator rather than this contract pack, but I think I can make that happen. Thanks for the feedback. Edit: Would you rather have the powers formatted by adding commas (i.e. 900,000,000,000) or with SI prefixes (i.e. 900 Gm, losing precision, but that's not as necessary here as it is for e.g. orbits)?
  13. You really shouldn't use Real Fuels and SMURFF together. They both make fuel tanks and engines lighter, so at best, you'll get unrealistically light parts, and at worst you get negative-mass glitches like yours. SMURFF has some protections against making parts with negative mass, but Real Fuels uses a different set of variables, it adds a bunch of new resources and tank types, and most challenging of all, it patches a lot of parts individually (as opposed to using the consistent 8:1 ratio that most stock tanks adhere to), so it's not practical for me (or the RF devs) to add patches to make them work together. The one thing SMURFF does that RF does not is make pods lighter, so if you really want to keep it, you could do as Nightside suggests. That will stop SMURFF from tinkering with engines and fuel tanks, and only change the masses of command pods.
  14. [1.3.0] Vens Stock Revamp Revamped 1.10.1

    Not that I know of, sorry. Probably the easiest way to go about this (if you want to) is: Make a copy of your VenStockRevamp folder somewhere outside of your working directory. Delete the working directory. Fork Ven's repo (on GitHub). Clone your fork onto your computer. Put your files back. You should be able to simply delete the GameData/VenStockRevamp folder and replace it with the one you set aside, and Git will work out which files you've changed and removed. (You might have to go in and manually add the files you've added.) Commit and push.
  15. [1.3.0] Vens Stock Revamp Revamped 1.10.1

    It would have been better to fork Ven's repository, or at the very least, make your first commit the unchanged repository, and work from there, so that it would be easier to track the specific changes you made from his version.