Poppa Wheelie

In this topic on 7 December I posted the above. Today I did a new Kerbin return to see if it was possible to return from Mun with no heat shield. I don't think this will work with the current version of the heating system. I just put an identical vehicle into a 12,000,000m orbit above Kerbin (a little past Mun's orbit), then at Ap I lowered the Pe to 60,421m (almost 100m lower than the mission above). But the lateral fuel tanks overheated and blew up almost immediately (while still above 60km). Next, I put the vehicle in a LKO and lowered the Pe to 60,495m. The lateral tanks also overheated and blew up well above 60km (64,548m, in this case). So, I'm not sure if it's possible to return from orbit without a heat shield. I don't intend to try again any time soon, at least until we get an updated reheating model, or until someone else figures out a way to return from orbit without a heat shield. Maybe you have to zero your horizontal movement and fall straight down? Someone else is welcome to give that a try. Small but significant update: I ran a little experiment to see if I could get a capsule with parachute from orbit to the surface of Kerbin by focusing on velocity at the 70km mark (versus my normal reentry focus of Pe setting). I made several runs, but these two show the boundaries within which success is possible: Velocity at 70km: 1998m/s - FAIL Velocity at 70km: 1684m/s - SUCCESS! With heat warnings

Update, 20231220: I don't think this will work with the current version of the heating system. I just put an identical vehicle into a 12,000,000m orbit above Kerbin (a little past Mun's orbit), then at Ap I lowered the Pe to 60,421m (almost 100m lower than the mission above). But the lateral fuel tanks overheated and blew up almost immediately (while still above 60km). Next, I put the vehicle in a LKO and lowered the Pe to 60,495m. The lateral tanks also overheated and blew up well above 60km (64,548m, in this case). So, I'm not sure if it's possible to return from orbit without a heat shield. I don't intend to try again any time soon, at least until we get an updated reheating model, or until someone else figures out a way to return from orbit without a heat shield. Maybe you have to zero your horizontal movement and fall straight down? Someone else is welcome to give that a try.

Yes, especially right now in KSP2, while I'm trying to avoid landing legs, I often build my landers to land on fuel tanks.

Very nice! On this lander used at least for Minmus, what part do you have under the side fuel tanks - the part that is actually touching the surface as your "landing feet"?

Now the game freezes when I enter IVA (with 'C' key). After I edited the Patch file earlier today, I restarted the game, but went to a vehicle in flight to try out the changes. This time I started a new save, with no vehicles in flight, went into the VAB, loaded up a vehicle, launched it, and attempted the IVA. Game froze. Tried from scratch a second time - game also froze. Logs: KSP: https://1drv.ms/u/s!AijA8HUkaaOEmQRjep1Mq1WcBRop?e=q5afma Player: https://1drv.ms/u/s!AijA8HUkaaOEmQVWnsY-6mYYsKHp?e=evV5kG Update 20231215: All is well after I replace the modified Patch file with the original. So, my game is fully functional. I'll just work within the 80 total character limit for now.

Are you saying the changes I made to the patch file should have worked? Or is there something I should do with the kOSMonitor.cs file you linked to?

Thanks. Any thoughts on where I would look for that? In the patch file you sent me on 29 September in this thread, I see "consoleWidth" set at 80 on line 50 and on line 105. I changed both of those and repeated the "set" and "print" test above. No luck.

I have another question, along the same lines. Is it possible to set this mfd terminal width to something even greater than 80? I've noticed that if I print a string (with kOS 'print') that is longer than 80 characters, then the string is split into two, and each is printed as if two print commands were used. Even if I specify the row to print on with "at" (such as "print myString at (myColumn, myRow)."), what I actually get is myStringPart1 on myRow and myStringPart2 on myRow+1. I want to print 40 or fewer actual printable characters to the screen, but with color change codes embedded, my strings are often coming out larger than 80 characters. Each color change requires 9 characters (eg, "[#rrggbb]"). If I want a string with 40 printable characters and 5 color changes (45 more characters), I'll bust the 80 character limit. I tried the straightforward "set terminal:width to 160." But then when I follow that with "print terminal:width." the response is "80". Can this be done?

I went to the Mun and back, using only the tech from "Starting Rocketry", the first node in the tech tree of the upcoming For Science! release.

OK, I'll go first. I needed to run this mission before 0.2 comes out, because I will begin holiday travel shortly after that, and won't be able to get back to KSP until January. So this was done in v 0.1.5. I only used parts from Starting Rocketry. To The Mun and back. Launch Mass: 42.86t All images for the entire mission can be found here: https://imgur.com/a/RWBogQW Here are some highlights Launch to Orbit Transfer to Mun Mun Landing Game Bugs On Return Direct Return to Kerbin (with no Low Mun Orbit) 30 Aerobraking passes of Kerbin So I didn't even attempt to meet the OP's requirement for keeping atmospheric velocity under 2000m/s. If there is going to be aerobraking, speeds will be above 2000. I have to believe that, even with the heat system we get with version 0.2, this vehicle would easily survive the aerobraking and final descent. The engine and fuel tank sitting under the crew capsule should be sufficient "heat shield". This would definitely work in KSP1. @PicoSpace, I request that you remove this 2000m/s requirement. I won't be able to do anything with this mission after version 0.2 comes out until I return from holiday travel in January. If I need to rerun this landing in 0.2 to demonstrate that it works, it will have to wait until then. Here are two tables that show the velocities I measured during the 30 aerobraking passes, and during the final descent (31st atmospheric entry) 31st Atmospheric Entry and Final Descent and Landing on Kerbin

In map view, it's very difficult to manipulate the map when looking directly down at the north pole of the target body. All mouse movements from this perspective cause far too much movement. We need the ability to make very small scale movements from this view, just as we can when looking directly at the equator of the body.

OK, great! I didn't recognize any fuel lines in your screenshots.

Use vacuum numbers only, for the whole thing. Your 3400m/s target for achieving orbit is the vacuum dV total of all stages used from Kerbin surface until orbit is achieved. You should use the sea level setting of the dV calculator only to make sure TWR is within range.

I think you threw away a lot of fuel. Your 6 tons of fuel consumed was spread out among all remaining tanks. Initially, with 12 drop tanks, when you reach the 6 total tons consumed, each drop tank has emptied 0.5 tons, but the remainder of each of those tanks is full. With 9 drop tanks remaining, the 6 tons will be spread out as 2/3 ton per drop tank. With 6 drop tanks left that will be 1 ton per tank. Etc. In order to make sure each drop tank is empty before dropping it, you'll need to transfer the remaining fuel out.

I recommend you use CKAN. With CKAN, you select which mod or mods you want, and CKAN does all of the installations.

Agree. All text for all return trips is incorrect, because the approach being used is just to mirror the text used on the outbound trip. The tool does return trip text incorrectly in every case. I was just using Mun as an example. Agree that even a powered landing on Kerbin won't need most of the 3400. To be generic enough to cover all cases, let me change my recommendation for the tutorial. The tutorial should specify that all or most of the dV for the "low orbit" to "landed on" step will not be needed for a body with atmosphere - the more significant the atmosphere, the less of the listed dV will be needed.

I'm copying @Casellina X's image here This is not the way to read the dV map. All of the text for the return trip is incorrect. This will definitely be very misleading to new players. From Kerbin surface, to a Mun landing, and back to the surface of Kerbin, should read like this: 3400 Kerbin to LKO 860 LKO to Mun Intercept 280 Mun Intercept to Low Mun Orbit 580 Low Mun Orbit to Mun Surface 580 Mun Surface to Low Mun Orbit 280 Low Mun Orbit to Elliptical Kerbin Orbit 860 Elliptical Kerbin Orbit to Low Kerbin Orbit 3400 Low Kerbin Orbit to Kerbin Surface And then the tutorial on how to use this tool should explain to new users that they can skip the last 2 steps (and associated dV) if they aerocapture at the LMO to EKO step, or that they can skip the very last step unless they intend to do a completely powered landing.

UI Elements and pop-up windows Ability to move any of these objects to anywhere on the screen Ability to move any of these objects completely off the screen, as stand-alone windows outside the game window, including onto another monitor Ability to re-order the kerbal headshot cameras Coloring Tool: Ability to specify RGB Ability to "color pick" colors of a part already present in the VAB Parts: Ability to name any part of an existing craft, while in the VAB or in flight Vessels: A vessel naming priority system, similar to KSP1 Docked vessels should take on the appropriate name Undocked vessels should each retain the appropriate names One button screenshot capability, like the F1 from KSP1 Better lighting in the VAB, especially during in-game night

I had not seen this David Scott video before. But I watched it this afternoon. Great stuff! Thanks.

Perhaps you've already seen this, but if not it's definitely worth watching. 1h21m long, but very fascinating throughout for anyone with an interest in the Apollo program. This includes the best explanation I've ever heard for what was really going on with those 1201 and 1202 alarms.

Very nice! And no 1201 alarm!

Thanks! I'll give this a shot. Update: I removed the [hw] tags at the beginning of each line (I left the hw tags on the top [CPU ID] line). I now have a 40 character width terminal (actually 41 characters), with much more readable font. Terminal:WIDTH still reports 80, but I can work around that. Thanks again!

How do I change terminal font and font size from within the script? I can see many fonts when I do "list fonts" from the terminal, but I can't figure out how to use any of them. I also see in the kOS documentation on github that I should be able to set Terminal:HEIGHT, but I can't seem to get that working either (although it does work on a "regular" kOS terminal). I want to be able to switch font and font size from within the script. I was told at the r/kOS subreddit that adjusting Terminal:HEIGHT is the only method from within the script for regular kOS terminals. It would be great if I could use the font used by the template to write the first line, with "CPU: 0 -", "KBRD", and "EXIT". See how much smaller the text is in the printable part of the terminal. And see how the top MFD is using several fonts and sizes (although programmatically, and not through the kOS script).

Hello @scimas, I guess I waited too long to follow the link you sent. I got an "Invite Invalid" error message today when I tried it. (Invite Invalid: This invite may be expired, or you might not have permissions to join.) Could you send another link? Today's question is: how do I change terminal font and font size from within the script? I can see many fonts when I do "list fonts" from the terminal, but I can't figure out how to use any of them. I also see in the kOS documentation on github that I should be able to set Terminal:HEIGHT, but I can't seem to get that working either. It would be great if I could use the font used by the template to write the first line, with "CPU: 0 -", "KBRD", and "EXIT". See how much smaller the text is in the printable part of the terminal.

That did it! Thanks!