MOARdV

Members
  • Content count

    1579
  • Joined

  • Last visited

Community Reputation

1363 Excellent

About MOARdV

  • Rank
    Rocket Scientist

Recent Profile Visitors

4879 profile views
  1. I'm working on some code to return terrain height at an arbitrary location. I already know about CelestialBody.pqsController.GetSurfaceHeight, and that works for a first-pass. However, I'd also like to be able to account for buildings / anomalies / whatevers when I am querying. I haven't really done much with the PQS stuff or the city related code, so I'm not sure where to look. Note that this is not necessarily for pinging directly below the vessel - it is for an arbitrary location on the planet which may or may not be in physics range. Otherwise I could use some of the vessel data fields and a physics raycast to find what I need.
  2. ASET Props version 1.3 was released for KSP 1.0.x. The props themselves are usable with any KSP version between 1.0 and 1.2.2. What you will need for those props to work is the correct version of RasterPropMonitor. The last version of it that works with 1.2.2 is v0.28.1
  3. There seems to be two variants of the RD-0146 that I've seen. There's the model with the nozzle extension (which the old KOSMOS URM pack modeled), and a variant that does not have the extension, which this pack and Bobcat's old soviet engines pack model. I'm not sure if that's really two different variants, or if many of the photos on line are of models of the engine with the extension removed.
  4. Okay, if it's intentional, then it's good. I certainly am not one to turn down gratuitous greebles, especially when they have SFX attached to them, like puffs of RCS.
  5. I hate to be *that guy* -- but are you sure the RCS Thrusters provide "the unnecessary boost needed to align the observatory". Wouldn't that be "the neccessary boost"? If it's unnecessary, why would I want to use them?
  6. After a long hiatus, I have released MAS v0.10.0. This includes a few quality improvements, and one major new feature (support for a context/right-click menu option that can in turn trigger MAS actions). Available on GitHub.
  7. L.C.A. project v1.2 Energia in KSP d25.10.17

    This works in a similar way, but it allows you to place the boosters in the correct location for the Energia configuration, without having to be precise rotating parts to align correctly.
  8. L.C.A. project v1.2 Energia in KSP d25.10.17

    For what it's worth, the CryoTanks mod lets you switch without having to add a MM config. That's what I've been using (along with an LH2 conversion for the RD-0120, of course).
  9. L.C.A. project v1.2 Energia in KSP d25.10.17

    I made a ModuleManager patch that makes it a little bit easier to build Energia. It adds attach nodes on the side of the E600 tank for the Blok A boosters, it copies the stock Hydraulic Detachment Manifold part to create an "Energia Booster Decoupler", and it adds a side node to the Zenit Block A fuel tank to attach to the decoupler. The boosters are correctly placed and rotated at +13.5 degrees and -30.0 degrees when using these nodes. It does not work with symmetry because of a KSP bug, so you have to manually attach each part. And, because it does not work with symmetry, you have to adjust fuel and engine settings on each booster. What I find works easiest is: 1) Surface attach the booster fuel tank, add the nose cone, engine, and other parts. Adjust fuel, engine thrust, gimbal, and autostrut settings. 2) Attach one Energia Booster Decoupler to a node. Remove the surface-attach fuel tank from step 1. Node attach it to the decoupler. 3) Alt-select the decoupler so you clone the decoupler + Block A. Attach to the next side node. Repeat for the other side of the craft. ModuleManager config (place somewhere in GameData) on DropBox. Config is public domain, so anyone may do anything with it. No guarantees / no warranty. It worked for me,. but I also have modified my installation a lot.
  10. KSP Weekly: Godspeed, John Glenn

    This makes me happy. The procedural fairings have been a bit ... off ... since they showed up. I'm glad it was a bug, and it's being fixed.
  11. A similar problem happens with external cameras in RasterPropMonitor. It appears (in the RPM case, at least) that scatterer is doing "something" during the render, but it's not using the external camera's parameters. Instead, it looks like it's using the main game camera's parameters (like something in the shader wasn't updated based on the external camera's Camera settings, perhaps).
  12. Most of my learning has been from looking at a couple of posts in the MM thread, and looking at what other people have done. Although that link to GitHub is a good resource that I probably should have looked at sooner.
  13. Yep. RealChute moves parachutes into the "none" category, and then adds them to its custom parachute category. KSP 1.3.1 changed a name that RealChute needs for that to work. The patch could possibly be made more generic by searching for the RC part modules instead of particular part names, so it would pick up parts from other mods: @PART[*]:NEEDS[RealChute]:HAS[@MODULE[RealChuteModule]]:FINAL { %category = Utility } (that's untested, so it may not work)
  14. I don't think there's anything as succinct as the CONTEXTREDIRECT config pages, but it should be quite possible using Lua scripting.
  15. A bit of background: The original RPM implementation had cameras defined as external parts (eg, the ExtCam part included with RPM), with a simple module on the part to identify them numerically. It could have been implemented as a "Name the camera" module, where each part could have a unique name that the user typed in. The downside to that approach is it has a slightly steeper learning curve, since the player would have to know in advance what the supported camera names were, and then make sure the camera parts were appropriately named in the VAB. That adds a lot of support overhead, since there will be frequent "How do I make the cameras work?" questions. (Incidentally, the "Name the camera" approach is what I implemented in MAS, but MAS also doesn't require the use of a hard-coded list of camera names - it can iterate through all of the cameras without knowing names in advance) In the case of the ALCOR lander pods, alexustas tightly coupled the lander pod with the IVA. The unusual (non-ExtCam) camera names all refer to transforms in the ALCOR lander, giving alexustas precise control over how that MFD works, and what it displays. I suppose it would be possible to update RPM to allow arbitrary names in addition to the simple ExtCam# implementation. Or, alternatively, to have a list of predefined camera names and require the user to select one for each installed camera (but see caveat later). That could be dicey if the user picks names that correspond to transforms on a part, like the case of the ALCOR lander - RPM would have to know how to prioritize the duplicate names. Alexustas uses a monochrome shader for a CRT-styled display in one of his lander can IVAs, and he uses the noise/gain shaders for some of the other MFD views. However, they're mostly in the currently unreleased update to the ASET Props and Avionics pack. The props included with the RPM distribution are rather old, and the configs for them were written a few years ago, prior to the shaders being available. I personally am not motivated to update the basic RPM IVAs and props, since I don't use them (my current IVAs all use the aforementioned ASET props pack). It would be feasible to add support for switchable shaders, and even tie them in to the tech tree, although I'm a bit hesistant to go that route since a) I never play career, so I wouldn't be able to thoroughly test the feature, and b) it opens a can of worms with respect to restricting other features in RPM based on available tech. Your proposal is well specified, and it would definitely be a way to add RPM features to earlier-era space flight without seeming totally out of place (I think there's a mod that actually uses more than one IVA, depending on the tech that was unlocked, but I don't remember which one that was) Now, the caveat I mentioned earlier: I am no longer developing significant features for RPM. I had a number of features I wanted to add to the mod, but I had to make a choice: Change existing functionality and break IVAs other mod authors created until they updated (not happening). Add new functionality that duplicates and enhances existing functionality (forcing me to maintain two similar code paths). Start a new mod. I went with the third option. I'm keeping RPM functional for now while I get MOARdV's Avionics Systems tidied up for a stable release, but RPM is basically in maintenance mode. I'm willing to accept new features if someone else submits a pull request on GitHub, but I don't have the time to develop and support major new features for this mod.