zengei

It wasn't listed as a dependency. I submitted a pull request to fix it.

Neat, I've hated the way KSP handles "science" for a long while now and it's kept me from playing in career mode. I've been thinking of working on something similar but my design was slightly different: Remove the perfect knowledge of the solar system that the Kerbals have right now and introduce the concept of discoverable information. I think at one point Squad had a similar idea, or still does, because if you look at the CelestialBody API, they have DiscoveryInfo. which seems to be a lot like what I'm talking about. The way I envisaged it working was by starting you off with either no knowledge or only basic knowledge of the celestial bodies except Kerbin, the Sun, and maybe Mun and Minmus. So if you want to know about Duna, you first have to discover it by performing an astronomical survey and detecting it. Then, once you know something is there you have to perform continued observations of it to derive information such as its orbital characteristics, size, mass, etc. Want to know if it has an atmosphere or what the atmosphere is composed of? Perform a spectroscopy experiment. All of this data would also be subjected to errors, based on the quality of your equipment or the number of observations you perform. Perform more observations, use better equipment, or get smarter scientists to lower your error. Why is this useful? My thought was to turn the map view into just a representation of the data we have, not a perfect representation of the system as it is. So if you add a maneuver node, the orbital path it calculates would be determined by your best current estimate of a CelestialBody's position, mass, velocity, etc; which may not correspond with reality. So the more science you perform, the better your data gets, and the more useful the map view becomes. I also thought of pairing it with a "simulator" type system, like in SRL, KCT, or HoloDeck so that you could simulate your flight without spending funds, but the simulation would be based on the data you have. So, for instance, if your current data underestimates the mass of Duna, you may be able to successfully escape Duna in the simulation, but may not actually have enough delta-v in reality. Or, for example, Duna may be represented by a perfectly flat sphere in simulation until such time as you launch a SCANSat scanner to map its terrain. By making the action of performing science yield relevant knowledge, I think you make it much more engaging, realistic, and educational to boot. I've also thought about the concept of "RawData" and "ProcessedData". Basically, sensors would produce RawData which could then be converted by instruments into ProcessedData, which could then be used by Kerbal scientists to produce "Facts" (i.e. knowledge). The difference between the two being that RawData is reusable: it can be reanalyzed to produce either new Facts or Facts with a lower amount of error once you have better equipment or smarter scientists. ProcessedData can only yield specific Facts with specific amounts of error. Once you've determined that Duna has X mass from ProcessedData, that's all the useful information you can glean. However, RawData is extremely large: so it takes up a lot of storage space and would take forever to send back to Kerbin. So your choices are: 1) Spend a lot of time and energy transmitting the RawData. 2) Convert the RawData to ProcessedData and just transmit that. 3) Return the RawData on a ship back to Kerbin. 4) Send a scientist Kerbal to the RawData to analyze it in situ. The only thing that's kept me from doing this are the huge amount of disparate areas it would have to touch and whether or not it's even feasible to do some of the stuff I want to do. Any thoughts on doing something similar? EDIT: Fully reading your design doc, I notice you mention something similar to the Raw/ProcessedData concept under "Unorganized Thoughts".

Deadly Reentry should be fine in CKAN with this pull request.

A mod needs to explicitly support the toolbar, it's not automatic.

Heads up, the release on GitHub doesn't include the distribution zip file so CKAN hasn't indexed the update yet.

Just a heads up, your latest distribution includes a MiniAVC.xml file, when that should be created by the plugin on first run.

It's not updated on Kerbal Stuff.

Okay, I figured out a couple of scenarios in which this could happen. Pushed a new version, 1.1.0, with the fix and a few other changes. The recommended way to change settings is now via a Module Manager patch, not via a UserSettings.cfg.

As a heads up, the new version of PlanetShine (v0.2.3.1) is now live with those changes. Specifics are in the changelog, but basically DistantObjectEnhancement still uses CelestialBodyColor and PlantShine now uses PlanetshineCelestialBody nodes. No more having to overwrite the PlaneShine config, yay.

I've seen this happen once, somehow the game settings get persisted while in plane mode. I've never been able to replicate it, or devise a scenario in which it could occur. To fix, just reset your input settings.

Hi Valerian, did you happen to see this pull request I made?

Thanks a lot for your help. One more thing, I've submitted a pull request to PlanetShine that will allow it to read CelestialBodyColor configuration nodes from any .cfg file, meaning OPM will no longer have to distribute a CelestialBodies.cfg which overwrites the default one. For this to work the file OPM/CelestialBodies.cfg just needs to be modified to include the intensity, atmosphereAmbient, and groundAmbientOverride fields that the one in the PlanetShine directory includes, and it should just include the configuration for the new OPM bodies, not all of them. This should streamline the metadata and packaging a lot as well. I would make the changes myself but I couldn't fine a publicly accessible source repository for OPM, does one exist? Thanks.

So I'm working on cleaning up the CKAN metadata for Outer Planets Mod and one of the sticking points is the custom versions of the Eeloo ribbons which conflict with those distributed by the Final Frontier mod. Looking into it, is there any reason why the custom Eeloo ribbons aren't packaged in OPM/Ribbons like the others with an entry in CelestialBodies.info for Eeloo? Final Frontier's code is such that it will overwrite the existing info with the one read from that file and this avoids the conflict. I've tested it myself and it works fine; OPM's Eeloo ribbons show up even though Final Frontier's default ribbons are still in place. Also, the distributed zip includes some .svn directories in the ribbon folders. These can be filtered out by CKAN, but they're of no benefit to manually installed users either.

This should be updated now.

Thanks, CKAN should be up to date now.

BahamutoD, can you push an update of the BDAnimationModules assembly to: https://github.com/BahamutoD/BDAnimationModules/releases ? It's what CKAN currently indexes for that dependency, thanks.

I've already done it here, it should show up if you do an update.

v1.0.0 out which is just a minor fix for a warning in the log on vessel load and a bump to a 'stable' version number.

Well...

See this issue I created.

Thanks a lot. I prefer to have a single distribution source (besides GitHub, which hosts the source) and I personally prefer Kerbal Stuff to Curse.

The metadata is here and here, I've created a pull request on your behalf to update it.

Just now seeing the PFD, that would be an awesome addition. I would love to also see a trend indicator on the speed tape and mayhaps customizable markers (V-speeds, max and minimum safe speeds). I assume the speed shown is the true airspeed (and by extension ground speed, since Kerbin has no wind)? With the new stock aero/FAR it may be possible to show an indicated airspeed and maybe mach number and angle of attack indicator. Now we just need some VORs scattered across Kerbin so I can fly /A to and fro.

v0.4.1 has been uploaded to GitHub and Kerbal Stuff which adds compatibility with with KSP v1.0. This version is not compatible with previous versions of KSP. EDIT: And CKAN has the new version now as well.

Glad to hear it's useful.