NonWonderDog
-
Posts
116 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by NonWonderDog
-
-
It sounds to me that you don't like people building planes that don't conform to your views of how a plane should look like rather than an actual concern on the aerodynamics model.
It isn't always about wingspan, and plenty of planes have existed that flew perfectly fine without massive wings (plus they don't even have lifting bodies). I find them retarded, but fascinating to look at because they are real planes that were fully capable of flight.
In FAR, and in real life, long skinny wings have better L/D ratios. That's why sailplanes have long skinny wings.
Fighter jets don't have long skinny wings because long skinny wings are horrible for supersonic flight -- wings don't work correctly when they have shockwaves forming on them. Luckily, the nose makes a conical shockwave that wings can hide behind. Past Mach 1, you want your wings swept backwards to stay within this cone. The higher the Mach number, the steeper the shock cone angle, so faster jets have more sweep (or longer noses).
You can't make swept wings too big, or they'd be structurally weak and the center of lift would be too far back. So you add wing area with a delta wing instead. Delta wings have another nice property in that they can generate lift at very high angles of attack without stalling (lift is roughly proportional to angle of attack). This means that a delta-winged plane can land at slow speeds (lift is proportional to airspeed squared), as long it doesn't mind doing so with the nose 30 degrees above the horizon. But big enough long skinny wings could make just as much lift at 12 degrees angle of attack, and with less drag.
All this is pretty simple, as evidenced in that it can be explained in 10 sentences. But it's enough to understand why the F-14 had mechanized wings, and why Concorde had a droopy nose.
KerikBalm's concern was that if the aerodynamic model was simplified by leaving out the supersonic effects, there would be no reason to use a delta wing. At all. Ever. The best space plane designs would look like sailplanes. And that would be stupid, because everyone knows that space planes don't look like sailplanes.
Most people have heard of the F-14, too, I'd imagine. So they would expect that changing wing geometry actually does something, or else the F-14 wouldn't have big heavy wing actuators. An aerodynamic model where it does nothing would be less fun, if only because you wouldn't try to build swing wings.
-
I tired out a propeller from KAX, but had several problems with it. I'm sure at least one is my lack of understanding but I want to know if any of this is intended behavior or something else is conflicting. First off, when I started the prop at zero throttle it started up, then died out and wouldn't restart without reverting to launch. So, I tried pushing the throttle up to full and as soon as I pressed space the place started moving forwards, became uncontrollable and veered off to the left. I thought maybe the landing gear was positioned badly so I moved it to the fuselage from the wings and it proceeded to perform the same maneuver.
As far as I can tell the hard pulling to the left and the instant application of thrust are probably not intended, but it could obviously just be a limitation in how the propellers are handled. Like I said, I'm trying to figure out if this is expected or if something might be conflicting, any thoughts?
Are you using the DefaultThrottle mod? Starting a prop engine at 0% throttle as set by DefaultThrottle seems to put it in a permanent flame-out state. If I move the throttle before starting it works fine, even if I move the throttle back to zero. After changing my DefaultThrottle setting to 100% I have no more problems.
I haven't used the KAX props to know if they apply any torque to the plane.
-
Seconding regex in that I don't really want this to be significantly harder than stock. What I want is a tiny planet inhabited by little green men, but launching rockets that make sense from a physics and engineering standpoint. The point of this mod in my mind is to allow generous payload fractions and easy interplanetary missions using realistic (but not specifically historical) Kerbal-sized rocket parts. At 6.4x I also find the planet densities believable, if not exactly astronomically possible.
I'm not sure you can quite get there with the mods available, though. RealFuels is a bit too grognard, the stockalike engine pack is a bit too halfway and fiddly, and nobody's maintaining a mod to make the pods and structural parts follow realistic densities. I actually started changing all the pod masses to their real-for-Kerbals equivalents, but it got to be too much. I never worked out a good way to do it programmatically, and I'd rather play with mods than spend all my time editing them. The stockalike engines seem to have too much thrust for their size, as well?
For those interested, the Mk 1 pod should weigh 350 kg including 50 kg of heat shielding, the Mk 1-2 pod should be 1.75 tons after adding a 250 kg heat shield, and Hitchhiker should weigh 1.25 tons. Those are my guesses based on Mercury, Apollo, and Harmony, erring on the heavy side. (Hitchhiker is way too small.) Maybe I can figure out some kind of formula based on those using ModuleManager's variable support.
I think we need a RealFuels version that isn't based on recreating Human space programs. It should have about six or seven fuels, and two of them should be interchangeable with LiquidFuel and Oxidizer so it doesn't require curated fuel tanks. Engines shouldn't have tech levels. The choices should be no more complicated than kerolox, hydrolox, methalox, or hypergolic. There should only be one fuel/oxidizer ratio per pair, independent of engine. And, crucially, it needs to have a way to integrate with MKS, TAC life support, Karbonite, Near Future etc. without huge amounts of curation work.
I've actually gone back to 1x Kerbin using KIDS (at 0.85+Isp fix) instead of Real Fuels just to play with MKS and such.
-
Nice! Copying the RealSolarSystem.cfg from the linked github repo in the RSS folder in gamedata will suffice to install this, right?
You also need the KerbinHeight.png terrain map in the RSS plugindata folder. That, and I made some minor adjustments to the positions of the other launch sites in LaunchSites.cfg. Nothing major, but there were a couple launch sites that were no longer on the shore, or sat on a 100 meter tall mesa after my terrain edits.
You might have to delete Kerbin.obj to force RSS to regenerate the terrain, as well. I'm not sure how that works.
There's currently a good chance that the pyramids, monoliths, and suchlike are floating hundreds of meters in the air. I've only repositioned the Island Runway onto the new terrain, so far.
[EDIT]I've updated my repo to have 6-hour and 24-hour day configs, and to raise the Kerbin average terrain height. There should be more gentle hills in the grasslands now. Now if only I can make some fjords...[/EDIT]
-
The next thing we're working on at the moment is terrain. Getting things less smooth and making sure the mountains look closer to stock.
If you want another hand on this, you can find my attempt at Kerbin from back in September here: https://github.com/NonWonderDog/6-4-KerbolSystem/tree/NewKerbinTerrain
I've just brought it up to date with Raptor's repo. The major idea at the time was to edit the heightmap and PQS parameters in order to make the terrain match the original planet texture. All the shorelines line up correctly, mountain textures are mostly represented, etc. If we can generate the planet texture from the generated terrain now that might not be that important.
My Kerbin grasslands ended up being very, very flat (that could be fixed by raising their elevation in the heightmap), but I got the highlands and mountains looking okay:
Javascript is disabled. View full album
-
Same effect, but using callbacks instead of polling.
It probably doesn't really make much of a difference except philosophically.
-
Ah, so that's how you listen for control input.
Thanks for this. I'd argue that it should only apply to the toggle key, though. I use the hold button for temporary autopilot overrides.
-
Unfortunately it seems to have some bugs now. After launching into an elliptical orbit my ship ended up flying at a constant altitude, with the periapsis chasing me around Kerbin whenever I time warped.
Maybe it works better if you install Blizzy's toolbar as well, but I've been trying my hardest not to need it anymore.
-
Here's the Bayes' Theorem explanation:
What you really need probability wise is the reliability of a part over time dt, starting at time t. You can compute this directly, but you have to know the details of the probability density distribution and take an integral, and you don't want that.
For whatever failure distribution a part has, it's fairly trivial to compute R(t), or the probability of survival between 0 and any time t. For specificity's sake we can also call this R(0,t). So you can get R(0,t) and R(0,t+dt) directly just by calling the reliability function once every dt.
But we need R(t,t+dt), which is a conditional probability. What is the probability that, given no failure at time t, that there will continue to be no failure at time t+dt?
Bayes' Theorem is P(A|
= P(B|A) * P(A) / P(. A is no failure over (t,t+dt). B is no failure over (0,t). P(B|A) is... well, it turns out that P(B|A)*P(A) is equal to P(A∩
, the probability of the intersection of events A and B. The intersection of events A and B simply means no failure over (0,t+dt).R(t,t+dt) = R(t+dt) / R(t)
Okay, that was all kind of mean of me. All you have to do is divide.
-
Thanks, I was actually going to figure out how to do this one myself if nobody else did.
I think the ideal behavior would be slightly different, though. When you toggle SAS on, it should always turn on in stability assist mode. If you use the momentary button, it should stay in whatever mode it was in last.
The idea is that I have SAS toggle as a button on my joystick, but I also have momentary SAS bound to the pinky switch. With SAS enabled, the pinky switch works as an autopilot override (as in nearly every US Air Force jet). The override shouldn't change the SAS mode.
I think what i really want is a button bind for stability mode.
-
The thing that will make this mod hard, and the reason why I said you'd need an understanding of the literature, is the randomness. If you try to balance it by play, you will simply never get a good result. You have to have a a result in mind and the ability to implement it, and then have the willingness to ignore people (or yourself!) who complain that their engines fail every launch or never fail at all. You have to design the reliability of the entire population of RT-10 boosters amongst all players, and trust that individual RT-10 failures follow the pattern.
To that end, you have to understand real failure distributions, and the math needed to model them. It's actually not that bad as long as you keep things simple.
If we take the simplest case, say we have 1000 widgets, and 10% of them fail each day. 100 widgets will fail the first day. There are only 900 left, so 90 widgets will fail the second day. 81 will fail on the third, 73 on the fourth, etc. As you see, the simplest model has an exponential failure distribution. This constant risk of failure -- a constant hazard rate -- is the basic assumption behind the Mean Time Between Failures metric.
The hazard rate h(t) is actually somewhat of an abstract concept in order to account for non-constant rates. It's equal to the expected number of failures in a population divided by all the accumulated time of all the items in the population, over an infinitesimal time slice, given that every item in the population is t hours old. Stated in a way that actually makes sense, the probability of an item experiencing its first failure over the next dt hours, starting at time t, is equal to h(t)*dt as dt approaches zero.
But for an exponential distribution, it's easy. The math works like this:
Hazard rate is constant, so let's call it lambda. MTBF is equal to 1/lambda for an exponential distribution. Hazard rate can be estimated directly from a sample population (the measured failure rate): if there are 10 failures in a sample of 100 devices scheduled to operate for 100 hours each, the hazard rate is 10/(100*100) = 0.001 -- A MTBF of 1000 hours.
The probability of a failure at time t (divided by duration) is f(t) = lambda*e^-(lambda*t). This is the failure density function. (10% of widgets fail each day (lambda = 0.1), 100 fail on the first day (f(0) = 0.1), 90 on the second day (f(1) = 0.09)), 81 on the third day (f(2) = 0.081), etc.)
The probability that that item will have failed after t hours is the integral of the density function, F(t) = 1 - e^-(lambda*t). This is the failure distribution function. F(infinity) is equal to one.
The probability that an individual item will survive is one minus that, or R(t) = e^-(lambda*t). This is the reliability after t hours.
With our 1000 hour MTBF, the probability that any individual item will survive for 100 hours is:
R(100) = e^(-0.001*100) = 90.5%
The probability that it survives for 1000 hours is:
R(1000) = e^(-0.001*1000) = 36.8% (Yes, 63.2% of our samples have failed after the mean time between failures. Math is weird.)
And honestly, if you don't go beyond an exponential failure distribution that's all you need. The probability of surviving for the next 1000 hours is 36.8% no matter how many thousands of hours it has survived so far, so you can just use the reliability function and be done with it. Only thing to keep in mind is possible numerical precision issues past 100,000 hours MTBF, and any fiddling you might have to do to get all the bits out of Unity's RNG.
Things get a lot more difficult with a variable hazard rate. If I'm feeling particularly brave I'll try to work out the math for a Weibull distribution, since front-loaded failures would make launches a bit more exiting, but I'll ignore wear-out as probably a bad idea for gameplay.
In the most general case, I think you only need the reliability at time t (when you last checked), the reliability at time t+dt (now), and Bayes' theorem to determine if something should fail. You should be able to foist the reliability calculation itself off on another module. (At least, that's how I remember probability working. I'll have to run through that.) I get incredibly confused when I think about the *second* failure using that method, though...
-
Isn't that just very unrealistic though? My main problem with a MTBF system is that the mean time would have to be stupidly low for gameplay reasons and it would just plain feel silly to me. 12 seconds MTBF on a rocket sounds silly. Or is it just me?
It depends on your opinion of Kerbal engineering.
Here are MTBF numbers for the SSME in 1993:
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930012456_1993012456.pdf
The MTBF for in-flight shutdown is between 112 and 8.3 (!!) flights, depending on power level. A flight is eight and a half minutes, which works out to MTBF times of 1 to 16 hours. For NASA's premiere lifter engine!
It has to vary per part, though. A jet engine has about 100,000 hours MTBF.
I'll see if I can put something together on the math later.
-
Ultimately I don't think you're going to be able to avoid the literature on reliability analysis if you want something that feels "right." You at least need to use Bayes' Theorem to set it up so the update rate doesn't change the number of failures per hour.
The wiki page is a decent start: http://en.wikipedia.org/wiki/Failure_rate
This random Powerpoint is okay: http://www.wilsonconsultingservices.net/MTBF_M2.pdf
The simplest way that would give good results would be to report the reliability of each part as MTBF, with a constant hazard rate derived from that (2000 hours MTBF = 0.0005 failures/hour = 1.39e-7 failures/sec). That's an exponential failure density, which is fine. If you want to be fancy you can let parts define one each of exponential, Weibull, lognormal, etc. failure densities and use the greatest hazard rate (which would let you define a bathtub curve for parts), but I don't really know how you'd report that data to the player. Presumably you'd have to average it into the MTBF score somehow.
Plus, you could have it literally say "mean time between failures = 12 seconds" on the starting boosters. That's a lot more fun that "50%."
Making engines more likely to fail during starts, etc, is a good idea, but it needs to be tied to the overall reliability. I'd recommend you just have a multiplier to the base hazard rate that applies for two seconds or something, maybe as a oneshot floatcurve. So if you engine is 0.01/hour likely to fail at any time, it's up to 10x more likely to fail (0.1/hour) during the two seconds after an engine start. And maybe the reliability is increased 100x when it's off. Again all of that is hard to communicate to the player. (Maybe you need separate active/inactive reliability scores.)
For inactive vessels, since you'll be using Bayes' theorem you can just sum up the probability that a failure occurred while you were away. And boo on your Kerbals for not telling you their life support was broken, I guess?
-
Ven's revamp does add an air intake to the Mk1 Cockpit, but that won't conflict as much as just not do anything.
You can always add this to make it work:
@PART[Mark1Cockpit]:NEEDS[AJE,VenStockRevamp] {
MODULE {
name=AJEInlet
Area=0.2
TPRCurve {
key = 0.0 0.95 0 0
key = 1.0 0.97 0 0
key = 1.5 0.90 0 0
key = 1.8 0.80 0 0
key = 2.0 0.70 0 0
key = 2.5 0.45 0 0
key = 3.5 0.00 0 0
}
}
} -
US wedges aren't currently FAR compatible, in that they don't work as aerodynamic fairings. We'd have to rename the parts to make them work with FAR which would break saves, there might also be additional work that was needed.
I'll talk to Daishi and see what we can do with minimum effort (Daishi is busy working on the next project).
FAR uses the part title, not its name.
This is configurable in-game, too:
Click on the FAR icon, go to Part Classification, and add "science bay" under the "Cargo Bay Title Contains:" section. The Science Bays will then be FAR compatible.
-
Don't forget though that entry angle is still a factor. If you come in steep, you have less time for aerobraking and may well still be supersonic when you reach deployment altitude.
Yep, but if you're going hypersonic, steeply downwards, at 4000 m altitude, and relying on parachutes to get you down safely, it really doesn't matter if they fail or not.
-
Well, you could add material density or porosity or similar fields to parts. Right now the truss parts are some of the most buoyant parts we have, even though they're mostly made of holes. Scaled to a realistic mass, they will literally rip splashed-down craft apart due to buoyancy forces.
(I also cleared "PhysicsSignificance=1" from every part using ModManager, so I don't know or really care what they do when they're physicsless.)
Is there any rotational damping on splashed-down parts? Single parts often seem to spin infinitely in the water, and that might be worth looking at.
-
Real main parachutes open between 3 - 7 km altitude, with drogues at 7 - 10 km. Scaled down to the Kerbin atmosphere, that means drogues at 6000 and mains at 4500.
If you do that, your parachutes will essentially never fail. Unless you hit a mountain before they deploy.
I've actually put together a modmanager config to set all the default parachutes to open at more reasonable barometric pressures. Just make sure not to try to use them on Duna like this.
I use the "arm when staging" option, so you might want to tweak these a bit higher if you use the default deployment mode. Any drogue or drag chutes from mods will need an exception added to the list:
@PART[*]:HAS[@MODULE[RealChuteModule]]:FINAL {
@MODULE[RealChuteModule] {
@PARACHUTE,* {
%minIsPressure = true
%minPressure = 0.4
%minDeployment = 7000 // 4500 on Kerbin
%deploymentAlt = 850
%preDeploymentSpeed = 2
%deploymentSpeed = 6
}
}
}
@PART[parachuteDrogue]:FINAL {
@MODULE[RealChuteModule] {
@PARACHUTE,* {
%minIsPressure = true
%minPressure = 0.3
%minDeployment = 9000 // 6000 on Kerbin
%deploymentAlt = 4500
%preDeploymentSpeed = 1
%deploymentSpeed = 3
}
}
}
@PART[RC_cone_double]:FINAL{
@MODULE[RealChuteModule]{
@PARACHUTE,0 {
%minIsPressure = false
%minPressure = 0.6
%minDeployment = 2500
%deploymentAlt = 850
%preDeploymentSpeed = 2
%deploymentSpeed = 6
}
@PARACHUTE,1 {
%minIsPressure = true
%minPressure = 0.3
%minDeployment = 9000 // 6000 on Kerbin
%deploymentAlt = 4000
%cutAlt = 2500
%preDeploymentSpeed = 1
%deploymentSpeed = 3
}
}
}
@PART[SDHI_ParaDock_1_ClampOTron]:FINAL{
@MODULE[RealChuteModule]{
@PARACHUTE,0 {
%minIsPressure = false
%minPressure = 0.6
%minDeployment = 2500
%deploymentAlt = 850
%preDeploymentSpeed = 2
%deploymentSpeed = 6
}
@PARACHUTE,1 {
%minIsPressure = true
%minPressure = 0.3
%minDeployment = 9000 // 6000 on Kerbin
%deploymentAlt = 4000
%cutAlt = 2500
%preDeploymentSpeed = 1
%deploymentSpeed = 3
}
}
}
@PART[SDHI_ParaDock_2_IACBM]:FINAL{
@MODULE[RealChuteModule]{
@PARACHUTE,0 {
%minIsPressure = false
%minPressure = 0.6
%minDeployment = 2500
%deploymentAlt = 850
%preDeploymentSpeed = 2
%deploymentSpeed = 6
}
@PARACHUTE,1 {
%minIsPressure = true
%minPressure = 0.3
%minDeployment = 9000 // 6000 on Kerbin
%deploymentAlt = 4000
%cutAlt = 2500
%preDeploymentSpeed = 1
%deploymentSpeed = 3
}
}
}As an aside, the parachutes really need a "panic deploy" action if you're coming down in the mountains. You'll have to right-click, go to info, and pull the pressure slider down to force them out.
-
Javascript is disabled. View full album
I'm finally getting around to learning git and contributing a few tweaks to Raptor's repository.
I'm not sure how well I'll end up maintaining this (git is confusing for a guy like me who uses svn at work), but anyone interested in playing with my terrain should be able to download my latest progress from here:
https://github.com/NonWonderDog/6-4-KerbolSystem/archive/develop.zip
Still a few things left to do, and I haven't found time to check the easter eggs yet. And I really want to see Kerbin with fjords.
-
I'm still toying with this, and I think I'm almost getting the hang of the terrain settings. The first image is from the mountains near KSC:
Javascript is disabled. View full album
The way the heightmap is drawn makes for some funny-looking mountain ranges sometimes, and I can't imagine what kind of plate tectonics would generate the geography near Roka. But with the noise frequency turned way up our goofy mountains look a lot bigger and more impressive -- even though I've shortened all the mountains significantly. I think I shortened them too much -- I was aiming for Everest but it looks like I ended up with Aconcagua -- but I'm having trouble raising them again and keeping the nice crags and valleys. This is using the edited heightmap I made, but I'm not sure how necessary it is. I'll try with the default one and see if it makes a difference.
I also want to go through and try to make sure all the easter eggs on on Kerbin aren't floating in the air or buried under a mountain. Anyone know how to convert the 3D coordinates shown in the terraforming mod to latitude and longitude?
-
Fighter pilots being what they are, fighter jets quite often take off in afterburner, especially if they're trying to look cool for an audience (or are taking off from a carrier). An F-15 at full afterburner can take off in a VERY short distance. For instance:
What they absolutely don't do, is go from one end of a 15,000 foot Shuttle Landing Facility runway to the other at full afterburner before rotating. The tires would explode and the plane would probably spin out of control at more than half the speed of sound and possibly disintegrate due to aerodynamic forces before exploding in a gigantic fireball and strewing a several mile area in front of the runway with flaming wreckage. The fact that such a takeoff is standard procedure in KSP for many players is slightly odd.
-
Here's the config I use, almost entirely adapted from Realism Overhaul:
@PART[mk1pod] {
@MODULE[ModuleHeatShield]
{
@direction = 0, -1, 0
@reflective = 0.05
@ablative = AblativeShielding
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 160 0 0
@key,2 = 5000 200 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 480 0 0
}
}
}
@PART[Mark1-2Pod] {
CoMOffset = 0, 0, -0.12
}
// ##########################################################################################
@PART[0625_Heatshield]
{
!MODULE[TweakScale]
{
}
@title = Heatshield (0.625m)
@mass = 0.05
@MODULE[ModuleHeatShield]
{
@direction = 0, -1, 0
@reflective = 0.05
@ablative = AblativeShielding
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 40 0 0
@key,2 = 5000 50 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 1920 0 0
}
}
}
// ##########################################################################################
@PART[1.25_Heatshield]
{
!MODULE[TweakScale]
{
}
@title = Heatshield (1.25m)
@mass = 0.08
@MODULE[ModuleHeatShield]
{
@direction = 0, -1, 0
@reflective = 0.05
@ablative = AblativeShielding
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 160 0 0
@key,2 = 5000 200 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 480 0 0
}
}
}
// ##########################################################################################
+PART[1.25_Heatshield]:Final
{
!MODULE[TweakScale]
{
}
@name = Heatshield-25M
@author = Bobcat,NK
!mesh = DELETE
MODEL
{
model = DeadlyReentry/Parts/deadlyReentry_1.25Heatshield/model
scale = 2.5, 2.5, 2.5
}
@scale = 2.5
@rescaleFactor = 1.0
@node_stack_top = 0.0, 0.06196643, 0.0, 0.0, 1.0, 0.0, 2
@node_stack_bottom = 0.0, -0.01, 0.0, 0.0, 1.0, 0.0, 2
@title = Heatshield (2.5m)
@mass = 0.10
@crashTolerance = 8
@breakingForce = 250
@breakingTorque = 250
@MODULE[ModuleHeatShield]
{
@reflective = 0.08
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 300 0 0
@key,2 = 6000 375 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 284 0 0
}
}
@RESOURCE[AblativeShielding]
{
@amount = 625
@maxAmount = 625
}
@MODULE[ModuleDecouple]
{
@ejectionForce = 40
}
}
// ##########################################################################################
@PART[2.5_Heatshield]
{
!MODULE[TweakScale]
{
}
@description = Oops. Somebody forgot to put a heat shield on the Mk 1-2 Pod. Here it is. Sturdy thermal shield to keep the fiery death on the outside of the pod. Make sure the shield points to the travel direction while re-entering, or the pod may still get heated up. Recommended for any pods re-entering atmospheres.
@mass = 0.125
@crashTolerance = 8
@breakingForce = 250
@breakingTorque = 250
@MODULE[ModuleHeatShield]
{
@reflective = 0.08
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 480 0 0
@key,2 = 6000 600 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 170 0 0
}
}
@RESOURCE[AblativeShielding]
{
@amount = 848
@maxAmount = 848
}
!MODULE[ModuleDecouple] {}
}
// ##########################################################################################
@PART[3.75_Heatshield]
{
!MODULE[TweakScale]
{
}
@title = Heatshield (3.75m)
@mass = 0.21
@MODULE[ModuleHeatShield]
{
@direction = 0, -1, 0
@reflective = 0.05
@ablative = AblativeShielding
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 1500 0 0
@key,2 = 6000 2000 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 50 0 0
}
}
}
// ##########################################################################################
@PART[6.25_Heatshield]
{
!MODULE[TweakScale]
{
}
@title = Heatshield (6.25m) - Inflatable
}
// ##########################################################################################
// ##########################################################################################
@PART[KM_iheat0]
{
@mass = 0.08
@MODULE[ModuleHeatShield]
{
@direction = 0, -1, 0
@reflective = 0.05
@ablative = AblativeShielding
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 160 0 0
@key,2 = 5000 200 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 480 0 0
}
}
@RESOURCE[AblativeShielding]
{
@amount = 250
@maxAmount = 250
}
}
@PART[KM_iheat1]
{
@mass = 0.125
@MODULE[ModuleHeatShield]
{
@reflective = 0.08
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 300 0 0
@key,2 = 6000 375 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 284 0 0
}
}
@RESOURCE[AblativeShielding]
{
@amount = 625
@maxAmount = 625
}
}
@PART[SDHI_2.5_Heatshield]
{
@mass = 0.125
@crashTolerance = 16
@MODULE[ModuleHeatShield]
{
@reflective = 0.08
@loss
{
@key,0 = 650 0 0 0
@key,1 = 2000 480 0 0
@key,2 = 6000 600 0 0
}
@dissipation
{
@key,0 = 300 0 0 0
@key,1 = 800 170 0 0
}
}
@RESOURCE[AblativeShielding]
{
@amount = 848
@maxAmount = 848
}
}It's a bit overkill, but you can still burn up with a heavy payload or a steep descent. I haven't actually had time to test the CoM offset on the Mk1-2 pod, though.
-
{inclination change at the ascending/descending node where your orbit intersects the target orbit}<this I understand. I do match inc burns all the time. Is LAN just a measurement of the inclination, or a specific point in the orbit? How does matching Inclination, control the point of LAN? the two must be independent, or matching one, would match the other. I don't understand how you do this>{inclination change at the ascending/descending node where your orbit intersects the target orbit} to change LAN. Either its way more complicated than I've figured out, or [i'm making it way more complicated than I need too.]<guilty of very often.
To get your LAN correct first try for Kerbin orbits, launch when the target orbit passes over KSC. LAN describes the location of the ascending node compared to the fixed starfield, and since KSC is on the equator you should launch when the ascending or descending node is directly over KSC.
To change the position of the ascending node when already in orbit (to precess the orbit), one way is to thrust normal to the orbit at the point 90 degrees past the ascending or descending node. This is most obvious (and correct) in a circular polar orbit -- thrusting out of plane at the poles won't make your orbit any less polar, but it will change the point at which you cross the equator. Be aware that this is NOT an efficient or even really correct maneuver otherwise, and it will change both your inclination and argument of periapsis.
Better for a circular orbit is to thrust at one of the two points at which your current and desired orbits cross. Better for an elliptical orbit is to scrub the mission and try again (seriously, don't look at the math for this one if you value your sanity). Your best bet for large changes is a bi-elliptic transfer, but figuring out where to start it can be fun.
LAN for orbits around Earth is almost always called RAAN (Right Ascension of the Ascending Node) for astronomical reasons (and to understand why you need other fun terms like "obliquity of the ecliptic"). You'll probably have more luck with "RAAN" in a Google search.
-
I still can't seem to control the textures, but that's more minor to me.
The landClass->altitudeRange->startStart, startEnd, etc. parameters seem to be fractions of or at least somehow based on a PQSLandControl parameter called vHeightMax. By default it's 3500. When the terrain was scaled by ~2x this should have been doubled as well.
I couldn't get very far by changing the altitudeRange values either. You'll get further if you add startStart, startEnd, endStart, and endEnd parameters for "baseLand" to the list (it's the default grass and trees), but it takes way too long to see changes without an in-game editor. I think these are essentially trapezoidal fuzzy logic functions for each land class, converted to meters ASL by multiplying by vHeightMax.
RSS reads vHeightMax, so you you might have okay results just replacing the PQSLandControl block with:
PQSLandControl
{
vHeightMax = 7000
}You can use the terraforming mod to mess with the terrain stuff (including vHeightMax) in near real-time. You can't change the landClass altitudeRange parameters, though.
= P(B|A) * P(A) / P(
Why is there a conflict of interest at all between realistic and unrealistic aerodynamics?
in KSP1 Discussion
Posted · Edited by NonWonderDog
The droopy nose is because of the delta wing. Since Concorde has a smallish delta wing, it landed at something like 35 degrees angle of attack (unlike most planes that land at closer to 12 degrees angle of attack). And so it needed a droopy nose for the pilots to see the runway. And it had a delta wing because of supersonic flight.
I thought that could be pretty easily inferred from my post.
It's just that things in real life look the way they do for a reason. I think that "aha" moment when you figure out why they look the way they do is fun, and more fun that just using swept wings because you think they look cool.