KSPrynk

Members
  • Content Count

    152
  • Joined

  • Last visited

Community Reputation

46 Excellent

About KSPrynk

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

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

  1. What's the problem? I'm using CTT 3.4.1 in KSP 1.10 x64, with MKS loaded, and didn't notice anything amiss.
  2. Can someone using GC in KSP 1.10 x64 confirm that they can add a vessel to a Ground Kit Container in the VAB? I can Select a part or sub-assembly from the container PAW, but when trying to Select a vessel, the Stock KSP load menu comes up and neither Load nor Merge has any effect. Is there a GC loading GUI that's supposed to appear, like there are for parts and sub-assemblies? EDIT: Nevermind. I see someone caught this earlier as GitHub Bug #77.
  3. @Avera9eJoe, how does one get this this stand-alone version of KSPRC City Lights doing manual install via Spacedock?
  4. @sarbian, I can confirm similar anomalous behavior with the Autopilot in KSP 1.10 x64 with MJ 2.10.0: 1) When using Landing Guidance to land at a map selected target on the Mun, my rudimentary two-stage lander will not first orient to an upcoming maneuver node before going to warp. Upon exiting warp, it scrambles to orient and fires ASAP, as there is no longer the usual buffer of X seconds upon exit of warp, to fine tune and re-settle into proper orientation. I'm wondering if the maneuver node is even being created, because it doesn't appear in the Navball (see also item #4 below), the point toward maneuver node SAS button stays dark, and there is no burn indicator. 2) Suicide burns are no longer such - the descent burn starts almost immediately at a small percentage of throttle, which increases as it gets closer to the ground (my lander has a 0.54 Kerbin g TWR on a full tank). This appears to be a function of the autopilot trying to keep up with a continuously lowering target speed, rather than doing the math to calculate when to burn to reach zero velocity at a targeted altitude (which appears to be 500m AGL, before the straight down "final descent" phase). Neither Land at Target nor Land Anywhere seems to stabilize the roll angle during descent. 3) On the Ascent Path Editor, for the Classic Ascent Profile, when Automatic Altitude Turn (AAT) is turned on, the Turn Start altitude and velocity sliders no longer work; the turn altitude is fixed at 2.8km, and turn velocity fixed at infinity. Despite that, when the AAT is turned on, it doesn't actually perform a turn until well past the listed altitude, and only a very short while before hitting the targeted apoapsis. I only get a proper AAT when I turn it off and enter the values in the alternate dialog box. One item of note: the ascent guidance does create and display a maneuver node for circularization burns. 4) The "show ascent navball guidance marker" hasn't appeared for a few versions now (since at least MJ 2.9.X); the show/hide button has no effect.
  5. True. But that's also free time to figure out how the effects work in the base game. So far, I've found CometDefs.cfg in the Squad\Resources folder. The parameters are surprisingly well documented with comments. There's also part.cfg in GameData\Squad\Parts\Misc\PotatoComet. I was going to see if I could briefly turn Minmus into a comet. Alternatively, it may require spawning arbitrarily sized Stock comets inside the MPE cometary objects, to give something for the VFX to latch onto.
  6. @Avera9eJoe, thanks. Just to be clear, I'm loving this optimization of Spectra. I hadn't seen the more recent Squad re-vamp planet textures up to this point, because of Kopernicus going into a temporary coma at 1.8.1. It's weird seeing how comparatively bland the terrain on Vall, Tylo, and the other re-touched planets are compared to what's come out in 1.9.X and 1.10. As I suspected, Squad's folder blew up a few hundred MB since 1.8.1, so getting some of that back on Spectra makes my RAM very happy....
  7. @Avera9eJoe, I've tried out Spectra in KSP 1.10 with EVE 1.8.0.2 and Scatterer 0.0610 (which I think are the most up to date) and everything appears to work - or at least not be obviously broken. I did have a question about Jool. The new, highly detailed, textures for the surface seem a bit muted with Spectra. Was this a deliberate adjustment, or just a side effect of the cloud layer settings? I took a craft on a death plunge into the atmosphere, and it seemed like the clouds were a bit more tenuous than usual, to the point where I could really only tell what was a cloud by time warping along. I thought Jool atmo layers were a bit more distinct in previous Spectra versions, but maybe I was thinking of Eve. To spice things up a bit, I copied the VallDust Object and renamed it JoolDust, and arbitrarily tweaked the color (40,100,70,70) and altitude (20000). This may have added some subtle ring-like optical effects on the planet (I have to revert back and see), but it felt more like a real gas giant, with various layers of different gases as temp and pressure changes. Is there a guide to EVE parameters out in the wild? I'm stabbing in the dark on the settings - for instance, I just assumed Color values were Red, Green, Blue, and Opacity. The leftover VallDust settings resulted in a relatively thin layer of fog, that I fell through quickly, so now I'm looking for how to make it thicker (in height). But I don't know how that impacts performance. My goal is a visual trip to the bottom that provides incentive to do a Galileo-style probe mission. I'm wondering if it's possible to duplicate the current surface textures as a translucent second layer, a few tens of km up, perhaps with shadowing, and a final layer of "superfog" near the crush depth line, to create a murky, dim layer of atmo between the two. It'd be a great place to hide some Carl Sagan-esque terrain scatter/BG surface feature life forms hanging in the air....
  8. @Exo's Lab, now that KSP 1.10 has dropped, have you thought about adding the new comet coma/tail FX to Geito and Lint/Mikey? That would look fantastic.
  9. This will probably work (I'm assuming you know how to backup your save and re-install if it doesn't): Using a text editor, like Notepad, go into Restock.restockblacklist and delete the line for Squad/Parts/Engine/rapierEngine/ and save it. This should prevent ReStock from blocking the Stock model from being loaded. Then, go to ReStock\Patches\Engine and find restock-engines-jet.cfg. The Rapier appears to be the only engine in this .cfg file, so your options are: 1) Delete the file completely (or, if at some point, more engines are added, delete all the lines that fall under the Rapier section). 2) If you want to keep the ReStock special effects, you might be able to clip out all the lines relating to the mesh and model, between the author and EFFECTS, but this line may be problematic: @PART[RAPIER]:HAS[~RestockIgnore[*]]:FOR[ReStock] I think you can get by with just @PART[RAPIER], to tell it that everything after gets applied to the Rapier. There's a Wiki here... https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax ...but I've been learning syntax the same way Antonio Banderas learned how to speak to Vikings in The 13th Warrior.... Remedial action, in case this screws everything up, should be to close KSP, delete your ReStock folder, and then just re-install ReStock. Side effects may include harmless tech tree duplicates that won't go away unless you start a new game, so I would experiment with this in a new-start Career game. Or better yet, create a separate, bare bones, install of KSP under a different folder and experiment in that.
  10. I'm using Stock Visual Enhancements with Spectra by pruning out redundant EVE, Scatterer, and Texture files or lines in combined .cfgs that cover the Stock planets, or anything that looks like a duplicate of what comes in Spectra (eclipses, shadows, ), leaving behind just the OPM ones. I probably haven't clipped it all out, but it works. I think Eeloo doesn't receive the Spectra changes when I do this (since it gets moved to Sarnus), but it's better than nothing. Poodmund's OPM Visual Overhaul may get re-worked eventually; he last commented on it in March....
  11. I understand the frustration, but it all it really does is extend the mapping time (tidally locked moons will be a pain) and forces you to be more clever in how you choose an orbit. My initial gripe, when this capability first appeared, was that the sensor was still consuming full power, even when it couldn't map anything, which meant I still had to have plenty of batteries to get through orbital darkness. Regarding a new imager that doesn't require daylight, I'll leave this food for thought: 1) An illumination system - near-infrared, UV, or visible - that lights up the ground from orbit would likely be insanely large and powerful. Read up on proposals by Krafft A. Ehricke for what were essentially orbital heliostats (https://www.nytimes.com/1977/02/06/archives/huge-space-mirrors-proposed-to-light-the-night.html). 2) A more realistic approach is probably a space-based sensor that operates in the thermal infrared bands, longwave infrared being a good one if you want to go hyperspectral. Thermal infrared is emitted light, not reflected, so it can work in the dark. One drawback is your sensor pixels will be noticeably bigger than your average visible light pixel, and your optics size would scale up proportionately (and your mass even more so), assuming you want the same resolution and field of view in your image. The really sensitive thermal imagers are also cooled to cryogenic temperatures, which would translate to increased power consumption (some of the ones pointing outside the solar system are cooled with liquid Helium (ex., Spitzer), but no need to get crazy here). EDIT: Regarding extended mapping time, I haven't looked at a worst-case body rotation period, and how long the generated contracts run. Something to maybe look into....
  12. @Avera9eJoe, I'm favoring this (unless the 1.10 textures don't live up to hype). Partly because I don't want the heartache of having to choose on a per planet basis, but, more pragmatically, anything that saves RAM by eliminating redundancy of (assumed) equally good results is a win. I think the value of Spectra is giving the extra ambiance and subtle details, which the base game doesn't provide, that can be enjoyed everywhere from ground level to high orbit. Alternatively, if there's still demand for the alternate terrain and textures, you may want to consider dividing up the Spectra folder structure to make it easy to prune redundant material out, or give instructions for quick and safe removal. Perhaps a MM patch or settings.cfg file could allow users to enable or disable loading of redundant material. This would please the terrain/texture fans, while helping out the RAM misers. I guess one thing to look into is which, if any, EVE or Scatterer effects are broken when using the Squad terrain. That might merit separate .cfg files.... I can also think of some new effects to look into for the future: - Infrequent rain, snow, and/or ground lightning, perhaps with dedicated cloud layers, separate from the planetary global fractals (or however they get derived) on Kerbin, Eve, and/or Laythe. - Infrequent large scale dust storms and/or fog (localized, ground level, "dirty" or white clouds). - I don't want to pre-judge the new 1.10 comets, but I'd be mildly shocked if Squad had atmospherics to go with them. If there aren't spectacular tails and geysers that come and go with distance to the Sun, then we may just get dirty textured asteroids on highly eccentric orbits.... I'd be curious if weather FX placement algorithms can be bounded by lat/long boxes or biomes to certain regions (ex., Kerbin's deserts for dust). Perhaps frequency of FX appearance can be tied to seasons derived from planetary distances from the sun or pulling the orbital LAN coordinates. There are so many factors that trigger weather, but I think some simplified, generic, rules could carry the day, if the appropriate situational data can be queried from the game. Perhaps to avoid continuous computation, the "weather" could be "refreshed" at relatively large intervals, and planetary or regional flags to enable FX could turn on and/off as appropriate daily rotation and/or annual orbital timing parameters dictate.
  13. @micha, @SuppaTenko, going back to some discussion a while back about limiting experiments to Kerbin SOI, I was thinking about what experiments shouldn't have different results (and increasing science return) based on what body you're orbiting. Microgravity material and life science experiments that aren't particularly influenced by local space radiation or magnetic fields come to mind. Picking through the science defs from NEOS got me interested in how they're defined in the KSP wiki, and ways to constrain where a experiment can be performed. I use DMagic Orbital Science and SCANsat and some of those parts get clever in defining discrete altitude bands where they can be used (which I have to pick through to figure out how). One thing I haven't come across so far is a way of allotting science points without any multipliers for the body being orbited, and constraining it to only be performed once (or with diminishing returns) anywhere within the solar system. I think this would be appropriate for some of the really high payoff experiments, to prevent a tech tree sweeping situation similar to what SuppaTenko described, by running them across Mun and Minmus orbits.
  14. @micha, the Kemini HGR fixes look great. At some point, you may want to update the OP instructions and/or KSPedia to explain the "move" function when the experiment storage location and lab are in separate parts (which I assume only applies to the HGR SoyJuice family). I got it on the second try. The first time, I think I did a sequence that led to a logical dead end that closed up behind me, but I haven't been able to replicate it since.
  15. Thanks. I got a sense of how Kemini_module and StoreExperiments worked once I figured out why the SoyJuice descent and orbital part cfgs had only one or the other, but every other craft had both. Regarding game balance, I'm trying to reserve judgement until I start a new career (waiting for KSP 1.10 and Kopernicus) and try it out, but the 2nd level KEES and Life Science experiments have huge science defs, which, at first glance, look like they become tech tree sweepers when the multipliers from further planets come into play. Part of me says these types of experiments would, in reality, not be significantly different just by changing locales. I noted further upthread a discussion about limiting KEES (and maybe the rest?) to just Kerbin SOI use. OTOH, I do recognize that getting these unique experiments up, assembled, and more importantly, back down, adds a layer of complexity that would be incentivized by a high science payoff. Still, that's a lot of science....