Angelo Kerman

Blueshift 1.7.5 is now available: - Fixed warp stutter issue where warp engines would rapidly vary their warp speed and cause repeated photonic booms as ships dropped below and exceeded the speed of light. - Added new Supercharger slider to the warp engine. With a value above zero, excess Gravity Waves will be funneled into active warp coils to improve their warp capacity. With EVA Repairs installed, they will wear out faster when supercharged. - Updated the warp engine sound effects.

As it turns out, I needed to make a small bug fix for Kerbal Flying Saucers. Here is the fix. The fix also updates compatibility with Blueshift. When Blueshift is installed, KFS will use Blueshift's converters. Sure, here you go: Craft file here.

Kerbal Flying Saucers 0.6.11 is now available: - Updated Blueshift compatibility patch. - Fixed issue where WBIGraviticGenerator would drain ElectricCharge if it is an output resource and the generator is turned off.

Not needed. Blueshift will patch KFS' gravitic engines to use the proper resource converter from Blueshift. If anything, I'll patch the Excalibur's engineering cores to use the proper converter from KFS, which will then get patched when using Blueshift. But given how incomplete the KFS mothership is, it can wait.

That engine is from Kerbal Flying Saucers. No stuttering even with the supercharger. Now it just lets you use the excess Gravity Waves produced by your generators to coax more warp capacity out of the warp coils- and wear them out faster. New release is being worked on, yes. I have some cleanup to do first.

Lots of spinning plates at the moment. 600km is right for Kerbin. Anyway, I've got several safeguards in place to disable the converter's run cycle bypass, and the Supercharger slider is working as well. If set to 0% then the warp engine will only use the minimum required GravityWaves to power the ship's warp coils and ignore excess production. At 100%, it'll use every available units of Gravity Waves and push the coils to produce more warp capacity (and potentially burning them out faster). Also, here's a new promo to describe the warp engine controls: WX-01 Warp Core Breech undergoing a shakedown cruise after a "minor refit." The "fusion timing belt" is working; no warp stutter. Supercharging the warp coil enables ship to travel at warp- which it can't do without the supercharger and with only one coil running. More pics: Flying with all her coils enabled. Successful test of the new supercharger powering all the warp coils. Speed is much higher. Arrival at Eeloo. Using low throttle, disabling supercharger, and using thrust limiter to fly visually instead of using map view. Warp Core Breech flies well enough in atmosphere too.

Yup, that's correct. From WBIWarpEngine: // Minimum planetary radii needed to go to warp. minPlanetaryRadius = 1.0 @Ooglak Kerman Random thought: I wonder if an Engineer 6 is a Stark instead of a Scotty...

It's always one orbital radius of the planet/moon/star that you're orbiting.

Thanks! I think the English version is "tip my hat." Fixing this issue is one of those cases where to get a break from programming, I do some programming on something else. Yes, it will work with multiple generators. The active warp engine already knows about all the generators on the ship. It adjusts their production rate when you venture into or out of interstellar space. My biggest concern is ensuring that the bypass that I put in doesn't cause problems with the generator when a warp engine isn't running, so I'm working on putting in safeguards. At worse, you might need to stop and restart the generator if something like that should happen (the engines are smart, they automagically disable the bypass when they stop running).

Using the Thrust Limiter can also help when you're interplanetary. Just like with regular engines, thrust limiter will help limit your warp speed. I've been trying various methods to fix the stuttering/warp speed pogo oscillations by trying to build a buffer, varying the supercharger output, and others, but everything I tried either didn't work or just delayed when the stuttering happened. Then it dawned on me: I could manually sync the generators! I'm testing a solution where an active warp engine effectively pauses the generator's resource cycle until the engine has a chance to do its thing. So far, I've had no stuttering: WX-01 Warp Core Breech, testing a "fusion-powered timing belt" to fix warp stutter.

If the power multiplier is below 1, that means that the warp coils are under-powered. Depending upon the coil's statistics, and the mass of your vessel, the ship might not be able to go faster that light. In fact, even if the coils are supercharged, the ship still might not go faster than light. It depends upon the mass of the vessel, the warp capacity of all the coils, and the amount of power available.

Ah, no need to apologize, I was using sarcasm. Unfortunately that got lost in translation. What I'm trying to do is resolve the oscillations/stuttering completely if possible. Overcharging the warp coils is part of the cause. The good news is that in my testing, just setting the power multiplier to 90% of the maximum possible value solves the problem with your test configuration. Now I just need to figure out the math to find the optimal value for the power multiplier. Since supercharging the warp coils will cause them to wear out faster, it makes sense for me to add a button to enable/disable it. Using the example above, when supercharging is disabled, the power multiplier can never go above 1. Thus, per time tick, the generator produces 3 GravityWaves, and the warp coils consume 0.2- you'll never run into the stuttering.

Actually, the warp engines and generators have GravityWaves in their part's resource list- it's just hidden from the player. The S2 gravitic generator, for instance, has 3000 GravityWaves- enough to store 20 seconds of output from the generator. One thing I tried last night is adding a delay in requesting resources in order to give generators time to catch up. I already had that mechanism in place for when the ship translates from interplanetary to interstellar space, for instance. Now it checks the vessel resources to see if it is low on GravityWaves and waits a few time ticks before checking again. If the vessel is still low, then the warp engine flames out. That helped, but now the oscillations just happen slower. The other thing I'm trying is to adjust the power multiplier- When you have more power than what the currently running warp coils need, by design, the engine will try to "supercharge" them to get more speed out of them. If you have EVA Repairs installed, that will make the coils wear out faster... Similarly, if you have less power available to run the coils than they require, they'll be under-powered and produce less warp capacity- and won't wear out as fast. For instance, in your ship configuration, you have one S2 warp core running, which generates 150 GravityWaves per second. 2 warp coils need 10 GW/sec. Per 0.02 second time tick (Time Warp level 1), that translates into 3 GW/tick produced, and 0.2 GW/tick required by the coils. The power multiplier takes total produced / total consumed, which is 150/10 = 15, and uses that multiplier when requesting resources from the warp coils. I did some digging, each coil will request 15 * 5 * 0.02 = 1.5 GW/tick. With 2 running warp coils, they use up 3 GW/tick. As noted above, sync issues don't let the system keep the power inputs and outputs in balance, so today I'm looking at: 1. Capping the power multiplier to around 90% of the total output to reduce the chances of overloading the generators. 2. Dynamically lowering the cap if the ship keeps running out of GravityWaves; 85%, 80%, 75%, etc. until the power input/output balances itself. 3. Adding a manual Supercharger button that doesn't let the power multiplier go over 1, and that players will forget using to prevent the oscillations from happening, and complain about the problem. 4. Dynamically adjusting the power multiplier cap, and adding the Supercharge button to set that multiplier to 1 when disabled, and confuse players about what the Supercharger button does.

See: Miracle Worker.

I've investigated the issue and have found that it is a timing issue within KSP itself. Blueshift relies on a part module based on ModuleResourceConverter that produces the gravity waves. The problem appears to be that the resource converter and the warp engine are out of sync; what should happen is that the converters aboard your ship should produce the gravity waves right before the warp engine/warp coils consume them. In fact, when I'm stepping through the code, that does indeed happen. However, without those breakpoints, the generators get out of sync with the warp engines, and your ship runs out of gravity waves. The reason that it doesn't happen in a planetary SOI is because the power levels are stepped down, so the generator has more than enough output to power the coils. A true fix to this problem is to do away with producing gravity waves as a vessel resource, and do something like Breaking Ground Science (from the Breaking Ground DLC). In the DLC, ground science parts have a generic Power Units produced and Power Units consumed, and they don't use vessel resources (like liquid fuel). In fact, they're just a simple integer value. But that would require a significant redesign of the system. Unfortunately, I don't have time right now to do that, and I'm grappling with some pretty significant burnout. The other solution is to add another generator, as you found out, or increase the output of the existing generators, or reduce the input needed by the warp coils. Keep in mind that the solution will only delay the problem; the heavier the vessel, the more likely you'll run into the issue as you run up against the limits of the generators and warp coils.

The science system in Wild Blue Industries was based on transferring experiments to and from stations like in the real world. It's been awhile, but I believe the stock MPL can generate LabTime from ResearchKits. You should be able to load the Temperature Study experiment into the stock Experiment Storage Unit. There should be a button on the part to show the experiment manifest to do that. These screens were made for M.O.L.E. several years ago, but the concept applies to the stock parts as well: https://github.com/Angel-125/MOLE/wiki/Science!

If I recall correctly, you can't just run the experiment for temperature study. You need to recover the part with the experiment.

Chapter 28 Orbital Dynamics’ new shipyard impressed KSP to the point where they began negotiating with the company for use of their facility- and for an OCTV or two of their own. Meanwhile, after months of travel, the First Eve Fleet arrived at the purple planet! Gilly Mapper arrived first, followed close behind by Bumblebee. Both spacecraft plotted a braking burn to enter high Eve orbit. The Eve RelaySat constellation entered Eve’s SOI five hours later and followed suit… Gilly Mapper had an eight-day wait before it could perform an interception burn with Gilly, but Bumblebee lowered its orbit four and a half hours after is braking maneuver. It tried to carefully skim the upper atmosphere to slow down, caressing Eve’s atmosphere once every 8 days or so. Meanwhile, Eve RelaySat performed its inclination change maneuver, increased its orbital altitude to 136,663.1 km, and then waited to circularize it. Then, on Montezu 9, 2001, KSC Mission Control realized that the Gilly Mapper lacked the delta-v that it needed to enter Gilly orbit. They promptly made a small course correction burn to avoid crashing into the tiny mϋn and ordered it to enter high Eve orbit in seven days… As Gilly Mapper high-tailed to high Eve orbit, Bumblebee nearly suffered a disaster as it skimmed the upper atmosphere of Eve once more. Additionally, it lacked the delta-V needed to circularize in low orbit, so KSCMC decided to raise its periapsis out of the atmosphere and reassess its situation. At least the Eve RelaySat constellation enjoyed some success. After setting up the resonant orbit, each satellite had 42 days before it had to circularize. Since they could handle that task on their own, the nuclear propulsion unit separated from the constellation and headed out on its own… Two days later, on Montezu 16, 2001, the propulsion unit- now called the Eve Nuclear Tug- burned to intercept Bumblebee. It took another 10 days to finally catch up to the space probe, and an additional six hours before everything was in place. Neither spacecraft had the docking ports needed to link up. But what Mission Control had planned hadn’t been done since Mϋnflight 3, and even then, it was an accident. As the Lindor rocket ascended, the third stage decoupled from the rocket-while the second stage still burned! Then Lieutenant Commander Dudmon Kerman expertly balanced the third stage while the second stage depleted its propellants. His efforts saved the mission- and earned him the Medal of Heroism. Since neither spacecraft had compatible docking equipment, KSP was essentially going to try and repeat Dudmon’s feat- around a distant planet and completely autonomously… As the two spacecraft rounded their periapsis, the Eve Nuclear Tug pointed retrograde while Bumblebee locked its engine bell from moving and gently maneuvered onto the front of the tug. Then, keeping the throttle low, Eve Nuclear Tug began gently pushing its companion craft. To their delight, it worked! The spacecraft lowered Bumblebee’s orbit from over 100,000 km to just 332.7 km. And with a quick burn later, the tug pushed Bumblebee’s periapsis to 67.1 km- just above Eve’s atmosphere. Because of the tug’s efforts, Bumblebee had the delta-v to safely deorbit. But it would have to wait until the Relay Sat constellation was in position… With Bumblebee’s mission saved, KSPMC turned its focus back to Gilly Mapper. Trajectory analysts tried various maneuver nodes to reach Gilly Mapper but found that the tug lacked the delta-v for a rendezvous. The best that they could do is head for Gilly itself. A half-hour after completing Bumblebee’s maneuvers, Eve Nuclear Tug performed a long burn towards Eve’s only mϋn and arrived two days later, on Acama 4, 2002. Mission planners weren’t sure if their next attempt would work, but they had to try anyway. If not- well, exploring Gilly was an afterthought for the First Eve Fleet. Eve Nuclear Tug left Gilly, matched planes with it 4 days later, but it had to wait for another 194 days for the transfer burn. At least by then, the Eve RelaySat constellation would finally be in place. * As the slow-motion dance of the First Eve Fleet continued, the Ministry of Space began their launch campaign to assemble the Second Duna Fleet. First, they launched the Duna Climate Observer, a satellite bus with 6 probes designed to measure Duna’s atmosphere at various locations. Next, they launched the Duna Geo Observer- a very similar satellite bus with 6 probes designed to take gravimetric and seismic readings on Duna’s surface. Then, the Ministry of Space launched Estonian 2, a redesigned Estonian Duna Lander that applied lessons learned from its predecessor. Finally, the vonKerman Space Agency launched a refurbished leftover Schafer rover that the Ministry of Space purchased for use on Duna. The Ministry of Space had two more redesigned Duna Copter probes to launch, but they had to wait. The space agency continued its launch campaign by focusing on the propulsion elements. After evaluating the Poseidon and Neptune atomic motors and reexamining the dangerous Emancipator open-cycle engine used in the First Laythe Fleet and First Eve Fleet, the Ministry of Space settled upon a new design: the NV-GE Liberator. Though not as powerful or as fuel efficient as the Emancipator, the Liberator was significantly safer to use, and it outperformed both the Poseidon and the Neptune. And having learned from the First Duna Fleet and the challenges at Eve, the improved Interplanetary Tug was equipped with all the docking port types used in the Second Duna Fleet as well as a dedicated SAFER nuclear reactor… Starting with the Schafer rover, each vessel in the fleet received one set of engine and fuel tank modules that comprised a MoS Interplanetary Tug. Sixteen flights later, each vessel had a dedicated nuclear-powered tug. Finally, the Schafer’s tug received the redesigned Duna Copter probes. Fully assembled, all the Second Duna Fleet had to do was wait for the launch window. The Ministry of Space knew that building the Second Duna Fleet and launching them on a swath of semi-reusable rockets was likely the last time that anyone would use such a method. In the future, building large fleets and/or vessels would become the domain of orbiting shipyards, with ground launches providing resources, crew, and components that couldn’t be made in space. The Orbital Dynamics/vonKerman Space Agency shipyard provided a significant advantage to both the Kerman States and the vonKerman Republic, and if the Ministry of Space wanted to remain competitive, they’d have to build a shipyard of their own… * As the mcKermans assembled their fleet in orbit, Scott sat in the cockpit of the Finch Mϋnar Landing Research Vehicle, a research and training vehicle conceptually equivalent to the vehicle that astronauts used to practice mϋnar landings with during the Mϋnflight Program. Nicknamed Jet Finch, the FMLRV was powered by four vertically mounted Panther jet engines set in afterburner mode. The engines provided enough thrust to power the research vehicle through vertical flight. While Jet Finch’s rocket motors were inert, the vehicle’s RCS thrusters were active, and Scott used them to translate over to a nearby helipad before settling the vehicle onto the ground. With that check flight completed, he lifted into the air once again, this time to an altitude of 700 meters before descending back down again. This time, he landed on the central landing pad built during the Last War. With the testing concluded, Scott piloted Jet Finch into the air once more, this time gunning the engines, which made the craft leap into the air. The uneven jet thrust caused it to wobble around, so Scott tried to enable the atmospheric autopilot. That made the problem worse, so he just as quickly disabled it. A few panicked seconds later though, the retired Air Force test pilot’s honed skills took over, and he brought Jet Finch back under control. Using the RCS, Scott swung the craft round and flew over the admin building. Off in the distance he could see the new causeway that they’d built between Runway 090 and Runway 027. Soon they’d be tearing up and rebuilding Runway 090 to reinforce it and install cooling systems. They were also about to roll Dauntless back to the OPF for her Orbiter Maintenance Down Period as well. The modifications that they’d planned were significant, but the benefits outweighed the costs. In retrospect, he realized that they should’ve built the Mk33s with the mods in the first place. Scott then rolled Jet Finch to the right and past Hangar Row, where they’d built a second set of hangars to house Dauntless and Resolute. If things went well, Resolute would receive the same modifications as Dauntless, as would Ascension. And as he made a final loop to land on Runway 027, he thought fondly about Skyranger. The first Mk33 ever built was too old and worn out to be modified, so she sat in retirement in Hangar 1. Should they send her to the Boneyard, like the K-20 Kerbal Soar and the Space Shuttle? Was there enough that they could salvage and build into a new ship? Scott had mixed feelings about either fate. Sending her to the Boneyard to take her place in history could also give their competitors a good look at her design. Taking her apart and rebuilding her might not be practical either; their engineering staff estimated that many of its composite frames were cracked and/or delaminating, for instance, and by the time that they replaced them, they’d have a new ship. For now, Skyranger would remain in the hangar. After a quick status check, Scott lifted off once more and hopped over to the helipad that he started from. As he shut down the Jet Finch, he reflected on the meeting that he was about to attend. KAF- well, the Kerman Air Force, the Kerman Aerospace Defense Command, and the Kerbal Intelligence Agency- had a potential solution for their “Blutonium Problem...” Over a decade ago... In the post-Mϋnflight era, the Kerman States had two competing programs for the Shuttle Launch System: One publicly hyped by Kerbal Space Program, and a lesser known one by the Kerman Aerospace Defense Command. The KADC program favored a two-stage design, operated by the Kerman Air Force, with a piloted, Lindor 5-derived winged first stage booster that landed at an airfield downrange of the launch site. Both the booster and the orbiter would be 100% reusable. While the orbiter had a small payload bay for hauling cargo to a space station, for cargo flights, the KADC design replaced the orbiter with an upgraded Duna 1C upper stage and attached a pair of liquid boosters to the first stage to deliver up to 43 metric tons and/or large volume payloads into orbit. In its cargo configuration, only the side boosters and winged first stage would be recovered. Realizing that they had competition for the Shuttle Launch System, KSP’s engineers redesigned their orbiter to accommodate the large payload requirements from the KADC, which also led them down the path of using a Lindor 5-derived first stage. But as the KADC design team would later discover, engineers couldn’t solve the first stage’s reentry heating problem with the technology available, so they settled upon the familiar solid rocket boosters and external tank. With both KSP and KADC agreeing to use KSP’s Shuttle Launch System, KADC fully expected to have their own fleet of orbiters, owned, and operated by the Kerman Air Force, but politics intervened. Instead of their own orbiters, KADC received an annual allotment of SLS flights dedicated to defense missions and had top priority when a flight had extra payload capacity. In fact, SLS-3 even tested a surveillance camera for the KADC. But when KSP cancelled OV-205, the Kerman Air Force tried unsuccessfully to acquire it, and when the civilian space agency ended the Shuttle Launch System altogether, they tried to acquire their retiring fleet, but again they were thwarted. Present day... The Kerman Air Force had looked at obtaining a Block 2 orbiter or two from Drax Aerospace when SLS entered the commercial realm, but when Orbital Dynamics successfully built and launched their Mk33- and demonstrated rapid turnaround capability- the Air Force saw a possibility to at last have a space fleet of their own. And when the Kerman Intelligence Agency quietly approached them about Orbital Dynamics’ “Blutonium Problem,” they saw their path forward. The delegation from KAF, KADC, and KIA were meeting with Orbital Dynamics not just about how to get rid of their Blutonium, but to convince Scott and Sara to build them a Mk33... * Mϋnraker 1 lifted off from Pad C on Acama 13, 2002, carrying a record 3 crew and 33 passengers in a heavily modified passenger airplane cabin. Four hours later, the Block 2 orbiter approached and docked with the Drax Space Hotel. As the first guests to the hotel, they were treated to a welcome celebration. A few days later, the orbiter departed from the hotel and returned to KSC at sundown. Mϋnraker 1 performed flawlessly, making a textbook landing, but its days were numbered. At long last, Sunraker was ready to fly.

Ok, I got the files. I'll try to look at this over the weekend.

Today I finished the weathering on the tailgate ramp, and created the "cargo" variant. As you can see, the new variant works with any of the body modules, not just the upcoming cargo bays: The next part is the Buffalo 2 Command Module. After that, I can finally produce an alpha release.

Unfortunately I've been pretty overwhelmed this week. I'll try to get to this over the weekend.

I made some good progress today, the B2 Tailgate is almost halfway done: Once I finish weathering the inside portion, the first tailgate model will be done. Then I need to make a variant for the straight up and down body modules.

I'd definitely need steps to reproduce this, including build of the craft, mods, etc.

I created a promo for one of Buffalo 2's new parts: Essentially it lets you convert Power Units to Electric Charge and vice-versa.

Did ETS ever go to Mars? If not, it would also be great to see that too! In the meantime, I look forward to the visualization of the ETS missions to the moon.