Raptor9

Logfile attached. KSP v1.4.1, 64-bit for Windows. Only KVV, Toolbar Controller, and ClickThrough Blocker installed. I started the game, went to my Sandbox save. Turned on the Toolbar Controller, selected "None", and then "Stock" for the KVV line within the Toolbar window. Let me know if there's any other actions you would like me to try for the logfile.

I hate to be the class idiot, but I'm having trouble getting KVV to work. I installed the current versions of KVV, ClickThroughBlocker, and ToolBarController (all from Spacedock) and selected "Stock" toolbar in the Toolbar Controller window for KVV to show up on, but the button still doesn't appear in the VAB/SPH. This was in an otherwise unmodded install of 1.4.1 as well as 1.4.2, both 64-bit Windows. I simply unzipped the respective zip files I got from Spacedock for all three plugins, and put them in the Gamedata folder. I read through (several times) the OP's of KVV, ClickThroughBlocker, and ToolBarController, as well as the readme files along with it. I'm pretty sure I haven't missed anything specific regarding install. Anybody have any suggestions before I attempt to post a logfile? I'm still hoping there's a bonehead step I'm overlooking.

@linuxgurugamer, you beautiful, wonderful, under-appreciated human being! Thank you sir.

I remember way back in the day when Maxmaps (one of the original producers that streamed KSP on Twitch every Friday) mentioned that they usually projected a fixed release date fairly far in advance, based on a running estimate on when the next version would be ready with the features they prioritized for that version. He said the main driving factor was coordinating press releases, syncing the website update with the new KSP game files, the Steam update, etc. Pretty much a bunch of stuff that was logistical in nature and for the most part not game development related. But I think that only applies with major updates, not patches; since those probably don't require huge database updates or press information. I regretfully don't have a citation link provided, it was quite a long time ago early in the alpha stages of development and I don't recall if he mentioned it in the forums or on one of his streams. I also realize that the current development cycle/team itself is undoubtedly much different than back then, with different producers, team members etc; but it would stand to reason that the logistics of getting updates "out there" hasn't changed much. Of course, I could be completely, blatantly wrong for all I know. The first paragraph is relying solely on my personal memory, and the second paragraph is pure conjecture on my part. Completely agree. Better to have speculation on when the next release will happen and let the "SoonTM" memes flow than let the pitch forks assemble when an update or patch is delayed beyond the announced date.

Keep in mind that in this example, the image-hosting service is Photobucket. There is an Imgur button one button to the right of the "Spoiler" button, but I've never used it and I've never used Imgur. @SiriusRocketry, hope this helps.

@SiriusRocketry, ok no problem. Give me a little bit and I'll piece together some screenshots and tips.

What difficulty are you running into specifically? Posting pictures in the thread, setting up spoilers blocks, or putting content in the spoiler blocks?

@SQUAD, seconded.

Hey @Jestersage, starting your own collection? Nice! Looking forward to seeing what you come up with.

Nope, just a crap ton of individual Oscar-B tanks stuffed in an orderly fashion inside the radiator panels. Which drives up the part count significantly, so I'm glad I can use just a single 1.875m tank now. Clipping fuel tanks inside each other is "cheaty" in my play-style. If you're really that curious on how it's put together, just download the craft file and look for yourself, it will be much easier.

Just a bunch of radiator panels placed in a circle, which is gonna change anyway now that we have 1.875m parts. I generally do one continuous burn, and adjust the throttle as necessary after the gravity turn to achieve orbit, but still maintain control via the gimbal. My launches pretty much go like this every time: 1) After launch, perform initial pitch-kick around 100m/s to start the gravity turn 2) Throttle down as necessary to keep acceleration no higher than 2 G's on the G-meter 3) Slowly drag the flight path vector (prograde marker) down as speed approaches 300m/s 4) Turn on SAS and select Prograde Hold as the rocket goes through transonic range 340-380 m/s, or just before SRB's jettison. This keeps the rocket stable during supersonic transition or during SRB jettison sequence (if side boosters are on the rocket of course) 5) Continue throttling as necessary to keep acceleration at 2 G's, and slowly drag the flight path vector down towards the horizon 6) Ideally, when the flight path vector hits +40 deg pitch above the horizon, I'm looking to be around 600m/s and somewhere between 13,000m and 18,000m altitude. The 600m/s at 40deg positive pitch is my "gravity turn check" gate that tells me I'm on track for a good LKO orbital insertion. If I'm launching a payload that is near the max payload rating of the rocket and/or the lifter has a lower TWR, I may pitch over less aggressively and end up passing 600m/s when at 45-55 deg pitch. 7) After passing my "gravity turn check" I switch SAS back on and select Prograde Hold again, then switch to map view and start monitoring my apoapsis. From this point forward, all I'm doing is adjusting throttle as necessary to hit my LKO apoapsis at about the same moment that I'm achieving orbital velocity. I keep throttling down and watching how fast my Ap altitude is climbing to time it appropriately. By the time my Ap is passing about 55km, I'm usually throttling the engine down to idle to maintain gimbal steering, and my Ap will slowly creep up above 70km as I semi-coast under minimal thrust. NOTE I jettison my payload fairings at 50km altitude either by staging or manually right-clicking on them. If you click on the link for "CisMunar Propellant Economy Part 1" tutorial video in this thread's OP (or in my signature), you'll see a demonstration launch of how I perform my launches at the start of the video. The payload is fairly heavy, so it's not an exact match to how I launch lightweight satellites to orbit, but you get the idea.

I assume you're asking why there aren't specific launcher configurations named as such? It's because they never existed. My naming convention *roughly* emulates the real-life Saturn rockets. Example 1: 'Titan 1B' first stage (consisting of the core booster and 2x SRBs) and 'Titan 2' upper stage combine to form the 'Titan 3' rocket lifter Example 2: 'Titan 1B' first stage and 'Titan 2P' upper stage combine to form the 'Titan 3P' rocket lifter Example 3: 'Titan 1B' first stage and 'Titan 3' upper stage combine to form the 'Titan 4C' rocket lifter (in this case, the "C" was added to denote it as a Cargo rocket only) So it's really just a mash-up of how I named and organized my individual rocket stages as subassemblies, to assemble complete lifters as the end product.

Yeah, Kerbin is a much closer analog to Laythe, both in gravity and atmospheric density. Duna's atmosphere is so thin it requires a much higher landing speed, and is harder to slow down and change direction. Plus only rocket engines work in Duna's atmo. Duna: - about 30% Kerbin's gravity - very thin atmosphere providing little lift, however little drag - no oxygen so only rocket engines work Laythe: - about 80% Kerbin's gravity - atmosphere is slightly thinner compared to Kerbin, but produces adequate lift - jet engine thrust will suffer a little, as if flying at high altitudes at Kerbin; however due to the lower drag and slower orbital velocity, I find it a little easier to get to orbit compared to Kerbin I would practice flying the spaceplane around Kerbin to simulate the flight sequences between Laythe orbit and the surface, but you could still practice the interplanetary transfers to Duna and back before going all the way to Laythe.

No thank you. I don't even have adequate time to run a simulated space program, let alone a real country. But thanks for the compliment.

@Nertea, after seeing your assorted update posts in your various mod threads, I gotta say your sarcasm has reached a new, arid level, of dryness.

Respectfully seconded.

I would say whatever course-of-action preserves the most of your sanity.

@Mark Kerbin I can't count how many times today I've been "Rick Rolled"

That and the fact that the name of the quoted T2 employee was "Al Coholic"

So far I've accumulated a fair amount of new and/or updated craft files for 1.4.x. As soon as Kronal Vessel Viewer is updated to 1.4.x, I'll start releasing the new craft files on KerbalX. I'm especially excited about using the new LV-1 'Frog' family of landers. The LV-1 landers were always my baseline landers, analogous to the Apollo lunar lander. Prior to 1.4, the family consisted of three variants. The LV-1A was the basic flags, footprints, and take a few measurements lander. The B-model traded some fuel reserves for space to bring a rover, like the later Apollo landings, to explore further away from the landing site. The LV-1C was a pre-staged habitation lander for longer duration stays and the ability to explore even more terrain. The LV-1C was created after some brief study into the Apollo Applications Program, but the 1.4 versions of the LV-1 expand on it even further. In all, the family now consists of 6 lander variants (so far), each with a specific purpose and unique set of capabilities, all inspired by concepts proposed for Apollo missions beyond the last mission, Apollo 17. The most notable feature of the landers is they all share a common descent module. The differences between the landers are whats riding on top, as well as what is placed in the two equipment bays on each side of the descent module itself. The sequence would go something like this: Initial Munar landings (No change from pre-1.4): LV-1A with a basic science package in equipment bay 1, and auxiliary fuel tanks in equipment bay 2. Follow-on Munar landings: after the player gets familiar with the performance and limitations of the LV-1A on the initial landings, some of the extra fuel stored in equipment bay 2 is replaced with the ER-1 'Rat' rover. Additionally, the orbiting EV-2A 'Runabout' will now include a sub-satellite in the service bay, which is released into a Munar orbit while the landing party is exploring the surface (These are analogous to PFS-1 and PFS-2 sub-satellites released by Apollo 15 and 16 respectively, and are part of my probe revamp project) Expanded science return landings: an un-crewed LV-1S 'Frog' Munar shelter is delivered by remote control near the next landing site by a crewed EV-2A conducting an orbital science mission. The next crew would arrive later in an LV-1B to conduct a multi-day/multi-week mission, using the LV-1S as the staging outpost (and larger science experiments in equipment bay 1 like a SC-9001 Science Jr.) and then returning to orbit in the LV-1B ascent stage. Long-term surface base: an un-crewed 'Olympus 5' rocket (yes @d4harp, I'm going with 'Olympus' ) would autonomously deliver an LV-1U utilities lander and LV-1H habitation lander to a suitable outpost location on the Munar surface. The LV-1U would provide a basic comms relay and propellant storage for fuel cell power on the LV-1H, which would be a larger habitation lander very similar to the existing pre-1.4 LV-1C. When the crews arrive, they will use the new LV-1C 'Frog', to ferry Kerbals down to the surface outpost. The new 1.4 LV-1C is essentially an LV-1A with some slight modifications as a single-stage lander, and a science storage container for transporting experiment data back up to the waiting EV-2A, if bringing back "hard copies" was preferred in lieu of transmitting the data. (Disclaimer, I haven't found any references to a single-stage lunar lander in the expanded Apollo proposals, but I didn't want a bunch of used descent stages cluttering up any surface bases and increasing local part count)

Absolutely glorious!

@SQUAD, thank you for the patch. I mean that sincerely. But there is clearly some more work to be done for the next patch.

It would appear this somehow led to this in 1.4.2 DLC. The 5m fairing base is now over 5 meters in diameter, outsizing the 5m parts and resulting in gaps between the fairing panels: This is a fresh clean install of v1.4.2 64-bit Windows KSP with the new DLC version 1.1.0 installed. Grabbed a new tank and a new fairing base, so this wasn't part of any imported craft file or anything. EDIT: Issue has been posted to the bugtracker with [1.4.2] text in the title to clarify.

Nertea updates his mods neither early, nor late, but rather exactly when he means too.

Not to mention that now may be the best time to do it than any other time in the near future, with a lot of the new stock parts requiring eventual craft rebuilding/retiring anyway.