kerbal ftl [Min KSP 1.12.2] Blueshift: Kerbal FTL

[redivh]

2 hours ago, Angel-125 said:

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:

This fixed all the issues I had! 

I did notice another small issue though, when I get close to a targeted star or planet it stops targeting it and I'm unable to re-target it.

Edited February 10, 2021 by redivh

[Angelo Kerman]

7 minutes ago, redivh said:

This fixed all the issues I had! 

I just noticed another small issue, when I get close to a targeted star or planet it stops targeting it and I'm unable to re-target it.

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.

[woeller]

This is normal stock behavior. You cannot choose a celestial body as a target in whose SOI you are.

[redivh]

Oh, I didn't realize that's normal. 

[Angelo Kerman]

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.

[Spaceman.Spiff]

Just now, Angel-125 said:

here is the Blueshift 1.0 release!

Congrats mate!

[Quoniam Kerman]

Possibility to make tubular warp nacelles?

Hell yes, at least good looking Star Trek style ships are now possible...

[redivh]

1 hour ago, Angel-125 said:

here is the Blueshift 1.0 release!

Great! 

[Angelo Kerman]

1 hour ago, Quoniam Kerman said:

Possibility to make tubular warp nacelles?

Hell yes, at least good looking Star Trek style ships are now possible...

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

[Spaceman.Spiff]

Angel

Do the fusion reactors use CRP resources (He3 Deuterium) or WBI ones?

[modus]

Looks very cool, congrats.

It says ksp 1.11 min. Does that mean it won't work on, let's say, 1.10.1, or that it's not supported?

[Angelo Kerman]

2 minutes ago, Spaceman.Spiff said:

Angel

Do the fusion reactors use CRP resources (He3 Deuterium) or WBI ones?

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.

[Spaceman.Spiff]

1 minute ago, Angel-125 said:

WBI Fusion Pellets

Ok

Maybe I'll take a crack at CRP configs for those who want them to mesh with FFT and others a bit better.

Don't expect much  I am quite unknowledgeable.

[Angelo Kerman]

9 minutes ago, modus said:

Looks very cool, congrats.

It says ksp 1.11 min. Does that mean it won't work on, let's say, 1.10.1, or that it's not supported?

Not supported. It should work but no guarantees.

[JadeOfMaar]

@Spaceman.Spiff Fusion Pellets exist in Classic Stock and CRP. There should be no need to create "CRP configs" and "FFT compatibility" for this mod.

[Spaceman.Spiff]

23 minutes ago, JadeOfMaar said:

"FFT compatibility"

I wasn't saying it was incompatible, but if someone wants to use on of the FFT engines and one of these reactors, they would need two different fuel types. That's all I was saying. It's not really a big deal

[AccidentalDisassembly]

This is VERY COOL. I do have one suggestion regarding warp rates - is it possible to alter whatever check/equation is determining current maximum warp speed in order to make a smoother 'ramp up' of max warp speed based on distance from a body/star/sphere around a barycenter/whatever? As it is at the moment, the instantaneous jump to 1000x warp speed at the boundary between planetary/interplanetary/interstellar is a bit jarring, and if you're pointing in sliiiiightly the wrong direction when you hit the boundary... zoom!

Is there any way of doing something like: Current max warp speed = max ship warp speed / 1000 * number of arbitrary useful distance units (1M km? 1B?) between ship and nearest celestial body" or similar? Or is it too expensive to calculate something like that?

EDIT: Also, just out of curiosity - graviolium is consumed by engines when not actively warping, and rate of consumption does not seem to change when warping at 3000c vs. 3c - is this as intended?

EDIT 2: Second suggestion - the auto-circularize feature is very handy, but not easy to use; can it be made a PAW menu button or similar ("circularize now for X graviolium"), as opposed to a setting in difficulty stuff?

Edited February 11, 2021 by AccidentalDisassembly

[CDSlice]

1 hour ago, JadeOfMaar said:

Fusion Pellets exist in Classic Stock 

Fusion pellets are in stock KSP? When did that happen?

[JadeOfMaar]

@CDSlice No. "Classic" Stock, WBI's alternative (to CRP) resource library.

@AccidentalDisassembly Perhaps a simple gradual ramp up (easing on/off of the brake) is the solution. The change in warp speed is applied over (at most) a 3 second span when entering or leaving an interstellar situation, and 1 or 2 seconds when interplanetary.

The auto-circularize is a cheat, and I'm sure most users won't be concerned. By definition (being a cheat) it shouldn't be so easy to reach. But when it is indeed enabled, it would make sense to have a PAW button, most likely in the style of a mode toggle.

@Spaceman.Spiff Okay. I'm not making it a big deal. From my brief play with a pre-release version, I'm aware of an Auxiliary Power generator in them so they do (and should still have) the ability to produce EC in bulk. Angel has very much an engineer's mind, so he would have a solid vision of what his power sources should be capable of. You should ask him. I'm interested in seeing that answer. ...I just remembered. Omniconverters. The best thing to consider doing is writing Omniconverter templates so that any WBI switchable converter can use FFT resource chains.

[Angelo Kerman]

1 hour ago, AccidentalDisassembly said:

This is VERY COOL. I do have one suggestion regarding warp rates - is it possible to alter whatever check/equation is determining current maximum warp speed in order to make a smoother 'ramp up' of max warp speed based on distance from a body/star/sphere around a barycenter/whatever? As it is at the moment, the instantaneous jump to 1000x warp speed at the boundary between planetary/interplanetary/interstellar is a bit jarring, and if you're pointing in sliiiiightly the wrong direction when you hit the boundary... zoom!

Is there any way of doing something like: Current max warp speed = max ship warp speed / 1000 * number of arbitrary useful distance units (1M km? 1B?) between ship and nearest celestial body" or similar? Or is it too expensive to calculate something like that?

EDIT: Also, just out of curiosity - graviolium is consumed by engines when not actively warping, and rate of consumption does not seem to change when warping at 3000c vs. 3c - is this as intended?

EDIT 2: Second suggestion - the auto-circularize feature is very handy, but not easy to use; can it be made a PAW menu button or similar ("circularize now for X graviolium"), as opposed to a setting in difficulty stuff?

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?

2 hours ago, Spaceman.Spiff said:

I wasn't saying it was incompatible, but if someone wants to use on of the FFT engines and one of these reactors, they would need two different fuel types. That's all I was saying. It's not really a big deal

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.

[Spaceman.Spiff]

6 minutes ago, Angel-125 said:

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.

IMO the included FFT and SD patches are nice; the mod works just fine without them, but they provide an extra utility.

[BrobDingnag]

Holy cow, you've successfully modeled the gravdrag system that Larry Niven used in his stories. I'm definitely using your FTL system over the others that are available.

[vardicd]

Didn't my install already have enough mods? Now I have to add another one? Glorious warp drives... 

[AccidentalDisassembly]

1 hour ago, Angel-125 said:

For your first question, it's not easy to calculate the edge of interstellar space in some cases.  ...

Is it possible to calculate distance to the nearest object instead, or something along those lines? For me, anyway, from a gameplay perspective, it would be pretty cool to have maximum speed be more variable - in a specific sense, though. If it's possible to somehow get 'nearest celestial', then perhaps it would be possible to make it so that the further you are from any body, the faster you can go; if you go straight up from the plane of the ecliptic in a system, you'd be able to gain speed pretty fast (as opposed to potentially going near planets in the plane), that kind of thing.

If it's not possible to do that easily, and if right now the speed is just based on "SOI type" and updates when SOI is updated, is it possible to vary the speed based on distance from the central point of the SOI? So that, for instance, if you transition into the Jool SOI, you can move faster near the edge of the SOI than at the center... which would be somewhat similar in effect to a continuously variable max speed.

Likewise, the acceleration / deceleration effect would be taken care of implicitly if max speed were a function of distance from the center of an SOI (assuming that's even possible).

I dunno, just kind of throwing out some random thoughts, with possibly very little basis in what's practicable.

Quote

the continual consumption of Graviolium as the cost of producing the Gravity Waves needed to keep your warp engines on hot standby.

Makes sense, thanks! Just have to remember to shut down the engine if I'm not using it. Easy enough.

Quote

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?

The problem (in my mind) is multi-part, but it boils down to: difficulty settings take many clicks to turn on and off, aren't 'visible' (mentally or literally on the screen), and this specific feature is something that would be easier to use with an active 'circularize now'. For instance:

1. You arrive near a planet, but don't want to circularize yet, because maybe you want to get to a different altitude than the one you happened to cut throttle at, or ... whatever reason. The option was on in the settings, you forgot; goodbye graviolium.

2. You turn the option off in the settings, maneuver a little bit to where you want, then want to circularize: back into the difficulty settings to turn the option on.

3. You do some kind of landing using a small craft, get some science, forget you have auto-circularize on; now you're off to the next body: oops, auto-circularize again when you didn't want to circularize yet, goodbye graviolium.

Now you have to go through the steps of changing the difficulty setting, doing a maneuver, turning the difficulty setting off again, then turning it on again when you want to circularize... it is far simpler, faster, and more intuitive from a gameplay perspective (and much more predictable!) to simply have a button - this also prevents guesswork like "at what altitude does auto-circularize kick in for this body? is it safe to stop at 5,000km alt and reorient for a maneuver, or do I need to turn the setting off, then back on...?

Hopefully that makes any sense at all!

 

 

[Angelo Kerman]

5 minutes ago, AccidentalDisassembly said:

Is it possible to calculate distance to the nearest object instead, or something along those lines? For me, anyway, from a gameplay perspective, it would be pretty cool to have maximum speed be more variable - in a specific sense, though. If it's possible to somehow get 'nearest celestial', then perhaps it would be possible to make it so that the further you are from any body, the faster you can go; if you go straight up from the plane of the ecliptic in a system, you'd be able to gain speed pretty fast (as opposed to potentially going near planets in the plane), that kind of thing.

If it's not possible to do that easily, and if right now the speed is just based on "SOI type" and updates when SOI is updated, is it possible to vary the speed based on distance from the central point of the SOI? So that, for instance, if you transition into the Jool SOI, you can move faster near the edge of the SOI than at the center... which would be somewhat similar in effect to a continuously variable max speed.

Likewise, the acceleration / deceleration effect would be taken care of implicitly if max speed were a function of distance from the center of an SOI (assuming that's even possible).

I dunno, just kind of throwing out some random thoughts, with possibly very little basis in what's practicable.

Makes sense, thanks! Just have to remember to shut down the engine if I'm not using it. Easy enough.

The problem (in my mind) is multi-part, but it boils down to: difficulty settings take many clicks to turn on and off, aren't 'visible' (mentally or literally on the screen), and this specific feature is something that would be easier to use with an active 'circularize now'. For instance:

1. You arrive near a planet, but don't want to circularize yet, because maybe you want to get to a different altitude than the one you happened to cut throttle at, or ... whatever reason. The option was on in the settings, you forgot; goodbye graviolium.

2. You turn the option off in the settings, maneuver a little bit to where you want, then want to circularize: back into the difficulty settings to turn the option on.

3. You do some kind of landing using a small craft, get some science, forget you have auto-circularize on; now you're off to the next body: oops, auto-circularize again when you didn't want to circularize yet, goodbye graviolium.

Now you have to go through the steps of changing the difficulty setting, doing a maneuver, turning the difficulty setting off again, then turning it on again when you want to circularize... it is far simpler, faster, and more intuitive from a gameplay perspective (and much more predictable!) to simply have a button - this also prevents guesswork like "at what altitude does auto-circularize kick in for this body? is it safe to stop at 5,000km alt and reorient for a maneuver, or do I need to turn the setting off, then back on...?

Hopefully that makes any sense at all!

 

 

For your example of Jool SOI, Blueshift does that already. When you enter a planetary SOI, your speed is reduced based on your altitude. The further out you are from the planet/moon, the faster you can go. Within interplanetary space, you have no such speed restriction. In fact, the resource consumption assumes interplanetary space. For interstellar space, trying to determine how fast you go based on distance from the nearest star can get tricky- especially when you have many stars to check like you do with GU. Every game update I'd have to check each star and figure out which is closest and then vary speed, and that would be a performance hit.

The way it is now, I just need to check the vessel's parent body (ships always orbit something) and look up its SOI radius. If the celestial body has an SOI, then I look at the altitude to see if the vessel is in interstellar space or not. If the celestial body has no SOI (technically barycenters do, and they were the cause of ships slowing down light-years from nearby stars), then I know that the ship is definitely in interstellar space. Those checks are quick and easy to make.

Since I know when a vessel transitions from interplanetary to interstellar and vice versa, I know when to apply the speed multiplier. For the next update, I'll add an acceleration of sorts so that you're not instantly flying along at interstellar speed. That should give players a chance to slow down if they miss their target.

 

For the auto-circularization, I see your perspective. I'm not too worried about the steps needed to enable/disable the ability to circularize, but I can add a PAW button to manually circularize if that option is enabled.