Lisias

You see, smartphones are useful toys on these situations. If you have a decent data-plan, you can even do a youtube-live…

No more "cleaning events" so?

Installed GAP, and then took the Contract for a Glider. "What could possibly go wrong?"

Try this one:

Well, besides being a good idea, I realized that blimps capable of carrying on some missions are terribly expensive - so cost ineffective. So, I had to spend some Science on the R&D as my missions was being severely impact by the lack of better engines. Once I had access to these engines, the very first thing I did was to upgrade my current biplanes - they already are field proven, after all. So, my Long Range Explorer was given a care. Double power on the Piston Engines, and 4 pairs of Junos for a extra kick (and a payload compartment). No bad! Twice the fuel consumption, but more than twice the max altitude and almost twice the speed at the aircraft service ceiling! And I always can shutdown the Junos and save fuel for long trips and still get a very decent cruising speed and tremendous range (assuming the crew would not kill themselves due the terrible cockpit conditions ). At sea level, the huge amount of thrust even allows a ballistic climbing (yeah, TWR 1.09!), and as the fuel is consumed on the journey and she's becoming lighter, I expect her to be able to get enough altitude for some stalled missions while I cook up a proper high altitude aircraft.

So, after two days diagnosing constant crashes while trying this mission (what was solved by deleting Kramax and recompiling KAX, Atmosphere AutoPilot, KER and Firespitter locally - not sure if all of this was needed, but the problem has gone after this recompile fest), I finally managed to really use my QuadraPlane Long Range Explorer. The Primary Mission was to take measurements on the low atmosphere near that island on the South Pole neighborhoods. The Secondary Mission was to map the the whole region in order to plan some Contracts I have there (using the SCAN Radar Altimetry Sensor). The Tertiary Mission was to land on the island once the mapping is done and a nice plain is available. The Primary and Secondary missions were accomplished, but I found that the extremely low clearance of the lowest wing set from the ground would made impossible land there without damaging the airplane. Since at the time we would had less than half of the total fuel needed for the mission, this wing set would not be really needed and could be sacrificed - but I choose to keep the airplane intact and the crew safe. If anything goes wrong, I don't have a plane that simultaneously can land on rough terrain and fly long distances - while the Long Range can fly for approximately 2800Km (almost fully used on this mission), my next best plane that could land there can reach a bit more than the half: I probably could reach the location, but would no be able to come back (not to mention the insufficient seat count). So, after 7 hours of torture and landscape sighting, the mission is over and it was a success: terrain mapped, contracts fulfilled and airplane field proven. I couldn't be more proud of my cheap'n'dirty approach to carry on my current contracts. That low clearance from the ground is a PITA even on the airstrip, you have to land almost perfectly leveled, or you will loose some parts on the lower wing-set. This big lady will not be used for landing on dirty lands. Airstrip only, baby. Another issue is handling this baby with low fuel. She need to be stable with tanks full, so all the control surfaces were trimmed to the full weight. But on the end of the mission, she's too light! While turning to enter into the downwind leg, I hit the rudders a bit too more than I needed, and she yawed 180º on me! Instantaneous deep stall!!!! However, the huge lifting surface and the now tremendous overpowered engines recovered from the stall in less than 100 meters - not bad. But that would be fatal on the final approach. On the aftermath, I need now a low-tech solution for the surface measurements contracts, not to mention the high atmosphere ones that my planes don't even dream on reach. Well... Time for some blimps.

Will do in the morning! Thx!

The flameouts are probably simulating propeller stall. The propeller stops working when the tips reaches near MACH 1 speeds. It's the reason the TU-95 use a double prop installment on each engine - they need to distribute the engine power into two blade sets, as a blade long enough to do the same job would break the sound barrier and just stop working. No propeller aircraft can go faster than mach 0.7 or 0.8 AFAIK.

So I need to first understand how the Autopilot handles engines first. I'm facing some troubles on Kramax and Atmospheric Autopilot too on my Firespitter planes - annoying to say the best, as biplanes are excellent low tech alternatives for science hunting on low atmosphere and surface of Kerbin. Well... Historically, crazy dumb-sas like me ended up dead, institutionalized or condecorated. Let's see what happens on the next months... POST-EDIT: This issue affects KER too - I just realized that (at least some) Firespitter engines don't allow KER to display Thrust neither TWR. I didn't thoroughly tested this, so more KER features can be affected.

This problem interests me. Could you please link me to some material that would depicts what firespitter should do to work on BDAc and Autopilot?

Tritium is radio active, isn't?

HI. That's the idea: I was doing some research on Hydrogen-2 and Hydrogen-3 (Deuterium and Tritium) in order to cook something to make the Engines work in a sensible way on II. Then I found something about Cold Fusion, or Muon Catalyzed Fusion. There's mainly two useful reactions: (d-mu-t)+ and (d-mu-d)+. In a nutshell, catalyzing two Deuteriums with a Muon produces less energy per Muon than when using Deuterium and Tritium, but it's not radioactive. So the Tritium consumers should consume Deuterium also, and would kill any near Kerbal when active as the Nuclear Engines do. The source of Muons is a Monte Carlo Generator for generating Muons for the fusion, and this thing works on Electricity. Huge amounts of Electricity. I need to add this as a new Part to II. The SciFi excuse, I mean, solution for this work is a magical discovery that eliminates the problem of the alpha-sticking, so each Muon would be indefinitely useful for catalyzation, making the Cold Fusion net positive. In order to simplify things, I think it's a good idea to ditch the internal resource definitions for Deuterium and Tritium and use the Community Resources Pack's (and so, CRP would be a hard dependency). My main problem at the moment is to calculate a viable and plausible ISP for the (d-mu-t)+ and (d-mu-d)+ engines. And the cost in E for the Muon Generator. POST_EDIT: on a second thought, I don't need a new Part for the Monte Carlo Generator. The rocket engines are such generators themselves! It only happens they have the expansion chamber embedded.

Not happy by going cheap while ferrying Tourists to the Karman Line: I tried and tried to repeat the stunt on LKO! Man, that was hard because I didn't wanted to spend money on the Launch Pad, so I was restricted to 140T vessels. Kicking butts into Karman's line and letting the Gravity weel bring you back is one thing, but achieving LKO on the whole shebang and then burning back is another. I had to compromise somehow, and came to this contraption: I managed to get LKO on it, but couldn't get back. The thing insisted in plummeting into water/ground at more than 30m/s, killing everybody: if I added enough chutes, I end up without fuel for the circularization. And without enough parachutes, she didn't bleed enough energy for a safe touchdown with the fuel she had left. And yes, the reentry were induced by aerobraking - on the Apogee, I retroburned just enough to get the perigee below the Karman Line, and from now on aerobraking did the trick. So... I had to spend more money than planned sending Tourists into LKO three times with three tourists each time, instead of doing it two times with 5, and using one spare seat to send a crew member into space to get experience. Well, you can't always get what you want, so (screenshots starts at deorbiting, as the ascension were pretty standard - except by no staging): And I managed to successfully recover the full vessel while landing and splashing down! (shot from the following mission) If I manage to land/splash down the thing next enough to KSC, I will manage to recover 97% of the cost of the vessel. I doubt I could manage to land back in KSC itself, but still trying! POST-EDIT: This is the vessel on the VAB - yes, I added chutes to the Fleas to recover them using Stage Recovery!! (I'm really going on the cheap! ).

Yeah, but that would make realtime monitoring cumbersome. I'm planning to "monitor" KSP the way I do my servers, DevOps style - not confuse it with DevWhoops style, a slightly different approach.

Looking only at the dV is missing the real problem: fuel mass. Kicking the butt of a 100t payload needs the same dV than kicking a 10t one's. But the last one would use a lot less fuel due less mass and less drag due the 1st stage smaller tanks. So, if you have a Fuel Station strategically positioned, it's better to launch your vessel without the fuel for the injection burn, getting it from the Station instead - that by its turn, would get its fuel from the Moon (for example), making it cheaper. The savings for a single launch perhaps would not be that bigger, but if you plan to implement and support a regular flight, the savings pile up. Essentially, it's what BFR is going to do (except by the Station's fuel source).

Do you really expect me to use Linux to play games? Really, even KSP offers a worst user's experience on Linux. Not Linux's fault, rest assured that I'm aware of that. But it's cumbersome to use Linux to play the most modern games. Granted, you can install WINE and waste some time setting up a ton of different configurations. And it will work for some games. But you can also install Win7 and get the same results with less efforts. And my time is always on a budget.

Not sure if it applies to every situation... I need to bleed a lot more delta-V to orbit Moon than to orbit Earth if I'm coming from the outer bodies, so if my fuel tanks are under budget, it's probably a better idea to go for a LEO's fuel station. Even by aiming the Moon, I could save some fuel launching the vessel without the fuel needed to the Moon's voyage, getting it from the fuel station. This would save me some mass to be kicked out of this world and, so, some fuel to reach the needed delta-V.

The limit is Unity. (more) seriously now: If you have a embedded GPU, you need to account the KSP needs and the GPU needs. So, in order to support a installment that would run on a 4GB RAM using a discrete 2GB RAM VideoCard, your mainboard needs to have 6GB of RAM. 4GB is barely enough on a vanilla installment on 1.4.3. Add to it the Mission Builder, and things start to get ugly. My best guess is that KSP 1.4.3 with mission builder should need about 6GB of dedicated RAM for the CPU (so, 8GB of mainboard RAM if your GPU is embedded). About the multicore thing... KSP multithreading model is adequate for the "vanilla" installment. But once you install mods, they start to "eat" cpu cycles while building each frame, and this slows down everything. Unity's Garbage Collector is far from top notch also, and this is the reason of the "stuttering" that plagues our installments. Currently, KSP spawns a thread/core to each spawned vessel on your universe, so the bottleneck are your biggest vessels. If you have a 1000 parts vessel and 100 vessels with 10 parts, that 100 vessels will be calculated across your multiple cores, but the core handling that 1000 parts beast will delay everything - so, it's usually better to have fewer really fast cores than many slower ones. Your GPU is the next bottleneck, but this can be settle up trimming your graphics settings and careful choice of visual enhancements.

We must free ourselves from the assumption that the fuel will come from Earth. Space will be only viable when we manage to get our fuel from near bodies, as Moon and perhaps asteroids. It's far more cheaper to ferry 100 tons of something from Moon to LEO than from the Earth's surface.

Kerbals are "parts"? I think they are "vessels". If I'm right, you would need some king of "docking port" to "dock" the Kerbals. OTOH, if you are right, this would simplify a lot the solution. I'm firing up KSP to check this. I'll be back! (c) 1984 Terminator. --- POST EDIT--- Yeah, Kerbals on EVA are vessels. I created a new save, strap some random parts together, put three poor Kerbals on the thing and put the thing orbiting something. Then I put one Kerbal on EVA, and tried to save the game with a Kerbal on a ladder. No joy - I think there's no prevision for persisting state when a Kerbal is not on EVA or is not inside a vessel. VESSEL { pid = 93d2d5b2892c4619840bc70ade0e4434 persistentId = 2883649892 name = Sigsel Kerman type = EVA sit = ORBITING landed = False skipGroundPositioning = False vesselSpawning = True launchedFrom = Runway And when landed: VESSEL { pid = ee066b906145474eb3bcdd8266f906e4 persistentId = 2459143087 name = Jensted Kerman type = EVA sit = LANDED landed = True skipGroundPositioning = False vesselSpawning = True launchedFrom = Runway So... "strapping" a Kerbal as a part appears to demand some brute force solutions too. What do not invalidate the idea - now we must find that kind of "brute force" would hurt a bit less.

I ditched Windows 5 years ago. I was a happy Mac user until the end of the last year, when Apple royally screwed up on an update and BRICKED my Mac on the same week it reached EoL and the Apple Shops started to refuse repairing. I managed to recover the thing by manually installing the latests OS from the recovery boot (it was impossible to do it by any other means). So, yeah. i'm going back to Win7. (sigh) Wise decision, as it appears. The Old'n'faithful Apple we used to know died with Jobs.

That would explain my difficulties on evac an aircraft while on Unplanned Uncontrolled Landing. At least on the Stock Cargo Bays, I'm able to drive wheeled crafts inside them. Heisenberg's huge hangar bays also allows this AFAIK (I didn't tried it myself yet, will do ASAP and come back here). Perhaps it's some glitch on the parts you are using? Perhaps something on the collision meshes?

Well, from my point of view.... Win9x was a 200MB hack that had inside a Win16 plugin that demanded Win9x to maintain a MS-DOS hack, I mean, "supervisor" plugged into the life support machines. Humm... Yeah, now I see your point. Win9X didn't needed MS-DOS for anything but to support Win16, but to accomplish that, it needed to keep MS-DOS on the loop pretending to be a "supervisor" - something as a "puppet ruler". I do not will change my mind on the subject, but I cannot criticize who thinks otherwise neither. Ok. Time for some coffee.

It is what would solve "my" problem in the most convenient way for me. Overkill? Well... Perhaps. The named pipe would solve the thing for me the same way. Frankly? Thinking twice about the matter, I would be "happy" either way. And, of course, I didn't considered the developer side of the problem - where you are pretty right about.

It should, but a IPC is even less. And save me from parsing the log after the event. Better. It would allow me to use some DevOps tools and monitor KSP on the fly Well, you said yourself. Imagine the huge waste of processing by setting up a fswatch to monitor the file, then parsing it to extract the information I need, and then consuming it. Now imagine this running 4 times per second. Not to mention that I would need to write different tools for Windows. A huge log file is convenient for post-mortem analysis. For runtime monitoring, not that much. At least on UNIX, I could setup a named pipe and get what I want the same way. But that should limit such activities for UNIX machines. POST-EDIT: Uh... Dude... We hijacked the thread... Better move it somewhere else.