MOARdV

Members
  • Content count

    1525
  • Joined

  • Last visited

Community Reputation

1302 Excellent

About MOARdV

  • Rank
    Rocket Scientist

Recent Profile Visitors

3864 profile views
  1. If I follow what you're asking correctly, yes. You could write a MM patch to add entries to the PERSISTENT_VALUES node in the MASFlightComputer config for the pod in question (or just edit the pod config, of course). That should set the initial page that is selected at part load time to whatever you specify. You would need to identify the MFDs, but even that's pretty easy to do with a tweak to the page configs.
  2. I don't know how dimming is done in stock (that is, how it decides to dim). The knobs that control it are GalaxyCubeControl.Instance.maxGalaxyColor = galaxyColor; // <-- appears to scale the skybox color (skybox texture color * this = displayed color) GalaxyCubeControl.Instance.glareFadeLimit = glareFadeLimit; // <-- I don't remember what this does. I set it to 1 in DOE.
  3. DOE does not control dimming the skybox when facing the sun. That is a stock behavior that (I assume) Kopernicus is overriding. Although maybe I should see if DOE can take that over from stock so it's consistent.
  4. Thanks to @Chaumas, I've got the feedback I needed on Mac compatibility. RasterPropMonitor v0.29.0 is now officially released for KSP 1.3.0. Changelist is on GitHub, along with the release, of course.
  5. It sounds like your expectation of what this mod does may not match what it's intended to do. DOE provides a way to see planets at great distances, and it provides a couple of ways to spot vessels outside of the KSP vessel loading distance of about 2km: Distant Vessel Rendering draws a ship when it is at extreme distances - beyond the vessel loading distance - so that very large space stations / space craft won't suddenly appear at that distance when they're loaded. Vessel Flares draw a point of light that represents the sun reflecting off of the vessel. In both cases, you're not going to see the distant vessel or flare on the dark side of a planetary body, because it's dark. The vessel you want to see needs to be illuminated by the sun, and it needs to be at an angle where you can see the light reflect off of it, and you need to be in a position where the sunlight isn't overwhelming your field of view. The best spotting times / positions tend to be when you have passed the sunset, or are approaching sunrise, and the sun is still above the horizon from the point of view of the vessel flare. There are other combinations of positions that work, but all of them require the vessel you're trying to see to be illuminated by sunlight.
  6. I've updated the mod again (after a few quiet updates that I didn't post here). I am now including an all-new IVA for the Yarbrough08 Mk. 1-1 A2 command pod, since I keep returning to it for IVA development (I still haven't found an IVA layout as well setup for the style of IVA I want to create). I've arbitrarily bumped the revision a few steps, since I think the DLL interface has stabilized for the most part, and it will be ready for a 1.0 release once I get a couple of other things updated.
  7. Thanks to the Linux people who provided feedback. I'm still hoping to hear from a Mac player before I stamp an official release: does the test build on DropBox work (no pink blocks on monitors, that sort of thing)?
  8. I looked at the log. You have a lot of mods, and a lot of exceptions and errors in that log that have nothing to do with RPM. I suspect you have at least one mod that is not 1.2 compatible in there, or it does not play well with others, and it is the problem. However, I'm not installing every mod you use to try to find it. I'd recommend you set up a second installation of KSP, and start removing mods to figure out what the minimal combination is that reproduces the errors you're seeing.
  9. Glad to hear that, and welcome to the forum! If a Mac player can give me the green light (hint, hint ), I'll kick the official release out.
  10. There is a test build on DropBox. This is not a formal beta, but a test release to see if the new shader management system works for Linux and OSX (I've tested it locally for Windows default and -force-glcore). I would like feedback from Linux and OSX players: do the monitors still show pink blocks instead of text? Or are they working? Are there any other unexpected pink blocks? If this finally solves the shader problem for Linux, and it doesn't break OSX, I will have an official release later this week, once I have a chance to tidy up the code changes I made.
  11. There are also a lot monitor<date><somecode>.png files in the screenshots folder, probably implicating RPM realizes it has a problem. How do I get at the logs to post those too? Font rendering in Linux is a known issue i am trying to find a solution for, unfortunately. The monitor images in the screenshots folder are a feature of RPM where monitor contents are saved with the screenshot - it will do that regardless of whether a problem is present, unless you edit the monitor config file to switch it off.
  12. Distant Object Enhancement v1.9.1 is out. This update includes new configs for RSS, courtesy @Phineas Freak, as well as (hopefully) a fix for localized body names during mouse over in flight.
  13. It is possible to make a DLL that will do what you are asking. However, I do not use BDArmory, so I am not interested in adding that capability and having to support it in RPM. I am willing to provide hints and suggestions for someone else to do make such a DLL.
  14. The exceptions are all happening in StageRecovery, in the method StageRecovery.RecoveryItem.SetRecoveryPercentages () You need to start with that mod / modder.
  15. Thank you for letting me know. It looks like I to do something different for shader creation / bundling. The Squad official process isn't working, or it's got some hidden steps somewhere. *sigh*