jwbrase

The shuttle was a really aggressively swept delta. Lift is low in FAR compared to stock, but planes in general lose tons of energy in a stall and deltas absolutely bleed energy before they get near the stall (the wingtip vortices from the front part of the wing inject energy on the upper surface of the back part of the wing, delaying the stall to higher angles of attack). If you've got a delta-ish planform and you're having trouble maneuvering aggressively enough to get down to your straight-and-level stall speed well short of the runway, you likely have a balance or control-authority issue and probably aren't getting anywhere near stalling with full stick back: this will negatively impact the flyability of your spaceplane in all flight regimes except vacuum: reentry will be hotter for a given aggressiveness of deceleration, transitioning from a jet-powered lifting ascent to a rocket-powered ballistic ascent will be more difficult, and subsonic flight will have the character you describe. In extreme cases there may be parts of the flight envelope in the mach 1 to mach 2 region where you have no up-elevator authority at all. If you *are* managing to pull enough AOA to get near the stall, and your stall speed is super high, you probably just don't have enough wing area. Can you post an overhead view of your spaceplane with CoM and CoL showing, and screenshot of a FAR AOA sweep at 0.5 Mach and at 0, 0.5, and 1 pitch settings? Gear could probably afford to be more draggy in FAR, but you shouldn't really need it to be draggy.

If you're 15 km out and 1.5 km up and maintain the same speed the whole way in (start at 200 m/s, end at 200 m/s), that corresponds to a L/D ratio of 10, which is about as good as a Cessna 172. Airliners typically have a L/D at their best glide AOA of about 15/1 or 20/1. Assuming an average speed of 150 m/s the whole way, slowing down from 200 m/s to 100 m/s in 15 km corresponds to a time of 100 seconds and a deceleration of 1 m/s^2 (or 1/10th of a gee), so you're not even making a 10/1 L/D there. So I'd say your L/D is reasonable. One big problem is that the mountains to the west of the KSC enforce a fairly aggressive descent rate for prograde reentries landing at the KSC, so if you have a spaceplane with better aerodynamics that a brick, you generally have to take some sort of measures to slow down once you're across the mountains. Airbreaks or spoilers of some type are generally helpful here. S-curves can be your friend: A spaceplane will generally be engineered with a delta planform for high-mach performance, which tends to enhance induced drag at subsonic speeds, so a few high-AOA turns can slow you down quite a bit. EDIT: What I have found is that FAR planes tend to have both less lift and less drag than stock, so takeoff / landing speeds are often ~50% higher. Building aircraft optimized for short-field performance is often an exercise in frustration. I think some of this may have to do that most KSP airfoils are flat plates (which doesn't have really great real-world characteristics), and often fairly thick ones at that (once again, not great).

Tried building a half-km x 50 meter three-deck (landing, hanger, launch) floating runway with girders, type 1 flight deck extensions, Ray balloons, and lots of Ubio-zur welding, but couldn't get something that would simultaneously stand up to the stress of flight operations, not crash the editor, and not go beyond what Ubio-zur could put into one part without glitches. Gave up, rigged my heavy cargo spaceplane with folding wingtips to get the wingspan under 40 meters, and started building a more traditional three-hull airship with 40m tweakscale. Editor's fine with it, part count is low, and then, with the thing not even half designed, I take a look at the cost, and just about take a stroke. Building at 40-meter tweakscale is *expensive*.

Ah. I'd not been playing KSP for a while and I am a number of versions back (because I have an active save that I'm trying not to break mod compatibility for, and because I've found that if I copy my existing install and save to a separate directory and update KSP, I end up just starting a new save and not finishing my existing one). I'd also swear I saw Angel-125 saying somewhere back on the thread that he hadn't given permission for Heisenberg to be included on CKAN (I just discovered Heisenburg in the past few weeks, and it may be the key to the upper-atmospheric heavy cargo terminal I've been wanting to build on Eve, so I've binged through most of the thread).

I don't believe Heisenburg itself is on CKAN, so I'm not sure how smoothly I'd expect CKAN installs of things that depend on it to go (in principle, a mod that depends on a mod that isn't on CKAN shouldn't be on CKAN in the first place for that very reason).

I looked through all the non-source releases of CLS on github, and they all have consistent capitalization of that folder name. The first thing I suspected was that maybe different versions had used different capitalizations, and he'd unpacked a newer version over an older one, but that rules that out, so about the only thing I can imagine is if files are being dropped into the folder at runtime. With a quick search through the folder tree, I found the following locations where files are referenced with an all-lowercase path (filename:line-number:text-of-matching-line): Ships/Script/Abort.ks:53:runpath("0:/cls_lib/lib_num_to_formatted_str.ks"). Ships/Script/Abort.ks:54:runpath("0:/cls_lib/lib_navball.ks"). Ships/Script/Abort.ks:55:runpath("0:/cls_lib/CLS_nav.ks"). Ships/Script/CLS.ks:49:runpath("0:/cls_lib/CLS_parameters.ks"). Ships/Script/CLS.ks:89:runpath("0:/cls_lib/CLS_dv.ks"). Ships/Script/CLS.ks:90:runpath("0:/cls_lib/CLS_gen.ks"). Ships/Script/CLS.ks:91:runpath("0:/cls_lib/CLS_hud.ks"). Ships/Script/CLS.ks:92:runpath("0:/cls_lib/CLS_nav.ks"). Ships/Script/CLS.ks:93:runpath("0:/cls_lib/CLS_res.ks"). Ships/Script/CLS.ks:94:runpath("0:/cls_lib/CLS_twr.ks"). Ships/Script/CLS.ks:95:runpath("0:/cls_lib/CLS_ves.ks"). Ships/Script/CLS.ks:96:runpath("0:/cls_lib/lib_instaz.ks"). Ships/Script/CLS.ks:97:runpath("0:/cls_lib/lib_lazcalc.ks"). Ships/Script/CLS.ks:98:runpath("0:/cls_lib/lib_navball.ks"). Ships/Script/CLS.ks:99:runpath("0:/cls_lib/lib_num_to_formatted_str.ks"). Ships/Script/CLS.ks:100:runpath("0:/cls_lib/CLS_log.ks"). Ships/Script/ChuteDescent.ks:3:runpath("0:/cls_lib/lib_num_to_formatted_str.ks"). Ships/Script/ChuteDescent.ks:5:runpath("0:/cls_lib/lib_navball.ks"). Ships/Script/ChuteDescent.ks:6:runpath("0:/cls_lib/CLS_nav.ks"). It's a bit odd, because it doesn't look like those files are being written to, but if they're just being read, I'd expect that A) It wouldn't create the files referenced, and B) CLS would fail to find the files and wouldn't work, but it seems it's managing to use the wrong-case filename to reference the files in the right-case directory, and is then creating the wrong-case directory and copying the files to it. About the only thing I can imagine is if something in the middleware stack between Linux and CLS (most likely Mono, maybe KSP itself) is aware that it may be run on multiple platforms and, when it doesn't find a file, is proactively looking for files that exist with mismatched case, then copying them to the path that's being referenced. I'm not sure that's the best solution; what if the user unpacks a new version of CLS over the right-case folder tree? That won't update the wrong-case files, and they'll likely be referenced instead of the right-case ones, so I wish it would just choke early on the bad filename rather than saving the day now and potentially causing subtle and tricky problems later, but that's not anything you can fix. All you need to do is make sure that you're always referencing files with the same case that they have on the filesystem, and then it doesn't matter what the middleware is doing on the back end.

A whole log looks overwhelming, but the general workflow one uses is to search the log using one search term, and then, depending on what you find, try others. If the user is just told, "give me all the lines that match this search term", then going back and forth with multiple search terms will take a while. If the user is given a tree of search terms to try, the likelihood that the user misses something in the tree or the dev forgets to include something is much higher. If the user just gives the dev the whole log to start, then the dev can work through the log at his own pace without having to wait for further user response.

If reaction mass is not an on-board resource, then the ideal case, performance wise, is to be pushing against an infinite block of solid reaction mass, and for our exhaust velocity to match our forward velocity. The spherical cow for this case is a wheeled rover on an infinite flat plane of infinite rigidity. In real life, this is very well approximated by any wheeled vehicle sittting on the ground, and in KSP, given that celestial bodies are on rails, I'm pretty sure that this ideal case is met pretty much exactly for rovers. The reason this is the ideal case is that if you are pushing against a finite mass (with your exhaust velocity thus having to be a bit greater than your forward velocity to conserve momentum), then some of the energy from your fuel ends up in the backwards motion of the exhaust stream rather than the forward motion of your vehicle. Of course, with any engine using a fluid as a reaction mass, you're never going to achieve this ideal exactly, but you still want as much reaction mass as you can get if you're sourcing it from off-board. You only need machinery to force air into the engine in the low speed regime, which is where you benefit the most from very high mass flow. At high speeds, ram pressure suffices. In fact, at very high speeds, ram pressure is your enemy: most of the thermal energy in your combustion chamber at high speed comes from ram compression and the fuel you're burning contributes relatively little. Given that your engine materials only remain solid up to a certain temperature, this places a limit on your maximum speed: once compression heating brings the gas stream up to the thermal limits of your engine, you can't add any fuel without melting the engine, so the engine can no longer provide any thrust. Now, if you had some super-material that could remain solid up to insane temperatures, you'd still have a problem: the temperature in your combustion chamber has to be less than the dissociation temperature of the products of whatever reaction you're using to provide heat (for kerolox, that will be the dissociation temperatures of water and CO2), or your fuel mixture won't actually burn until it's on the way out the tailpipe (so that some/all of the heat added by burning the fuel doesn't expand the airstream in time for the exhaust nozzle to turn it into forward motion of the aircraft). Scramjets solve this problem by slowing down the incoming airstream less, so there's less ram compression. SABRE (the real-life inspiration for the RAPIER) solves this by using LH2 as fuel, and using the LH2 to cool the intake air as it's compressed (actually it's a bit more complicated than that, but that's the general idea).

Well, then it's not what I'm calling a "COuGHjet", as the fuel (that is the fuel-oxidizer mix) is not completely on-board. A ducted rocket, where no burning of any kind happens downstream of the rocket chamber, would be a type of COuGHjet, but isn't what I'm asking for here. Heating intake atmo with burning fuel is what I'm proposing, and at low speed, yes, it's going to be outperformed by a propeller, and the electrical efficiency of a fuel cell probably pushes the range at which the propeller is a better choice up to higher speeds (compared to a propeller driven by reciprocating engine with oxidizer supplied from on-board, or by a COuGHjet turboprop). But that's actually no different from the case for regular jets in an oxygen atmosphere, if you allow the fuel cell to use atmospheric oxygen. But at some speed (at latest Mach 1, for realistic propellers, and probably well before that), the jet will start outperforming the propeller.

Yes, that is one way of building a jet that will work in an inert atmosphere, but I'm actually proposing something more low tech: you just have a normal jet engine, and you squirt both fuel and oxidizer into the combustion chamber. Your compressor draws in inert ambient air, and forces it back into the combustion chamber, where it mixes with and is heated by the burning fuel-oxidizer mixture. The hot ambient air / exhaust mixture is then expanded through your turbine (*but see below), powering the compressor, and then expanded out through the back of the engine, producing thrust. Other than the oxidizer injector in the combustion chamber, this is just a normal jet engine. Keep in mind that 80% of our air here on earth *is* inert, and serves only as working fluid in a jet engine, having nothing to do with burning fuel. The 20% oxidizer that God was so kind as to mix into our atmosphere means we don't have to cart oxidizer along in onboard tanks, but in an environment where that is missing, the operation of a jet engine could be largely the same, just with different supply tankage and plumbing. (*In reality, you might well structure the engine differently, especially if you expected it to operate exclusively in inert atmospheres, but the main point is that a existing oxygen-breathing design could be changed into a "COuGHjet" just by adding an oxidizer injector to the combustion chamber. It might not be the most efficient way to do it, but it would work on Venus or Mars or Titan (or Duna) with minimal changes).

Would it be possible to have center-of-mass trim options? Most useful would be trim forward and trim aft: Most of my use of TAC Fuel Balancer has been for Concorde-style CoM adjustments in different mach regimes on large FAR spaceplanes. Rather than selecting individual tanks to move fuel into/out of, it would be nice to have a single-button means of shifting fuel forward/aft. Extra nifty would be the ability to specify a datum point on the spacecraft in the hangar, and then, in flight, type in an offset in meters from the datum, punch a button, and have the fuel balancer automatically maintain CoM at that position. Absolutely incredible would be a mechanism to configure a CoM adjustment schedule based on variables like mach number or air pressure.

I have a feature request: Would it be possible to have jets that breath an inert atmosphere? It's not as dumb a question as it sounds: your reaction mass doesn't have to contribute anything to your heat generating reaction, it just has to be heated and expand. So you can carry both fuel and oxygen onboard and mix them in the combustion chamber, like a rocket, but still get better specific fuel consumption than a rocket (because you're still using the local atmosphere for reaction mass instead of just the stuff you're burning). I call this concept the COuGHjet: "Completely Onboard GHuel" It would be nice to have oxygen / explodium breathing modes for atmospheres with appropriate content, but just having the COuGH mode available everywhere would be nice, without further optimization.

I have buzzed an anchored airship in a jet, so as long as you're not too ambitious, (i.e, as long as you're not trying to launch the rocket *from* the airship) you can give your Kerbals an eagle's view of Jeb's first launch into orbit. Unfortunately, the exact thing I was trying to do with that doesn't seem to work. I have a long-term vision of an Eve base that never touches ground, with the crew return vehicle delivered suspended beneath a pair of balloons, one on each end, and docked to the main base until its time to head home. At that point, the crew climbs into the CRV, undocks it, and switches the vehicle from a baloon-on-each-end configuration to a both-baloons-on-one-end configuration (so that it hangs vertically), anchors so that the balloons can be retrieved, separates from the baloons, tilts over a bit so as to not hit the baloons on the way up, and burns for orbit. Unfortunately, there are a few snags: 1) When anchored, vessels are considered to be landed, and even though unanchoring allows the vessel to move again and generally act as if it were flying freely through the air, it does *not* put the vessel back into a "flying" state as far as the game is concerned, e.g, for science. This perpetual landed state also causes the ride to be a bit rough while flying, for whatever reason. The vessel has to be unloaded and reloaded on the ground, by quicksaving and reloading, returning to the KSC, or (presumably, I haven't tested this) loading another vessel to be able to be in a "flying" state again. So if my floating Eve base is to be transiting between different biomes and gathering biome-specific airborne science data, it will have to land after reanchoring to regain the ability to go into a non-landed state game-engine-wise. Of course, if it is truly a base and not a mobile airship, this won't matter so much (other vessels will transit to different biomes and collect science), unless the perpetual landed state sticks with docked vessels when they undock. 2) In a test I performed tonight on Kerbin, the idea of suspending a rocket beneath a pair of balloons with KAS winches, anchoring the whole setup to preserve the balloons, and cutting the rocket loose doesn't seem to work too well. The Kraken didn't eat it quite as quickly as the time I forgot to anchor, but the balloons (or their attached winches and other sundry parts) did explode maybe 20 or 30 seconds after the rocket was launched. This may not strictly be a deficiency in the Hooligan Airships, I'd guess it breaks as many of the assumptions made by KAS as it does those made by Hooligan Airships. 3) A cosmetic issue: Hooligan Airships doesn't currently have the parts needed to do the CRV in a really satisfactory manner. The available stowable balloons (they need to be stowed for atmospheric entry at Eve. Even if the parts can survive it, I'd consider it cheating, physics-wise) seem to all be wide and short (height-wise), whereas to avoid collisions between the envelopes, it would be preferable to have narrow balloons that get all their volume from being tall. Also, the only way to do the horizontal-to-vertical transition with existing parts is to winch together the fore and aft balloons, then have a separator between the back end of the rocket and the back balloon. This causes the back end to drop like a stone, and will give your poor Kerbals whiplash. Now Kerbals are resilient and BadS Jeb will indubitably come through the experience grinning from ear to ear, but if I were engineering something like this in real life, I'd have the back balloon mounted on a rail running from nose to tail of the rocket, and would gently move it along that rail so that the tail would drop smoothly, in a way less likely to kill fragile human astronauts.

Yes, that was the point of my post: The planet's SOI is infinite (wherever you go, its gravity is always the dominant gravitational influence on you), but you can still achieve escape velocity (the velocity at which your apoapsis is at an infinite height above the planet).

In addition to all the things mentioned above, I run a daily, full-system, incremental backup on my computer, and it's saved my butt KSP-wise multiple times, including from having had KSP update before I'd had a chance to duplicate the folder for the old version. Getting a routine automatic backup set up is a fair bit of work, but once you've got it going it's fairly painless and can turn a potential major crisis into a minor hiccup.

Is there any way of setting up a trigger on something like a keystroke or a joystick button? KSP v1.1 seems to have made the longstanding Linux throttle range bug worse (it used to not happen if the throttle axis was centered when KSP started, now it almost always happens no matter what I do), so I'm creating a throttle calibration script to unbuginate the throttle behavior (and add some 90's analog joystick nostalgia at the same time). Currently, it just use a timed wait: Print "Please move throttle to minimum within 5 seconds.". wait 5. set min to ship:control:pilotmainthrottle. print min. Print "Please move throttle to maximum within 5 seconds.". wait 5. set max to ship:control:pilotmainthrottle. print max. on ship:control:pilotmainthrottle { set ship:control:mainthrottle to (ship:control:pilotmainthrottle - min + 0.001) / (max - min). return true. }. Print "Ready.". wait until false. The offset of 0.001 is to avoid some weirdness that happens at zero throttle without it (the throttle goes to somewhere around 0.5, assuming that the KSP Linux Joystick Bug has stuck PILOTMAINTHROTTLE between 0.5 and 1 on this run of KSP). Even a small offset prevents this. What I'd like to have is something like this: Print "Please move throttle to minimum and press any joystick button.". //Code here to wait for joystick button event. set min to ship:control:pilotmainthrottle. print min. Print "Please move throttle to maximum and press any joystick button.". //Code here to wait for joystick button event. set max to ship:control:pilotmainthrottle. print max. on ship:control:pilotmainthrottle { set ship:control:mainthrottle to (ship:control:pilotmainthrottle - min + 0.001) / (max - min). return true. }. Print "Ready.". wait until false.

That looks like a workalike of the AGC software in Python. What I'm suggesting is a workalike of the AGC hardware, for which one could write arbitrary software that need not correspond to the historical AGC software.

I really like the concept of kOS, especially combined with RemoteTech, but it works at a rather higher level of abstraction than I'd like. Rather than having a high-level interpreted language ready to accept user input from square one, it would be fun to have a programmable autopilot mod that focused on assembly-level programming of an emulated CPU, where if you want an in-flight interpreted scripting language, you have to write it. Ideally, such a mod would have different CPUs at different places on the tech tree with architectures exposing more and more useful features, but it would probably be good to do a single-CPU mod with no tech tree first as a proof of concept. So my idea for a starting point would be an emulation of the Apollo Guidance Computer, or else an architecture heavily inspired by it. It would be really fun to be able to write software for a Munar landing on top of the historical AGC architecture (of course, the architecture of the computer's I/O to spacecraft systems would probably have to be entirely redesigned to fit general KSP craft instead of the specific hardware of the historical CSM and LEM, but otherwise a fairly faithful reproduction of the instruction set and memory bank switching architecture could probably be done). Does anybody think this sounds like a fun project?

Frankly, I've found that the best solution to this, for more than just KSP, is not to use any USB or Bluetooth sound devices at all, but put everything through 3.5 mm jacks and physically plug/unplug different speakers/headphones. My current setup is a daisy chain: I have a pair of speakers connected to my computer by 3.5mm jack, and then I have the base station for my wireless headphones plugged into a 3.5mm port on the speakers. To switch between speakers and headphones, I just plug or unplug the base station from the speakers. The problem that this solves is that USB and Bluetooth sound devices are registered with the operating system as separate sound cards, and neither Windows nor Linux handles switching back and forth between different sound devices well, making workarounds like SSD necessary. By daisy chaining everything, I keep my motherboard sound chipset as the sound device in use at all times, and just switch physically between the speakers that that sound device is outputting to being either my speakers or my headphones.

While I agree that pretty much every jet and liquid fuel engine should have an alternator, it isn't that hard to outfit a spaceplane with copious battery power, and once you're in space, solar panels will do.

If that is the case, and if no solution that will support BBCode is acceptable for technical/administrative reasons, then I *strongly* believe that it would be preferable to go with a solution that forgoes formatting and just does plain text with ">" at the beginning of every line in a quote (like mail clients often do with plain text e-mails). The WYSIWYG editor for the current software is unusable, and often even enter and backspace don't always behave as expected. In fact, I am trying to insert a couple of newlines for a paragraph break as I type, and every time I press enter it just moves the cursor to the beginning of the quote (*up* the page from where I'm typing). So I'll have to insert a poor man's paragraph break to separate thoughts. ======================================================================================================================================================================================================================================================================================================================================================================== I seem to recall (please correct me if I'm misremembering) that when the forums first switched over and we were all first reacting to the new software, one of the justifications given for the switch was that the old software was no longer supported, with consequent security implications. It is thus understandable, and, indeed, professionally to be expected that you would look for something that was still supported by its vendor. But regarding this particular software I would like to say that if the vendor's quality control is so lax that such blatant UI bugs are getting through, it is likely letting security bugs through in droves. If the obvious and incredibly annoying problems aren't being caught, the sneaky, insidious ones certainly won't be (and that's ignoring that the possibility that some of the UI bugs could also have security implications). So this software, at best, is almost certainly not any better, security-wise than what we had previously and may be worse. From a UI perspective this software is solidly worse. Now, I'm not saying "you must go back to the old software immediately", I'm more saying "there is as much, if not more, of a case for abandoning this software as there was for the old software". And in saying that, I'm not even saying "we have to find something else immediately", because we'll certainly want the new-new solution to be thoroughly vetted to insure it isn't just as much of a fiasco as the current software. But something certainly needs to be done about finding an alternative.

Finally! A noble's pet project that I can get behind!

It's adamantine, silly! Don't tell me you don't see the connection between the Kraken and HFS. :-P

Oops... I'm used to another sim where ISP is measured as straight effective exhaust velocity. I forgot for a moment that KSP measures it in seconds. Anyways, yes, in KSP you need to multiply the ISP by ten. And yes, the 40% figure I gave for 1/2 fuel fraction was wrong, your figure is correct.

Just a couple real quick and dirty rules (not mathematically exact): If your fuel mass is 2/3rds of your launch mass (i.e, a mass ratio of 3), your delta V will be equal to your ISP. If your fuel mass is 7/8ths of your launch mass (mass ratio of 8), your DV will be twice your ISP. If your fuel mass is 1/2 of your launch mass (mass ratio of 2), your delta V will be about 40 percent of your ISP. Your thrust to weight ratio is your thrust divided by your mass, with the decimal point shifted one digit to the left.