Angelo Kerman

Interlude: The Discovery This mission report is almost at the end, but I'm already planning the next one. In the meantime... With the excitement on Duna almost over- for now- the crew of Duna Base Expedition 1 settled into their new routine of building out more of Duna Base, processing the data from their historic land trip, and training for their upcoming launch. Over the next few months, their daily reports were informative but, frankly, boring. At least in Kerbin orbit, things were more interesting: Magic Boulder Shipyard got to work building the SCV Discovery. The core components of DSEV-03 consisted of the command module, followed by the habitat ring. Yard workers carefully built both components- Orbital Dynamics was responsible for building all the components for the lead ship in the Discovery-class- and assembled them in the Portside Yard. Then they filled all the resource bins and locked them until the ship was ready to launch. After that, they started building the next set of components. Except for the propulsion module, everything aft of the habitat ring was optional and mission specific. For her maiden flight, the Space Consortium Vessel Discovery would be fitted with a Shuttlepod Hangar to deliver two Shuttlepods to Laythe Base. Aft of the hangar, crews mounted a Type 1 Cargo Rack, followed by Liquids Container Module. Crews filled its tanks with propellium for the ship’s reaction control system- gravitic RCS “thrusters” for a ship the size of the Discovery-class were still in development, so DSEV-03 and likely DSEV-04 would need a refit once I make the part the new system became available. Finally, they built and mounted the ship’s Gravitic Propulsion Module, filled its stores of graviolium and xenon gas, and locked the tanks until the ship’s maiden flight. Except for the Shuttlepod Hangar, the International Space Consortium considered the modules comprising the ship’s keel as the standard layout for the Discovery-class. They provided the most versatility given the ISC’s current needs. But while the shipyard completed the ship’s initial configuration, they had more work to do… DSEV-03 had a few things to haul to Laythe to expand the kerbal presence there. First, the crews attached a pair of docking extension tunnels to the Type 1 Cargo Module. Next, they docked two large Drop Pods to the tunnels. Designed specifically for a one-way journey to Laythe’s surface, the Drop Pod landed large amounts of cargo and then shot away from its payload to dispose of itself. In this case, one drop pod carried a Sandcaster 3D printer while the other one had a submarine for exploring Laythe’s oceans. Once yard workers secured the two Drop Pods, they began docking additional modules to the ship. The starboard side of the ship received an Orbital Outpost designed and built by Drax Aerospace as a competitor to the Oasis-class station. It had six docking ports, a habitat cabin for up to 4 kerbals, a small laboratory, and a storage area. Its mid-section had a pair of solar arrays, but they’d be useless as Laythe orbited the dark side of Jool, so ISC ordered a pair of SAFER nuclear reactors and mounted them to the Outpost’s port and starboard docking ports. With that completed, workers mounted another docking extension tunnel, and then docked and secured an Orbital Dynamics Homestead Mk 4 station module to Discovery’s portside. When combined with the Orbital Outpost, the two station modules would form the core of Laythe Station. Finally, the Cargo Module gained a pair of half-sized Standard Shipping Containers that held graviolium and fusion pellets, along with a prototype Stardust satellite and a GPMV. While the containers would stay at Laythe Station, Stardust and the GPMV would cruise around Jool orbit and attempt to find the Green Giant's graviolium belt- if it had one. At last, the SCV Discovery (DSEV-03) was fully assembled and ready for its maiden flight- but it would have to wait a couple of weeks for the launch window to open, and it was time for Duna Base Expedition 1 to return to Kopernicus...

@Rakete Here is my configuration with OPM and REX: // Stock solar system LAST_PLANET:NEEDS[!JNSQ] { // Name of the last planet. // This is the name of the celestial body, NOT the display name! // name = Eeloo name = Plock // Name of the star that the planet orbits. // This is the name of the celestial body, NOT the display name! starName = Sun } Here is where I am: Here is my location: Make sure that in settings.cfg, you set up the LAST_PLANET entry for Plock. Now, here is the stock solar system, no Kopernicus, OPM, or REX: LAST_PLANET:NEEDS[!JNSQ] { // Name of the last planet. // This is the name of the celestial body, NOT the display name! name = Eeloo // Name of the star that the planet orbits. // This is the name of the celestial body, NOT the display name! starName = Sun } Here's where I am: Here's my status: I haven't tried your edited rex configurations, this is with the out-of-the-box mods for OPM and REX. If you're still experiencing issues with interplanetary/interstellar space after changing the LAST_PLANET config, then the fault might be in your edited config file.

In my cases, I'm interplanetary. Not seeing Interstellar when between, say, Kerbin and Duna.

Also verified that Blueshift is correctly identifying intersteller space with OPM and REX installed (at stock scale) In both of my test cases, Blueshift is correctly identifying interplanetary space, so I'm not sure why you're having trouble. As soon as I leave Kerbin's SOI, I'm interplanetary, and once I'm sufficiently out past Plock, I go interstellar.

I've verified that Blueshift is correctly identifying interstellar space with OPM installed and setting the last planet as Plock. E.G. LAST_PLANET:NEEDS[!JNSQ] { // Name of the last planet. // This is the name of the celestial body, NOT the display name! // name = Eeloo name = Plock // Name of the star that the planet orbits. // This is the name of the celestial body, NOT the display name! starName = Sun } works.

Are you sure Real Exoplanets works with the stock solar system? The mod description seems to indicate that it's for Real Solar System.

Yeah, that should be DSEV 3.30.0. I fixed the release.

Chapter 14 Although it felt like several long months, Emma vonKerman, Ferwin Kerman, and Calbro mcKerman had spent just over eighty days driving the Buffabus to various “anomaly” sites on Duna. It was difficult to adjust to the relatively cramped quarters at first, but the trio eventually fell into a routine that worked for all of them as they partook in the longest offworld “road trip” in the history of kerbalkin. By the end of their journey, they drove nearly two thousand kilometers- easily surpassing Bill and Jeb’s famous driving record on the Mün. “When Jeb wakes up, he’s going to be mad,” Dudmon Kerman commented. Cheers went up in the Buffabus and at Duna Base as the trio triumphantly returned to Knights Landing. Despite its wear and tear in the harsh and dusty environment, the Buffabus endured the long trip as well as its crew did. Emma took a “victory lap” around the base before parking it near one of the engineering building’s airlocks. She hooked up an umbilical hose to the Buffabus as the rest of the team headed inside. “Welcome back,” Dudmon shouted as everyone stretched their legs in the habitat building’s hydroponics garden. When the trio left, the space had been barren. Now it had grass, some fake plastic trees, and even a couple of park benches! “We printed the trees up to remind us of home,” Raald mcKerman said. “They’re hollow inside and have lights to help the seeds grow. We’ll take them down before we leave to give room for the real trees to grow. They should be fully grown in a few years.” “We’ve been building out the insides of Duna Base since you guys left,” Dudmon said. "We have more printers in the engineering building, the individual crew quarters in the hab are done, and even the labs are ready to go- minus the stuff we can’t make on Duna, of course. We also worked with Mission Control to devise a bypass to the Sandcaster’s hardwired memory core. We’ll be able to print up just about everything we need with enough resources once we install the bypass. As soon as you guys get settled in, we’ll get to work on that.” “What will you build next,” Emma asked. Dudmon grinned. “We’ve been watching you guys have all the fun exploring the planet while we’ve been sitting here building out the base,” he began. “But when you guys were ordered home, Tobias pointed out that there were a couple of anomalies on your list that you wouldn’t get to. So in between jobs, He and Jonas designed a new lander and flyer to go hunt for them.” “Lander? You can print engines now,” Emma asked. “No,” Dudmon admitted, “that would take a complete rewrite of the software just to print the tools that we’d need. But we have two working Fulcrums that need something to do.” * The commercial success of Orbital Dynamics’ gravitic engine hinged upon finding multiple sources of graviolium, and many companies were trying to figure out which asteroids might contain more of the stuff, and whether veins of the exotic matter existed on celestial bodies. In the vonKerman Republic, engineers at Das Kosmos, the semi-civilian supplier of the VKR’s rocketry, investigated a different approach in hopes of cornering the graviolium market. Their research into the exotic matter suggested that dust-form graviolium may exist within the magnetic fields of celestial bodies like Kerbin and Jool. If that was indeed the case, then it could be collected-albeit slowly. The day’s launch was intended to test that theory. The Fleigenross rocket lept off the pad without its side boosters. It didn’t need them given the mass of the payload. Within a few minutes, the first stage expended its propellant and dropped away to perform its automated landing sequence, and the second stage continued its climb into orbit. It almost ran out of propellant as it lofted its payload into a 511.7 km by 512.1 km orbit. Once the new craft reached the dayside of Kerbin, the upper stage dropped off its client and lit its engine one last time for a destructive reentry. Soon after, the client satellite deployed three large solar arrays and then unfurled several hexagonal collectors. The collectors contained dozens of aerogel cells that Das Kosmos hoped would collect graviolium dust. The satellite even had a storage container ready to hold collected graviolium dust and a standard docking port for visiting spacecraft to transport the graviolium elsewhere. The satellite, known as Stardust 1, was open for business. Unfortunately, it didn’t work. The engineers poured over the data, looking for faults. The collector cells were in working order, the transfer system checked out, and the storage tanks were in good working order. The problem was that there was no graviolium to be found. There was only one thing left to try… Das Kosmos convinced the VKR to let them borrow the Raumschlepper, Drakken Palast’s space tug that was used to transport kerbals and cargo to and from Minmus. The venerable aerobraking space tug departed the station- leaving its passenger module behind, and made its way over to Stardust 1, arriving an hour and a half later. It had no trouble docking with Stardust. Once the satellite retracted its solar arrays and its collectors, it was ready to move. The problem was where to go; was it too high? Too low? The vonKermans didn’t know. For their first attempt, they decided to drop Stardust’s periapsis down to 87 km- just above Kerbin’s atmosphere. If that failed to produce results, then they would raise the apoapsis to 2,000 km, and see what they could find. If that too, failed to produce results, they’d try once more at 5,000 km. Raumschlepper executed the burn to lower its orbit, dragging Stardust 1 along with it. After the burn was completed, the graviolium satellite re-deployed its solar arrays and collector. Kontrol monitored the graviolium detector all the way down to periapsis. They found nothing. Going for broke, Kontrol commanded Raumschlepper to drag its client satellite all the way up to 5,000 km, and then went fishing. As the tug and satellite crossed 1,300 km, Stardust’s graviolium detector started picking up whiffs of dust. That excited Kontrol, but their hopes faded as the combined spacecraft flew past 2,000 km. It appeared that Kerbin did indeed have a “graviolium belt” but it was very slim. At apoapsis, Raumschlepper increased its periapsis to 1,400 km. Then, as Kontrol monitored the readings, they realized that the best concentration of graviolium existed at about 1,500 km. “We’re collecting 0.000022 units of graviolium per second,” Amber vonKerman said, confirming her readings. Though successfully testing their theory, the rate of graviolium collection- almost one unit per day- meant that it could take months to obtain viable amounts of the exotic matter. In Kerbin orbit, graviolium dust wasn’t commercially viable without deploying large numbers of collectors. But out in Jool orbit, they might have better luck. In the meantime, Raumschlepper disengaged from Stardust 1, performed a plane change maneuver, and returned to Drakken Palast- nearly out of propellant- two hours later. * Back at Duna, the vonKermans finished modifying the Sandcastle printer and put the finishing touches on their prototype Duna Drone. Given the difficulties over the years of flying aircraft in Duna’s atmosphere, they were taking no chances with wasting their precious rocket engines on a design that simply couldn’t fly. Tobias wanted to ensure that they had a working design before building a lander around it. The first attempt flat out didn’t work. At 410 kg, the drone was simply too heavy for its 4 propellers to handle. Disappointed, Jonas took the drone back inside and dismantled it. He rebuilt the drone to double its rotors, and that worked. The next version of the drone lifted off Duna’s surface and hovered around successfully! With a couple of modifications, it would be ready to be fitted to a lander… With the Sandcaster working around the clock, Jonas modified the drone to finish its construction, and the team mounted it inside the printed launch vehicle. “It can’t reach orbit,” Jonas pointed out, “but it has enough delta-v to make a hop to an anomaly.” The first location, dubbed Lem’s Knoll, was approximately 818 km away. The engineers mounted one of the salvaged Fulcrum engines to the rocket, fueled it, and sent it on its way. The unnamed rocket reached an altitude of 228 km and jettisoned its payload fairings before plunging back through the thin atmosphere on its way down. Nobody was sure if the plan would work- if it would have enough delta-v to slow down or not. But the good news is that if nothing else, it proved that the Fulcrum engines still worked. The landing burn began and just as immediately flamed out after running out of propellant. The rocket slammed into the desert floor, but the landing gear absorbed the hard landing. Then it bounced a couple of times before resting on its side, intact. Luckily, clever use of the gyros and landing gear got the craft upright again. Once everything settled, the team took stock of the situation; they landed 7.3 km from their desired landing site. And after final checks, Duna Drone 1 powered up its fuel cell and lifted off of its transportation. A half-hour later, Duna Drone 1 landed next to its quarry- yet another stone arch. The anomaly was the original target of Duna Gravity Probe 5, but it never made it to the site due to the poor navigation technology at the time. Knowing that they’d discover little about the stone arch, the DBE-1 team decided to try and locate the old probe. It didn’t take long for Duna Drone 1 to find the probe. The exploration team noted the location of the probe- just 7.5 km from its intended landing site- and tried for one last location… It took another hour and a half, but the helicopter probe finally found its last target, resting in one of Duna’s many craters, and getting windblown by a powerful windstorm. “You can see the vortices of dust coming off of the RCS ports,” Ferwin noted. The cracked hull of the very first Estonian Lander laid partially buried in the Duna sand. It crashed into the crater nearly six years ago when its main chutes failed to open. The useless wreck was nothing more than a footnote in history now, but even still, it served as a reminder of the failed Estonian design that cost the life of Ribler mcKerman. With no other artifacts relatively nearby to explore, the Duna Base science team quietly shut down each of the drone’s electric propellers. Duna Drone 1’s mission came to an end, resting next to the wrecked spacecraft. * With one Fulcrum left, there was another anomaly that proved to be well out of reach for either the Dunabus or the Duna Drone and its current rocket transport. The problem was how to reach it, and the only solution was to add additional tanks to the current design to reach the distant site. The engineers elected to spread out the rocket by adding side-mounted drop tanks. A week later, the new delivery vehicle and Duna Drone was completed. The vonKermans carefully dragged the launch vehicle over to where they could install the last available Fulcrum engine and fuel it for launch. At last, it was ready to fly… Tobias vonKerman gave the Duna Drone 2 a salute before the trio of engineers went back inside for the launch. Site 04-9 was about 1,608 km away from Duna Base. The countdown proceeded normally, and Duna Drone 2 lifted off the desert floor without incident. It had some issues with its trajectory, but a few course corrections got it back on track. Mostly… “Dee Dee 2 is overshooting,” Dudmon noted, looking at the projected landing site. “Aeroshell deployed,” Tobias noted, reading the telemetry. That was by design. If the launch vehicle lacked the propellant to land safely, Duna Drone 2 had a chance to use its propellers to abandon ship and possibly slow down. It was a slim chance, but it was better than nothing. Fifteen minutes later, Duna Drone 2 hit its namesake’s upper atmosphere once again. “Core tank is fully fueled,” Tobias said, satisfied. “Final course correction burn completed… Drop tanks, uh, dropped… Looking good so far.” As the explorers watched the telemetry intently, Duna Drone 2 encountered shock heating, but the bulk of the launch vehicle protected the drone from the heat. It looked worse than it actually was due to the craft’s relatively slow velocity and the thin atmosphere. After the plasma shock dissipated, everything happened quickly. The craft performed a braking burn to slow down, gunned the engine at the last moment, and touched down safely, just 4.34 km away from the desired landing site! “Ok, engine stopped and safed,” Dudmon said triumphantly. The launch vehicle worked well, delivering the drone within acceptable parameters. After ensuring that the Fulcrum wouldn’t accidentally ignite again, Duna Drone 2 turned on its navigation lights, extended its comm antennas, and deployed its BTDT cameras. The probe was ready for launch. Duna Drone 2 reved its electric propellers and broke away from its delivery vehicle. Moments later, the drone began searching for the anomaly, got a reading, and headed towards it. The drone had a mishap and scraped the ground, causing it to lose one of its props, but thankfully it was still airworthy. A few minutes later, Duna Drone 2 found the anomaly. “All that work for yet another of those strange arches,” Ferwin said and sighed. With no other anomaly, probe, or other lander in the vicinity, Duna Drone 2’s mission was at an end. * “After careful deliberation,” former KSP Administrator and newly appointed ISC Chairman Gene Kerman began, “the International Space Consortium has selected Orbital Dynamics’ Modular Deep Space Exploration Vessel as the winner of the Experimental DSEV Program. Both teams provided outstanding designs, but Orbital Dynamics’ revolutionary concepts offer the best path forward. With that said, neither the Newton-class nor the Halley-class provide exactly what we’re looking for, and admittedly, our requirements have changed because of feedback from both crews.” Gene paused a few seconds to let that sink in before continuing. He put a new image on screen. “This is the Discovery-class Deep Space Exploration Vessel, a new class of ship that meets the ISC’s needs. The Discovery-class provides living quarters, deep freeze pods, a laboratory, a sickbay, and a briefing room for a dozen crew members. The command hull also has a large hangar bay capable of holding a Compact Payload Maneuvering Vehicle as well as a single Shuttlepod with its revolutionary gravitic engine. The Discovery-class is also powered by a gravitic engine module, but it can also accommodate other engines, such as Halley’s fusion engine, should graviolium prove to be too scarce to mine in quantity. “The modular nature of the Discovery-class enables the ship to be configured at an orbiting shipyard for a variety of missions- and enables the ISC to spread the production contracts around. Orbital Dynamics is responsible for the ship’s command hull, gravitic engine module, its Shuttlepod, and for the integration of all vessel hull components, while the Arrow Space Corporation and Drax Aerospace will provide other modules such as hab rings, cargo racks, and bulk fluid containers. In short, Orbital Dynamics is the primary contractor for the Discovery-class, but everyone wins with this new ship design. “Finally, the International Space Consortium has placed orders for two ships. Discovery, designated DSEV-03, is the lead ship in the class, and DSEV-04, whose name will be announced after the student naming competition. Both ships will serve as pathfinders for the next two vessels in the fleet. Given the tight time constraints, all our efforts will be focused on building Discovery in time for the next launch window to Jool. DSEV-04 will follow soon after. Now, I’ll take your questions.” “The Kerman States spent a lot of funds on the Nautilus,” Karbal Kerman, reporter for GNN, prompted before the other reporters had a chance to speak up. “That’s, uh, DSEV-01, the first Deep Space Exploration Vessel, right?” “Yes,” Gene answered. Gene hated that guy. He’d hoped that Karbal would’ve been promoted to news anchor by now so that he wouldn’t have to deal with him… “If you could direct your questions towards the DSEV(X) Program…” “What’s going to happen to the Nautilus,” Karbal interrupted. “For that matter, what will happen to Kopernicus- uh, DSEV-02?” Gene sighed inwardly, but publicly didn’t miss a beat. “The Nautilus is currently just over a year away from returning to Kerbin,” he began. “The crew is still in cryosleep, and the ship’s systems are functioning normally. Nautilus represents a huge investment for not just the Kerman States, but also for the mcKerman Kingdom and the vonKerman Republic. She was state of the art when she launched but that was over five years ago, and a lot has changed since then. Project Laythe originally planned to turn her into a space station when she returned, but that changed when we leased Sky Reef from Orbital Dynamics. Once she returns, Nautilus will be placed in a storage orbit and kept in ready-reserve status until DSEV-05 and 06 are operational. At that point, Nautilus will be decommissioned and offered to private ventures as a museum ship. “As you’re well aware, Kopernicus is still on active duty and orbiting Duna. She and her crew have another 190 days until they return to Kerbin. Given the decisions made during her design and construction and the technology available at the time, Kopernicus cannot meet the new quality of life standards set by the International Space Consortium for Deep Space Exploration Vessels. As a result, she will be decommissioned and recycled upon her return to Kerbin unless a private venture steps forward to preserve Kopernicus as a museum ship. “Now, if there are questions related to Nautilus’ and Kopernicus’ successors…”

Latest pre-release is available here. - Fixed issue with wonky resource generator display in the VAB/SPH. EfficiencyBonus is also accounted for in the display.

All good, no worries. Next update will fix some of the converter displays values. I have not updated the version number for the pre release. The link is the same, I just update the zip file. It’s not professional but it’s faster to just replace the zip file than to create a new pre-release version.

Moved thread to KSP 1 modded technical support thread.

Latest pre-release is available here: - Fixed issue where generator resource consumption dropped to zero when flying in interstellar space. This is an issue that @Ooglak Kerman reported. Fixed at last.

Yeah, the only way that I could fix it is to override the converter's "GetInfo" method, which generates the text showing the inputs and outputs. Then I could account for EfficiencyBonus as well as adjust how those performance numbers are displayed. That's non-trivial, but it is doable.

Ok, I've looked into this. The S3 Gravimetric Generator consumes 36 Graviolium/hr and 0.68 Fusion Pellets/hr. If you look at the config file, the generator (and the S3 Warp Sustainer) consume 0.01 Graviolium/sec. The S3 Heavy Warp Sustainer consumes 0.02 Graviolium per second, which is 72 Graviolium/hr (0.02 /sec * 3600 sec/hr = 72/hr) and 1.35 Fusion Pellets/hr. Based on my calculations, the Heavy Warp Sustainer produces twice as much as the S3 generator, and consumes twice as much resources, which is by design. Looking at the part model (it's been awhile since I've seen the older S3 sustainer), the Heavy Warp Sustainer even has two fusion reactors on it, so I definitely went "moar boosters" on it for the increased capacity. I think the issue you're running into is how the game is reporting the numbers. For some reason, if the value is 0.01/sec, then you'll get that 36/hr that you see with the S3 Warp Sustainer and the S3 Gravimetric Generator. But bump that number up to 0.02/sec like I did for the S3 Heavy Warp Sustainer, and suddenly you have 0.02/sec being reported, when I'd think that it should report 72/hr. And on top of that, the readout doesn't even take into account the part's EfficiencyBonus! Technically, I could use the same numbers on the S3 Heavy Warp Sustainer as I do on the S3 Gravimetric Generator, set the Heavy Systainer's EfficiencyBonus to 2, and in flight it would be twice as efficient- but in the VAB/SPH, it would show the exact same performance values as the S3 Warp Sustainer & S3 Gravimetric Generator. Yay KSP 1...

@Falki This looks like a great addition to KSP 2. I look forward to watching how it develops. Are you considering adding Discoverables to the display as well? I like the "?" feature of SCANSat displays that showed anomalies, and something like that in Orbital Survey would be great.

I've investigated your issue and can verify that when anomalies are set to isKnown = true, you can reach the gates even without visiting them beforehand. You will need to visit at least one of them before order to visit any of the rest. You might need to disable jumpgates, save and reload your game. If that doesn't delete the gates then you can manually delete them via the tracking station. Once you've done that, install the patch below, set isKnown to true for the jump gate, restart your game, and re-enable jumpgates. I've fixed a couple more issues and here is the latest pre-release update. The fixes are: - Adjusted part costs for the Bussard Collectors and Plasma Vents. - Fixed negative Funds cost of the Mini Jumpgate Platform. - Fixed issue where space anomalies all had the same vessel name. I haven't had time to look at that yet but it is on my list.

Latest pre-release for Blueshift can be found here. - Added Debug Mode menu item to the Blueshift Settings menu. This supersedes the "debugMode" field found in settings.cfg and various part module files. - Added Sphere of Influence support for JNSQ's planet Nara.

Remember that other stars will already have their own SOI. So you don't need custom definitions unless you want to alter what is considered the "last planet" for a particular star system.

Yeah, REX might be messing with what is defined as the "last planet" in the Kerbol system. For non-JNSQ usage, that LAST_PLANET node will define Kerbol's SOI by specifying Eeloo as the last planet.

Pre-release means that the new update isn't done yet, but I'm rolling out changes as I make them so people can try them out. Think of it like "Early Access" for the next patch. Yeah, you'll need to modify the settings.cfg in the Blueshift folder. For other planet packs, like, say Galaxies Unlimited, I don't have to define the last planet for every star. That's because each star system already defines its own SOI. It's only the Kerbol system that doesn't do that, and I think the Grannus Planet Pack needed some help too. I guess it's possible that since REX is adding exoplanets to the Kerbol system, they're extending Kerbol's SOI pretty far out. Try adding this to your Blueshift/settings.cfg file: LAST_PLANET:NEEDS[!JNSQ] { // Name of the last planet. // This is the name of the celestial body, NOT the display name! name = Eeloo // Name of the star that the planet orbits. // This is the name of the celestial body, NOT the display name! starName = Sun }

First pre-release of the latest Blueshift: https://github.com/Angel-125/Blueshift/releases/tag/v1.10.0 I think you can set it via: // 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 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 } // 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 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 } I haven't tried this for Kerbol, however, and I'm not even sure what the name of the sun is in the game. You might also try playing with // This multiplier is used to calculate a star system's sphere of influence based on the furthest planet from the star (if any). // We artificially calculate the solar SOI because the home system (Sun, a.k.a. Kerbol) technically has an infinite Sphere of Influence. // A value of 1 puts the distance at the semi-major axis of the furthest planet. 1.1 is 10% past that distance. soiMultiplier = 1.1 this is in the settings.cfg file.

Finally figured out the problem with generators and action groups, testing the fix is ongoing. I may have the first pre-release in the next evening or by the weekend; I need to finish up the S1 multi-coil prototype part first.

I suspect the issue is that Blueshift doesn’t know about REX. If these exoplanets are orbiting Kerbol then yeah, Blueshift isn’t aware of REX. I had to manually define the interstellar SOI of Kerbol due to the way that the game works. My guess is that with REX installed Blueshift will need to adjust the Kerbol interstellear SOI. Thank you. I intend to take it slow, especially given my workload for my job and family concerns. That said I intend to publish incremental previews as I fix things so you’re not waiting forever for all the fixes. They will be pre-release builds. The action group issues have proven to be elusive due to the Blueshift generators using stock part modules for the generator code. My stuff just adds special effects on top of the existing stock part module. Not sure why that is a problem. Once I finish the S1 multi coil prototype I will look at the generator code again.

The multi-coils will be new parts. The existing warp coils won't be going away. You'll be able to visually tell the difference in the editor; the new parts will show two segments in their part icon. The action groups thing is definitely perplexing and I don't know what causes it, but it's on my list to investigate. P.S. They should have high warp capacity, require a large amount of GravityWaves, and produce a correspondingly high StaticCharge.

Happy New Year! A little bit at a time so I don't burn out, I'm investigating Blueshift's issues and what can be done about them. First up: multi-segment warp coils! These will come in 2, 4, 6, 8, and 10-segment variants for the S1, S2, and Mk2. No more warp coil spamming! I'm also thinking about a Mk3 form factor warp coil, something akin to the USS Excelsior, but we'll see. Right now in Blender, I can modify 3D models that I've already built, but making something from scratch is gonna take more learning... Anyway, the mult-segmented warp coil will automatically adjust its mass, cost, and performance based on the desired part variant.