Lisias

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.

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.