• Content Count

  • Joined

  • Last visited

Community Reputation

32 Excellent

About KSPrynk

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm actually glad for the combination of CryoEngines, with the CE ReStock patch to convert the Vector and a few others to LH2-Ox, and this latest mod for Methalox. I was trying to mentally justify arbitrary selection of Raptor and BE-4 equivalents from the LFO pile for my New Glenn and Starship analogues, and I can also make a 3.75m SLS that actually runs on the right fuel as well. If anything, I vote for expanding the LCH4 selection at some point in the future. I think there's a lot of source material to build off of. LandSpace in China is building the TQ-12, there was Morpheus doing a lander engine a while back, and USAF might still pick up a "mini-Raptor" for a Falcon Heavy upper stage (since they helped pay for it....) Starship and Morpheus also have RCS that runs on the same fuel. In the near term, if there's going to be a NFLV 1.2.1 imminent, may I suggest adding a patch in the Methalox Extra to allow the 1.25m and 2.5m ISRUs to have an additional LCH4 and LCH4-Ox selection option, to complement the CryoTanks LH2 ISRU patch? If we're going to build Starships, getting off Duna is going to need ISRU....
  2. @Nhawks17, @Nertea, there appears to be a graphical bug on the KerbalAtomics Eel 0.625m NTR when using RealPlumeStock. The plume gets placed nearly all the way up the extensible nozzle and appears to be exhausting near the fixed end of the nozzle, by the chamber (or bottom of the part, if the nozzle extension was retracted). I don't know if the "leaky" extension joint was intended, but it's not consistent with the other extensible nozzle engines, such as those that come with Cryogenic Engines. This effect does not appear when using RealPlume 11.2.0 by itself, but then there's no vacuum expansion at all without the RPStock patches for KA. On a related note, I think RPStock 1.3.1 is bundled with an out-of-date version of RealPlume, as the latest Cryogenic Engines (v1.0.0) threw 41 errors (non-detrimental) at me on loading. I resolved the errors by installing RP 11.2.0 from the linked GitHub page, in place of what RPStock 1.3.1 was bundled with. The fix for the Eel plume in the RPStock patch for KA seems easy enough. In the KarbalAtomics.cfg file, I edited the position value from -1.6 to -1.0... @PART[ntr-sc-0625-1]:FOR[RealPlume]:NEEDS[SmokeScreen] { PLUME { localPosition = 0.0, 0.0, -1.0 EDIT: I've added an Issue on the RPStock GitHub site.
  3. @UnanimousCoward, @Snark, there's a small graphics bug for the ReStock version of the RA-100, in ILCE v1.6. I believe it's leftover from a previously reported error in the ReStock GitHub Issues page here: https://github.com/PorktoberRevolution/ReStocked/issues/608 I'm seeing the same glitch: the light is hanging in mid-air, above the antenna. EDIT: It looks like both the 1.25m and compact antenna part switch variants of the light may be getting loaded, regardless of the variant selected OR the smaller tip light is just a legacy light that needs to be blocked off from loading. The relatively large light on the compact variant seems to be positioned correctly, but the tip light on the 1.25m variant gets placed about a meter high. I think the compact variant light is partially sticking out the bottom of the antenna tip (looks like a ring) on the 1.25m variant, which may have been by design, and supports my theory that the hanging light wasn't supposed to load. I'm using KSP 1.7.3 x64 on Win10. Tried on a clean install with just ReStock v0.1.4, IL v1.5, ILCE v1.6, and MM v4.0.2.
  4. @Avera9eJoe, Poodmund noted in the latest release of OPM that Kopernicus 1.7.3 has a new OnDemand functionality that "intelligently handles memory usage with respect to textures...." This sounds like a godsend for RAM-limited folks. Are you going to take a crack at it?
  5. That got my attention - does this mean there's an imminent update to OPM-VO to make the most of this capability? Sounds like something all the Visual Modders should be jumping at.
  6. I'm loving the detail (and holding my breath on the RAM impact). Looking forward to this update. Will the new models for previous engines substitute automatically on existing craft or are they going to be new part names? Also, any 0.625m LHO engine in the works, comparable to the KA Eel? Small craft and probes could use some cryo love...
  7. @Frostiken, just a heads up, there seems to be a ReStock conflict with RealPlumeStock (dev pull version #81, from the OP, to include ReStock) patches for Missing History. It's particularly noticeable on the LV-T30 Reliant and T45 Swivel engines - the engine plumes appear to originate at the throats of the new ReStock models and pass through the nozzle walls. The easy fix seems to be to delete the MH patches for those engines (not sure why MH has patches for T30 and T45...) in RealPlumeStock, if you're using ReStock. I'm not sure what kind of Boolean check logic can resolve this automatically, either for players who want to keep both sets of Porkjet type engines, or those (like me) that remove just those engines from MH and use ReStock's.
  8. I went into Missing History and deleted the Engine folder from the PorkjetParts folder. No particular rationale for one over the other, although they do have slightly different performance stats.
  9. @Katten, have you looked at how the SOAP cameras interact with the scenery since v1.7.X? I tried out the SOAP-1 on Kerbin and the Mun, in KSP v1.7.2 x64, and the scenery in a picture gets cut off beyond a certain distance, plus there's also no sky in the image (more specifically, no skybox I think). I landed on the Mun, and I got a pic of some hills under a blank blue background. Interestingly enough, when I launch off the Mun to about 10km up, I can capture an image of the skybox, but not the surface of the Mun or Kerbin on the horizon. I think Squad re-did the Stock skybox in 1.7.X and it may be more than just better image detail.
  10. I noted the same, and submitted an Issue. EDIT: Ignore my issue on 3 July 19. Went back further and saw it brought up In April, with note that it was to be addressed in version X.X.X.11
  11. I'm not sure if this just cropped up in KSP 1.7.2, but I'm seeing an issue with lights turning on their "glow" decals for the lenses when the part they're attached to turns its lights on. This does NOT happen in the VAB; I only see it after launching a craft into flight. More specifically, I can add Mk1 and Mk2 Stock illuminators to a Mk1 lander can or Mk 1-3 command pod, and then turn on the lights on the command pod within the PAW (or with the "U" button, even if the illuminators are unbound from that Action). Within a few seconds, the "glow" decal for the attached lighting parts comes on, even though the lights aren't illuminating. Hovering the mouse arrow over the part to highlight it briefly cures it, then it comes back. The reverse situation comes up when activating the illuminators and turning off the command pod lights. Illumination takes place, but the glow decal disappears either after a few seconds, or after hovering over it with the mouse. This issue gets more problematic when adding illumination mods like Aviation Lights. The blinking and color change functions become irrelevant, at least on the lenses, because they'll come on full strength, white, and continuously, regardless of the actual state of the light, or the glow will stay off if the CM's lights are off. I tried looking this up in the Bug Tracker, but didn't see anything (at least for 1.7.2 bugs) and the search/filtering tools are rather...weak. I'm using KSP x64 on Win10. First saw this on a modded install, then I did a separate clean one, with and without the Squad expansions. UPDATE: I've added this as an issue in the bug tracker. UPDATE 2: I've added detailed replication steps in the bug tracker.
  12. @UnanimousCoward, if you're still adding to the bard's playlist, there's a piece of Nertea's StationPartsExpansionRedux which happens to override its apparent clone in ReStock, and it might be an easy win. The 1.25m Standard Clamp-O-Tron Docking port uses a lot of the same components as the ReStock part - the .dds files are apparently the same - but the model (or models) have a different name. SSPXR preserves a standard version of the model, but the part switcher adds two alternate color variants with smaller outer diameters, and possibly different cone angles. Indicator Lights will work on the standard docking port, with ReStock (and your ILCE patch) and SSPXR installed, if I delete the section of SSPXR's .cfg file that tries to implement its version of the part. But that also defeats Nertea's intent of having alternate color variants of the port. I figured since at least the base variant looks exactly the same as the ReStock one, your patch for ILCE should work on it (and maybe on the other port color variants) by using the correct references. I said it might be easy, because I thought I could do it by making a copy of your previous ReStock ILCE patch code for the docking port and editing in an AFTER statement that checks for SSPXR instead of ReStock, and then pointing it to the correct(?) model it's using. Unfortunately, it either isn't that simple or I just missed something. The .cfg file SSPXR uses for the docking port is here, and should help identify the model(s) it's looking for: StationPartsExpansionRedux/Patches/SSPXr-StockPartReplacements.cfg
  13. @Snark, I found a couple of Exception Errors when using MH with Kerbal Atomics, the associated LH2 NTR patch for MH, and RealPlume. I wasn't sure whether @Nertea wrote his own patch or whether you're feeding them to him. In any case, I posted in the KA forum here:
  14. I've found a couple of Exception Errors that seem to be a combination of Missing History (v1.7.3), Kerbal Atomics (v1.0.2) and the associated KerbalAtomicsLH2NTRModSupport extra, and Real Plume-Stock (v1.3.1). I think the MH LH2NTR patch in KA is the culprit. - I can run MH with Real Plume without any errors. - I can run MH with RP and KA without the LH2NTR patch without errors (I figured this would be the same as above). - I can run MH with KA and the KA LH2NTR patch without errors. It seems to be when the LH2 patch for MH goes to RP that it throws the errors. The error message on the loading screen is "2 errors related to GameData/KerbalAtomicsLH2NTRNModSupport/hydrogenNTRsMissingHistory.cfg" I'm using KSP 1.7.1 x64 with MM 4.0.2. I tried the above on a fresh install with just the three mods listed. The engines and the associated RP new plumes seem to run fine, so I'm not sure what the Exception is about. EDIT: I've added a GitHub Issue in the KA repository.
  15. @UnanimousCoward, fantastic work, these look really great. I just found out about ReStock and I was almost prepared to suffer without IL. I'd recommend submitting this as is to @Snark to roll into another iteration of ILCE in the meantime, if you don't know if/when you'll get around to the ReStockPlus parts.