FlexGunship

August 28, 2020

I'm having a really cool bug where any atmosphere (Kerbin, Laythe) glows iridescent white-hot... it looks like the atmosphere is burning.

I tried tweaking scatterer (and then disabling everything in the config) but to no avail. Any thoughts?

April 24, 2017

1 hour ago, Galileo said:

You may have not noticed in your other game, but when using scatterer, GPP clouds, and all of the optional mods, ksp will use roughly 10gb and even more on Mac and Linux.. That's without part packs. It has been that way since 1.1 and probably earlier. So when you say "plenty of other mods" 13gb is pretty good. My game, with my 85 other mods installed, hits 16-18gb and has since before 1.1.

Just for reference: SVE and SVT (much smaller mods) when used together, use about it 5.6gb.

Well, I'll certainly take your word for it. I opened up my backup game (same mods, same 6.4x GPP, only different SD and GPP versions) and, on the launch pad, with the same rocket, I get 4,076MB (old version) versus 12,968MB (new version).

I will take this as evidence that other folks are NOT having this problem and I will work on it for myself (i.e. fresh install, log file investigation, module manager messages, etc.).

My hunch is that there's a circular reference with the "career saver" config file. I don't have any evidence to support this. Wish me luck! I'll let you know if I sort it out.

April 23, 2017

Hey all,

After updating from GPP version 1.1 to 1.2.2 (using the "save career" config file, if that matters), I now see that KSP takes up 13GB of RAM (compared to 5.6GB before the change) and makes the game entirely unplayable. When I updated the GPP version, I also updated Sigma Dimensions to the latest version. The install uses the 6.4x resize and includes plenty of other mods.

I'm working on debugging it myself via the log file, but right now I'm just wondering if anyone else is having a similar experience.

I have my pre-update game backed-up, so this isn't crippling, just wondering if this is a common experience.

Thanks!

March 27, 2017

I think this is a pretty good idea... is there any way that this new set of limitations could help improve compatibility with "Kerbal Research and Development"? I wish I had a stronger understanding of the blacklisting that happens between these mods, but I love TweakScale and Kerbal R&D both so much. I almost always manually black listing engines from TweakScale just so I can R&D them.

November 7, 2016

3 hours ago, Dre4dW0rm said:

3.3.7 no longer works in the KSP 1.1.3. The X/C functionality is back to stock, and there's no button in the toolbar.

Confirmed. Same here. Uninstalled through CKAN. Looking for the previous version now.,

April 30, 2016

29 minutes ago, blowfish said:

ModuleManager 2.6.23 is not compatible with KSP 1.1.2 (probably could have guessed that it was that without looking at the logs).

Wow, good catch. I appreciate the quick response. I saw that it was updated to 2.6.24 but didn't even think to see if it had been added to ckan. Just went back to check and there seems to be a bug in ckan. It shows that 2.6.23 is installed and that the latest version is 2.6.24 but doesn't offer the "update" check box.

April 30, 2016

13 hours ago, blowfish said:
I think I figured it out. Kopernicus has a hard KSP version checker which will cause it to disable itself on anything but the exact version of KSP it was compiled against. In this case, that's 1.1.0.
[WRN 19:08:26.360] [Kopernicus] Detected incompatible install.
Current version of KSP: 1.1.1.
Supported version of KSP: 1.1.0.
Please wait, until Kopernicus gets updated to match your version of KSP.
[LOG 19:08:26.361] [Kopernicus] Aborting...
Nothing that can be done until Kopernicus updates.

Updated Kopernicus to v1.0.3 which is compatible with KSP v.1.1.2 (the latest release). I'm still seeing the same issue; nothing seems to rescale. However, there is significant change to log files.

https://www.dropbox.com/sh/0vhyxfk20ilwhb7/AABvM2-NN_GgT8gWlzEzjqf0a?dl=0

It looks like it was successful?? But no change in game experience.

//=============================================================================================================//
//=====  Kopernicus 1.0.3 - (BuildDate: 30.04.2016 08:31:16; AssemblyHash: 9AaUB43ZZtDXuEYjgwJORmZ/eTs=)  =====//
//=============================================================================================================//
[LOG 12:12:56]: Logger "Kopernicus" was created
[LOG 12:12:56]: Injector.Awake(): Begin
[LOG 12:12:56]: Parsing Target name in (Kopernicus.Configuration.Loader) as (System.String)
[LOG 12:12:56]: Parsing Target timeScale in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Double])
[LOG 12:12:56]: Parsing Target scale in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Double])
[LOG 12:12:56]: Parsing Target Epoch in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Double])
[LOG 12:12:56]: Parsing Target useOnDemand in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Boolean])
[LOG 12:12:56]: Parsing Target onDemandLoadOnMissing in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Boolean])
[LOG 12:12:56]: Parsing Target onDemandLogOnMissing in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Boolean])
[LOG 12:12:56]: Parsing Target mainMenuBody in (Kopernicus.Configuration.Loader) as (System.String)
[LOG 12:12:56]: Parsing Target maxViewingDistance in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Double])
[LOG 12:12:56]: Parsing Target scaledSpaceFaderMult in (Kopernicus.Configuration.Loader) as (Kopernicus.Configuration.NumericParser`1[System.Double])
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Sun
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Moho
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Eve
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Gilly
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Kerbin
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Mun
[LOG 12:12:56]: [Kopernicus]: Configuration.Loader: Loaded Body: Minmus
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Duna
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Ike
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Dres
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Jool
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Laythe
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Vall
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Tylo
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Bop
[LOG 12:12:57]: [Kopernicus]: Configuration.Loader: Loaded Body: Pol
[LOG 12:12:58]: [Kopernicus]: Configuration.Loader: Loaded Body: Eeloo
[LOG 12:12:58]: [Kopernicus]: Configuration.Loader: Loaded Asteroid: Stock
[LOG 12:12:58]: Injector.Awake(): Completed in: 1977.9692 ms
[LOG 12:12:58]: StarLightSwitcher.Start() => Sun
[LOG 12:12:58]: Found Body: Sun:0 -> SOI = Infinity, Hill Sphere = Infinity
[LOG 12:12:58]: Found Body: Kerbin:1 -> SOI = 84159286.4796305, Hill Sphere = 196414707.77848
[LOG 12:12:58]: Found Body: Mun:2 -> SOI = 2429559.11656475, Hill Sphere = 3170563.33757116
[LOG 12:12:58]: Found Body: Minmus:3 -> SOI = 2247428.3879023, Hill Sphere = 3730392.49065433
[LOG 12:12:58]: Found Body: Moho:4 -> SOI = 9646663.0233281, Hill Sphere = 22060314.8155466
[LOG 12:12:58]: Found Body: Eve:5 -> SOI = 85109364.7382441, Hill Sphere = 185949494.965972
[LOG 12:12:58]: Found Body: Duna:6 -> SOI = 47921949.369738, Hill Sphere = 125063736.748336
[LOG 12:12:58]: Found Body: Ike:7 -> SOI = 1049598.93931162, Hill Sphere = 1225978.58343315
[LOG 12:12:58]: Found Body: Jool:8 -> SOI = 2455985185.42347, Hill Sphere = 4065824625.34358
[LOG 12:12:58]: Found Body: Laythe:9 -> SOI = 3723645.81113302, Hill Sphere = 5186318.66159496
[LOG 12:12:58]: Found Body: Vall:10 -> SOI = 2406401.44479404, Hill Sphere = 3893201.55262435
[LOG 12:12:58]: Found Body: Bop:11 -> SOI = 1221060.86284253, Hill Sphere = 2029674.44211376
[LOG 12:12:58]: Found Body: Tylo:12 -> SOI = 10856518.3683586, Hill Sphere = 14757877.6267184
[LOG 12:12:58]: Found Body: Gilly:13 -> SOI = 126123.271704568, Hill Sphere = 142427.423478875
[LOG 12:12:58]: Found Body: Pol:14 -> SOI = 1042138.89230178, Hill Sphere = 2038945.47430365
[LOG 12:12:58]: Found Body: Dres:15 -> SOI = 32832839.5767762, Hill Sphere = 92059713.5005964
[LOG 12:12:58]: Found Body: Eeloo:16 -> SOI = 119082941.647812, Hill Sphere = 266016718.015223
[LOG 12:12:58]: Injector.OnDestroy(): Complete
[LOG 12:12:59]: [Kopernicus]: RuntimeUtility Started
[LOG 12:12:59]: StarLightSwitcher.Awake(): Begin

April 30, 2016

28 minutes ago, blowfish said:

Thanks for providing those, but I don't think you've actually described the problem yet. Does the solar system not rescale? Are you seeing visual artifacts, or getting a crash?

The game is identical to pre-installation of 64k. The mod had no discernible effect.

Edit: i could switch into full SQA mode if you want... but i was mostly just commenting on the previous poster, and then (when he didn't respond with logs) I filled in for him.

April 30, 2016

37 minutes ago, blowfish said:

"It won't work" is pretty vague. Could you describe the problem in detail? Logs would be nice as well.

Here's mine... butt loads of mods.

https://dl.dropboxusercontent.com/u/28426566/KSP%2064k%20Log%20-%204-29-2016/KSP.log

EDIT: Here's the entire Kopernicus log, also:

//=============================================================================================================//
//=====  Kopernicus 1.0.2 - (BuildDate: 24.04.2016 03:19:54; AssemblyHash: EVPtIOBJH9b3mJFDeu/9aNjb1VI=)  =====//
//=============================================================================================================//
[LOG 19:08:26]: Logger "Kopernicus" was created
[LOG 19:08:26]: Injector.OnDestroy(): Complete

April 30, 2016

18 minutes ago, OzEtkin said:

I tried installing 64K with Kopernicus 1.0.1 and 1.0.2, as well as Module Manager 2.6.23 and 2.6.22, but it won't work. I'm not sure if I'm doing something wrong, and thanks for any help.

6 hours ago, Sandworm said:

If you look a few posts back, I posted a link with a temp fix for this heating bug. It's been with Kopernicus/64k for a long while.

https://www.dropbox.com/s/ll4660khksuo29z/64k_Temp_Fixes_for_KSP1.1.rar?dl=0

For what it's worth, I can't seem to get 64k working either. I've tried it with Kop 1.0.2 and without the cache files in Sandworm's fix. And I've tried it with it. I'm still seeing a normal sized Kerbin. So, you're not alone OzEtkin. I think weought'a just wait for the official release.

December 13, 2015

On 12/10/2015, 8:54:14, NecroBones said:

Glad to help! I'm curious to see what you come up with, if you get it working.

For what it's worth, I've given up for now. I tried creating a few of my own dummy parts just to test the parsing of fields that are separated both by commas and semi-colons and I don't see a way to do it. I wrote a python script to just go through *.cfg files and make the changes I want (for now).

December 10, 2015

I'm trying to go through configurable tanks and re-volume them. Below is what I have (no errors, but no success). Ironically, it doesn't ruin the part as I thought it would. I expected to fail because entries in "resourceAmounts" are not exclusively comma delimited. So my hunch was that when I replaced resource amounts, var* would be empty and I'd get a bunch of zeros.

But that's not what happened... instead, there was no discernible effect at all. I included a sample part in the example.

@PART[TPtank1m0mA]:FOR[FuelTanksPlus]:NEEDS[!InterstellarFuelSwitch|InterstellarFuelSwitch&!CryoEngines]
{
	MODULE
	{
		name:NEEDS[!InterstellarFuelSwitch|CryoEngines] = FSfuelSwitch
		name:NEEDS[InterstellarFuelSwitch&!CryoEngines] = InterstellarFuelSwitch
		resourceGui:NEEDS[InterstellarFuelSwitch] = LiquidFuel+Oxidizer;LiquidFuel;Oxidizer
		resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer
		resourceAmounts = 45,55;90;110
		basePartMass = 0.0625
	}
}   

@PART[TP*]:HAS[MODULE[FSfuelSwitch]]
{
	@MODULE[FSfuelSwitch]
	{
		var0 = #$resourceAmounts[0]$
		var1 = #$resourceAmounts[1]$
		var2 = #$resourceAmounts[2]$
		var3 = #$resourceAmounts[3]$
		@var0 *= 1.5
		@var1 *= 1.5
		@var2 *= 1.5
		@var3 *= 1.5
		@resourceAmounts = #$var0$,$var1$;$var3$;$var4$
	}
}

@PART[TP*]:HAS[MODULE[InterstellarFuelSwitch]]
{
	@MODULE[InterstellarFuelSwitch]
	{
		var0 = #$resourceAmounts[0]$
		var1 = #$resourceAmounts[1]$
		var2 = #$resourceAmounts[2]$
		var3 = #$resourceAmounts[3]$
		@var0 *= 1.5
		@var1 *= 1.5
		@var2 *= 1.5
		@var3 *= 1.5
		@resourceAmounts = #$var0$,$var1$;$var3$;$var4$
	}
}

Any suggestions? Or is this not supported in MM?

December 9, 2015

9 hours ago, NecroBones said:
Yep, the "volume" number will only come into play with ModularFuelTanks, and I'm not sure how much that and InterstellarFuelSwitch (IFS) cooperate with each other (that part would be a question or them).

But outside of that, the IFS configs take precedence over the part's own settings, if you have IFS installed. You'll also need to modify MODULE[InterstellarFuelSwitch]. The amounts are stored in the variable "resourceAmounts", but it's a list that's comma & semicolon separated, for each of the configurations. So I don't think this will work with a simple math function.

For example, for the same fuel tank, here's the MM config used for IFS:
@PART[TPtank2mL05625]:FOR[FuelTanksPlus]:NEEDS[!InterstellarFuelSwitch|InterstellarFuelSwitch&!CryoEngines]
{
	MODULE
	{
		name:NEEDS[!InterstellarFuelSwitch|CryoEngines] = FSfuelSwitch
		name:NEEDS[InterstellarFuelSwitch&!CryoEngines] = InterstellarFuelSwitch
		resourceGui:NEEDS[InterstellarFuelSwitch] = LiquidFuel+Oxidizer;LiquidFuel;Oxidizer
		resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer
		resourceAmounts = 2160,2640;4320;5280
		basePartMass = 3
	}
}

Okay. Thanks for the quick response. I've used variables in module manager before to change ISP curve, so I think I'll be able to parse it out if given enough time. I used ckan, and I think it was this mod that suggested modular fuels...I could be wrong. That why I incorrectly assumed they were linked.

December 9, 2015

This might be the wrong place (I posted in Fuel Tanks plus also), but I can't seem to modify the volume of these special tanks via module manager. When I use the following, I see the volume increase in the part selector, but once I place the part the volume returns to normal.

@PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[FuelTanksPlus]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume *= 1.5
	}
}

@PART[*]:HAS[@RESOURCE[LiquidFuel]]:AFTER[FuelTanksPlus]
{
	@RESOURCE[LiquidFuel]
	{
		@amount *= 1.5
		@maxAmount *= 1.5 
	}
}

@PART[*]:HAS[@RESOURCE[Oxidizer]]:AFTER[FuelTanksPlus]
{
	@RESOURCE[Oxidizer]
	{
		@amount *= 1.5
		@maxAmount *= 1.5 
	}
}

The result is what you see below:

%7Boption%7D http://imgur.com/gAeIssJ (compare the right-click volume to the part selector volume)

December 9, 2015

I suspect this is the wrong place (I'm also going to post in Interstellar Fuel Switch also), but I can't seem to modify the volume of the tanks via module manager. When I use the following, I see the volume increase in the part selector, but once I place the part the volume returns to normal.

@PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[FuelTanksPlus]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume *= 1.5
	}
}

@PART[*]:HAS[@RESOURCE[LiquidFuel]]:AFTER[FuelTanksPlus]
{
	@RESOURCE[LiquidFuel]
	{
		@amount *= 1.5
		@maxAmount *= 1.5 
	}
}

@PART[*]:HAS[@RESOURCE[Oxidizer]]:AFTER[FuelTanksPlus]
{
	@RESOURCE[Oxidizer]
	{
		@amount *= 1.5
		@maxAmount *= 1.5 
	}
}

The result is what you see below:

%7Boption%7D http://imgur.com/gAeIssJ (compare the right-click volume to the part selector volume)

August 8, 2015

I'll go read the source code and get back to you when/if I see the answer in it.
- - - Updated - - -
I'm looking at source now, but did you every try it like this?
key0 = #$key,0$
@key0 = #$key0[1]$
@key0 *= 1.3
@key,0 = #0 $key0$
- - - Updated - - -
Hmmm might have figured it out... maybe?
key0 = #$key,0[1, ]$
@key0 *= 1.3
@key,0 = #0 $key0$

Tried the first... not the second. Will try the second now.

EDIT: you tricked me! You edited between my refreshes. I was about to replay... "wait, that won't work".

DOUBLE EDIT: Well... this will be the FIRST time I've ever used variables on atmosphereCurve and didn't get an error.

- - - Updated - - -

Felbourn, you're a genius. It works. It actually works. I thought I had a typo, but when I checked in game values, it was fine. so I'm unclear as to what "0[1, ]" and "1[1, ]" actually do. Well, I know what they do... I don't really know why.


@PART[*]:HAS[@MODULE[ModuleEngines*]]
{	
	@MODULE[ModuleEngines*]
	{
		@heatProduction *= 0.33	

		@atmosphereCurve
		{
			key0 = #$key,0[1, ]$
			@key0 *= 1.3
			@key,0 = #0 $key0$
			key1 = #$key,1[1, ]$
			@key1 *= 1.3
			@key,1 = #1 $key1$	
		}			
	}
}

August 8, 2015


        @atmosphereCurve
        {           
            @key,0 = #0 $/VARS/isp_v$
            @key,1 = #1 $/VARS/isp_sl$
        }

Okay, I came close to this part. I didn't see any evidence of it doing anything. do I need a different /VAR/ for every single engine? MM completes one modification before moving on, right? So I should be able to use the same convention. But, this doesn't take the value and actually modify it, right? In fact, as near as I can tell, it writes a value indiscriminately.

- - - Updated - - -

@PART[yourPartName]
{
    @MODULE[ModuleEngines*]
    {
        @atmosphereCurve
        {           
            key0 = #$key,0[1]$
            @key0 *= 1.3
            key1 = #$key,1[1]$
            @key1 *= 1.3
            @key,0 = #0 $key0$
            @key,1 = #1 $key1$
        }
    }
}

Spoiler alert... that doesn't work. You've latched on to the exact problem. There seems to be no way to get to that second value.

EDIT: Uh, okay, upon a closer look. I have NOT tried exactly what you posted. It looked like something I did try.

- - - Updated - - -

Okay, I came close to this part. I didn't see any evidence of it doing anything. do I need a different /VAR/ for every single engine? MM completes one modification before moving on, right? So I should be able to use the same convention. But, this doesn't take the value and actually modify it, right? In fact, as near as I can tell, it writes a value indiscriminately.
- - - Updated - - -
Spoiler alert... that doesn't work. You've latched on to the exact problem. There seems to be no way to get to that second value.
EDIT: Uh, okay, upon a closer look. I have NOT tried exactly what you posted. It looked like something I did try.

DOUBLE EDIT: Okay, yes, same message I got before (doing it a different way)... essentially it can't grab ONLY the second entry.


[LOG 20:33:21.326] [ModuleManager] Error - Failed to do a maths replacement: @atmosphereCurve : original value="0 210" operator=* mod value="1.3"
[LOG 20:33:21.327] [ModuleManager] Error - Failed to do a maths replacement: @atmosphereCurve : original value="1 175" operator=* mod value="1.3"

August 8, 2015

I'm becoming somewhat of a MM master at this point. I'm "reprogramming" my entire game with it to change balance, and well... everything. I even used MM to quite a generic square root function that I use for a few calculations when altering mass values! I can help you out Flex. But I'm not 100% sure what you're asking still. You just want to change the Isp vsalues for one atmo curve in one engine?

No, I'd like scale the ISP of all LFO engines up by about 30%.

Example... take:

atmosphereCurve

{

key = 0 400

key = 1 300

}

...and make that...

atmosphereCurve

{

key = 0 533

key = 1 400

}

EDIT:

Right now I'm... kinda... doing this by:


@RESOURCE_DEFINITION[LiquidFuel]
{
	@density *= 0.7
}

@RESOURCE_DEFINITION[Oxidizer]
{
	@density *= 0.7
}

Double Edit: To be clear, I gave an example above, but I'd like to hit all engines with an equivalent scale.

August 7, 2015

Sigh... I'm officially too stupid for this (which I didn't expect, I write motion control software for a living).

I just want to take atmosphereCurve and rescale it to improve fuel economy for 64k. I've tried standard edits, and not variables. I can't seem to get the data out and modify only the ISP by some multiplier.

Has anyone done this successfully? Or is there a module manager file for a mod that does this that I can reference?

August 5, 2015

I don't think you're going to be able to do that the way you want. You might have to use variables instead as detailed here: http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253

Okay, thanks. I haven't seen anything about a parsing values (which would allow me to pull apart the data inside the "key = x y" in x and y), and I think that's a necessary step for generating the source value for the variable. But... trial-and-error will tell!

I don't think FloatCurve values can be edited with simple math. It's two or four numbers separated by spaces, and I don't believe MM knows what to do with that. As Starwaster mentioned, you might be able to do something with variables, though I don't know how you'd isolate the individual values in the first place.

Got it, thanks. Yes, parsing the information out of a space-delimited string(?) seems to be the principle challenge.

August 5, 2015

Okay, I did my best to hunt this down. I've read the ModuleManager handbook and syntax guides, I've reviewed all of the examples that are linked in there, and I just finished searching this thread.

I know there are similar questions, but I haven't seen this one.

I want to perform arithmetic on the second entry of each index of atmosphereCurve while leaving the first in tact. (This is to make 64k somewhat easier from a delta-v stance, but not a thrust/construction stance.) I've tried the following:

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 *= 1 *= 1.33
@key,1 *= 1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,0 = 0
@key,0 *= 1.33
@key,1 = 1
@key,1 *= 1.33
}
}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
@MODULE[ModuleEngines*]
{
@heatProduction *= 0.66

@atmosphereCurve
{
@key,*,1 *= 1.33
}
}
}

I usually tackle these things on my own, but this one is besting me. Any thoughts?

August 1, 2015

I think I have a bug to report; I'm scared because it's so similar to others that already have solutions. Here goes:

Description: "Shape" right-click UI element only rarely appears (i.e. about 1 in 10 new designs)

Mod version: 1.1.7 (0)

KSP version: 1.0.4

Attempted solutions (none have worked):

1) Based on this thread, I checked each mod for KSPAPIExtensions.dll and verified version (all are at v1.7.5; three mods have this file, none have older versions)

2) Wrote a ModuleManager config to overwrite all of the techRequired elements:

@PART[*] 
{
    @MODULE[ProceduralShape*]
    {
        @techRequired = start
    }
}

On the next startup, I validated that my "modules editted" value increased by some number.

3) I took a part which DID have the "shape" menu (procedural tank), ALT+LeftClick'd to create a copy, added it as a sub-assembly. When pulling from the sub-assembly menu, the part loses the "shape" UI element.

4) Used Alt+F12 to refresh the techtree.

Other details: All other UI elements show. Parts that already show the "shape" UI element, still allow the shape to be changed.

EDIT: Sigh... I posted five minutes too soon. "Reload Parts and Rebuild Tree" worked. The "shape" UI element has returned!

DOUBLE EDIT: IT'S GONE AGAIN!! Reloading and rebuilding the tech tree works once, and then the "shape" UI element is gone on scene change.

TRIPLE EDIT: The Xenon tank "shape" menu shows 100% of the time, so I opened both .cfg files to compare. Then I realized I shouldn't even have access to Xenon tanks!! I guess it's time for a clean KSP install.

OVER EDIT!!: Figured it out. Something corrupted my "ModuleManager.TechTree". I restored it from a different install and it seems okay. Context menus are back.

August 1, 2015

A solution was presented here. Worked for me https://github.com/BryceSchroeder/Kopernicus/issues/48

Confirmed... this resolved my issue as well. At least for now!

The link referenced indicates that one should change these entries in the Survey{} section of contracts.cfg.


		//TrivialHomeNearbyRange = 2000
		//SignificantHomeNearbyRange = 4000
		//ExceptionalHomeNearbyRange = 6000
		TrivialHomeNearbyRange = 200000
		SignificantHomeNearbyRange = 400000
		ExceptionalHomeNearbyRange = 600000

July 18, 2015

I've just tried a fresh install of stock v1.0.4. I got Kronal Vessel Viewer via the CKAN (results are the same if I download directly from GitHub). Th image shows a single capsule in the VAB with the KVV window open. Not only does the live pre-view not work but the resulting screenshot looks just like the preview.

Has anyone seen this? KVV used to work for me, but it hasn't since v1.0.4. Again, this is a clean install (from Steam) with only KVV installed.

June 27, 2015

Further to the last post about editor extensions being upgraded to the wrong version. Does ckan read the software number as decimal? i.e the latest version 2.12 is not being installed as it should, but instead its installing 2.2 which is an older version.

I posted this in the Editor Extensions thread. You can verify that it's true by changing the values in the registry.json file.

This will hide a mod from showing in the application:


"ksp_version_max": "1.0.30",
"ksp_version_min": "1.0.0",

But this will show it:


"ksp_version_max": "1.0.4",
"ksp_version_min": "1.0.0",

So, ckan thinks that *.30 < *.4

Honestly, if I had to suggest anything to the amazing developers of ckan (and, seriously, ckan is AMAZING), there needs to be a hidden "pro-mode" where you can override the the version you're running and the folder. I have the same two problems repeatedly:

1) I'm not allowed to install a mode without editing the .json file despite knowing that a particular mod works with my version (or wanting to test it... yes, yes... manual install...)

2) I have always kept several installs of KSP on my desktop (RSS, last stable, stock, etc.) but ckan hates desktop folders and lists them as invalid installs.

I think I understand why those are there (to protect the little nooblets from hurting themselves and then complaining to modders or the ckan devs), but I'd like a super secret "pro-mode" that let's me override some of these things without editing the .json file.

Maybe when you enable it, the owner of every mod you install gets your username. And if you do anything other than post constructive bug reports you get an instant perma-ban from the forum and Harvester calls you a "industrial poo inhaler" on the KSP website.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by FlexGunship