OhioBob

Please describe the problem you're having. We understand you can get it to work, but what about it is not working? Pictures are also worth a thousand words.

It sounds like I should probably bring this up then as a Kopernicus issue. I know Kopernicus has done a lot recently with the solar panel code for multiple star systems. Hopefully this is something fixable too.

Yes, it is a binary system. The planet I'm referring to orbits the secondary star. I think you're definitely on to something here. If the day/night terminator is based on the light of the primary star, then the result would likely be what I'm seeing. I haven't verified the light direction but I can if you need me to. The terminator for all the other planets is probably doing the same thing; it was just particularly obvious for this planet because it's tidally locked. I ran into a similar problem with PlanetShine. It also assumes the lighted hemisphere is the one facing the primary star.

@DMagic, I don't know if you are aware or not, but it looks like there's something bugged in your day/night terminator. I'm working on a mod that has a tidally locked planet that keeps one hemisphere always facing the sun. Other than small movements due to libration, the day/night terminator shouldn't change. However, during the course of a year the terminator displayed by SCANsat moves one time across the entire planet. It's not showing the actual illuminated face of the planet.

dayLengthMultiplier isn't used by Kronometer (that's a Sigma Dimensions thing). To configure Kronometer you should read the syntax page... https://github.com/StollD/Kronometer/blob/master/README.md#kronometer-syntax

Doesn't matter.

So far I've only tried Snacks. I wanted my first encounter with life support to be something simple, so Snacks sounded like a good place to start. I might eventually try USI or TAC, but not yet. I think I've heard more good comments about USI than TAC, but they both look interesting. I doubt I'll try Kerbalism; from what I've heard, it just takes over too much of the game. It also doesn't work with multiple stars, and I'm currently using a binary star system.

Read the instructions again and make sure you did everything and did it correctly. You have to install the Clouds folder from GPP, and you have to download and install EVE.

@Mrj4ck, it's probably the same lighting bug that we talked about on the previous page. Either, (1) switch to Koperniucs 1.3.1-2, or (2) delete the Light{} node from the file Sun.cfg. An update to SVT is planned that will fix this, but the developer hasn't had time to release it yet. If neither of those solutions fixes the problem, then you're going to have to provide more information (click "how to get support" in Galileo's signature for instructions).

Shouldn't be. Is it always underwater or just sometimes? One of the mods (scatterer, in think) sometimes causes KSC to appear underwater, but this is usually fixed just be changing the scene and going back. If it's always underwater, then you must have done something wrong. You're going to have to provide more information about your installation if anybody is going to help you.

But not zero. It was my very first Mun mission in which I killed Jeb by having him land on and tumble down the side of a mountain. Although the odds are slim, up to that point it had happened to me 100% of the time. (Of course that percentage has dropped dramatically since then.) I'm now always a little paranoid of mountains and try to avoid them whenever possible.

Yep, that's fairly easy to do. This is the method I use... What I do for a return from Mun or Minmus is to set the periapsis at Kerbin at about 22-24 km. At that height I find that I usually land at a point that is just about directly beneath the periapsis. Of course it depends on the aerodynamic characteristics of the reentry vehicle, but if we're using anything like a Mk1-2 command pod, we'll be pretty close. After setting up the maneuver node for the transfer back to Kerbin, I check the time to periapsis. Let's say the time to periapsis is 1 day, 1 hour, 45 minutes. Although we expect to land directly beneath the current periapsis, the terrain beneath the periapsis at the time of landing is not what it is now. We have to take into account Kerbin's rotation. In one day Kerbin will return to its exact current position, so we can ignore the number days. What is important is the hours and minutes, because that represents how much Kerbin will change from current. In this example we have 1:45, or 105 minutes. Kerbin rotates one degree per minute, so in 105 minutes it will rotate 105 degrees. Therefore the landing site is going to be 105 degrees west of the spot that is currently beneath the periapsis. You can estimate the 105 degrees by eyeballing it, or you can use a map like that below. The white vertical lines are spaced 15 minutes (15 degrees) apart, with the longer lines being 1 hour (60 degrees) apart. Just find the current spot under the periapsis and move the appropriate distance to the left to find the predicted landing site. The time to periapsis that you read with the maneuver node may not be the same as you get after completing the burn (there's always going to be some error). Therefore it pays to double check the landing site after you've completed the burn to make sure it hasn't change by a lot. If you don't like the looks of the predicted landing site, then just delay performing the transfer burn for a later orbit. Let's say you're orbiting Mun once every 45 minutes. That means waiting one orbit to perform the burn will shift the landing site about 45 degrees to the west. This way you can plan ahead and schedule the burn for the time that will place the landing site right where you want it.

You must have accidently hit a wrong key because the answer you got is 496456.27 divided by 60. You have an extra 1000 seconds in there. The correct result is, 22 days, 5 hours, 37 minutes, 36.27 seconds.

You should ask your question in the mod's thread.

Iota's orbital/rotation period should be 495,456.27 seconds.

If you want to replace the intensity curves with ones updated for Kopernicus 1.3.1-3, I recommend these: ScaledIntensityCurve { key = 0 1 0 0 key = 500000 1 0 -2.885E-07 key = 1000000 0.9 -1.443E-07 -1.443E-07 key = 2000000 0.8 -7.213E-08 -7.213E-08 key = 4000000 0.7 -3.607E-08 -3.607E-08 key = 8000000 0.6 -1.803E-08 -1.803E-08 key = 16000000 0.5 -9.017E-09 -9.017E-09 key = 32000000 0.4 -4.508E-09 -4.508E-09 key = 64000000 0.3 -2.254E-09 -2.254E-09 key = 128000000 0.2 -1.127E-09 -1.127E-09 key = 256000000 0.1 -5.636E-10 -5.636E-10 key = 512000000 0 -2.818E-10 0 } IntensityCurve { key = 0 1 0 0 key = 3000000000 1 0 -4.809E-11 key = 6000000000 0.9 -2.404E-11 -2.404E-11 key = 12000000000 0.8 -1.202E-11 -1.202E-11 key = 24000000000 0.7 -6.011E-12 -6.011E-12 key = 48000000000 0.6 -3.006E-12 -3.006E-12 key = 96000000000 0.5 -1.503E-12 -1.503E-12 key = 192000000000 0.4 -7.514E-13 -7.514E-13 key = 384000000000 0.3 -3.757E-13 -3.757E-13 key = 768000000000 0.2 -1.879E-13 -1.879E-13 key = 1536000000000 0.1 -9.393E-14 -9.393E-14 key = 3072000000000 0 -4.696E-14 0 } IVAIntensityCurve { key = 0 0.9 0 0 key = 3000000000 0.9 0 -4.328E-11 key = 6000000000 0.81 -2.164E-11 -2.164E-11 key = 12000000000 0.72 -1.082E-11 -1.082E-11 key = 24000000000 0.63 -5.410E-12 -5.410E-12 key = 48000000000 0.54 -2.705E-12 -2.705E-12 key = 96000000000 0.45 -1.353E-12 -1.353E-12 key = 192000000000 0.36 -6.763E-13 -6.763E-13 key = 384000000000 0.27 -3.381E-13 -3.381E-13 key = 768000000000 0.18 -1.691E-13 -1.691E-13 key = 1536000000000 0.09 -8.453E-14 -8.453E-14 key = 3072000000000 0 -4.227E-14 0 } Just copy these into Sun.cfg over the old curves and you should be good. They do the same thing as the old curves but with the correct units for use with 1.3.1-3.

Although it appears that support for PlanetShine has ceased, I still have a problem to report. This is information that users and mod developers might find useful. Be advised that PlanetShine does not work correctly with multiple star systems. Based on the result of in-game tests, PlanetShine apparently always identifies the primary star of a multi-star system as the source of sunlight. For instance, if planets are in orbit around the secondary star of a binary system, and vessels are in orbit around those planets, then the direction of light reflected onto those vessels presumes that the lighted face of the planet is the one facing the primary star. The secondary star, which is the actual source of sunlight, produces no reflected light. For any multi-star planet packs, it appears that PlanetShine can be configured to work only with the planets orbiting the primary star. For planets around other stars, you'll just have to go without PlanetShine for those.

What I can tell you is that the first 18 numbers are Area/CD/Depth for the six faces of the drag cube. The faces are X+, X-, Y+, Y-, Z+, and Z-. I believe the Y axis parallels the longitudinal axis of the vessel, with the Y+ surface being the one facing forward (in default orientation - axes rotate with part). I don't know what the last 6 numbers are, but I don't think that have anything to do with drag. Here's an example: PART { url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod DRAG_CUBE { cube = Default, 1.016,0.6655,0.7373, 1.016,0.6768,0.7316, 1.251,0.4785,1.097, 1.251,0.9474,0.3449, 1.013,0.662,0.7326, 1.013,0.6605,0.7441, 0,0.1044,-0.001006, 1.269,1.133,1.271 } } Arranging the data in a more useful form, we have Surface Area CD Depth X+ 1.016 0.6655 0.7373 X- 1.016 0.6768 0.7316 Y+ 1.251 0.4785 1.0970 Y- 1.251 0.9474 0.3449 Z+ 1.013 0.6620 0.7326 Z- 1.013 0.6605 0.7441 As you can see, the pointy end has the lowest CD (Y+) and the blunt end has the highest CD (Y-). These CD values are apparently further modified by the multipliers found in Physics.cfg. These modifiers adjust for the orientation of the face relative to the flow (tip, side or tail), and the Mach number. If the face is at an angle to the flow, e.g. partly facing forward and partly facing sideways, I think the face is prorated in some way between the two types.

I presume you've upgraded to Kopernicus 1.3.1-3? Kopernicus made some changes in the way that sunlight varies with distance. This can cause problems if the mods you are using it with are not up to date with the changes. Change back the Kopernicus 1.3.1-2 and that should fix the problem. In the meantime, SSRSS may have to release an update if it's not currently compatible with the latest Kopernicus. @Galileo, I'm not sure what the status of SSRSS is in regard to its light intensity curves. I can help write some new curves if you need to release an update. Just let me know if there is anything I need to do.

Drag basically works the way it does in real life. KSP uses the drag equation, The atmospheric density, ρ, is computed from the air pressure, temperature, and molecular weight. KSP uses reasonably realistic atmospheric models. The flow velocity, u, is, as far as I know, the surface speed of the vehicle. The drag coefficient, CD, and reference area, A, are more of a mystery. I don't fully understand it, but it works something like this: Each part in KSP is represented by a drag cube, with each face having an area and drag coefficient. This information is found in the file PartDatabase.cfg. Somehow KSP figures out how much each part contributes to the drag and sums the results, but I really don't know exactly how it's done. I'm pretty sure that one part of the operation is to determine the exposure of each face of the drag cube relative to the flow, taking into account occlusion. The game's Aero GUI readout (found in the cheat menu) gives the total drag and drag coefficient, but I'm uncertain how those numbers are arrived at. The game could sum the areas and compute a total vehicle CD, from which the drag is computed in a single operation. Or it could compute the drag for each part individually and then sum the individual drag values to arrive at a total. There are also a bunch of drag multipliers in the file Physics.cfg, but I don't know how all that comes into play. I've attempted to perform some computer simulations outside of the game, but I've never been able to figure out exactly how KSP computes drag. I generally just set the reference area to the projected area of the vessel, and then estimate the drag coefficient empirically, back calculating it from the total drag and dynamic pressure readouts in the Aero GUI. It's such a pain to do that I've pretty much given up on it. I wish it were simpler, but it's not. (edit) Correction, the Aero GUI does not give the drag coefficient, it just gives the total drag. It also gives the dynamic pressure. Dividing drag by dynamic pressure gives the product CDA. I suspect that the drag of each part is computed individually and then those numbers summed to give the total. But your guess is as good as mine.

I don't have any formalized rules, but I do try to follow some general guidelines when I can. First, using hyperedit or cheat mode to run simulated tests is perfectly alright. I just make sure I revert back after the test is over. And I try to never use any of those cheats when I'm executing the mission for real. I also consider using F5/F9 perfectly acceptable to undo silly things like accidentally hitting the staging key, or timewarping past a maneuver. In real life there would be safeguards in place to prevent those types of thing from happening, while this is just a game. I just don't take it seriously enough to play a no reverts. However, if I mess something up because of a bad design or poor planning, then that's just tough luck. Reverting because of piloting errors is more of a gray area. I don't like to do it because I do consider that cheating, but I've done it on quite a few occasions.

@eddiew, if you what to get even more specific, you can compute the body's black body temperature using, where L is the star's luminosity (Watts), a is the body's albedo, σ is the Stefan-Boltzmann constant (5.6704E-08 Wm-2K-4), and D is the body's distance (meters). For Ciro, L= 3.3415E+24 W, and for Grannus, L = 1.030E+23 W. Black body temperature will get you in the ballpark, but it's not exact. For an atmospheric body you have to add for the greenhouse effect. Earth's greenhouse effect raises the temperature about 34 K, while on Mars it's about 8 K, and on Venus it's about 500 K.

There is a specific part just for storing science... https://wiki.kerbalspaceprogram.com/wiki/Experiment_Storage_Unit I don't know if it has a limit on how much science it can hold. If so, I've never reached it. It is limited, however, in that it cannot hold multiples of the same experiment. (Sorry, it's experiment storage unit. I mistakenly wrote equipment storage unit in my previous post.)

A body at X distance from Grannus will have the same temperature as a body at 5.7X distance from Ciro.

It's been awhile since I've dealt with this issue, so I'm really not certain what's possible in the latest KSP version. You can always put an "experiment storage unit" on the returning vessel. This unit can collect all science from all vessels and store it. You then just have to bring the storage unit back to Kerbin. A kerbal can also transfer science from one pod to another, but I think he has to move from one to the other via EVA. When he exits one pod, just tell him to take the science from that pod. The science will then move with him and will be added to the next pod that he boards. I don't think it's possible to have a kerbal move science simply by using the transfer feature.