Jump to content

Captain H@dock

Members
  • Posts

    136
  • Joined

  • Last visited

Reputation

46 Excellent

Profile Information

  • About me
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm afraid I didn't make myself clear. KSP Trim is not working as trim does work on real aircrafts. In KSP, Trim is an offset on control input but only so long as you give no input. As soon as you're giving an input, trim is ignored, until you stop giving inputs. On real planes, Trim in an offset on neutral control input even when you are giving inputs, it adds up to your input. For instance: In KSP you could be half trim aft, hands off the control: control surfaces are at a 50% deflection to pitch up. Apply a little back pressure (5% of max back pressure) on the stick, and the trim setting is currently ignored until you release the stick. Which means by pulling back, the control surfaces reduced their deflection (to 5% pitch up), and are pitching less up, instead of going to 55%. Let go of the stick, and they're back to 50%. Note: This won't be visible if you're using binary inputs (keyboard). But I'm using a joystick for planes, and this means I can't use control surface trim because it produces discontinuous inputs by being ignored except when crossing the neutral input area... Note2: I know what the trim tab looks like on a small aircraft. What KSP is doing surely isn't emulating that. Note3: There's a small chance this might be a side-effect of AFBW, but I really don't think so, I'll try to confirm that tonight.
  2. Trim does do something, just as long as there are no control inputs. Which is not what planes trim is supposed to do, but it might make sense for rocket (it's not because I can't think of any reason for it that it makes no sense). However, it makes Trim pretty useless for planes, which by definition require constant inputs. And I second that "plane holds" would be nice to have, yet they would probably complexify the interface, meaning this is probably better left to a mod for those of us who want to do plane things.
  3. Same as above. Perfect for when you want to point at a direction relative to your craft: docking, flying a plane... Unlike chase which often drift for no real reasons. On top of it, RCS burns always make sense in locked mode, because the vertical and horizontal axis are matching the navball one. If you go to locked and put yourself behind your craft, I/K will do vertical burns that will move your craft toward the top (K) or the bottom (I) of your screen. Likewise for J/L (though looking at your craft from the front in locked mode will look like J/L are reversed).
  4. [quote name='vixr']Jeb takes one last look at his stranded lander, fires up the MMU and flies home without it... That scene just makes me smile.[/QUOTE] Except that in 1.0.5 Jeb now catches fire quite high in the atmosphere even after a suborbital hop. So I would say these days are gone (and rightly so). :wink:
  5. Same here, my ascent profile doesn't work anymore. You don't seem to cool down until 18ish km, which is fine with decent TWR/TDR spaceplane, but might prove a problem for the more optimised ones. But if you climb earlier, and settle for less air breathing speed (1400 instead of 1500 in my case), you can still do it with the same fuel load. However, getting more than 1450 m/s from the air-breathing will probably be difficult now... What I've been using for that quick run (fuel loads are from 1.0.2, fill everything for a lot of margin):
  6. So that's confirmed! Thanks you so much for that fix. This deserve so much more publicity (I follow the dev notes and the squad cast minutes and I only remember hearing about the distance and marker now being on the target, but not the indicator being fixed). So many good things in 1.0.5, but this is one I've really been longing for.
  7. I just stumbled on this when going through the full Change Log: [COLOR=#333333]* Fix vector to target (on navball) to calculate from current control-from-here transform to target transform, rather than vessel root transform to target transform.[/COLOR] source: http://forum.kerbalspaceprogram.com/threads/138798-The-Grand-KSP-1-0-5-Discussion-Thread%21 Now, it will be another 2 hours until I'm able to run 1.0.5, but could this mean the Navball target indicator bug (for off-centered docking ports) has been fixed? :) For context on that bug : http://forum.kerbalspaceprogram.com/threads/131879-Radial-Attached-Docking-ports?p=2144650&viewfull=1#post2144650
  8. That exploit was fixed in 1.0.3 if I'm not mistaken. Only the scientist manning the lab now count for science generation speed.
  9. In 1.0.4 I was doing all my rapier runs at a constant altitude somewhere between 15.2 and 15.8 km. Anything lower and I was overheating when reaching 1100m/s. Upon reaching 1450-1520 m/s, I was starting a constant speed pitch up, aiming for a 10-12 degrees climb (prograde marker) at 19 km. Speed was usually starting to decay between 22 and 24 km, where I would usually switch. I haven't had the opportunity to play 1.0.5 yet, but I should be able to 6 hours or so.
  10. But as the air is getting thinner, you also loose thrust. Try to climb at a constant speed, and check the tooltip of the engine: Thrust is decreasing. To gain speed, you need drag to decrease faster than thrust does, which is dependent on several parameters (on top of which i'm not).
  11. It has a TWR of less than 1. Source: You can't lift off Kerbin using it. Nor Tylo. In fact the wiki quotes the jet pack as capable of providing a 3.2 m/s² acceleration. That would make it a .4 TWR compared to Tylo surface gravity, or 0.33 compared to Kerbin.
  12. LV-n isn't possible with a reasonable size according to my planning. The only engine in 1.0.4 (apart from the super big ones) with enough TWR and ISP is the aerospike. Payload fraction is about ridiculous and dV is marginal (5.2K dV), but TWR is higher than 1.0 from orbit, and above 2.0 from take-off. Except if my math/data are wrong.
  13. Well, the equation is always that simple. Also, nobody should have to guesstimate natural log in the 21th century. Just prepare a spreadsheet with dry weight, fuel weight (or wet weight), and Isp as inputs, and voila, you get dV for single stage ships. It's then up to you to enrich it with spreadsheet wizardry (using id and vlookup for quick tanks and engines referencing, options for extra tanks or payload) for what your use cases are. Also, this thread is making me slightly nervous regarding my Tylo re-usable lander (no ISRU). Luckily, I won't know if I've made a terrible mistake until 2 kerbal years from now...
  14. I'm fairly sure the 3.7x he's mentionning is a scale factor, not a version number. kerbol A.Bx refers to the Kerbol System where all distances are multiplied by the A.B decimal number. I'm assuming other physical properties are scaled appropriatly, hence the higher dV requirement to orbit. edit: Also, considering how much I've struggled to make a Tylo chemical re-usable lander with an aerospike (which is similar to your dV requirement => 5,000 ish dV), I suspect OP won't be able to get any decent payload fraction with KSP default parts.
×
×
  • Create New...