kerbal ftl [Min KSP 1.12.2] Blueshift: Kerbal FTL

[Ooglak Kerman]

Now.. off to some place close and easy.  Bop!  Compared to Hale, Bop is just super easy.  But made more difficult by trying to land at the dead Kraken.  I managed 1.6KM away.

The first pic is the landing site.  The blob to the right of the command pod is the Kraken

Spoiler

Jeb then took a quick EVA on over to have a look at the great nemesis.  Awww.  his eye fell off.

Spoiler

Then over to check out a strange pile near the Kraken.  I think it's Kraken poop.

Spoiler

These things are all incredibly easy to get to the neighborhood of, but then pretty darn hard to actually get the final few KM.

Total in-game time - 4hrs and change.  Most spent in Bop orbit and landing.

The timeframe of all of this is very compressed, but the overall difficulty level is about the same.  It's particularly tough for me because I've leaned on Mechjeb for most all the things in the past and now I have to do it by hand.  Oh how I envy those who make it look so easy.

Edited April 25, 2022 by Ooglak Kerman

[Revilo2601]

Landing on a planet or moon (without atmosphere) I have found an easy solution for me. Having trajectories, kerbal engineer I can set my landing spot rather simple. The trick for landing is to bring retro to surface, target and radial out on one line. Now when you burn put the nav ball between radial out and retro to surface and you can jiggle the speed down by maintaining your landing spot. Simply move your marker on the nav ball to radial out, when your spot comes to near, closer to retro when it goes too far away.

However I wasn't able to find some easy solution for atmospheric re-entry 

Edited April 26, 2022 by Revilo2601

[Ooglak Kerman]

7 hours ago, Revilo2601 said:

Landing on a planet or moon (without atmosphere) I have found an easy solution for me. Having trajectories, kerbal engineer I can set my landing spot rather simple. The trick for landing is to bring retro to surface, target and radial out on one line. Now when you burn put the nav ball between radial out and retro to surface and you can jiggle the speed down by maintaining your landing spot. Simply move your marker on the nav ball to radial out, when your spot comes to near, closer to retro when it goes too far away.

However I wasn't able to find some easy solution for atmospheric re-entry 

Is that landing with the Gravatic engine? 
I just got the trajectories mod and am learning it.  I'm paying the price for leaning on Mechjeb for so long.

[Clancythecat]

Honestly, i think it's balanced that mechjeb can't use the gravitic engines and warp drives, it's like the technology is so advanced that the normal auto pilot doesn't understand it.

[Revilo2601]

Well wasn't able to use gravitic engines by now, though if I get the concept right, the engine provides acceleration and not thrust. But that actually doesn't matter because in any case you are reducing your horizontal and vertical speed, depending on the angle (marker position on the nav ball). So in theory it shouldn't matter if it is a good ol' chem rocket, or a gravitic engine.

Just try my system for once ^^

[Rakete]

On 4/25/2022 at 12:07 AM, Rakete said:

Craft: See here for download: https://www.filemail.com/d/zvceznxosbhdxux

As simple as possible: only stock, blueshift and a required Liquid Deuterium (from Far Future Tech by Nertea) tank as it is required to run the warpdrive.

 

Needed Mods: Nerteas Far future mod (my other mods are only visual: Waterfall, eve, spectra). further nertea mods (Near future Suite, Spacedust, Systemheat, dynamic battery storage, cryo tanks, cryo engines, kerbal atomics, deployable engines, SSPXr etc.) are also installed in my install, but should not have any effect on your plugin, I guess. I use the full cabinet of Nerteas Mods (except Restock/Restock+)

Steps to reproduce: Take the vessel out of Kerbins SOI into a solar orbit of Kerbins Stock Solar system. Set e.g jool as target, set SAS on target mode (pointing to jool)

The vessel has 8 s1 coils, which should not eat all of the s2 core's waves (demand 40, generstion 150)

1. Activate only one coil, watch the maximum warp factor, set throttle to 100% )do not change it in the following steps. Turn up your audio output.

2. Activate a second coil, watch the maximum warpfactor. 

Step 3 to 9. Activate further coils and watch the maximum possible warp factor with each activation (it does not increase with every activated coil. It goes up/down/oscillates/flickers). At some point in the coils switching on process, the sounds starts to makes bumpy sounds (ksps flameout sound, but crippled to only being cracking sounds).,the warp factor calculations show flickering/fast oscillating results. If it does not, throttle down to 0% and re-accelerate.

10. Activate the additional displacement generator: The sound disturbances and the max. Warp factor oscillations are gone, the ugly test rig ship now goes much (!) faster (which it shouldn't, as the s2 warp core should generate 150 waves/s and the 8 coils should only need 8x 5 waves (so... 40) .. so it should be more than enough waves without the additional generator active. Interestingly this does not happen in Kerbins SOI. I guess there is some stepsize issue in the simulation causing oscillation in the internal calculations of the warp system supply values (waves or warp capabilities). This causes sound symptomes (KSPs flameout sound crippled to bumpy cracks), weird behaviour in terms of change in max warpspeed if you de/activate further coils, and a ride with weird warpvelocity changes (depending on the grade of oscillations). Adding a (not needed) s2 displacement generator solves the issue, but it should not be needed according to the part values in terms of produced and consumed gravitic waves.

The issue occurs when you have a ship with a multitude of small coils in a Kerbol Orbit. It did nit occur e.g. with a single bigger S2 coil

@Angel-125: Please let me know, if you haven't had the time to download the vehicle for reproduction of the issue (so that I will upload it again), since the download is only available for 7 days, because it's free. 

May I ask most politely and nicely, if it is possible to provide a fix/more robust calculation algorithm in the next iteration of Blueshift? (Sorry for any possible misunderstandings, I am no native english speaker).

Edited April 28, 2022 by Rakete

[Angelo Kerman]

36 minutes ago, Rakete said:

@Angel-125: Please let me know, if you haven't had the time to download the vehicle for reproduction of the issue (so that I will upload it again), since the download is only available for 7 days, because it's free. 

May I ask most politely and nicely, if it is possible to provide a fix/more robust calculation algorithm in the next iteration of Blueshift? (Sorry for any possible misunderstandings, I am no native english speaker).

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

[Ooglak Kerman]

Ran into an interesting - read PANIC - thing with the alien saucer that is now Jebs Orbital Bar and Grill.  Docked a warp tour ship that has gravatic to it.  Shifted away to something else and came back.  It was like the saucer was trying to warp away - looping.  I had an earlier save before the dockup and redocked.  Same behavior.  I'll try to narrow it down this weekend to potential causes.  I've had a number of other warp and non-warp ships docked to it that didn't exhibit that behavior, but none had gravatic.  Stay tuned.

Hoping it'll just be one of those kraken things.

[Angelo Kerman]

On 4/28/2022 at 1:02 PM, Rakete said:

@Angel-125: Please let me know, if you haven't had the time to download the vehicle for reproduction of the issue (so that I will upload it again), since the download is only available for 7 days, because it's free. 

May I ask most politely and nicely, if it is possible to provide a fix/more robust calculation algorithm in the next iteration of Blueshift? (Sorry for any possible misunderstandings, I am no native english speaker).

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

[Ooglak Kerman]

It appears that the issue I was having with the Jebs B&G saucer trying to flying away is definitely some wierd issue with the 12-kerbal tour ship when it's docked to the B&G.  I can reliably reproduce the issue with that ship but no others. It manifests when I dock, close the game, come back, and select on the B&G.  Tried ships with warp engines but no gravatic.  Warp with Gravatic.  Gravatic with no warp.  Plain ol chem rockets.   Doncha just love the vaguarities of the physics engine in this game?  Of course, that saucer is so heavily modified now with extra parts.  Who knows.

This will be interesting once I put Jebs Orbital Sculpture Garden together.

Note to self: quick saves!

Solution:  The 12-kerbal warp tour ship is banned from the B&G.  But now... after a week of the merger with the company who acquired the one I was with..  I am spent.

Edited April 30, 2022 by Ooglak Kerman

[Ooglak Kerman]

I have discovered how much mass is too much for an S2 Warp Core and S2 Warp Coil.  My Jool Warp Refueler just would not budge until I dumped enough liquid fuel/oxy.  The upside was that entering the SOI of Vall lacked any drama whatsoever.  It was originally sent to Jool as a depot and without any but the minimum of liquid resources and then fueled for "eventualities".

It looks like the capacity of the bigger warp coils/rings goes up very quickly.  Reiterating the necessity to balance this capacity with ship mass.  It's super easy to have a warp ship that is just too fast to do anything with.  Or one that will take <gasp> 15 minutes to get to Jool SOI from Kerbin.

Did I record this vital data?  Of course not.  Document code?  Why do you think we call it code?

Spoiler

 

Edited May 3, 2022 by Ooglak Kerman

[Angelo Kerman]

On 4/28/2022 at 1:02 PM, Rakete said:

@Angel-125: Please let me know, if you haven't had the time to download the vehicle for reproduction of the issue (so that I will upload it again), since the download is only available for 7 days, because it's free. 

May I ask most politely and nicely, if it is possible to provide a fix/more robust calculation algorithm in the next iteration of Blueshift? (Sorry for any possible misunderstandings, I am no native english speaker).

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.

[Ooglak Kerman]

58 minutes ago, Angel-125 said:

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.

That there is an impressive feat of investigation.  You are truely a Eng-6 "Scotty+".  Warp and Gravatic systems are impressed and work efficiently around you.   Lower level Engineers wax your car and take up a collection to keep it full of fuel.  Sci-5s come to you for advice.  Pilot-5s ask you for directions.  You show the League Of Smart Technologists the way.

Seriously though.  Good sleuthing.  I have wondered a bit at how all that interaction happens.

Edited May 4, 2022 by Ooglak Kerman

[Angelo Kerman]

15 minutes ago, Ooglak Kerman said:

You are truely a Eng-6 "Scotty+".  Warp and Gravatic systems are impressed and work efficiently around you.   Lower level Engineers wax your car and take up a collection to keep it full of fuel.  Sci-5s come to you for advice.  Pilot-5s ask you for directions.  You show the League Of Smart Technologists the way.

See: Miracle Worker.

[Ooglak Kerman]

I might just have to write you into my story.  The legendary, semi-mythical Angelo Kerman.  He lives in the mountains to the west of the KSC in a fortress of wonderful wonders where he creates technologies that make others wonder... "How DOES he do that?"  Hmm..  possibilities...

29 minutes ago, Angel-125 said:

See: Miracle Worker.

See: Sysadmin at a startup

[Rakete]

16 hours ago, Angel-125 said:

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.

Hope you get well soon. I wish you all the best! @Angel-125

 

Impressive analysis. This is kinda what I had guessed. Mhhh... Since this is a getting out of sync issue, could this be maybe fixed by adding a gravitywave buffer to the parts as an invisible resource container? In a way, that out-of-sync moments are fed from the gravitywave buffer, if there are not enough waves from the core? (This would require the out-of-sync moments not being in a way, that whole wave generation loops are skipped in relation to their consumption, draining the buffer over time.) The idea is to buffer a fluctuating generation and a fluctuation consumption (which are in balance in an averaged calculation - or even better with an overproduction). Meaning, as long as the generator produces more waves, than are consumed, the buffer may cope with this KSP-simulation-increment generated fluctuation. Like you can smoothen the residual waves in a DC voltage with a capacitor (sorry, real life electrical dev. engineer...) after generating them out of AC.... Maybe a wave storage of 10x of the amount the generated waves/s of a core added to each warp core/generator config will do?

What do you think? Could be a temporary fix, which would generate less fixing work instead of redesigning the whole mechanism. Is this a valid idea? Unpleasent side effect could be, that you could ride the vehicle after shuting down the core as long as there are still enough waves stored. But would be a minor issue to me.

 

Sidenote: for the KSP simulation step issues of electrical charges @Nertea has done some impressive work with his dynamic battery storage Mod, which stabilizes the generation/consumption in relation to KSPs simulation algorithm. Maybe this can be an inspiration or synergy source if you may find the time to attack the root issue.

 

Edited May 4, 2022 by Rakete

[Angelo Kerman]

10 hours ago, Rakete said:

Hope you get well soon. I wish you all the best! @Angel-125

 

Impressive analysis. This is kinda what I had guessed. Mhhh... Since this is a getting out of sync issue, could this be maybe fixed by adding a gravitywave buffer to the parts as an invisible resource container? In a way, that out-of-sync moments are fed from the gravitywave buffer, if there are not enough waves from the core? (This would require the out-of-sync moments not being in a way, that whole wave generation loops are skipped in relation to their consumption, draining the buffer over time.) The idea is to buffer a fluctuating generation and a fluctuation consumption (which are in balance in an averaged calculation - or even better with an overproduction). Meaning, as long as the generator produces more waves, than are consumed, the buffer may cope with this KSP-simulation-increment generated fluctuation. Like you can smoothen the residual waves in a DC voltage with a capacitor (sorry, real life electrical dev. engineer...) after generating them out of AC.... Maybe a wave storage of 10x of the amount the generated waves/s of a core added to each warp core/generator config will do?

What do you think? Could be a temporary fix, which would generate less fixing work instead of redesigning the whole mechanism. Is this a valid idea? Unpleasent side effect could be, that you could ride the vehicle after shuting down the core as long as there are still enough waves stored. But would be a minor issue to me.

 

Sidenote: for the KSP simulation step issues of electrical charges @Nertea has done some impressive work with his dynamic battery storage Mod, which stabilizes the generation/consumption in relation to KSPs simulation algorithm. Maybe this can be an inspiration or synergy source if you may find the time to attack the root issue.

 

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.

[Rakete]

2 hours ago, Angel-125 said:

that players will forget using to prevent the oscillations from happening, and complain about the problem

I didn't mean to complain. Sorry, if i sounded impolite, as english is not my native language. Sorry if I did so. I just thought, these informations might help you to make this great mod even better.

Somehow I am not sure if I understand, what you are going to do there, but it sounds very good. 

So there will be an overcharge button, which results in faster speed but more likely oscillations/stutterings and a not-overcharge setting, which will lead to slower speeds but more stable behavior? Seems logical. Go fast and maybe become instable or choose the stable conservative flight profile. Makes sense for me.  If i understood it wrong, correct me if you like.

Does this have effects on the design rules for a warp ship the player should know? Will the PAW maxWarpspeedprediction in the VAB consider the new setting option?

 

Thank you so much for your efforts in providing great mods for KSP !! This can't be said enough.

Warp Engineering is complicated. Zephram Cochrane would be proud... 

 

(Song of the day: Roy Orbison - Ooby Dooby... a glass of booze for all the guys who get the joke. )

And when the oscillations are gone: Steppenwolf - Magic carpet ride...because.... eeehm... you know, a warp engineer can't start up a warpship without it. sorry, too many movie references

Edited May 4, 2022 by Rakete

[Angelo Kerman]

25 minutes ago, Rakete said:

I didn't mean to complain. Sorry, if i sounded impolite, as english is not my native language. Sorry if I did so. I just thought, these informations might help you to make this great mod even better.

Somehow I am not sure if I understand, what you are going to do there, but it sounds very good. 

So there will be an overcharge button, which results in faster speed but more likely oscillations/stutterings and a not-overcharge setting, which will lead to slower speeds but more stable behavior? Seems logical. Go fast and maybe become instable or choose the stable conservative flight profile. Makes sense for me.  If i understood it wrong, correct me if you like.

Does this have effects on the design rules for a warp ship the player should know? Will the PAW maxWarpspeedprediction in the VAB consider the new setting option?

 

Thank you so much for your efforts in providing great mods for KSP !! This can't be said enough.

Warp Engineering is complicated. Zephram Cochrane would be proud... 

 

(Song of the day: Roy Orbison - Ooby Dooby... a glass of booze for all the guys who get the joke. )

And when the oscillations are gone: Steppenwolf - Magic carpet ride...because.... eeehm... you know, a warp engineer can't start up a warpship without it. sorry, too many movie references

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.

[Rakete]

14 minutes ago, Angel-125 said:

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.

Solved for my demonstration build is good progress marker. I am impressed of your speed. Wow! Yeah, this ugly testbuild was just a testbed to learn the basic mechanics of your mod. Somehow i tend to find bugs in such very ugly testrigs. I really got on nerteas nerves with all my bugreports, but in the end, it all turned out good.   

If the powermultiplier is below 1, can a ship then still go faster than c? Or will not overcharging affect the warp capability in general?

Good night for today, as it is here right after midnight. 

 

 

 

Edited May 4, 2022 by Rakete

[Angelo Kerman]

1 hour ago, Rakete said:

Solved for my demonstration build is good progress marker. I am impressed of your speed. Wow! Yeah, this ugly testbuild was just a testbed to learn the basic mechanics of your mod. Somehow i tend to find bugs in such very ugly testrigs. I really got on nerteas nerves with all my bugreports, but in the end, it all turned out good.   

If the powermultiplier is below 1, can a ship then still go faster than c? Or will not overcharging affect the warp capability in general?

Good night for today, as it is here right after midnight. 

 

 

 

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.

[Ooglak Kerman]

58 minutes ago, Angel-125 said:

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.

I would argue that underpowered is kind of relative.  For something like a resource tanker, I've found that 0.5C capability when interplanetary is kind of the sweet spot.  It can make a 360 around Kerbin in a 1200KM orbit in around a minute with no drama and rendezvous are a snap. 

Things that can go more than about 5C interplanetary can be super difficult to throttle back enough to make rendezvous or do an encounter with a small SOI body without lots of drama.  That last one is where the gravatic really shines.  Except for getting to the general area, a well powered warp engine isn't a big help for things like Gilly, or especially Hale or Ovok (Sarnus system).

Going mobbing from one side of the Kerbol system to the other in a few minutes also doesn't give you the chance to admire the scenery along the way. 

[Angelo Kerman]

5 hours ago, Ooglak Kerman said:

I would argue that underpowered is kind of relative.  For something like a resource tanker, I've found that 0.5C capability when interplanetary is kind of the sweet spot.  It can make a 360 around Kerbin in a 1200KM orbit in around a minute with no drama and rendezvous are a snap. 

Things that can go more than about 5C interplanetary can be super difficult to throttle back enough to make rendezvous or do an encounter with a small SOI body without lots of drama.  That last one is where the gravatic really shines.  Except for getting to the general area, a well powered warp engine isn't a big help for things like Gilly, or especially Hale or Ovok (Sarnus system).

Going mobbing from one side of the Kerbol system to the other in a few minutes also doesn't give you the chance to admire the scenery along the way. 

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.

[modus]

1 hour ago, Angel-125 said:

Using the Thrust Limiter can also help when you're interplanetary. Just like with regular engines, thrust limiter will help limit your warp speed.

Yes, I learnt that the hard way.

For 'short' hops, let's say to Duna or Jool, I always set the trust limiter to 50% or less.

[Rakete]

5 hours ago, Angel-125 said:

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.

This sounds great. We have a saying in german: translated literally it would say "I draw a my hat" to your programming/fixing skills. Maybe it doesn't make sense in english, but let's just say I am very impressed how fast you dig through the issue. 

Does this solution also work with multiple displacement wave generator setups like a warp core and also a wave generator in case of bigger vessels? Do they all sync with each other?

Edited May 5, 2022 by Rakete