kerbal ftl [Min KSP 1.12.2] Blueshift: Kerbal FTL

[Rakete]

39 minutes ago, Angel-125 said:

Where did you do your testing? What planet?

I did it on Jool for simple reproduction (no need for planet mods). Simply teleported a testrig there consisting of Exo-harvester of FFT, command module, energy supply (Some Reactor - i took a simple Fission Reactor from NF Electrical, but your fusion reactors will do too), cooling for the harvester (since they require System Heat Mod from nertea) and some big graviolium tanks.

Remember: The FFT-Harvester obeys the vehicle orientation. In my testcase the harvester was oriented prograde for maximum harvest. (the harvester collects nothing when oriented 90 degree to flight direction or retrograde....)

 

 

Suggestion for a target calibration/balancing: I think a 1500 units graviolium tank should be filled in about one kerbal month in an Orbit near jool, but outside its atmosphere, so that the player doesn't have to waste kerbal centuries but also experiences, that harvesting is not an instantaneous process. 

I guess the density value of gravi is not high enough OR the abundance value has an issue. Just my guesses... Maybe @Grimmas knows better.

Edited May 13, 2022 by Rakete

[Angelo Kerman]

4 hours ago, Rakete said:

I did it on Jool for simple reproduction (no need for planet mods). Simply teleported a testrig there consisting of Exo-harvester of FFT, command module, energy supply (Some Reactor - i took a simple Fission Reactor from NF Electrical, but your fusion reactors will do too), cooling for the harvester (since they require System Heat Mod from nertea) and some big graviolium tanks.

Remember: The FFT-Harvester obeys the vehicle orientation. In my testcase the harvester was oriented prograde for maximum harvest. (the harvester collects nothing when oriented 90 degree to flight direction or retrograde....)

 

 

Suggestion for a target calibration/balancing: I think a 1500 units graviolium tank should be filled in about one kerbal month in an Orbit near jool, but outside its atmosphere, so that the player doesn't have to waste kerbal centuries but also experiences, that harvesting is not an instantaneous process. 

I guess the density value of gravi is not high enough OR the abundance value has an issue. Just my guesses... Maybe @Grimmas knows better.

Yeah, I definitely need help from @Grimmas or @Vexxel to figure out the right abundances.

[Grimmas]

Oh wow that is seriously broken, haha. I'm unfortunately not an expert on SpaceDust either. I sort of fixed it, through trial and error, but I might have gone too far with nerfing it. Give this a try (replace the Jool section in SpaceDust.cfg in Blueshift/Patches). I can get a few units of Graviolium per day with this, depending on the orbit. 

Spoiler

SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
    resourceName = Graviolium
    body = Jool

    RESOURCEBAND
    {
        name = JoolGraviolium
        title = Jool Graviolium Belt

        minAbundance = 0.000000000000000000000000000000011        
        maxAbundance = 0.000000000000000000000000000000041

        alwaysDiscovered = false
        alwaysIdentified = false
        allowRemoteDiscovery = true
        allowRemoteIdentification = true
        remoteDiscoveryScale = 0.1
        remoteIdentifyScale = 0.1

        useAirDensity = false
        distributionType = Spherical

        altLowerBound = 500000
        altUpperBound = 10000000
        altPeak = 7000000
        altVariability = 0
        altFalloffType = Linear
        altitudeSquish = 0.9

        latLowerBound = -15
        latUpperBound = 15
        latPeak = 0
        latVariability = 1
        latFalloffType = Linear
        countScale = 20
    }
}

I'm holding off on changing the other planets and doing a PR until we have some consensus on sane values.

Edited May 14, 2022 by Grimmas

[Rakete]

I would consider a balancing, where you don't have to spend years in Jool-Orbit, as it would only make the player press the timewarp button. Something, e.g. 1500 unit per 30 day  month... (uuuh.... kerbals must have more than 12 months... January, Jebuary, Bobuary.... )so... considering a 30 day month, it would mean 50 units every kerbal day, maybe more, to give a realistic feeling. Maybe half a month for 1500 would do either... a big harvester would have multiple 1500-gravi-tanks, as it would make sense to maximize your harvest in relation of the mission costs.. Filling it over years would be maybe annoying to some players. Getting to jool is already challenging for many players, so I guess, it should not be too hard, once you get there and have the high tech equipment to harvest (you need much stuff: Harvester, proper cooling, proper energy supply without any real solar power out there at jool, etc)

What do you all think about the target balancing? So I am no expert how to tweak this. Hope, the others know how to do. But somehow I feel, this will lead to a great gameplay experience, so send a harvester to jool and bring back the gravi, parallel to harvesting on dres (Does it exist? ) and eve. 

 

For calibration I would suggest setting max and min abundance equal (for reproducing results during balancing), since the gameseed of each save determins as far as i know the abundance the player meets in the game. A deviation can be set afterwards.

 

Unfortunately I am not on my computer right now to test stuff... RL demands today... maybe in the evening. 

Edited May 14, 2022 by Rakete

[Rakete]

 @Grimmas@Angel-125

Hey,

I spent the afternoon with some tweaking (Can't see KSPs loadscreen anymore... ). Here is my proposal for Jool:

These values filled 4 big Gravitanks (6000 Units, as you might send as a harvester to Jool) in about 70 days in timewarp @ 350km fully circular orbit, which takes a lot dV to reach/leave.... Maybe it might be cut to half abundance, if you wish. That would make 140 days to fill 4 tanks

I tweaked in a way, so that the highest amount of gravi is right above the atmosphere of Jool (200km is Jool's atmospheric upper end). They really fast disappear due to their instable nature in jools atmosphere. The peak is at 200km (Sweet spot between being caught in Jools gravity and not being destroyed in jools atmosphere due to reactions with Jool's gases. Going further out, they disappear as well as a result of not being bound in the gravity well.

 

Opinions on that ?! These values can also be adapted for the other planets changing the orange values according to their names and atmospheric heights. I saw, there is also a gravi-ring around kerbin. This ring should be weaker, I guess... maybe 1/2 of Jools abundance to make the players go to Dres, Jool, Eve... BUT Bussard-Collector harvesting (via FFT) is already really really late-game-content (depending on your used techtree), that's why I wouldn't go lower than 1/4 of Jool's Gravi abundance - in order to not make it overly annoying to get gravi in the late game (without repeatedly shipping Gravi from anywhere (becomes tedious if you do it the twentieth times). It might make players build a gravi harvesting fuel station in Kerbins Orbit (in the late game, when they did manage to get the exopheric harvester equipment!), which accumulates Gravi over time and gives it to the warp vessels when needed - sounds like a neat concept, I think.

 

I also changed the latitude bounds to make it a little more like a belt. a bit slimmer, so that you need to have the correct orbit, to collect the hot stuff.

 

I gave it only little gameseed-variation (min/max abundance) to ensure the basic gameplay is kept.

 

 

SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
    resourceName = Graviolium
    body = Jool

    RESOURCEBAND
    {
        name = JoolGraviolium
        title = Jool Graviolium Belt

        minAbundance = 0.00000000000000000000000000000017        
        maxAbundance = 0.00000000000000000000000000000020

        alwaysDiscovered = false
        alwaysIdentified = false
        allowRemoteDiscovery = true
        allowRemoteIdentification = true
        remoteDiscoveryScale = 0.1
        remoteIdentifyScale = 0.1

        useAirDensity = false
        distributionType = Spherical

        altLowerBound = 180000
        altUpperBound = 10000000
        altPeak = 200000
        altVariability = 0
        altFalloffType = Linear
        altitudeSquish = 0.9

        latLowerBound = -10
        latUpperBound = 10
        latPeak = 0
        latVariability = 1
        latFalloffType = Linear
        countScale = 20
    }
}

 

 

What do you think?

 

 

Edited May 14, 2022 by Rakete

[Rakete]

Update: Here my full proposal on the  Space dust bands within the spacedust config of the Stock planets (don't know the other stuff from JNSQ - please adapt it the way you like, since I don't know their atmospheric values.)

Logic: Jool is the reference as mentioned in the post above.

Graviconcentration:      Kerbin (50% of Jool) < Eve (75% of Jool) < Jool (100%) < Sun (10000% of Jool, if you get there and don't burn).

 

updated full Blueshift Spacedust config (with all your other Spacedust compatibility patches untouched) here for download: ------> -------> ------> ------> ------> ------> https://www.filemail.com/d/yuobrelsxkenlvs

Sorry, I'm not on github. But you may pull it into Github if you wish @Angel-125

@Grimmas Can you please check the stuff according to the 4-eyes-principle?

 

 

Here is what I changed in the config

// Space Dust bands
SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
	resourceName = Graviolium
	body = Sun

	RESOURCEBAND
	{
		name = KerbolGraviolium
		title = Kerbol Graviolium Belt

        	minAbundance = 0.000000000000000000000000000017        
        	maxAbundance = 0.000000000000000000000000000020

		alwaysDiscovered = false
		alwaysIdentified = false
		allowRemoteDiscovery = true
		allowRemoteIdentification = true
		remoteDiscoveryScale = 0.1
		remoteIdentifyScale = 0.1

		useAirDensity = false
		distributionType = Spherical

		altLowerBound = 261600000
		altUpperBound = 2616000000
		altPeak = 0
		altVariability = 0
		altFalloffType = Linear

		latLowerBound = -5
		latUpperBound = 5
		latPeak = 0
		latVariability = 0
		latFalloffType = Linear
		countScale = 200000
	}
}

SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
	resourceName = Graviolium
	body = Eve

	RESOURCEBAND
	{
		name = EveGraviolium
		title = Eve Graviolium Belt

        	minAbundance = 0.00000000000000000000000000000013        
        	maxAbundance = 0.00000000000000000000000000000015
		alwaysDiscovered = false
		alwaysIdentified = false
		allowRemoteDiscovery = true
		allowRemoteIdentification = true
		remoteDiscoveryScale = 0.1
		remoteIdentifyScale = 0.1

		useAirDensity = false
		distributionType = Spherical

		altLowerBound = 80000
		altUpperBound = 500000
		altPeak = 90000
		altVariability = 0
		altFalloffType = Linear

		latLowerBound = -5
		latUpperBound = 5
		latPeak = 0
		latVariability = 0
		latFalloffType = Linear
	}
}

SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
	resourceName = Graviolium
	body = Kerbin

	RESOURCEBAND
	{
		name = KerbinGraviolium
		title = Kerbin Graviolium Belt

        	minAbundance = 0.00000000000000000000000000000010        
        	maxAbundance = 0.00000000000000000000000000000012
		alwaysDiscovered = false
		alwaysIdentified = false
		allowRemoteDiscovery = true
		allowRemoteIdentification = true
		remoteDiscoveryScale = 0.1
		remoteIdentifyScale = 0.1

		useAirDensity = false
		distributionType = Spherical

		altLowerBound = 60000
		altUpperBound = 525000
		altPeak = 130000
		altVariability = 0
		altFalloffType = Linear
		// Peak value little bit more shifted outwards of the atmosphere border to make it a bit easier to find a pleasent location for a gravi-refill-Station in orbit with FFT-Exo-Collectors. Just for player-friendliness change it, if you don't like it.

		latLowerBound = -5
		latUpperBound = 5
		latPeak = 0
		latVariability = 0
		latFalloffType = Linear
	}
}



SPACEDUST_RESOURCE:NEEDS[!WildBlueIndustries/FlyingSaucers,SpaceDust]
{
    resourceName = Graviolium
    body = Jool

    RESOURCEBAND
    {
        name = JoolGraviolium
        title = Jool Graviolium Belt

        minAbundance = 0.00000000000000000000000000000017        
        maxAbundance = 0.00000000000000000000000000000020

        alwaysDiscovered = false
        alwaysIdentified = false
        allowRemoteDiscovery = true
        allowRemoteIdentification = true
        remoteDiscoveryScale = 0.1
        remoteIdentifyScale = 0.1

        useAirDensity = false
        distributionType = Spherical

        altLowerBound = 180000
        altUpperBound = 10000000
        altPeak = 200000
        altVariability = 0
        altFalloffType = Linear
        altitudeSquish = 0.9

        latLowerBound = -10
        latUpperBound = 10
        latPeak = 0
        latVariability = 1
        latFalloffType = Linear
        countScale = 20
    }
}

 

Edited May 14, 2022 by Rakete

[Angelo Kerman]

If you guys can playtest these settings for a few days, I'd definitely appreciate it. In the meantime, I'll keep building up the new graviolium collector..

[Rakete]

46 minutes ago, Angel-125 said:

If you guys can playtest these settings for a few days, I'd definitely appreciate it  In the meantime, I'll keep building up the new graviolium collector..

@Angel-125 I'd recommend downloading my file (if you want to) in the next days, as the download is only available 7 days (because it's a free filehoster, but only host stuff for a limited time). I am looking forward to your warp nacelle bussard collector... eeeh... graviolium collector. Love the star trek feel to it. Will it glow and have effects in it, like Zephram Cochranes Phoenix had?

 

@ the others: feel free to test these configs. As far as I tested it, while iterating on it, I was okay with it. Maybe it needs a little reduction, to make it more rare... maybe...  But I am really interested in your opinion on it. Feedback or updates are welcome.

Edited May 14, 2022 by Rakete

[Angelo Kerman]

Progress on the dust collector Type B variant:

It has two sets of rotors that spin when in operation.

The internal rotors heat up when collecting dust:

[Angelo Kerman]

 

[Rakete]

 What can I say more, than: I really love the style... I also love, that you kinda stick to the classical startrek-look before the great era came to an end with start of the really bad J.J.Abrahms movies and the also bad Discovery series... maybe I'm too old to like the new interpretation of Star Trek, shown in the Abrahms movies and the always-crying-Burnham-series. 

(Note to my self: Don't say: Gimme! Gimme! Gimme!.... really looking forward to this new toy.)

These rotors hopefully don't introduce torque to the spaceship, right? 

Edited May 15, 2022 by Rakete

[SkyFall2489]

There's 2, conterspinning ones, not to mention it would be a useless feature that takes time to implement but doesnt make the mod more fun...

[Rakete]

48 minutes ago, SkyFall2489 said:

There's 2, conterspinning ones, not to mention it would be a useless feature that takes time to implement but doesnt make the mod more fun...

Depends on moment of inertia of each rotor and rotational speed of each rotor... but I guess, the spinning things inside the module do not effect physics calculations at all.  It was more a rhetoric question.

Yes, you are right in general. But I do not want to interfere in Angel's design decisions. It's his mod and his design. To my mind, I like the design intended by Angel. For me many KSP Mods live by those little cute details.

Edited May 15, 2022 by Rakete

[Rakete]

Just set up an Graviolium-Storage-Extension to my orbital refueling station that already harvested trace gases from Kerbins exosphere (I did give it some exosphere by Spacedust configs a while ago). Now it can also collect gravi over weeks and months, in case a warp ship (to be developed) comes around and needs fuel.

 

The four harvesters (one points alway almost prograde, so the orientation of the station has not steadily be corrected) are currently retracted as you can see due to some refit work, which is necessary since the day Sahra Kerman discovered the strange particles that are near the station after a firmware upgrade to their spectrographic tracegas analyser. Maybe they can be harvested? Maybe they can be eaten? We will have to do some research to find out, what we can do with them. Maybe pour them out as topping on Minmusian ice cream? We will see. Or is it just a firmware bug of the scanner? Sahra dreams of ice cream toppings...

Meanwhile at the KSC: "We are gonna die, aren't we?" .... B. Kerman looks at some draft of upcoming blue prints of some kind of more effective and more portable harvester for those strange ice cream topping particles.... "You know, playing around with gravity ... is ... dangerous... My professor at the Kale University also said so.... And this not just a boat race against Koxford...". Jeb smiles back "They are glowing and spinning. They must be great!"...

 

 

 

So much for my playtesting ;-) I'm havin' fun.

Edited May 15, 2022 by Rakete

[Angelo Kerman]

9 hours ago, Rakete said:

 What can I say more, than: I really love the style... I also love, that you kinda stick to the classical startrek-look before the great era came to an end with start of the really bad J.J.Abrahms movies and the also bad Discovery series... maybe I'm too old to like the new interpretation of Star Trek, shown in the Abrahms movies and the always-crying-Burnham-series. 

(Note to my self: Don't say: Gimme! Gimme! Gimme!.... really looking forward to this new toy.)

These rotors hopefully don't introduce torque to the spaceship, right? 

I'm seriously digging Strange New Worlds. They did a great job with the ship design, sets, and costumes. Anyway, it's my modding day off, but I did a quick test of the textures:

[Teslamax]

On 5/13/2022 at 2:06 PM, Rakete said:

@Angel-125

I have the same message.

Log snippet follows:

Spoiler

[ERR 22:00:06.343] Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part  ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype GravioliumInstrument ---> System.Exception: Exception while loading field primaryColor on type B9PartSwitch.PartSubtype ---> System.FormatException: Could not value parse as color: Graviolium
  at B9PartSwitch.Utils.ColorParser.Parse (System.String colorStr) [0x002e4] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at (wrapper delegate-invoke) System.Func`2[System.String,UnityEngine.Color].invoke_TResult_T(string)
  at B9PartSwitch.Fishbones.Parsers.ValueParser`1[T].Parse (System.String value) [0x0000b] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00022] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0001d] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00038] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0009e] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x000ea] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x0010f] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at PartModule.Load (ConfigNode node) [0x001ab] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 

 

 

Edited May 15, 2022 by Teslamax

[Rakete]

3 minutes ago, Teslamax said:

I have the same message.

 

Try this config. It contains Angels fixes from his pre-release 1.7.8 plus my configs for Spacedust belts (Jool, Kerbin and Eve), which are to be verified by some other players ... So try to replace the Spacedust.cfg in the Blueshift\patches directory with this file:

 

https://www.filemail.com/d/yuobrelsxkenlvs

 

 

Edited May 15, 2022 by Rakete

[Teslamax]

1 hour ago, Rakete said:

Try this config. It contains Angels fixes from his pre-release 1.7.8 plus my configs for Spacedust belts (Jool, Kerbin and Eve), which are to be verified by some other players ... So try to replace the Spacedust.cfg in the Blueshift\patches directory with this file:

 

https://www.filemail.com/d/yuobrelsxkenlvs

Thanks!

No more "Fatal Error"!

Edited May 15, 2022 by Teslamax

[Grimmas]

1 hour ago, Teslamax said:

I have the same message.

Log snippet follows:

  Hide contents

[ERR 22:00:06.343] Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part  ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype GravioliumInstrument ---> System.Exception: Exception while loading field primaryColor on type B9PartSwitch.PartSubtype ---> System.FormatException: Could not value parse as color: Graviolium
  at B9PartSwitch.Utils.ColorParser.Parse (System.String colorStr) [0x002e4] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at (wrapper delegate-invoke) System.Func`2[System.String,UnityEngine.Color].invoke_TResult_T(string)
  at B9PartSwitch.Fishbones.Parsers.ValueParser`1[T].Parse (System.String value) [0x0000b] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00022] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0001d] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00038] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0009e] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x000ea] in <a3c2951fc74e4639820ef37d2d29f386>:0 
   --- End of inner exception stack trace ---
  at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x0010f] in <a3c2951fc74e4639820ef37d2d29f386>:0 
  at PartModule.Load (ConfigNode node) [0x001ab] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 

 

 

This is already fixed in the repo on github, make sure you use the 1.7.8 pre-release version.

Edit: basically what Rakete said lol.

 

BTW @Rakete I was playing a bit with Blueshift earlier today, went interstellar on a 100t ship and I saw that only took about 20-25 Graviolium to travel from Kerbin to GU's Nova Kirvani (a few lightyears away). I don't know how this compares to typical usage but I'm starting to think that being able to harvest thousands of Graviolium per month as you proposed may be too lenient.

Edited May 15, 2022 by Grimmas

[Rakete]

1 hour ago, Grimmas said:

This is already fixed in the repo on github, make sure you use the 1.7.8 pre-release version.

Edit: basically what Rakete said lol.

 

BTW @Rakete I was playing a bit with Blueshift earlier today, went interstellar on a 100t ship and I saw that only took about 20-25 Graviolium to travel from Kerbin to GU's Nova Kirvani (a few lightyears away). I don't know how this compares to typical usage but I'm starting to think that being able to harvest thousands of Graviolium per month as you proposed may be too lenient.

Ah okay... due to kopernicus unpleasent bugs with shadows on my system (see thread there, fix inbound) i don't have planet mods currently installed, so I can't validate, how much is the usage on interstellar travel happens. so feel free to change the values and make a better proposal.  I just took the gravitanksize as a baseline. 

By the way... while playing around with the outer planets i think i remember, that I almost drained the integrated gravitank of a warpcore. Might be, that interstellar travels are very efficient and interplanetar eats much more gravi? I think a warpcore eats gravi over time and not distance, right? So a slow ship needs more gravi per trip, I guess... I remember that the in-planetary-SOI-warping on approach to Sarnus (or was it Neidon?) and the other gas giants were very slow and gravi munching. There is a harsh slowdown near big gravity sources (like the Frameshift drive in Elite Dangerous has)

My values were just an initial proposal. Feel free to tweak them further. What factor do you consider?

Current abundances × 0.3?   0.2 ?   0.1?   0.05?

Edited May 15, 2022 by Rakete

[Ooglak Kerman]

@Angel-125 I just installed Blueshift 1.7.7 and got a MM error for Spacedust patch.  It looks like this is the source

 

[ERR 18:07:00.652] pass specifier detected on insert node (not a patch): WildBlueIndustries/Blueshift/Patches/SpaceDust/SPACEDUST_INSTRUMENT:NEEDS[!WildBlueIndustries/FlyingSaucers]:AFTER[SpaceDust]

Given I don't use SpaceDust, I'd guess it's safe to just delete that patch for now?

[obnox twin]

30 minutes ago, Ooglak Kerman said:

@Angel-125 I just installed Blueshift 1.7.7 and got a MM error for Spacedust patch.  It looks like this is the source

 

[ERR 18:07:00.652] pass specifier detected on insert node (not a patch): WildBlueIndustries/Blueshift/Patches/SpaceDust/SPACEDUST_INSTRUMENT:NEEDS[!WildBlueIndustries/FlyingSaucers]:AFTER[SpaceDust]

Given I don't use SpaceDust, I'd guess it's safe to just delete that patch for now?

Do you have flying saucers? and is wildblue stuff installed correctly?

[Ooglak Kerman]

Both Blueshift and KFS are definitively installed and correctly.  I've been using the heck out of both of them and only now upgraded from 1.7.4 to 1.7.7 for Blueshift.  The error is centric to the patch for the SpaceDust mod.

I do not have FFT or SpaceDust installed though.

 

Update:  I just applied Blueshift 1.7.7 with the SpaceDust patch removed against a clone from a week ago with Blueshift 1.7.3 and all appears good.  More testing though

Edited May 17, 2022 by Ooglak Kerman

[obnox twin]

39 minutes ago, Ooglak Kerman said:

Update:  I just applied Blueshift 1.7.7 with the SpaceDust patch removed against a clone from a week ago with Blueshift 1.7.3 and all appears good.  More testing though

Thats good but spacedust is recommend to make it easier to harvest gravlioum from planetes gravity fields. But you play to your choice

[Ooglak Kerman]

 @Angel-125  Removing the SpaceDust patch clears up the errors.

Interesting results with Blueshift 1.7.7.  I'm using Vals old warp tanker as a test case here.  At the lower end of thrust limiter - 18.5 - The ship will not budge.  Only with the Supercharger at 100% will it move and then interplanetary speed is as previous ~.25C

By comparison, in Blueshift 1.7.3, with the thrust limiter at 18.5 the ship moves right out and achieves the same interplanetary speed as above.

With Blueshift 1.7.7 installed and with the thrust limiter at 100 and Supercharger at 100, the ship is right sporty and interplanetary speed is now .63C

So, it appears that the lower end of warp drive performance is driven even lower by the supercharger and that the upper end is significantly better.  I suppose this sort of thing should be expected with experimental upgrades to experimental alien tech, but I'm grumbling over my carefully crafted performance charts now being rendered useless.

Darn you to heck Angelo Kerman!  I expect that Val will have more choice words once she tests the upgrade.

@obnox twin I've been following the SpaceDust discussions with considerable interest but am not ready to commit yet.  The graviolium belt at Jool is really quite rich with Blueshift and KFS.  I'm just awash in graviolium now and fusion pellets are actually a resource issue - though since they are used so sparingly... no so much an issue.  I actually think graviolium is just too plentiful at Jool and should be dialed back an OOM.  Too late though.. I've got a HUGE stock.

Big hulking guy with muckle hammer: "Hey buddy..  you got a big graviolium stock there.   Be a shame for something to happen to it." 

Along those lines - I'd love to see harvested graviolium degrade over time.. maybe into Ore or vacuum or something equally useless - though no idea how that would play out in the programming.

Edited May 17, 2022 by Ooglak Kerman