kerbal ftl [Min KSP 1.12.2] Blueshift: Kerbal FTL

[Rakete]

9 hours ago, Angelo Kerman said:

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.

Happy New Year, dear god of most kerbally warpdrives

(i really love your mod(s)).

 

 

 

Will this be a compatible change, or will have all existing crafts, that use warpcoils already have to be adjusted to keep their look and functionality ? (in other words, will the new multi-length coils be technically new parts while keeping the old deprecated ones in the folders to be found by older crafts? 

Especially warp-sstos have a hard time balancing Center of mass things for full and empty states, so it would be nice, if the old parts could still be found in the files (maybe just hidden from the VAB/SPH to be not placed anymore on new vehicles)

 

While you are planning a new Blueshift release, could you maybe have a look at the reason why some actions can only be assigned to actiongroups while in flight and not in the VAB? e.g. the aux displ. wave generators can not get their toggling assigned to an actiongroup while building. It can only be assigned to an AG while in flight. Thats kinda odd. Can I repair it myself by editing the config? If so, what so I have to change, to repair it myself?

 

 

 

P.s.: Excelsiorclass-Warpcoils should promiss transwarp. And not fullfil that promiss 

Edited January 2 by Rakete

[Angelo Kerman]

4 hours ago, Rakete said:

Happy New Year, dear god of most kerbally warpdrives

(i really love your mod(s)).

 

 

 

Will this be a compatible change, or will have all existing crafts, that use warpcoils already have to be adjusted to keep their look and functionality ? (in other words, will the new multi-length coils be technically new parts while keeping the old deprecated ones in the folders to be found by older crafts? 

Especially warp-sstos have a hard time balancing Center of mass things for full and empty states, so it would be nice, if the old parts could still be found in the files (maybe just hidden from the VAB/SPH to be not placed anymore on new vehicles)

 

While you are planning a new Blueshift release, could you maybe have a look at the reason why some actions can only be assigned to actiongroups while in flight and not in the VAB? e.g. the aux displ. wave generators can not get their toggling assigned to an actiongroup while building. It can only be assigned to an AG while in flight. Thats kinda odd. Can I repair it myself by editing the config? If so, what so I have to change, to repair it myself?

 

 

 

P.s.: Excelsiorclass-Warpcoils should promiss transwarp. And not fullfil that promiss 

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.

[Rakete]

@Angelo Kerman I noticed that Blueshift has issues in detecting the active vessel being in interstellar space, remaining in interplanetary mode while using the REX planet pack:

I went halfway to another star, but blueshift stills shows interplanetary as spatial position , thus not enabling the muxh higher interplanetary speed limits.

 

[RayneCloud]

Welcome back to it and happy new year, please take your time and focus on your own health and well being first. I wont speak for everyone, but I am glad to have you back at it @Angelo Kerman Thanks for the best FTL mod in KSP. <3

[Angelo Kerman]

23 hours ago, Rakete said:

@Angelo Kerman I noticed that Blueshift has issues in detecting the active vessel being in interstellar space, remaining in interplanetary mode while using the REX planet pack:

I went halfway to another star, but blueshift stills shows interplanetary as spatial position , thus not enabling the muxh higher interplanetary speed limits.

 

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.

12 hours ago, RayneCloud said:

Welcome back to it and happy new year, please take your time and focus on your own health and well being first. I wont speak for everyone, but I am glad to have you back at it @Angelo Kerman Thanks for the best FTL mod in KSP. <3

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.

[Angelo Kerman]

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.

[Rakete]

7 hours ago, Angelo Kerman said:

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.

Sounds great!

 

Before the next BS-release you might also want to have a look on the gravi-usage of the S3 heavy sustainer it uses 0,02 gravi /s (according to the part description in VAB) meaning 7,2 gravi /h where all other S3 parts are at 36 gravi / h. I guess you meant 72 gravi / h for the heavy sustainer? I can only speculate, that the low value is unintentional.

On 1/3/2024 at 10:18 PM, Angelo Kerman said:

On 1/2/2024 at 10:34 PM, Rakete said:

@Angelo Kerman I noticed that Blueshift has issues in detecting the active vessel being in interstellar space, remaining in interplanetary mode while using the REX planet pack:

I went halfway to another star, but blueshift stills shows interplanetary as spatial position , thus not enabling the muxh higher interplanetary speed limits.

 

Expand  

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.

How can I do that? I'd e.g. aim for Kerbols SOI being twice the size of the orbit of the farest planet (for me Plock, since I use OPM). What do I have to edit?

Offtopic: I you are in the mood for bew BS parts,... maybe a S1 Warpcore and S0 coils would be funny for little warp-capable vessel that start from a bigger mothership. Just an idea if you should be in the mood for new parts. 

Also an idea to go even bigger like Nerteas NF - Launch vehicles mod, thar come with 5m and 7m parts. Such super heavy and super expensive warpdrives might be capbleable of ferrying supergate-parts over to another solar system (Somehow the generarion of alien gates does not seem to work for me. Probably the same reason with REX as on the interstellar speed issue).

Edited January 5 by Rakete

[Angelo Kerman]

First pre-release of the latest Blueshift: https://github.com/Angel-125/Blueshift/releases/tag/v1.10.0

3 hours ago, Rakete said:

Sounds great!

 

Before the next BS-release you might also want to have a look on the gravi-usage of the S3 heavy sustainer it uses 0,02 gravi /s (according to the part description in VAB) meaning 7,2 gravi /h where all other S3 parts are at 36 gravi / h. I guess you meant 72 gravi / h for the heavy sustainer? I can only speculate, that the low value is unintentional.

How can I do that? I'd e.g. aim for Kerbols SOI being twice the size of the orbit of the farest planet (for me Plock, since I use OPM). What do I have to edit?

Offtopic: I you are in the mood for bew BS parts,... maybe a S1 Warpcore and S0 coils would be funny for little warp-capable vessel that start from a bigger mothership. Just an idea if you should be in the mood for new parts. 

Also an idea to go even bigger like Nerteas NF - Launch vehicles mod, thar come with 5m and 7m parts. Such super heavy and super expensive warpdrives might be capbleable of ferrying supergate-parts over to another solar system (Somehow the generarion of alien gates does not seem to work for me. Probably the same reason with REX as on the interstellar speed issue).

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.

[Rakete]

13 hours ago, Angelo Kerman said:

First pre-release of the latest Blueshift: https://github.com/Angel-125/Blueshift/releases/tag/v1.10.0

Sounds great. What does pre-release mean? Are there further changes incomming?

The description on github made me smile: yadaYada=true ??? I love such eastereggs in configs.

 

13 hours ago, Angelo Kerman said:

think you can set it via:

I will try this. I guess you mean the settings.cfg in the Blueshiftfolder, right?

So I will have to define a last planet for every Star. Including Kerbol (=Sun?) right? Have you done this for other planetpacks (where the vessels go interstellar speeds), or where do they get their configs from? Or did they configure blueshift for their mods in their configs?

I figured out a workaround it i fail to tell blueshift the starsystem config: REX has an option to lower the interstellar distances. As last resort I could tune them down, so that the interplanetary behavior of BS will suffice. I made myself an excelsheet to calculate the warp range of a vessel based on graviolium usage per time, max. Warpfactor and available graviolium on the vessel. 

 

 

I will try out the new BS version as soon as i can. Probably tomorrow.

 

[Angelo Kerman]

2 hours ago, Rakete said:

Sounds great. What does pre-release mean? Are there further changes incomming?

The description on github made me smile: yadaYada=true ??? I love such eastereggs in configs.

 

I will try this. I guess you mean the settings.cfg in the Blueshiftfolder, right?

So I will have to define a last planet for every Star. Including Kerbol (=Sun?) right? Have you done this for other planetpacks (where the vessels go interstellar speeds), or where do they get their configs from? Or did they configure blueshift for their mods in their configs?

I figured out a workaround it i fail to tell blueshift the starsystem config: REX has an option to lower the interstellar distances. As last resort I could tune them down, so that the interplanetary behavior of BS will suffice. I made myself an excelsheet to calculate the warp range of a vessel based on graviolium usage per time, max. Warpfactor and available graviolium on the vessel. 

 

 

I will try out the new BS version as soon as i can. Probably tomorrow.

 

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
}

[Rakete]

50 minutes ago, Angelo Kerman said:

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:

And this will make BS accept, that Kerbins SOI is smaller than defined in REX and thus enables interstellar speeds? You said it might extend Kerbins SOI extremely far. 

REX adds separate solar systems. It adds nothing to the Kerbol system itself - at least not on the user side. It could be, that the stars out there techically move around kerbol so slow, they are almost static. Maybe ?! I don't know how REX is defined and how Kopernicus definitions work technically. 

[Angelo Kerman]

20 minutes ago, Rakete said:

And this will make BS accept, that Kerbins SOI is smaller than defined in REX and thus enables interstellar speeds? You said it might extend Kerbins SOI extremely far. 

REX adds separate solar systems. It adds nothing to the Kerbol system itself - at least not on the user side. It could be, that the stars out there techically move around kerbol so slow, they are almost static. Maybe ?! I don't know how REX is defined and how Kopernicus definitions work technically. 

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.

[Rakete]

13 minutes ago, Angelo Kerman said:

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.

So in my case I should define Plock (from Outer Planets Mod) as last planet for kerbol. And the others should be straight forward according to their definitions, I hope... uuufff.... I guess I have to learn to read kopernicus definitions e.g. Alpha Centauri has 3 stars on their way around a common barycenter. I guess, this has some name too, which would be the reference for the farest planet.

Edited January 5 by Rakete

[Angelo Kerman]

3 hours ago, Rakete said:

So in my case I should define Plock (from Outer Planets Mod) as last planet for kerbol. And the others should be straight forward according to their definitions, I hope... uuufff.... I guess I have to learn to read kopernicus definitions e.g. Alpha Centauri has 3 stars on their way around a common barycenter. I guess, this has some name too, which would be the reference for the farest planet.

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.

[Angelo Kerman]

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.

[Rakete]

On 1/5/2024 at 7:03 PM, Rakete said:

will try out the new BS version as soon as i can. Probably tomorrow

Sorry for not having had the time to test the new BS version. Unfortunately my work-free time around xmas is over so I will have to give a try in the next days around weekend  - as soon as i find the time. So please be not disappointed, that there's no report on the action group fix yet.

 

On 1/5/2024 at 1:11 AM, Rakete said:

Before the next BS-release you might also want to have a look on the gravi-usage of the S3 heavy sustainer it uses 0,02 gravi /s (according to the part description in VAB) meaning 7,2 gravi /h where all other S3 parts are at 36 gravi / h. I guess you meant 72 gravi / h for the heavy sustainer? I can only speculate, that the low value is unintentional.

Have you had time to have a look? @Angelo Kerman

 

 

[Angelo Kerman]

On 10/27/2023 at 9:27 AM, StormxWolf said:

Hi, I am looking to modify the alien jump gates such that I can access other gates before I have ever discovered them. I see you have a setting: "isKnown" which seems to do exactly that however I have set it to "true" and I seemingly cannot use other gates unless I have first rendezvoused with them. Could you let me know how I can edit a save to make a spawned gate usable without ever actually rendezvousing with it? Let me know if you know of some way to accomplish what I am trying to do or if I am being unclear.

Thank you for the fun mod!

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.

1 hour ago, Rakete said:

Sorry for not having had the time to test the new BS version. Unfortunately my work-free time around xmas is over so I will have to give a try in the next days around weekend  - as soon as i find the time. So please be not disappointed, that there's no report on the action group fix yet.

 

Have you had time to have a look? @Angelo Kerman

 

 

I haven't had time to look at that yet but it is on my list.

[Angelo Kerman]

4 hours ago, Rakete said:

Sorry for not having had the time to test the new BS version. Unfortunately my work-free time around xmas is over so I will have to give a try in the next days around weekend  - as soon as i find the time. So please be not disappointed, that there's no report on the action group fix yet.

 

Have you had time to have a look? @Angelo Kerman

 

 

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...

[JadeOfMaar]

8 hours ago, Angelo Kerman said:

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.

I discovered that one for myself recently, and backed off of it. It would make a fine addition to the list fo things handled by KSPCF. It's really nice that the TAC LS converter module does this properly. Maybe that's a major part of why that module exists.

[Angelo Kerman]

6 hours ago, JadeOfMaar said:

I discovered that one for myself recently, and backed off of it. It would make a fine addition to the list fo things handled by KSPCF. It's really nice that the TAC LS converter module does this properly. Maybe that's a major part of why that module exists.

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.

[Angelo Kerman]

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.

[Rakete]

On 1/9/2024 at 9:09 PM, Angelo Kerman said:

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.

Is this a different pre-release than the one few days ago? the pre-release version number did not change.

[Rakete]

On 1/9/2024 at 3:24 AM, Angelo Kerman said:

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...

I made a mistake.... i typed in a zero too few in my (brain) pocket calculator. 0.02 × 3600 is indeed 72/h not 7.2/h ... my fault by being too tired in the evening

Edited January 10 by Rakete

[Angelo Kerman]

2 hours ago, Rakete said:

I made a mistake.... i typed in a zero too few in my (brain) pocket calculator. 0.02 × 3600 is indeed 72/h not 7.2/h ... my fault by being too tired in the evening

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.

[Angelo Kerman]

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.