Frederf

Didn't change. Wasn't holding alt, but 'x' for KAS. It was very frustrating to try to see attachment with EVS pop up message in the way.

I can't wrench a part on with KAS and EVS. Every time I click to build the part on it switches me to the target vessel instead.

Quick note that the KSP AVC link doesn't land on this thread (forum index instead). Thanks for your development.

Just to let you know I couldn't get RemoteTech and Galileos to work together and I ended up having to change the config to Body = 6. Body = 5 was Niven.

This is a fantastic mod and I get a lot of use out of it. However I have a persistent want. Most times I'm approaching Kerbin I'm not in the aerodynamic configuration that I will be entering the atmosphere in currently. Or rather I will shed parts down to some sort of capsule subset of parts. The annoyance is that the aerodynamic properties of the two configurations aren't the same so a perfectly planned reentry in one configuration can be hugely different than the other. However if I could apply some sort of manual aerodynamic file from my back pocket (perhaps recorded on a totally different flight) then I could specify an aerodynamic body that much more closely resembles what will be flying. If I could "save a cache" say as "Capsule 1" and then "specify aerodynamic cache" later on a totally different mission to override the aero body for predictions that would be both helpful to me for precision purposes but could add extra gameplay value as well. It might become routine to do "test body" mission to capture aero data in support of future missions.

I use FAR so if nothing else it's the lite version of RC included in FAR.

I'm having a problem with Smart Parts in 1.0.5, namely that staging isn't staging everything. A booster on a radial decoupler which shares a stage with the parachute will behave in two different ways if staged via space bar or via a smart part. Pressing spacebar will arm the parachute and decouple while the smart part is only decoupling the stage.

Is it possible to make the fuel lines much more fragile? Right now two space craft floating next to each other have a strong chance to develop extreme oscillations and fly apart. I'd much rather the fuel hoses would breakaway than the perpetual jiggle machine to eat my craft.

I'm also having this issue. It sounds like something that would be in options but I can't make heads or tails of the options. There's a trashcan icon along with the pause, message, etc. options for alarms but no tooltips means I have no idea what it's supposed to do. In either setting I get the same build up of old alarms.

The GitHub source and release links seem to be backward. The release doesn't contain a GameData folder and has all the bare .cs script files.

I know the default MFD autopilot page is supposed to integrate with Mechjeb but there are some rather useful stock 6-way SAS programs that would be super nice to access in IVA.

I was on one version ago. No longer an issue. [Enhancement] Disable jetpack mouse input while dragging

Would a change away from 0 cost procedural parts avoid that issue? I wonder if it would be relatively simple to change the procedural cost from (0+calculated_amount) to (nominal_value+-calculated_deviation). The final cost would be the same but for mods (such as this) that have to fallback to the static value it would at least be close.

It might be a repeat report but I have an item duplication bug regarding carried containers: Assuming wrench in Kerbal slot #1, carried container in Kerbal slot #2. Inside the container there is also an item (let's say the basic battery) in the container's slot #2. The Kerbal is on EVA near a container mount, "2" is pressed and "X" is held while the container outline is hovering in blue over the node attach point. LMB is pressed to complete the attachment of the container to the mount. The result is that it is the battery from inside the container is attached to the mount instead of the container itself by virtue of the similarity in slot #. Additionally the placed item does not subtract from the container's inventory so one battery is now two batteries. --- On a different front dragging and dropping parts with EVA RCS enabled can double as controlling the EVA reorient. If you made certain KIS actions restricted while the RCS joysticks are in hand it could steer users away from the mixed control situation while also being quite plausible (Kerbals need their hands free for tools and whatnot).

In the VAB in the KCT dialog the bottom button is "Part Inventory." I have another issue with inventory, namely certain parachutes are more plentiful than rabbits in heat. Probodobodyne OKTO 1 Mk1 Command Pod 2 Modular Girder Segment 17 ... RealChute Radial Chute 810400 Mk-R Radial-Mount Parachute 909198 RealChute Cone Chute 1735596 Mk16 Parachute 976598

I'm doing a bit of empiricism now about what experiments can provide MPL data and which can't. This is my first MPL and first round of experiments shoved in so I know that all of them are unique. Not every experiment is MPLable and some are but for "+0" data. Surface Sample from Runway +1 Materials Sample while flying at Kerbin EVA report flying over Kerbin's mountains +0 Surface Sample from Kerbin's Deserts +1 Atmospheric Pressure Scan from Kerbin's Deserts +0 Mystery Goo Observations from Kerbin's Deserts +0 Materials Study from Kerbin's Deserts +1 Temperature Scan from Kerbin's Deserts +0 Mystery Goo Observation from KSC +0 Materials Study from KSC +1 It appears that several experiments simply don't count for MPLification and others have their values floored due to being less than 1 data value. Maybe in other multiplier areas the 0s get higher.

With clever choice of landing spot it's possible to be very near 2 or 3 or more biomes such that a rover trek was practical. Biome scanning and mapping really help. I really really wish someone makes a "Trek" mod to abstract long motions by walking Kerbals, boats, rovers, etc. without the tedium of holding down "W." There are several surprising uses for rovers besides transportation buggies. Any time you need to dock craft on the ground wheels really help. An orbital craft landing next to a refueling miner really benefits from a "truck" so you don't have to do the infamously difficult hoverdock procedure. An Eve probe might roll to the top of a hill before liftoff as it really changes the required fuel to escape the atmosoup. Cranes are popular as are full mobile gantries. If you want to layout navigation beacons for landing on the KSC runway a wheeled drone is handy. Similarly spotlights on wheels can help illuminate buildings and landing areas both at home and abroad.

In my space program I've moved to the stage where I can put science experiment data in a mobile processing lab and get extra science from it. The difficulty is I've completed a lot of basic science missions but haven't processed them in the MPL before. So I'm just having to guess what "depleted" science activities still are valuable run through the MPL. I wish I had a way to record, predict, and track what science out there (both ones I've done simply or haven't at all) is going to provide that +1 (or better) data yellow button. My understanding (it could be wrong) is that once I MPL-ify an experiment it's used up and I have to make them unique. I'm trying to get good science out of the MPL but it's hard to judge what I can and should feed it.

I've had it without trim. Oddly I thought it was SAS too but once I tried it WITHOUT SAS running and it didn't do it.

Love this mod. If we want to get competitive I would keep SA and remove Science! if I had to pick one. In any case, I only have the smallest of quibbles with it. One the checking is too rapid. Going over the smallest bump triggers the alert for airborne. Some sort of delay where it won't produce the alert until the condition has been satisfied for some duration (a second or so) it would really calm down the interface. I doubt anyone would mind such a delay or even notice. The second is gathering science, especially EVA reports, are still alerted as valid science even after I stuff a copy into the capsule. I totally understand that it is a valid experiment since the data hasn't been turned in yet, but it's going to be. The mod can't know that of course so perhaps a right click temporary dismiss would help? "Don't bother me about this science until I leave and come back"? Sometimes you decide not to do an experiment (EVA while flying, can't reset, etc.) but still want a blank slate to get a fresh alert later.

Good catch. I wasn't doing all the transforms in my head properly. 60 deg inclination is going up-right ascending (north east) and down-left descending. But when you rotate half way around Kerbin down-left becomes down-right so again south east.

To pile onto the previous explanations: You can get anywhere from anywhere given enough fuel. Efficiency is good to keep the fuel requirement manageable but oopsies and tweaks are fine. Some adjustments are cheap to make and others are expensive. Since KSC moves around the equator in time there are two times per rotation when KSC (and thus the rocket on the launch pad) passes through the plane of the target orbit. You don't have to launch at one of these two moments but it absolutely helps. If you can be in-plane from launch to final destination the whole time, life is easier and it takes less fuel overall. You can eyeball the situation by focusing on Kerbin and shifting the camera such that the target orbit collapses to a line. You're looking at the edge of the target orbit. Then you can warp ahead in time until KSC rotates under that line, either side is fine. So these are the two launch times that are desired. The space craft leaves the pad co-planar to the target orbit. If the target orbit is inclined 60 degrees you want to launch on about a heading of 30 or 210. The idea is that launching east (90) is 0 degrees inclination increasing to the north (0) for 90 inclination. Going west (270) is 180 inclination and so on. In any case it should be clear to see that 60 degree inclination is a mixture of 2/3rd northward and 1/3rd eastward orbit. The whole confusion about heading and inclination is because the history of compasses is 000 is north increasing clockwise while in math/astronomy east is 000 and increases counterclockwise. Those jokers. The caveat to the above is there are two sides to every orbit and if you're using the #2 launch location you'd have to go heading 210 off to pad to keep in plane. It's pretty easy to tell them apart look at the dots' motion just above the launch site. If you manage to get into a coplanar (+-5 degrees) roughly circular 70x70km ideal around Kerbin you're 95% of the way there. Then the task is simply to burn prograde when you're on the opposite side of the "Ap" of the target orbit. Prograde burning will inflate the opposite side of your orbit. Inflate your "Ap" out to the target's "Ap" and once out there inflate (or deflate) your "Pe" to match the target orbit's. If your circular orbit after launch isn't such a nice circle there are more adjustments. The only ideal would to have your "Pe" post launch be exactly opposite of the target's "Ap." If it isn't some burning toward or away from Kerbin during your "Ap inflation" will shift the resulting position of the "Ap." Any extra orbit size on the same side as that high target "Ap" is absolutely fine because you're going to do that anyway. Extra orbit size on the "Pe" side is a fuel inefficiency. Corrections to match orbits should always be done at where your orbit crosses the plane of the other orbit. Until you're on the same sheet of paper as the target orbit, you have a 3D problem. Once you get on his plane then it's a 2D problem solvable with only radial and pro/retro-grade. Once you get your Ap-Pe lines to match up it's a 1D problem solvable with only pro/retro-grade.

This is a multidimensional analysis involving (in order): Environment Atmospheric Density Local Gravity Vessel Terminal Speed Vessel Weight Free Parameter Total Drag (Parachutes) In general a full understanding of "how will the craft behave under parachute(s)" is a multi-dimensional solution space. But mission requirements can fix several of these to reduce the dimensionality of the solution space to something more useful. (A) The first to be fixed is likely the atmospheric density which is characteristic of the landing environment. The density is strictly a function of altitude per body. Every atmosphere of every body is simply density in character there exists an altitude on every body that is representative of an altitude on Kerbin. Provided that altitude is accessible (greater than 0m) one could happily test parachutes for a Duna surface mission on Kerbin at some appropriate altitude. More atmosphere means a slower craft in a linear way I believe with stock. (G) The second to be fixed again by environment is local gravity to which surface gravity is often a perfectly adequate. Gravity strength is multiplicative with vessel mass to determine weight. More weight means a faster craft, again linear. (S) The vessel by construction will have some maximum impact speed to safely land. To be the best of my knowledge this is the impact strength of the part which comes into contact with the surface or the strength of the joints which hold together the parts. Landing legs which survive 100 m/s impact are of little use if the forces rip apart the craft. Stronger craft require less parachutes which can save weight but often that robustness is heavy in its own right. (M) Vessel mass is again due to design. The more massive the craft the faster it will fall. (P) Drag from parachutes counteracts the falling speed. Each parachute will provide drag proportional to the speed. ----- Assuming the landing happens at terminal velocity, the relationship is very straightforward. Downward force and upward force are equal. Downward force is mass (M) and gravity (G) and upward force is the atmosphere density (A) times the parachute factor (P) times speed (S)*. *squared. M x G = P x S^2 x A Given M, G, S, and A are known, P is determined: P = M x G / S^2 x A All it would take is to look up what "P" values various parachutes are, plugging in some numbers and rounding up as a safety factor. The first step is to calibrate this equation to some meaningful values for known parachute parts and units of M G S and A. Without regard for the pleasantness of the number we might define 1 "P" parachute factor to maintain a 1 ton mass inside 1 m/s^2 of gravitational acceleration to a terminal velocity of 1 m/s in 1 MT/m^2 of density. I've tried to use the most KSP-native units here. I could just as easily defined a 1kg mass under Kerbin's surface gravity to a terminal velocity of 6m/s at Kerbin's surface at Kerbin's surface density. The former is more elegant and general while the latter might be most useful in common cases. Both tables of "P" values for various parachutes would be the same except for a multiplication constant. ----- Assuming that pressure is indicative of density (large changes of temperature and molecular composition invalidate this). So a 920 kg craft: under 9.70m/s^2 gravity is going 6.09m/s in an atmosphere of 58.75. (4.1) under 9.75m/s^2 gravity is going 5.84m/s in an atmosphere of 76.45. (3.44) under 9.78m/s^2 gravity is going 5.50m/s in an atmosphere of 86.74. (3.43) under 9.81m/s^2 gravity is going 5.10m/s in an atmosphere of 99.66. (3.48) Throwing out the first one and averaging the rest I get a "P" factor for a Mk16 parachute of 3.61. If it pleases you you can multiply this number by 1000 and input the craft mass in kg instead of metric tons and it is equivalent. Alternatively one could express this in atmospheres which would have an effect of moving the decimal nearly 2 places to the right. Doing both moves the decimal 5 places. ----- A fine theory but does it stand up to experiment? To Duna! Our familiar 920kg craft just as before reentering. What will our speed be? It should be the square root of MG/PA. M 920 kg G 2.86 m/s^2 P 3.61 A 11.97 kPa 7.8 m/s! Turns out it was closer to 10.8. Seemed pretty reliable on Kerbin but under reported on Duna. Was my math bad? Certainly possible. It's also possible the pressure is not a good indicator of density when switching from Kerbin to Duna. As far as I know Duna should be both colder and of a denser molecule compared to Kerbin which should improve parachute performance.

You can click on company icons! In the mission control building in career! And it changes to show a description of the company! With contract attribute tendencies bullet points! That is all.

The mover between the surface and orbit wants the absolute minimum equipment on board since every gram hurts the bottom line. No refineries, no drills, no ore containers, just fuel, engines, and landing legs. Assuming you have KAS or some other way to transfer resources on the ground it's much better to leave the refining equipment stationary. The trip down to join the drill for example should contain enough fuel for the trip down but not back up. Refuel on the ground and bring it to the orbital depot. Offload all fuel except enough to go down again. This way you don't need ore storage and fuel storage on the mover (heavy), just fuel. The argument against this is if you need something other than fuel bi propellant, say liquid fuel only for a nuclear engine. Then your mover might need LF/OX while your cargo is just LF or something else as ore eventually might serve a different purpose. You might want LF/OX making capability on the ground still (carrying round trip fuel is expensive) but perhaps you need a separate cargo and mover fuel container. The shallowest gravity well is best for both the mover's consideration and the benefit of refueling craft headed for points beyond which is why Minmus is much more appealing than Mun.