KSPrynk

Members
  • Content Count

    118
  • 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. @Nertea, another request on NFeX: the indicator line for the antenna feed-to-reflection defaults to "on". Even after turning it off, adding another antenna brings it back up again, adding clutter to the VAB. Can we get a global Toggle so the indicator stays in the last state (on or off) until that state is deliberately changed by the user? I've added a separate Issue on GitHub.
  2. @Nertea, FYI, I added an Issue on the NFeX GitHub regarding PLTO core orientation and placement of labels relative to the orientation of the new probe cores. These are cosmetic issues, but I think they cause some confusion in trying to figure out, at a glance, which way a probe core is oriented, both in the VAB and in flight. Great job jumping on probe craft; they've needed some love for a while now.
  3. @RJVB09, I just tried this out and it looks like a great. I'm very interested in real world red and brown dwarf systems and the visual impacts associated with shifted lighting spectra. Just FYI, I'm seeing a graphical glitch (I think) on both Brun and Tersa where there's a cloud of "glare" that's not centered on any particular celestial body. On Brun, it's just outside the orbit of Yurff, and on Tersa, it's slightly inside the orbit of Gren. I'm using Kopernicus 1.7.3-2, EVE 1.7.3, and Scatterer 0540. I did this on a separate test instance of KSP 173, with no other planet packs or planetary FX mods. But speaking of spectra.... I'm running my fully modded KSP 173 game with Spectra on the Stock system and SVE, more specifically, a pruned version that just keeps the configs for Outer Planets Mod. There's some kind of conflict with 3LR, which I haven't narrowed down yet, that seems to overlap cloud and lighting effects, with and without the BoulderCo and Improved System folder contents. If feasible, I would suggest supplying graphical FX configs, perhaps with new names, that don't refer to .cfg files that have content that may be re-used amongst other planets, either Stock or add-ons, like OPM, GPP/GEP, ES, etc.. I'm on the fence regarding system placement, relative to Kerbol. Given their distance, Warp Drive appears to be the *only* way to get to them. Are there any non-FTL drives that could make it without game-millennia of travel time? Lastly, can you talk more to your vision for the 3L series?
  4. I thought they got new plumes in Zorg's RealPlumeStock, as of v1.5. Wasn't sure if that was his own implementation or in collaboration to update to new FX format. In any case, EngineLightRelit seems to have gone to a more elaborate parameter format, which I think I first noted in KA, when the LH2NTR issue resurfaced. Without going back and trying to put together older versions of NFE and EngineLight, I was wondering if the EngineLight glow effects were supposed to match the plumes, and whether !MODULE[tjs_EngineLight] was supposed to set the color. My suspicion was that this reference to the module was now pointing to a dead end when using EngineLightRelit.
  5. @Nertea, I love the new plumes on all the engines, but the NFP Electric Engines seem to have issues with inconsistency of EngineLight effects. The stock Dawn Xenon engine produces a blue illumination glow, which appears to be in the engine-configs.cfg folder of EngineLightRelit (v1.6.1.1). The KA NTRs have a reddish glow when using LH2, as expected to match up with their red plumes. The KerbalAtomicsEngineLightRelit.cfg patch appears to follow the same definitions as the Dawn glow that comes with EngineLightRelit. Pretty much all the NFP electric engines produce a bright yellow-tinged glow, regardless of the propellant's plume color. It looks like the NFP patch for NFPropulsionEngineLight.cfg all point to the same !MODULE[tjs_EngineLight]. Is this module supposed to be figuring out the appropriate EngineLight color, based on plume (propellant) color, or is the yellow glow by design for all of them? Or is this NFP EngineLight code obsolete, and in need of a refresh for EngineLightRelit?
  6. @Nertea, @Wyzard, I'm getting an exception error for hydrogenNTRsMissingHistory.cfg in the KA LH2NTR Mod Spt extra, using the new RealPlumeStock 1.5. I'm guessing this is related to the previous issue from June/July regarding the LH2NTR patch pointing to obsolete RealPlume code, and Wyzard's work-around fix. As far as I can tell, the new plume FX are working properly on the MH part (KANDL in this case*). BTW, I've only started checking out the NTRs, but the new plume FX are beautiful. Can't wait to see how all the combustion engines and electric thrusters came out.... *EDIT: I normally remove the BKN NTR Lightbulb, but after a clean install of MH, I get two exceptions, I'm assuming one for each.
  7. Yeah, that was it. I set PhysicsSignificance = 0 in the .cfg file and it behaved as expected. I'm trying to figure out if there was a compelling reason for it being set to 1 (off). I let it Physics Warp 4x under full gravity on a vessel on the pad, no autostruts, then with Rigid Attachment and various autostrut settings and it either sunk a little or the vessel started to wiggle a little (as other parts do), but nothing broke. Aerodrag on de-orbit operated normally too. If anything was going to be physicsless, I guess I would've expected it to be the little dipole loop.... Unless somebody else finds the drawback, I recommend making the .cfg edit for a version update.
  8. @linuxgurugamer, I think I've found a another model bug. The FD-01 dish antenna does not seem to have a center of gravity. Attaching it to the probe core adds the mass, but sliding the part around doesn't offset the vessel CG at all; verified in flight and when viewing KER and RCS Build Aid torques. The other two comm antennas don't have this problem. EDIT: The FD-01 apparently is immune to drag as well. Did a re-entry with the antenna offset by over a probecore's width and there were no entry heating effects or aerodrag torque on that side of the vessel.
  9. 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....
  10. @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.
  11. @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.
  12. @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?
  13. 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.
  14. 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...
  15. @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.