Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    I've been doing some experimenting and what I'm seeing is a combination of good news and bad news. First, the good news. I think the NavBall and KER's surface latitude/longitude readout are correct. Both appear to be recognizing the tilt and are accommodating for it. The bad news is that KER is providing orbital elements relative to the ecliptic. That is, when I put a vessel in an equatorial orbit around Kerbin, KER says my orbital inclination is 23.4 degrees. If there were some sort of a toggle in KER to switch to a geocentric-equatorial readout, I think everything would work great. I didn't test MechJeb because I don't use it and I'm not familiar with it.
  2. OhioBob
    I just thought about the NavBall. How is it oriented? Is N-S still up-down, or is it tilted to the axis? This is really part of the same issued I talked about with the coordinate systems. @Dagger, I love what you've done here and I believe it has great potential, but I think there are farther reaching issues that need to be addressed to really make it practical to implement. Perhaps there are other members of the mod community, such as the KER and MechJeb devs ( @jrbudda and @sarbian ), that should get involved. There really need to be a way for the game to recognize the tilt of the axis and have the NavBall and position/orbital element readouts displayed in a geocentric-equatorial system. Perhaps there could be a way to toggle between the current coordinate system and one relative to the equator of the current body. The issue about orbit contracts is also a very good point.
  3. OhioBob
    In real life there are many different coordinate systems used. We usually define a spacecraft's orbit and position relative to the body it is orbiting. For spacecraft orbiting Earth we use a geocentric-equatorial system, and for those orbiting the Sun we use a heliocentric-ecliptic system. In KSP everything is relative to the ecliptic because none of the planets have axial tilt. But if we were to introduce tilt to Kerbin, for example, I'm guessing that KSP will continue to use the ecliptic system even when in orbit of Kerbin. That could introduce some problems, though I'm not entirely sure what the ramifications are. It could be very confusing at the least. (edit) I think one of the potential problems is if we are trying to target some specific spot on the planet for a landing. We would really need, in that case, a geocentric-equatorial coordinate system. I realize this is probably way more than you've considered at this point. But being able to have alternate coordinate systems is probably something that needs to be addressed in the future to take full advantage of axial tilt.
  4. OhioBob
    @Dagger, I understand that the axial tilt is constant for a particular planet. (Of course in real life there is axial precession, but that's not we're talking about.) What I mean to ask is this... In the image you post, Earth's axis in tilted toward the right. Using your mod, will all other planets to which I give an axial tilt also have their axes tilted toward the right. Or is it possible, for example, to have one planet's axis tilted to the right, and another planet's axis tilted to the left (or toward us or away from us).
  5. OhioBob
    @Dagger, this is interesting. Congrats on figuring it out. I have a couple questions: 1) Can the direction of tilt be specified? I understand that I can tilt an axis X degrees, but can I say I want to tilt it X degrees in the direction of Y longitude? Or do all the axes tilt in the same direction? 2) Does this have any affect on the coordinate system used for orbiting spacecraft? For example, will the inclination of a spacecraft's orbit be in reference to the ecliptic, or to the planet's tilted equator?
  6. OhioBob
    I've already made that change for the next update (unless someone else on the dev team changes it back).
  7. OhioBob
    It might make more sense if you look at a part config. Below is the config for the OX-STAT Photovoltaic Panels, As you can see, it has a MODULE in it with the name "ModuleDeployableSolarPanel". Only solar panels use that MODULE. So what my config does is search the parts and finds those having a MODULE named "ModuleDeployableSolarPanels". It then adds to that MODULE the line, useKopernicusSolarPanels = false It's just the same as if you manually added that line to each solar panel config, like this:
  8. OhioBob
    There are definitely planet packs out there that add other stars, GPP for example. It was when the mod devs started adding other stars that the limitations of the stock solar panels was discovered. But if you have no plans to use any of those planet packs, then it's understandable why you might want to turn off Kopernicus' solar panel module.
  9. OhioBob
    Yep, that should work too. The only issue I have with that method it is requires editing a Kopernicus file. If Kopernicus updates, you have to edit it again. With my method you can just drop the file into GameData and forget it.
  10. OhioBob
    I don't think you need to turn off Kopernicus' solar panels, but if you really want to, you need to edit the part configs. This can be done with a module manager patch. I think the following does it: @PART:BEFORE[Kopernicus] { @MODULE:HAS[#name[ModuleDeployableSolarPanel]] { useKopernicusSolarPanels = false } } What this does is find every part that has a "ModuleDeployableSolarPanel" module and adds "useKopernicusSolarPanels = false" to it. Just copy and paste the above code into a text editor, like Notepad, and save it as a text file but with a .cfg extention. You can name it anything, something like UseStockSolarPanels.cfg. Then just copy the file to somewhere inside your GameData folder.
  11. OhioBob
    @garwel, we've decided on the following custom configs for Galileo's Planet Pack and Grannus Expansion Pack. You said you'd be willing to add this to Kerbal Health, so we'd be grateful if you can do that. If you see any problems with the configs, please let me know. I've included every celestial body in GPP and GEP, which may be more than is necessary. Many of the bodies, specifically moons, have the same settings as they would have by default, so including them in list may be redundant. If you want be to remove these redundancies to trim the list down in size, I can do that. Thanks for all your help.
  12. OhioBob
    Yep, I already figured that out by experimentation. Thanks.
  13. OhioBob
    As patient as is needed to quietly wait until Thomas can find time in his busy schedule to release an update. There are already planet packs that have other star systems. That's been a thing for awhile. I think some people have messed around with blackholes too, but I don't know for sure about that.
  14. OhioBob
    We removed it only because it was an eyesore that ruined the view of Tellumo's rings when in the Tracking Station or Map View. Didn't realize Lili wouldn't be able to be targeted. We might have to undo it. In the meantime, if you want the orbit line body icon back, find the following file, GameData/GPP/GPP_Planets/Lili.cfg Within the file, find the following code and delete the two lines line in red. Orbit { referenceBody = Tellumo color = 0.5,1.0,1.0,1.0 inclination = 0 eccentricity = 0 semiMajorAxis = 1455000 longitudeOfAscendingNode = 0 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 0 epoch = 0 icon = 0 mode = 0 } BTW, not being able to target Lili doesn't mean you can't effectively reach it, it just means you don't have some of the usual tools to help you.
  15. OhioBob
    @Tyko, I wonder what would happen if you just did a terrain offset. Try something like this: @Kopernicus:AFTER[GPP] { @Body[Iota] { @PQS { @Mods { VertexHeightOffset { offset = 2000 // any positive or negative number, will move terrain upwards or downwards } } } } } If it changes both PQS and ScaledVersion, then you'll gain nothing. But if it changes one and not the other, maybe you can get the radii of the rims to match. (I'm starting to grasp at straws.) (edit) Adding the above means that you should also delete the cache before restarting the game. (edit 2) This might not work on oceans worlds because it could change sea level. It would have to be tested.
  16. OhioBob
    The scaled version is just a color map and a normal map. ScaledVersion { Material { texture = path/colorMap normals = path/normalMap } } The PQS is a lot more complicated. It can be just a height map and a color map, but often there are additional PQSmods that contribute to a planet's terrain. There are all types of PQSmods that can add height noise, craters, color, etc. Virtually an entire planetary surface can be generated using PQSmods.
  17. OhioBob
    It might just be the viewing angle. When near a body, i.e. 25-30 km, the horizon is much closer then when we're at a high altitude. It could be that the mountains you're seeing in the ScaledVersion are over the horizon of the PQS. As the altitude increases, the PQS horizon moves farther away. Perhaps at 100+ km the previously "over the horizon" terrain will come into view to where the PQS becomes a closer match to the ScaledVersion. The above is just a guess. I really don't know enough about how it works to say for sure. It could be that there's more to the problem than I thought.
  18. OhioBob
    I don't think changing altitudes will necessarily eliminate the problem, but maybe you can find settings that will make it less noticeable. The way things work is there is a PQS generated surface, which is what we see when we're close to or landed on the surface. PQS is what generates the terrain, i.e. hills, mountains, etc. When at a distance, we don't need that terrain detail, so to ease the demand on your computer, we transition to a simple image of the planet. This simple image is the ScaledVersion of the planet. The fadestart/end settings determine at what distance we transition from one to the other. The following ScaledVersion { fadeStart = 25000 fadeEnd = 30000 } tells us when the ScaledVersion fades in. In this example, the scaled version starts to fade in at 25000 meters, and is fully faded in at 30000 meters. And the following PQS { fadeStart = 30000 fadeEnd = 120000 } tells us when the PQS fades out. Here the PQS surface starts to fade out at 30000 meters, and is fully faded out at 120000 meters. Even though the ScaledVersion is fully faded in at 30000 m, it is normally not visible at this height because the PQS is still at 100%. It is not until the PQS starts to fade out that we begin to see the ScaledVersion. Between 30000 m and 120000 m we'll see a blend of the two images, with the PQS gradually giving way to the ScaledVersion as we move farther and farther away. At 120000 m the PQS has completely faded away and we are left seeing only the ScaledVersion. The problem that you're having is that the ScaledVerion apparently has a larger radius than the PQS. It's not suppose to be that way. Normally when the ScaledVersion fades in, it's hidden behind the PQS. But because of the larger radius, you're seeing the rim of the ScaledVersion fade in as an apparent ghost image around the edge of the PQS. Something you might try doing is to set the fadestart/end setting to very narrow ranges. That way you'll very quickly transition from one to the other. It might look really bad as you move through that transition, but it should be brief. Everything below should look OK and everything above should look OK. Just place the transition at a height that will be least hateful.
  19. OhioBob
    The [Vacuum] part shouldn't be needed. Just @ScaledVersion.
  20. OhioBob
    If you want just the scatterer effects (i.e. no EVE effects), then just install scatterer and none of the other visual mods.
  21. OhioBob
    The first group of settings under the @SigmaDimensions node are global. So @landscape = 0.76 applies to all bodies unless there is a planet specific multiplier that overrides it. The height of geographical features are multiplied by the "Resize" and "landscape" parameters. So maybe "landscape" is changing the PQS but not the ScaledVersion. If so, that could explain why the apparent radius of the ScaledVersion is larger than the PQS.
  22. OhioBob
    There's no surprise that it worked without SD and RESCALE. Sounds to me like it's an issue with SD. The only other thing I can suggest for you to try is to edit the 2.5xKSP.cfg and change the @landscape multipliers to 1. That's the only thing I see in the cfgs that might do something.
  23. OhioBob
    GPP comes with cache files included, which are intended to speed up initial load time. Did you delete them? (edit) Now that I've thought about it a little more, I can see why deleting the cache wouldn't no anything. I presume Kopernicus does it's thing first, and then Sigma Dimensions. So while deleting the cache will force Kopernicus to rebuild it, it should rebuild it back exactly the same as it was before because nothing has changed.
  24. OhioBob
    According to the config, 25K is where the scaled version starts to fade in, and it is fully faded in by 30K. 30K is where the PQS starts to fade out, and it is completely faded out by 120K. So if you're seeing it start at 25K, then it's likely the "ghost" image you're seeing around the rim is the scaled version fading in. I assume that everything looks good above 120K? Normally the scaled version and the PQS should match up, but it sounds like yours aren't for some reason. The only time I've seen this happen is when something in the textures and/or config has changed, and the cache hasn't been deleted. Deleting the cache causes Kopernicus to rebuild it, and that usually fixes the problem. But you said that you deleted the cache and it didn't do anything. Which cache did you delete, GameDate/Kopernicus/Cache, or GameData/GPP/Cache? You want to delete the one in GPP.
  25. OhioBob
    How large is large? One possibility is Galileo's Planet Pack. GPP has 2 stars and 29 planets/moons. And with the addition of Grannus Expansion Pack, another 11 planets/moons are added. You can also add Outer Planets Mod, which adds a third star and another 16 planets/moons. So all together, that's 3 stars and 56 planets/moons. I'm sure there are other good choices as well, but I'm not really familiar with anything other than GPP/GEP/OPM.
×
×
  • Create New...