Lisias

I made a seaplane. But it didn't splashed down exactly as I envisioned... ADDENDUM: Well, I think it's an improvement… Now I just have to find a way to save the engines.

It depends of the "Mission" - I have 3 different installments, each one with a specific "Space Program". The one I'm playing right now is Career with some mods, and to make things not too easy: Do not kill Kerbals. If there's no way to fulfill a contract without killing a Kerbal, the contract is ditched. Go Space-X : fuel is cheap, hardware is expensive. Recover everything I can. Do and redo the mission again until I manage to recover every stage Delay every facility upgrade until there's no more way to advance Always exhaust all the current facilities capability before upgrading Delay investment on the Tech Tree the most I can Always exhaust all the current parts applicability before advancing tech Be a bean-counting cheap "stand-up guy". Somewhat hard, due the rules 1 and 2. I ended up doing a lot of Science using biplanes.

Speaking frankly, as long the current componentized architecture is preserved and we can keep working and using mods as we do right now, I don't care if they (also) go Steam for mods. Once the problems I mentioned previously are worked out, it can be even an additional source of revenue, including for modders - someone has to curate the Workshop and keep things tight, and being paid for such a job is hardly a bad thing on my book. I have no illusions that no new problems will arise from this stunt - but as long the net revenue is positive for everybody, I'm ok with it.

Very few if any. Currently, I'm using about 90 mods on 1.4.4 without perceptive glitches - all appears to work fine. The mods are: KSP: 1.4.4 (Unix) - Unity: 2017.1.3p1 - OS: Mac OS X 10.12.6 000_AT_Utils - 1.6 ClickThroughBlocker - 0.1.6.5 Filter Extensions - 3.2.1 TexturesUnlimited - 1.1.2.14 Toolbar - 1.7.17.11 USI Tools - 0.12 ToolbarControl - 0.1.6.9 Airplane Plus - 21.0 AnyRes - 2.0.2.3 Electric Lights - 1.0.4 AutoAction - 1.10.1 AutomatedScreenshots - 0.8.3 Aviation Lights - 4.0.5 B9 Animation Modules - 1.2 B9 Part Switch - 2.2.1 B9 Aerospace - 6.5 B9 Aerospace HX Parts - 6.5 B9 Aerospace Legacy Parts - 6.5 Bon Voyage - 0.13.3 CameraTools - 1.10 Chatterer Extended - 0.6.2 Chatterer - 0.9.95.2110 Chrononaut - 0.4.1 Community Category Kit - 3.0 Community Resource Pack - 0.10 CommunityTechTree - 3.3.2 Community Trait Icons - 1.0 ConfigurableContainers - 2.4.3.1 Contract Configurator - 1.25 Contract Pack: Kerbal Academy - 1.2.1.1 Contract Pack: Bases and Stations - 3.7.0.2 StationScienceContinued - 2.4.1 Contract Pack: Tourism Plus - 1.5.2 Corvus CF - 1.3.2.2018031401 CustomBarnKit - 1.1.17 DMagic Orbital Science - 1.3.0.12 AGExt - 2.3.3.6 DistantObjectEnhancement - 1.9.1 DockRotate - 1.4.1.10 EVAEnhancementsContinued - 0.1.13.1 Easy Vessel Switch - 1.6.6640.41793 EditorExtensionsRedux - 3.3.19.3 FMRS (Flight Manager For Reusable Stages) - 1.2.7.2 FShangarExtender - 3.5.3.1 FuseBoxContinued - 0.1.16.1 HGR Community Fixes - 1.6 Hangar - 3.3.4.2 Haystack ReContinued - 0.5.4.2 Historian Extended - 1.3.2 HullcamVDSContinued - 0.1.9.3 Interstellar Fuel Switch - 3.6 RasterPropMonitor - 0.30.5 Kerbal Attachment System - 0.6.4 KSP-AVC Plugin - 1.2.0.2 KSPWheel - 0.11.9.27 KerbalElectric - 0.1.1 Kerbal Engineer Redux - 1.1.5.2 Kerbal Foundries - 2.2.6.16 KerbinSide-Complete - 1.4 Filter Extensions - 2.2 LaserDist - 1.0 MOARdV's Avionics Systems - 0.18 MarkIVSystem - 2.4.1 KerbalSlingShotter - 1.1.1 Modular Rocket Systems LITE - 1.13.2 ModularFlightIntegrator - 1.2.5 NavBallDockingAlignmentIndicatorCE - 1.0.4.1 Stockalike Mk1 Open cockpit - 1.1.1 PartCommanderContinued - 1.1.4 PartWizardContinued - 1.3.7.4 PatchManager - 0.0.15 RCS Build Aid - 0.9.7 RemoteTech - 1.8.11 RoverScience - 2.3.5 SCANsat - 1.1.8.6 SXTContinued - 0.3.23.6 ShipManifest - 5.2.1 SmartParts - 1.9.9 SmartStage - 2.9.11 SolverEngines - 3.6.2 StageRecovery - 1.7.2 TAC Fuel Balancer - 2.18 TakeCommandContinued - 1.4.12 ThrottleControlledAvionics - 3.5.2.1 ThroughTheEyes - 2.0.2.2 TimeControl - 2.9.2 ToadicusToolsContinued - 0.22.3.1 Trajectories - 2.2 Kerbal Alarm Clock - 3.9.1 Transfer Window Planner - 1.6.3 TweakScale - 2.3.12 Universal Storage - 1.4 VesselMover - 1.7.3 WASDEditorCameraContinued - 0.6.13.1 World Stabilizer - 0.9.2 kOS - 1.1.5.2 KAX Continued Unofficial - 2.7.1.1 I have 2 more installments for dedicated missions with a lot more, but didn't had the time to test them yet. I'll update this post as soon as I do it. [I didn't fired any of them yet after 3 weeks!] ADDENDUM: MOARdV's MAS was just updated. I'm downloading it right now. ADDENDUM'S addendum: B9 Animation Modules too. Frankly? Rest assured: people are working here. Fast. [Jul21: I was wrong. Only 2 mods broke, but these single two caused a hell of a problem… ) ADDENDUM's addendum's addendum: it's Jul,19 and to my knowledge only Kerbal Konstructs broke really bad. A lot of mods were updated in the mean time, so if any of them was broke, they fixed it before I realized the problem. The after-math is still positive, but KK was a blow. ADDENDUM's addendum's addendum's addendum: it's Jul,21 and I finally understood what happened with KK and Kopernicus (another victim). The 1.4.4 (apparently) broke an important interface on a minor release - what's, frankly, unthinkable. The effort to fix problems and revamp the game is clear, but the new issues that being created in the process are serious show stoppers.

Worst. I think I quoted the wrong guy. Sorry.

Steam user here. Currently, there's four ways to launch KSP, at least on MacOS X: Using the Launch Icon Steam puts on my Desktop Clicking on KSP's entry on the My Library list Clicking on the Launch.app program on the KSP install directory (Squad's own launcher, as it appears). Clicking directly on the KSP.app to run KSP directly. Since I have access to every single depot from Steam since the first time KSP was distributed on Steam (it was there that I downloaded the Demo version before deciding to buy it), and since I downloaded some of them to compare, I can say with a reasonable sure of being right that there never was, and presently there're not a single apparent movement into this direction. It would be nonsense anyway, as there're some other distributors (GoG, G2A, HumbleBundle and some others I found on Google but I choose not to mention as some of them appears to be…. fishy…) and I don't think it would be a wise move to ditch everybody else. Even if 80% of the present KSP users are from Steam, there's that other 20% to chase for. Money don't grow on trees. One very interesting thing I noticed by analysing the different versions of KSP on its history (the actual history, not the Making - #tumdumtsss ) is its highly componentized architecture. Localization appears to be implemented by adding a plugin, Lingoona. The novelty on the 1.4.4 series appears to be the "steam_api.bundle", so Steam support is merely adding a DLL into the right place it appears to me. I didn't bored to play lego by adding or removing such plugins, but the pattern appears to be solid. So, adding equivalent support for the remaining distributors appears to be easily done - and perhaps, even by third parties. So, even by going Steam, there're no doors to be closed on this - and so, the same movement can be replicated everywhere. What probably include Kerbal-X, CurseForge or whatever, as long someone is willing to write the plugin - but I'm wild guessing, probably a lot of work would need to be done on these services to support this stunt. In a way or another, I understand the fear that we, poor humans, are subject. Almost everybody here appears to love the game, but sometimes we must refrain ourselves to let our emotions on the loose in order to preserve the very thing we love. Love and fear are a very destructive combination.

This is precisely what that "Chain of Thrust" would do. But please consider that delegating this directly to Steam would demand some financial compensation, what I don't know if would be acceptable or not at the present state of affairs. It's my main objection about a Mod Workshop too. At least, until this is solved somehow. This kind of problem would cause a severe backslash IMHO. I'm not sure CKAN is for everybody. At least until now. CKAN lacks that "Chain of Thrust", so updated mods still can break thinks and, worse, corrupting save games. Some mechanisms to rollback also the save-game changes due the update are needed. Hummm… Now that you mention, yes… You're right. That should be made clear to the end users somehow. I do not consider myself a common joe user, but I also missed that obvious point. I have about half a dozen installments for KSP (only one Steam managed), but it's due testing and mission dedicated mod collections. O simply didn't thought about this issue, it just happened that I made the "right thing" without being aware. Neither do I. I was brainstorming about what would be needed to make this happen safely. Or the less unsafely possible.

I was "youtubing" for some aviation history and found this: And then I look on what I did here: And I'm wondering about how my designs can be somewhat similar "in spirit" as the soviet ones…

Being the reason some countries allows a consumer to get a refund when things go wrong. Now imagine an avalanche of refunds due some broken mod being installed on the workshop. Worse, something that was working but got broke on a update. People willing to use the workshop don't want to skin cats themselves. People here are ok with it (I rely only on AVC, I don't even use CKAN). But… we are not the average gamer. Most people want new things, shinny and new - as long it's easy to install and don't crash their computer. Modders usually don't use Steam's Workshop. Common people do. Modders usually don't demand refunds. Users do.

Not necessarily. A very simple mechanism based on Jenkins or some other CI tool can automate the process. If a chain of thrust is stablished, one single worker can do the job of gathering information directly from the mod's code repository or page, saving the developer from the burden. I don't use CKAN. Gave it a try, but by an incredible lack of luck on the same day some mods were automatically updated and one of them broke everything (and I spend 2 days figuring out the problem). So I concluded that going manual is the better alternative - I know what I'm doing, I know what caused the break when it happens. For a Mod Workshop correctly work on Steam, that Chain of Thrust I mentioned must be stablished. Someone, somehow, must guarantee minimal functionality from the Mod before upstreaming it to the Steam. Things cannot break when it come from Steam, or the backslash will be severe.

A very few perhaps. Most of them, nops. In a way or another, backup your installment. Just in case.

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.