Jump to content

Lt_Duckweed

Members
  • Posts

    249
  • Joined

  • Last visited

Reputation

430 Excellent

Recent Profile Visitors

3,640 profile views
  1. With the altitude you are at I wouldn't worry about this. While the speed of sound is around 250m/s up at the altitudes where I was flying in my example, down where you are it's going to be closer to 285m/s. So your props have gone slightly supersonic, however, slightly supersonic is ok, as the ducted fan blades don't hit their performance wall until around Mach 1.2 You could extract a bit more speed with more tweaking of the prop, but if you are happy with what you have, its a pretty good result.
  2. 229.4m/s (approximately Mach 0.9) in level flight at 13.7km A few tips: For whatever reason, for the 2x4 fixed panels, long side edge on into the airflow is lower drag than any other setup, especially the left long side (going by the default orientation when attaching it to a forward facing part in the SPH). For the size rotor you have, 6 panels is massive overkill. 1 2x4 panel is more than enough for a single small rotor. Ducted fan blades are better than propeller blades in pretty much every conceivable metric (and shrouds are cosmetic only, you just need the blades) Due to lower speed of sound on Eve, I get better results limiting RPM to 400. If you offset the base of the fan blade directly inwards towards the axis of rotation, it will improve the thrust to torque ratio on the blades, so you can run more per rotor. The farthest you can go is one shift tick past the axis of rotation (so the base of the blade is on the other side from the rest of the blade). This should let you comfortably run a pair of large ducted fan blades on the smallest rotor Run a pair of two blade rotors, with two solar panels. This should get you a lot more thrust and greatly increase top speed, but will not effect your overall mass much since you removed the extra solar panels. In low light conditions where 2 panels may not be enough, simply lower the torque limit on the rotors a bit. This will lower your top speed a bit, but it will still be a lot faster than you are getting right now.
  3. The key is setting the deploy limit on a service bay to one of the axis groups in the action group configuration. While you cannot deploy a service bay while it is shielded, you can adjust the deploy amount, which results in it deploying. The setup goes like this: You have a root fairing whose base is shielded from solar heating by some other part that is larger than the base, but smaller than the overall fairing, so it can shield the base and be shielded in return. In front of this, a structural plate or multiple structural plates have all drag cube faces fully occluded, creating perfect shock shields. A service/payload bay is positioned such that the center of the bay is considered "inside" the fairing, but a substantial portion of the bay volume is actually located outside of the fairing. A flag or flags of the largest size that the bay can shield are located in the portion of the bay that is outside the fairing. If the flags are not located in the shock shadow of the main shock shield (as is the case for the main station) then a smaller shock shield(s) is constructed that sits immediately in front of the flags, but is also still outside the fairing. Finally, the axis group chosen to control service bay deploy limit is adjusted to open/close the bays as desired. Interestingly, there are a few other scenarios where you can use axis groups to perform actions that are normally forbidden via action groups. Some examples: Actuating service/payload/cargo bays when they are shielded. Deflating an inflatable heatshield after it has already been inflated (can be done as many times as you like) Deflating an inflatable airlock that already has a kerbal inside it.
  4. Are you using grandparent autostrut? It's practically useless for stiffening in cases like this. Autostrut a few parts on the payload to heaviest, and a few of the parts on the rocket/side boosters to root.
  5. Yes the the mults and clamps are just dimensionless constants. You start with a value of 1, then take the density and velocity mults and go from there
  6. The actual trueThrustMult you get once above the flowMultCap is: trueThrustMult = flowMultCap + (thrustMult - flowMultCap) / (flowMultCapSharpness + (thrustMult - flowMultCap)/flowMultCap) By default, flowMultCapSharpness is 2 and no stock engine has an alternate value Working an example, the Whiplash has a flowMultcap of 2 and the default sharpness of 2. So at a normalized density of 1 (for example, flying at sea level at 30 degrees latitude at "3 am" or 45min after midnight under Kerbin time) at a speed of exactly Mach 3, the supposed thrust mult of 5.8 would get transformed like so: trueThrustMult = 2 + (5.8 - 2) / (2 + (5.8 - 2) / 2) = 2.97 EDIT: As an additional note, the atmCurve is not based on pressure, but on normalized density, with a normalized value of 1 = 1.225 km/m^3, which is the sea level density under the ISA (International Standard Atmosphere) and occurs at a temperature of 15C. Interestingly, this results in jet engines not providing their full advertised thrust on the runway, as it is significantly warmer than 15C on Kerbin's equator, and so the atmosphere is less dense.
  7. VertexHeightOblateAdvanced 1.1.1 What's new: Fix for NullReferenceException and broken camera when in the SOI of a body without a PQS (Stars and Gas Giants) Download Github SpaceDock
  8. unfortunately no And oblate SOI would be cool but also difficult to implement in code.
  9. @Whirligig Girl I believe you will find this quite interesting. I have updated VertexHeightOblateAdvanced with two new camera modes, one of which aligns normal to the shape defined by the PQS mod, and the second of which aligns with apparent gravity:
  10. VertexHeightOblateAdvanced 1.1.0 What's new: When in the SOI of a body implementing VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies. SURFACE NORMAL Functions like FREE camera mode, but with the vertical axis aligned perpendicular to the shape defined by the VertexHeightOblateAdvanced instance. This eliminates the "uphill effect" that oblate bodies have. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. GRAVITY NORMAL Functions like FREE camera mode, but with the vertical axis aligned with the local apparent gravity vector, taking into account the effects of rotation. Surfaces that look flat and level are actually flat and level relative to gravity. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. Download Github SpaceDock
  11. You don't need anywhere close to this much twr on your nervs. When your rapiers stop being able to accelerate you somewhere a bit past Mach 5, you should still have a lift to drag ratio close to or exceeding 4 if you have paid attention to some basic drag optimizations. You are also high enough that the nervs are at essentially 100% thrust and ISP. At this point a initial twr of 0.3-0.4 will cut it, and as you burn off fuel and also get closer to orbital speed, the needed twr to overcome drag will drop even as your actual twr will climb. It's harder than stock scale sstos for sure, but it's a lot easier than stock part RSS sstos, which have been done before by a number of people.
  12. Is this body meant to represent Haumea perchance? When replicating a existing body with a known shape, it would be easiest to use CustomEllipsoid mode, so you can set the a, b, and c parameters equal to the known real values. Additionally, when using UniformEquipotential or PointEquipotential, the radius and geeASL you input must match the values for the poles. For Haumea this would be something like 525km radius, and a geeASL of around 0.095 Unfortunately this still gives a shortest possible period under the Uniform model that is longer than the actual real period of Haumea. This is because in reality, Haumea is probably not uniform in density but is denser towards the core, and thus would have a shorter period than what the model would predict. In such a case it is supposed to clamp to an oblate value that is within the bounds of the model, but seems like this edge behavior may have a bug I need to fix. All that said, assuming this is indeed Haumea, my recommendation would be to use the polar radius and gravity, and try using CustomEllipsoid to manually set the a,b, and c values (c should be 1, a should be a bit over 2, and b should be around 1.6).
  13. Can you post the config for the planet so I can take a look? Since it tries to be as realistic as feasible on shape, if a planet isn't rotating all that fast it won't change the shape much at all. It's possible that is the issue here. As an example, if the Earth was had a period of 6 hours, or 4x faster than it does now, it would only have a Equatorial to Polar axis ratio of 1.07, which is going to be hard to notice to the naked eye.
  14. Love it! This is exactly the reason I included Blend mode. Pure PointEquipotential just doesn't quite look right for a lot of bodies, but blending with a standard oblate distortion broadens the lens enough to get something that looks really good! Oh and as a side note, for ease of use for end users, it is perfectly acceptable, encouraged even, to distribute the VertexHeightOblateAdvanced dll, readme, and license packaged with Whirligig World in GameData\000_DuckweedUtils\VertexHeightOblateAdvanced\
  15. VertexHeightOblateAdvanced VertexHeightOblateAdvanced is a custom PQS Mod intended for use by planet modders to enable easy creation of oblate bodies via a simple PQS Mod, rather than via a heightmap. Additionally, when in the SOI of a body implmenting VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies. Planet pack developers implementing VertexHeightOblateAdvanced are encouraged to bundle it with their mod, for the convenience of users. Examples PointEqupotential UniformEquipotential Low UniformEquipotential Low UniformEquipotential High UniformEquipotential High Download Github SpaceDock Installation and Use Install ALL listed dependencies, following the links below Download and extract the VertexHeightOblateAdvanced zip file Place the GameData folder into your KSP directory Once installed, simply add a VertexHeightOblateAdvanced node to the Mods node in your body's PQS node Using the following Google Sheet, find appropriate periods for your body to get the desired oblateness, based on body surface gravity and radius. Camera modes: SURFACE NORMAL Functions like FREE camera mode, but with the vertical axis aligned perpendicular to the shape defined by the VertexHeightOblateAdvanced instance. This eliminates the "uphill effect" that oblate bodies have. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. GRAVITY NORMAL Functions like FREE camera mode, but with the vertical axis aligned with the local apparent gravity vector, taking into account the effects of rotation. Surfaces that look flat and level are actually flat and level relative to gravity. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. Parameters and expected values: oblateMode: overall controller for type of generation used Values: (PointEquipotential, UniformEquipotential, Blend, CustomEllipsoid) PointEquipotential: Generates a point mass equipotential UniformEquipotential: Generates a uniform density equipotential, either a Maclaurin spheroid or Jacobi ellipsoid deppending on energyMode and period Blend: Multiply a PointEquipotential by a CustomEllipsoid CustomEllipsoid: Generate an ellipsoid based on a, b, and c axis values energyMode : Used with: oblateMode (UniformEquipotential) Values: (Low, High) Low: For the given period, generate using the low oblateness branch. Always generates a Maclaurin spheroid High: For the given period, generate using the high oblateness branch. Generates either a Maclaurin spheroid or Jacobi ellipsoid based on period mass: Mass of the body as set in the Properties node. Optional if both radius and geeASL are provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) radius: Mass of the body as set in the Properties node. Optional if both mass and geeASL are provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) geeASL: Surface gravity of the body as set in the Properties node. Ignored if both mass and radius are provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) period: Rotational period of the body as set in the Properties node. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) a: The primariy equatorial axis as a ratio of provided radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) b: The secondary equatorial axis as a ratio of provided radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) c: The polar axis as a ratio of provided radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) Requirements ModuleManager Kopernicus FAQ Q. I'm not a planet modder? Do I need this? A. You do not need to install it manually yourself, but if you found this in you GameData, it is because a planet pack you have/had needs/needed it and so it was either included with the mod or auto installed through CKAN Licensing VertexHeightOblateAdvanced is licensed under the MIT License
×
×
  • Create New...