Angelo Kerman

For your first question, it's not easy to calculate the edge of interstellar space in some cases. If you're orbiting a star, then we definitely know the SOI boundary. But in mods like Galaxies Unbound, there are barycenters that the vessel can also orbit, and they count as interstellar space. But maybe some kind of spool up time would help. So as soon as you go from interplanetary to interstellar space, or the reverse, you gradually speed up or slow down. As @JadeOfMaar suggests, speeding up into interstellar speeds should take longer than slowing down to interplanetary speed. For your second question, Graviolium is consumed to generate the Gravity Waves needed by the warp engines and warp coils. They're produced by the gravitic generators, which are derived from the stock resource converter. Right now, the "dumpExcess" field is set to true on Gravity Waves so that the generators will also continue to produce Electric Charge. If you set that value to false, the generators will stop consuming Graviolium when the Gravity Waves "tanks" are full, but then you'd also lose Electric Charge generation. You could separate Electric Charge generation from the Gravity Waves generation, but that has the potential to slow down your game as you increase the number of resource converters that are currently running. Plus, you'll need to remember to 1) start your power generator, 2) start your gravitic generator, and 3) make sure your warp engine is running, which may be too many steps for some. Finally, combining the generators made it easier to figure out which one should be driving the part's effects. So for now, think of the continual consumption of Graviolium as the cost of producing the Gravity Waves needed to keep your warp engines on hot standby. As for the consumption rate not changing when you hit interstellar speeds, by rights it probably should change, but interstellar speeds weren't considered when the mod was originally built back in November. I figured that timewarp would take care of it, but warping during timewarp proved to not be straightforward. I'll have to think about how I want to handle interstellar versus interplanetary resource consumption. For your third question, I'm not understanding how it's not easy to use.. you enable it from the Game Difficulty -> Blueshift menu, and when you drop out of warp, 3 seconds later you auto-circularize. What's the use case that you're thinking of for manually hitting the circularize button? What it comes down to is that I don't want to end up maintaining module manager patches for mods that I don't use, just to satisfy user demands, and Blueshift is designed to work without any mod dependencies. That reminds me, I need to add a stock converter option to slowly produce Fusion Pellets from Ore if you don't have Wild Blue Tools installed... Anyway, using Fusion Pellets as a resource is consistent with the fusion reactors in my DSEV mod. But if you really want Blueshift's generators to use FFT resources, I'd suggest building the module manager patches for it. Maybe the real thing to do is remove the patches for FFT and SpaceDust, and let users create their own patches if they want that support.

OO, a Gene Kranz would be great too. These new skins look great!

Not supported. It should work but no guarantees.

They use WBI Fusion Pellets. Blueshift has no external dependencies. I haven't used CRP in a long time but I vaguely recall that they have my definition of Fusion Pellets as well.

If by tubular you mean ring-shaped warp coils, the definitely. The warp rings can be stacked atop each other to form a tube.

Since there aren't any more major issues, and my CKAN PR was approved, here is the Blueshift 1.0 release! Blueshift will be up on Spacedock shortly... Changes - Updated SOI multiplier for stars with no planets to 500x the star's radius. It was too easy to miss the star otherwise... - If Auto-circularize is enabled, then starships will automatically circularize in interplanetary space if a star has no planets. - Hid the Jump Tech node until the jump tech parts are done. Speaking of jump tech, I'm busy working on the next space anomaly: the jump gate: This is a single segment of the jump gate. There will be two versions: one that you discover like the existing Space Anomaly, and one that you can research and build. Once finished, you'll be able to jump to any other gate in your known network- player-built gates are automatically known. If having jump gate anomalies aren't your thing, then there will be an option in the Blueshift Game Difficulty menu to disable Jump Gate Space Anomalies. You'll still be able to enable/disable the regular Space Anomalies if desired.

DSEV 3.7.0 is now available - It's hard to believe that Deep Space Exploration Vessels is now over 5 years old! Once I've finished my current projects list (Blueshift and Kerbal Flying Saucers), I do have some minor texture updates in mind to leverage the skills I've learned since 2015. Nothing major, just a few updates to get a better match with Restock parts. - Added support for KSP 1.11.1 - Fixed missing stack node on Nautilus Bridge. - Fixed decal issues on Nautilus Bridge. - Size 1 (Moho), Size 2 (Delta), and Size 3 (Duna) tanks are hidden when Restock is installed.

I've seen that too, but I don't know what causes that. I don't do anything with targeting except displaying what the vessel is targeting.

Blueshift 0.7 is now available. Anomalies - Reduced time between anomaly checks. - Improved chances for a space anomaly to spawn. Spheres of Influence - Updated how stellar spheres of influences are calculated in order to improve interstellar space detection. - Changed homeSOIMultiplier in Settings.cfg to soiMultiplier. It is now used for all star systems. - Added new soiNoPlanetsMultiplier to artificially create an SOI for star systems without planets. - Fixed issue where starships would slow down well before reaching a star system (I'm looking at YOU, Galaxies Unbound! Thanks for such great variety! ) Warp Tech - New navigation assistance- warp engines have some additional fields in their Part Action Window: Spatial Situation: Planetary/Interplanetary/Interstellar/Unknown Course: <name of the selected target, if any> Distance: <Ly, Gm, Mm Km> Config Nodes New format for LAST_PLANET (remember, each planet needs its own LAST_PLANET node. These are optional, GU is calculated automatically) LAST_PLANET { // Name of the last planet. // This is the name of the celestial body, NOT the display name! name = Cernunnos // Name of the star that the planet orbits. // This is the name of the celestial body, NOT the display name! starName = Grannus } CKAN - Added Blueshift to CKAN (PR submitted, might take a few days to update). And a new infographic:

Fortunately, for GU, Blueshift can automatically compute the SOIs

Next update the LAST_PLANET config node will look like this: // Blueshift can calculate the home system's sphere of influence based on the furthest planet from the star, but some planet packs // don't make it easy. To help the mod out, you can define a LAST_PLANET node that tells Blueshift what the last planet is for the specified star. // Each star needs its own LAST_PLANET node. LAST_PLANET { // Name of the star. // This is the name of the celestial body, NOT the display name! name = Grannus // Name of the last planet. // This is the name of the celestial body, NOT the display name! lastPlanetName = Cernunnos }

Set starName = AlphaCentauriA. That's based on the debug logs I've added in the next release. If it will be easier, next update will just have name and lastPlanetName, with name being the celestial body's name (AlphaCentariA in this case). Speaking of which: I have a couple of tweaks to make, then I'll post the next update tonight.

Important note: make sure to use the body's name, not its display name. I think "Nova Kirbani A" is the display name for "AlphaCentaruiA"

Yup, that is correct. Next update will also help clear up the SOI issues.

I've confirmed that the mk2 parts are showing up. You might need to search through your logs to find, say, the wbiMk2WarpCore and see what the logs say. I'd also need to know what other mods you have installed, especially ones that use the mk2 form factor. The next update will allow you to define a last planet for the stock Sun. You'll simply define a LAST_PLANET config node. There won't be a problem defining a LAST_PLANET node whose lastPlanetName is not the actual last planet in the system. Anomalies can be found in the tracking station. The detection cycle is specified in the Settings.cfg file's anomalyCheckSeconds value, which is set to 600. That means, every in-game 600 seconds, Blueshift will check to see if it should spawn an anomaly. If you look in the Blueshift/Parts/SpaceAnomalies/Tet folder, the wbiTet.cfg file has the SPACE_ANOMALY config node. There is a value called spawnTargetNode, which specifies on a roll of 1 to 1000, what minimum value the random number generator needs in order to spawn an anomaly. If you lower the value to, say, 1, then you'll pretty much guarantee that you'll spawn an anomaly. In the Tracking Station, anomalies are prefixed by "UNK" and they're classified as Space Objects. I'm shooting for this evening or tomorrow to release another Blueshift update that will redo how solar spheres of influences are calculated and hopefully put an end to the problems with determining where interstellar space is. Meantime, it looks like there are 29 stars in GU, 13 of which have planets... [LOG 11:34:40.716] [Blueshift] Last planet in the Sun system is: Eeloo [LOG 11:35:06.337] [Blueshift] Last planet in the AlphaCentauriA system is: Orus [LOG 11:35:28.488] [Blueshift] Last planet in the AlphaCentauriB system is: Syro [LOG 11:35:39.420] [Blueshift] Last planet in the ProximaCentauri system is: Elius [LOG 11:35:46.656] [Blueshift] Last planet in the BarnardsStar system is: Iores [LOG 11:35:58.853] [Blueshift] Last planet in the LuhmanA system is: Vivus [LOG 11:36:06.554] [Blueshift] Last planet in the EpsilonEridani system is: Tias [LOG 11:36:06.555] [Blueshift] Last planet in the TauCeti system is: Liolan [LOG 11:36:06.556] [Blueshift] Last planet in the TeegardensStar system is: Teec [LOG 11:36:06.557] [Blueshift] Last planet in the Lich system is: Phobor [LOG 11:36:06.558] [Blueshift] Last planet in the 3Orionis system is: Atlas [LOG 11:36:06.558] [Blueshift] Last planet in the Trappist1 system is: Trappisth [LOG 11:36:06.559] [Blueshift] Last planet in the Betelgeuse system is: Infurus Given that there are some stars without planets, I'm crafting a way to artificially create a star's SOI that has no planets. I have to say, @StarCrusher96's GU mod has been very helpful! :)

I'm not familiar with First Flight, but an existential threat is a common theme in my mission reports. This time though, I have some different ideas on the matter.

Each of the name/starName/lastPlanetName needs to be in its own separate LAST_PLANET node. So only one set of name, starName, and lastPlanetName per LAST_PLANET.

Heh! At this point, NSWR is beyond their technology, and the open-cycle gas-core rocket is right on the edge of theory and practice. The designs are still in flux but the majority is figured out. I was originally going to go for Duna like I did in many previous saves, but I decided that for JNSQ I'd do something different. And JNSQ Laythe looks really cool... The president looked at KSP's data, realized that Laythe might be their salvation, and indeed diverted the space agency's funds and directive to Laythe...

I figure that the exhaust velocity of the Emancipator is high enough to escape orbital velocity around Kerbin and Laythe, so it's not as much an issue as one might think. Plus, the Emancipator has very high thrust, which I need for these craft. The LADV uses cryogenic fuels so the surface of Laythe is safe.

Can you try adding the Kirbani barycenter to the LAST_PLANET list?

Chapter 4 “Next slide, please,” Brigadier General (ret) Gene Kerman, Director of KSC, said. The screen behind him switched to a new image, this one depicting a large space vessel with a bulbous bow, a torus mid-section, and an aft section consisting of an array of heat radiators and a cluster of tanks. A single rocket motor protruded from the tank cluster. “This is the Nautilus, what we’re classifying as our first Deep Space Exploration Vessel, or DSEV. At nearly 50 meters long, she will be the largest kermanned spacecraft ever built…” “Why aren’t you going to Duna instead of Laythe,” Karbal Kerman, one of the reporters, interrupted and asked. “Wasn’t that the original plan?” “It was,” Gene sighed and admitted, “and it was the reason that we handed cisminmar space over to commercial companies. But our scientists recently confirmed that the Jool Surveyor’s sensors were correct. Laythe does have a breathable atmosphere and liquid water on its surface. Given how far Jool is from Kerbol, Laythe shouldn’t have liquid water. We would really like to know why. More importantly, is there life on Laythe? We want to know that too. Because if life can exist here on Kerbin and on Laythe, then it’s likely to exist throughout the universe. So to definitively answer your question, the new president saw our findings and redirected our efforts to reach Laythe instead of Duna.” “How does Kongress feel about that,” Karbal jabbed. “You’ll have to ask them,” Gene quickly shot back. He took a brief pause before continuing. “As we did with the Shuttle Launch System and Starlab, we’re expanding the limits of technology with Project Laythe. For the Nautilus, we’re creating a centrifuge to generate artificial gravity through centripetal force. Based on our research at Starlab, the bodies of astronauts can degrade over time without sufficient gravity. And since it takes a couple of years just to reach Jool and another couple of months to enter Laythe orbit, we want the crew to be as fit as possible when they arrive…” “How will the crew avoid getting stressed out? It doesn’t look like they have much more space than on KOS,” Karbal interrupted. Again. Gene sighed. Again. “For those who may not be aware, kerbals are distantly related to several amphibian species on Kerbin, genetically speaking. Some of our distant relatives hibernate during winter. Their bodies are nearly frozen solid and their hearts stop beating. But they don’t die, thanks to antifreeze permeating their cells while ice forms in body cavities around their vital organs. When spring arrives, they thaw out and resume their activities. I am not an expert on the subject, but the vonKermans have been testing some ‘deep freeze’ technologies that would enable kerbals to hibernate too…” “The crew be become… corpcicles,” Karbal asked. “Is that safe?” “Nothing about space flight is entirely safe,” Gene admitted. “The astronauts know the risks each time they launch. But the deep freeze technology does look to be relatively safe. It is revolutionary technology, one that enables us to stretch our resources for longer duration missions. But we have even more innovations in store. “If you look at the ship’s main engine, you’ll notice that it’s an unusual design. That’s because the vonKerman Space Agency, the mcKerman Ministry of Space, and Kerbal Space Program are all collaborating to jointly develop the NV-GX ‘Emancipator’ Atomic Rocket Motor. Before you ask, yes, the NV-GX is indeed powered by nuclear fuel. That’s why all three spacefaring nations are working together to develop it-to ensure that none of the technology would be used for atomic weapons research, which was banned by the Last War Armistice, and that we all share the technological benefits. “While an ‘Atomic Rocket Motor’ may sound like a bomb of some sort, in truth it is more like an atomic power plant here on Kerbin. But instead of heating water and producing steam to spin generators, the NV-GX heats propellium to produce thrust. The net result is an engine that is over twice as efficient as a cryogenic engine like the KS-25B ‘Rainbird’ engines that powered the Shuttle. Next slide, please.” The picture changed to show Nautilus without its aft radiators and propulsion section. Additional modules adorned its docking ports including some that were clearly of vonKerman design. “DSEV-01 is rated for up to five missions to Laythe,” Gene continued, “after which it will remain in Kerbin orbit to form the basis of KOS-2 and replace Starlab, which will be about twenty years old by then and ready to retire. Next slide, please.” The picture changed to another craft, this one consisting of a dart-shaped craft tipped by what looked like a modified Estonian crew capsule. A set of tanks similar to those on the Nautilus followed behind it. “This is the Laythe Ascent Descent Vehicle, or LADV,” Gene began. “On the outbound trip it carries no crew, but it’s designed to land a crew of eight onto the surface of Laythe and return them safely. Next slide, please. “This is the Laythe Mission Support Vehicle, or LMSV,” Gene began. “It carries no crew, but it does carry a habitation module where the crew will spend their time while exploring Laythe. Next slide, please. “This is the Laythe Rover Supply Module, or LRSV. This craft consists of a drilling rig, extra supplies, and an automated rover. While we don’t expect to find much in the way of resources, the drilling rig will enable us to stretch our supplies. We intend to dock the LRSV to the Habitat to augment its capabilities. Next slide, please. “Finally, the Icebreaker Mining Vehicle, or IMV. The IMV is needed to produce the propellant that Nautilus will need for its return trip- though if needed it can scavenge propellant from the other vehicles. “When the next available Jool window opens in about a year, we’ll be sending the IMV along with the LADV, LMSV and LRSV. We’re calling this space flotilla the Laythe Support Fleet. We’ll also send a Bumblebee Atmospheric Mobile Flyer, or BAMF to find a suitable location to land. “Every Jool launch window thereafter, we’ll send a LADV, LMSV and LRSV to pre-position the equipment and resources needed to explore Laythe. They’ll become the outpost for the next mission to Laythe, or if needed, they’ll provide backup hardware should the previously sent mission craft fail. In addition, we launch Nautilus with a crew of eight. “As you can imagine, all these vehicles are awfully expensive. The Nautilus alone, for instance, costs almost as much as a Lindor 5 launch. They would be beyond KSP’s budget to handle alone. But if you haven’t already guessed, Project Laythe is an international program like Starlab- only this time, the vonKermans are joining us along with the mcKermans…” *** Back in his Gene’s office, Oskar vonKerman (Director of the vonKerman Space Agency), Charles mcKerman, (head of the mcKerman Ministry of Space), joined Gene for a post-press conference debrief. “That went well,” Charles began. He sighed. “Our planet truly has such a… Je Ne Sais Quoi feel to it like the leKermans say…” “A hundred years, that’s all we’ve got left,” Gene lamented. “Just like the kermantians had...” “But unlike the kermantians, we have spaceflight. We shall save as many as we can,” Oskar decreed.

Hm. Interesting. I didn't see that in my testing. What stars are you seeing that with?

MOLE 1.26.0 is now available: - KSP 1.11.1 support. - Mk2 Docking Port now has a "Buffalo" part variant that's designed to fit the Buffalo Crew Module. - 1.875m Titan parts are hidden when Making History DLC is installed. - Deprecated the mini grabbing unit since one exists in stock now.

LAST_PLANET { name = ProksimusKirbani starName = Proksimus Kirbani lastPlanetName = Elius }

Buffalo 2.10 is now available. Hard to believe that Buffalo is now over 5 years old! Right now my plate is full for making any revisions and such, and given that my skills have improved since this was release, I've considered creating a successor to the Buffalo once I've finished my current projects (Blueshift and Kerbal Flying Saucers). It depends upon how soon those projects get done and how close to release KSP 2 is. Anyway, here are the changes: - Updated for KSP 1.11.1 support - Storage containers updated to use OmniStorage and support stock inventory system. - Added stock inventory to all parts with crew capacity.