kerbal ftl [Min KSP 1.12.2] Blueshift: Kerbal FTL

[Ooglak Kerman]

@Rakete WRT the warp performance bump by an Eng-5, I will certainly admit to a goodly amount of desire to not get the story line I've got going get off the rails.

I agree with you about performance enhancements that an Eng can squeeze out of a system - but we should balance that with real life necessities with playing the game.  That warp tanker I've got with an S2 Core and 6 x S1 coils would take over an hour to get out of Kerbol SOI.  Then about 45 minutes interstellar.  Then an unknown amount to get somewhere useful in the Nova Kirbani system. 

All of that is easy to personally manage with normal systems where it takes 100 years or so to get to a place.  Set a timer to stop the time warp and time warp at max and walk away if you want.  You cannot do this with warp drives.

A possible compromise I can think of would be something like @Angel-125 implemented with turning off the planetary space speed brake.  Perhaps...  Allow interstellar speeds in interplanetary space as long as the target is an interstellar target?  I don't know if that is reasonable though.

Personally, I'm willing to sit and twiddle my thumbs for 15-20 minutes while the ship goes to a place.  1 1/2 or 2 hours?  Not so much.

7 minutes ago, SkyFall2489 said:

The issue with your old code was that it was attempting to edit the warpSpeedSkillMultiplier of the part node, not the warp engine module. You see, you selected the part when you said @PART... at the very beginning. the HAS statement selects parts with a specific module node, it does not select that module node for modification.

Ok then.  That makes sense.  I need to spend more time with the MM documentation.  Thanks for the explanation.

[SkyFall2489]

3 minutes ago, Ooglak Kerman said:

Ok then.  That makes sense.  I need to spend more time with the MM documentation.  Thanks for the explanation.

In my opinion, experience is one of the best ways to learn coding. Try some more patching, and eventually you will truly understand the ways of ModuleManager...

Edited June 1, 2022 by SkyFall2489

[Ooglak Kerman]

Tonights homework is to try and reduce the amount of lines and characters of the patch that worked into something much less readable. 

Get rid of those pudgy zeros and leave it lean and mean with a bunch of ones.

 

[SkyFall2489]

9 minutes ago, Ooglak Kerman said:

Tonights homework is to try and reduce the amount of lines and characters of the patch that worked into something much less readable. 

Get rid of those pudgy zeros and leave it lean and mean with a bunch of ones.

 

That may not be the best strategy. MM patching and CFG files actually don't increase loading time by that much compared to textures and models, and it's good practice to make your code readable.

[Grimmas]

3 hours ago, Rakete said:

I also found something odd:

The WBI bussard collectors have defined SystemHeat (Mod by nertea, FFT-Dependency --- maybe a depency for the spacedust/FFT exospheric harvester module too ????) values for cooling (outlet temp and cooling needs (some kW were defined) as you can see in the VAB tooltip. But if you place them in the VAB, there is no systemheat interface, that makes them attachable to heat loops. Is it intended to be part of systemheat? Or is the availability of those values just an cosmetic issue?

@Grimmas You seem to be more an expert on MM patches then the really really unknowing me. Can you see, whats wrong there?  Has something to be fixed? I remember, that you are also a FFT user. (Why do I always think of fast fourier transformations, when I write FFT ?? ) At least, i doesn't seem to generate errors... So maybe we should just remember, that even if its tool tip in the vab implies SystemHeat cooling needs, it doesn't need Systemheat cooling. Your opinion? Could be the easiest way, even not the cleanest.

Short version, it's working as intended.

SpaceDust is compatible with SystemHeat but it's not a hard dependency. The current bussard collectors were configured for SpaceDust but not for SystemHeat. Those values you are seeing are defaults from SpaceDust (with the Heat Output being literally the EC consumption value) but these values won't do anything unless and until the part is also configured for SystemHeat.

[Ooglak Kerman]

Just now, SkyFall2489 said:

That may not be the best strategy. MM patching and CFG files actually don't increase loading time by that much compared to textures and models, and it's good practice to make your code readable.

Yeah.  That's kind of a leftover from my early days with perl.  At the agency I was at, there were competitions where they gave you the input and the desired output.  The objective was perl in 1 line of 80 chars or less.  Of course, the roll of perl we had was.... "special".  I never did that well.

[AmanitaVerna]

I'm seeing this exception in my Player.log, coming from Blueshift when the PartLoader compiles Blueshift warp cores and warp engines and when drag cubes are being created for them, except for the deprecated ones, which aren't showing the exception. I don't know if this is an issue at all. I assume not because I played a long session without any noticeable problems, but I also don't have any Blueshift stuff unlocked in the tech tree yet.

System.NullReferenceException: Object reference not set to an instance of an object
  at Blueshift.WBIWarpEngine.disableGeneratorBypass () [0x0000d] in <876363c33e3345f481201ed7e06cfd08>:0  
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

I got a "413 Request Entity Too Large" error when I tried to upload the Player.log file to pastebin (It's like 33.4 MB unzipped ).

I zipped it up (reducing it to 1.2 MB) and put the zip file on onedrive here as an alternative: https://1drv.ms/u/s!AlnEemcsDL9XlcoI1o4N7eKckqu9ag?e=WdIRLz

[Ooglak Kerman]

@SkyFall2489  Ok... you asked.  You got.  The story unwinds.  And I blame you for wherever this goes..  Chosen font is important also.

2 minutes ago, AmanitaVerna said:

I'm seeing this exception in my Player.log, coming from Blueshift when the PartLoader compiles Blueshift warp cores and warp engines and when drag cubes are being created for them, except for the deprecated ones, which aren't showing the exception. I don't know if this is an issue at all. I assume not because I played a long session without any noticeable problems, but I also don't have any Blueshift stuff unlocked in the tech tree yet.

System.NullReferenceException: Object reference not set to an instance of an object
  at Blueshift.WBIWarpEngine.disableGeneratorBypass () [0x0000d] in <876363c33e3345f481201ed7e06cfd08>:0  
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

I got a "413 Request Entity Too Large" error when I tried to upload the Player.log file to pastebin (It's like 33.4 MB unzipped ).

I zipped it up (reducing it to 1.2 MB) and put the zip file on onedrive here as an alternative: https://1drv.ms/u/s!AlnEemcsDL9XlcoI1o4N7eKckqu9ag?e=WdIRLz

The first question you will certainly get will be framed around which version of Blueshift you are using.

Edited June 1, 2022 by Ooglak Kerman

[Rakete]

8 hours ago, Grimmas said:

Short version, it's working as intended.

SpaceDust is compatible with SystemHeat but it's not a hard dependency. The current bussard collectors were configured for SpaceDust but not for SystemHeat. Those values you are seeing are defaults from SpaceDust (with the Heat Output being literally the EC consumption value) but these values won't do anything unless and until the part is also configured for SystemHeat.

Alright then... got it.

But can you doublecheck if the bussard collectors collect from spacedustbelts? For me they have shown an delta-value of 0 (not 0.00 as it is displayed if there are very little changes) in the ressource window in the upper right hand corner, while being active in the middle of a spacedust graviolium belt. 

Edited June 1, 2022 by Rakete

[Rakete]

8 hours ago, Ooglak Kerman said:

That warp tanker I've got with an S2 Core and 6 x S1 coils would take over an hour to get out of Kerbol SOI.  Then about 45 minutes interstellar.  Then an unknown amount to get somewhere useful in the Nova Kirbani system. 

Mhhh... maybe install a bigger S3 core, an auxilliary displacement generator and some more and bigger coils and a full powered supercharger? As you said: It's a tanker.  That's what the parts are for, aren't they? Moar boosterssssssss! I guess six little coils and a s2 core (alone) are a little weak for a tanker. Maybe some orbital construction is necessary for a ship of a tanker size. A tanker needs big engine, like real world tankers... they are slow, eat black oil and smoke like you burn wet hay stacks. 

I did a test yesterday: a ship went to neidon (OPM reinstalled) in about 5 minutes without any timewarp. One S2 core, and some s2 coils. Would have been faster, if took an additional displacement generator and stuffed those waves into the coils. Moar power. I mean, where is the fun, when we don't have to optimize our warp vessels and always get a racemachine by simply stacking the smallest warpcores on a heavy vessel?

 

(I remember an ENT episode where Merrywheather visited an freightship, where he grew up. It did only warp two or so...)

Otherwise: isn't there a MM patch value for the interstellar warp boost? Maybe increase it by factor 4 for your applications?

 

Also... I noticed, that Physicstimewarp of KSP work quite okay with Blueshift - at least at my humble testscenario. But not the on-rails-timewarp, that causes.... issues...

Edited June 1, 2022 by Rakete

[AmanitaVerna]

11 hours ago, Ooglak Kerman said:

The first question you will certainly get will be framed around which version of Blueshift you are using.

The latest one, 1.8.2 (with KSP 1.12.3).

Edited June 1, 2022 by AmanitaVerna

[Angelo Kerman]

4 hours ago, AmanitaVerna said:

The latest one, 1.8.2 (with KSP 1.12.3).

That should get fixed in the next release.

[obnox twin]

I want to snag a few asteroids for graviloium mining but I haven't snagged an asteroid before so is there any good guides to help?

[SkyFall2489]

@obnox twin Send a ship with the SENTINEL telescope to an orbit lower than some celestial body, and turn on asteroid tracking. Asteroids will suddenly spawn way faster in orbits nearby the orbit of that body. If the body is Dres, additional asteroids will spawn in high dres orbit as well. To capture an asteroid, I'd reccomend the dres ones, so start in a low orbit, make a burn out as if heading to a moon, have a correction along the way, and when you get close, cancel relative velocity as if docking. Then, burn towards the asteroid, cancel out velocity, and repeat until you are very close. Then, extend the klaw and approach at less than 1 m/s. Both stock drills can mine graviolium.

Edited June 1, 2022 by SkyFall2489

[Ooglak Kerman]

1 hour ago, SkyFall2489 said:

@obnox twin Send a ship with the SENTINEL telescope to an orbit lower than some celestial body, and turn on asteroid tracking. Asteroids will suddenly spawn way faster in orbits nearby the orbit of that body. If the body is Dres, additional asteroids will spawn in high dres orbit as well. To capture an asteroid, I'd reccomend the dres ones, so start in a low orbit, make a burn out as if heading to a moon, have a correction along the way, and when you get close, cancel relative velocity as if docking. Then, burn towards the asteroid, cancel out velocity, and repeat until you are very close. Then, extend the klaw and approach at less than 1 m/s. Both stock drills can mine graviolium.

Heh.  That's so true.  Dres is just a junkyard of asteroids in my game.  So much graviolium and other stuff to be had.

@SkyFall2489 I never plan my stories and this one surprised the heck out of me.  it was a good suggestion.

[SkyFall2489]

4 hours ago, SkyFall2489 said:

@obnox twin Send a ship with the SENTINEL telescope to an orbit lower than some celestial body, and turn on asteroid tracking. Asteroids will suddenly spawn way faster in orbits nearby the orbit of that body. If the body is Dres, additional asteroids will spawn in high dres orbit as well. To capture an asteroid, I'd reccomend the dres ones, so start in a low orbit, make a burn out as if heading to a moon, have a correction along the way, and when you get close, cancel relative velocity as if docking. Then, burn towards the asteroid, cancel out velocity, and repeat until you are very close. Then, extend the klaw and approach at less than 1 m/s. Both stock drills can mine graviolium.

Oh, and if you have a warp ship, you can do "warp randezvous". Basically, you get within a few KM of the target (in this case an asteroid) and hit auto circularize, and the game will place your warp ship 50m away from the target. Then advance slowly, and klaw it.

[Ooglak Kerman]

1 hour ago, SkyFall2489 said:

Oh, and if you have a warp ship, you can do "warp randezvous". Basically, you get within a few KM of the target (in this case an asteroid) and hit auto circularize, and the game will place your warp ship 50m away from the target. Then advance slowly, and klaw it.

This is the strategy for Jeb on board WS-8675309 "Hold Mah Beer" (I regret this naming).   Be patient approaching your target in warp lest you splash yourself across it.  Having a gravatic engine onboard makes final approach right easy.  It uses the RCS commands and the level of control is so much better.
You will really want to have the full size drills. Those dinky little small ones are pretty slow.  In the past the ratios for making fusion pellets was kinda (extremely) difficult but they may have been adjusted.

Edited June 2, 2022 by Ooglak Kerman

[Angelo Kerman]

1 hour ago, Ooglak Kerman said:

This is the strategy for Jeb on board WS-8675309 "Hold Mah Beer" (I regret this naming).   Be patient approaching your target in warp lest you splash yourself across it.  Having a gravatic engine onboard makes final approach right easy.  It uses the RCS commands and the level of control is so much better.
You will really want to have the full size drills. Those dinky little small ones are pretty slow.  In the past the ratios for making fusion pellets was kinda (extremely) difficult but they may have been adjusted.

This is what I currently have for making fusion pellets:

@PART[ISRU]:NEEDS[!WildBlueTools,!FarFutureTechnologies]
{
	MODULE
	{
		 name = ModuleResourceConverter
		 ConverterName = Fusion Pellets
		 StartActionName = Start Fusion Pellets
		 StopActionName = Stop Fusion Pellets
		AutoShutdown = true
		TemperatureModifier
		{
			key = 0 100000
			key = 750 50000
			key = 1000 10000
			key = 1250 500	
			key = 2000 50	
			key = 4000 0
		}				
		GeneratesHeat = true
		DefaultShutoffTemp = .8
		ThermalEfficiency 
		{
			key = 0 0 0 0
			key = 500 0.1 0 0
			key = 1000 1.0 0 0
			key = 1250 0.1 0 0
			key = 3000 0 0 0 
		}


		UseSpecialistBonus = true
		SpecialistEfficiencyFactor = 0.2
		SpecialistBonusBase = 0.05
		UseSpecialistHeatBonus = true
		SpecialistHeatFactor = 0.1
		ExperienceEffect = ConverterSkill
		EfficiencyBonus = 1
		resourceOutputName = Fusion Pellets

		 
		 INPUT_RESOURCE
		 {
			ResourceName = Ore
			Ratio = 0.001
			FlowMode = STAGE_PRIORITY_FLOW
  		 }
		 INPUT_RESOURCE
		 {
			ResourceName = ElectricCharge
			Ratio = 30
		 }
		 OUTPUT_RESOURCE
	 	 {
			ResourceName = FusionPellets
			Ratio = 0.00045
			DumpExcess = true
			FlowMode = ALL_VESSEL
		 }
	}
}

 

[Ooglak Kerman]

Yes.  I use the stock large ISRU for my fusion pellet needs and will admit to a small tweak to make it work with KFS installed.
What I referred to was the requirement for the microISRU to make fusion pellets from Ore, water, minerite, and hexagen

[Angelo Kerman]

Today I got the Mk2 Bussard Collector up and running:

Next I need to make the Mk2 Plasma Vent.

[Ooglak Kerman]

I need to make sexy MK2 stuff on which to hang cool WildBlue tech

[Ooglak Kerman]

@Angel-125 I only tried briefly to mess with the K-pad.  It doesn't appear that it can be equipped to a Kerbal.  Is this true or am I missing something?

Edit:  Sorry, was confusing with a mod that gives beercans that I couldn't get to work.  Don't have KIS installed so no KPad

 

Edited June 3, 2022 by Ooglak Kerman

[Angelo Kerman]

Last image for the night: the Mk2 Plasma Vent:

[modus]

And first image of the morning here!

 

[Angelo Kerman]

Are there any config changes needed for SpaceDust at this point? I am aiming for a release this weekend. As this will be the final release for some time, here are some pre-release notes:

Changes

New Parts

- Mk2 Bussard Collector: This collector collects particles while at warp similar to the S1 and S2 Bussard Collectors.

- Mk2 Plasma Vent: This part vents plasma and eliminates Static Charge when Kerbal Flying Saucers is installed. Without it, it just looks cool.

WBIJumpGate

- Jumpgates will no longer automatically activate when there are only two gates in the network unless the autoActivate flag in WBIJumpGate is set.

- Added the ability to switch vesel focus back to the source jumpgate after making the jump. This makes it easier to bring multiple vessels through the gate.

WBIWarpEngine & Settings

- Added warpEngineerSkill to the global settings.cfg file, and changed the default value for WBIWarpEngine's warpEngineerSkill to an empty value. If WBIWarpEngine's warpEngineerSkill is defined, then it will override the global warpEngineerSkill value.

- Added warpSpeedBoostRank to the global settings.cfg file, and changed the default value for WBIWarpEngine's warpSpeedBoostRank to -1. If WBIWarpEngine's warpSpeedSkiwarpSpeedBoostRank is greater than 0, then it will override the global warpSpeedBoostRank value.

- Added warpSpeedSkillMultiplier to the global settings.cfg file, and changed the default value for WBIWarpEngine's warpSpeedSkillMultiplier to -1. If WBIWarpEngine's warpSpeedSkillMultiplier is greater than 0, then it will override the global warpSpeedSkillMultiplier value.

Fixes

- Fixed NREs generated during part loading.
- Fixed texture issues with mk2 warp tech parts.