[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[AccidentalDisassembly]

There is an issue with how TweakScale deals with tech stuff, and it prompted me WAAAAAAY back before Lisias' time to request a change in how TS handles tech. Didn't get traction, sadly. But if you walk through what will actually happen if you define things like you're proposing, there is an issue because specific techs are tied to specific scaleFactor values, not to ***relative*** scale sizes. I will try to illustrate, please correct me if I am not understanding how this actually works.

For the sake of clarity, let's assume there are only 6 techs in the game (Tech1-Tech6) and only 2 parts in the game (a 0.625m PartTiny, and a 5m PartBig).

Let's also just assume that PartTiny gets unlocked when Tech1 is discovered, and PartBig gets unlocked when Tech2 is discovered.

Now, assuming you use this:

{
	name = stack
	freeScale = true //This here causes other problems with tech unlocking + scaling
	defaultScale = 1.25
	suffix = m
	scaleFactors   = 0.625, 1.25, 2.5, 3.75, 5, 7.5
	incrementSlide = (doesn't matter for the purposes of the example)
	techRequired   = Tech1, Tech2, Tech3, Tech4, Tech5, Tech6
}

PartTiny unlocks at Tech1, but can't be scaled yet. Unlocking Tech2 allows it to be either 0.625m or 1.25m. However, because it can freeScale, It can most likely be scaled to 1.249999999 before unlocking Tech2 - not that big a problem, but it's a limitation of using freeScale in conjunction with tech unlocks.

That makes sense - you discover the next tech (Tech2 is after Tech1), you get to scale the part. However, now you've unlocked PartBig at Tech2. When it is unlocked, the possible scales available to it are 5.0m AND 1.25m AND 0.625m - but only those 3 scales.  You can see how that's a little funky. Then you discover Tech3, the scaleFactors available for PartBig will be: 0.625m, 1.25m, 2.5m, 5m. Specific techs allow specific diameters, not changes in diameter.

In theory, the way a user would expect it to work is: a part can be scaled more and more (maybe only up, maybe up AND down, maybe only down, depending) the more tech nodes are unlocked after the part's own tech node. Or maybe the logic would be more similar to: "This part can't get smaller than it is right now (not than a specific diameter) until you unlock [Tech X]." Neither case can be covered by how TS works now without a huge number of custom patches. Using a different SCALETYPE (like surface, or free, or other types that aren't related to diameters) doesn't really fix the problem, because you still have to write scaletypes or patches for every flavor of part.

The more parts you introduce, the more it breaks down: imagine a part that unlocks at Tech 6, but it's a 0.625m part, and you don't want it to be able to scale to 2.5m until Tech 7... Thus you have to define a very large number of SCALETYPEs (or unique patches per part, alternatively) to account for different parts of different sizes unlocking at different nodes and needing other, different nodes to unlock other sizes.... 

I think that it would be necessary to implement a different logic to handle things in the way the user would expect (go farther in tech tree = more options for a given part). Something like:

Part's max/min scale = its original scale +/- one scaleFactor per tech node unlocked after (in the tech tree) its own tech node.

Or you could make TS recognize something like this:

@PART[thepart]
{
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 5.0 (or whatever)
		%ScaleUpTechs = TechNodeName, TechNodeName, TechNodeName... // first node allows one upward increment in the SCALETYPE, 2nd allows two, last unlocks embiggening completely
		
		%ScaleDownTechs = TechNodeName //If there's just one name here, then discovering this tech lets you do any scale < original
        // Or, if ScaleUpTechs and ScaleDownTechs aren't defined for the part, then it can scale freely from the start
        // Or, you could use a different logic, like:
        %ScaleUpTechs = 1 //One node after the part's node is required for each increase in scale defined in the SCALETYPE
	}
}

There are probably other (and better) ways of doing it than that!

Edited May 13, 2020 by AccidentalDisassembly

[Lisias]

2 hours ago, AccidentalDisassembly said:

There is an issue with how TweakScale deals with tech stuff, and it prompted me WAAAAAAY back before Lisias' time to request a change in how TS handles tech. Didn't get traction, sadly. But if you walk through what will actually happen if you define things like you're proposing, there is an issue because specific techs are tied to specific scaleFactor values, not to ***relative*** scale sizes. I will try to illustrate, please correct me if I am not understanding how this actually works.

Hummm.. tricky to understand, I think I did it - but not exactly sure. But I see your point, at least...

 

2 hours ago, AccidentalDisassembly said:

For the sake of clarity, let's assume there are only 6 techs in the game (Tech1-Tech6) and only 2 parts in the game (a 0.625m PartTiny, and a 5m PartBig).

Let's also just assume that PartTiny gets unlocked when Tech1 is discovered, and PartBig gets unlocked when Tech2 is discovered.

PartTiny unlocks at Tech1, but can't be scaled yet. Unlocking Tech2 allows it to be either 0.625m or 1.25m. However, because it can freeScale, It can most likely be scaled to 1.249999999 before unlocking Tech2 - not that big a problem, but it's a limitation of using freeScale in conjunction with tech unlocks.

It looks more like a flaw on the code when limiting things. Since Tech Tress were never effectively used before, I can fix this behaviour with little to no fuss on the status quo. One can only freeScale towards an already unlocked scaleFactor.

 

2 hours ago, AccidentalDisassembly said:

That makes sense - you discover the next tech (Tech2 is after Tech1), you get to scale the part. However, now you've unlocked PartBig at Tech2. When it is unlocked, the possible scales available to it are 5.0m AND 1.25m AND 0.625m - but only those 3 scales.  You can see how that's a little funky. Then you discover Tech3, the scaleFactors available for PartBig will be: 0.625m, 1.25m, 2.5m, 5m. Specific techs allow specific diameters, not changes in diameter.

How about a Tech allowing to freeScale the part? The techRequired would unlock the diameter, as you specified. And another Tech would be required to allow freeScale between the diameters.

That would include a handicap also on parts that are already freeScale.

 

2 hours ago, AccidentalDisassembly said:

In theory, the way a user would expect it to work is: a part can be scaled more and more (maybe only up, maybe up AND down, maybe only down, depending) the more tech nodes are unlocked after the part's own tech node. Or maybe the logic would be more similar to: "This part can't get smaller than it is right now (not than a specific diameter) until you unlock [Tech X]." Neither case can be covered by how TS works now without a huge number of custom patches. Using a different SCALETYPE (like surface, or free, or other types that aren't related to diameters) doesn't really fix the problem, because you still have to write scaletypes or patches for every flavor of part.

Or specify behaviours for groups of parts. The problem you are pinpointing appears to be already solved, besides not specifically to the Tech problem.

You can even specify different Techs for different parts - scaling a Engine would need a different set of Techs than scaling a Wing.

-- -- -- 

I will give a another look on the rest of the post later, it's after work now and I'm somewhat tired of thinking.  Tomorrow morning I will reread this, with a fresh mind, and retake from here.

[AccidentalDisassembly]

25 minutes ago, Lisias said:

Hummm.. tricky to understand, I think I did it - but not exactly sure. But I see your point, at least...

It looks more like a flaw on the code when limiting things. Since Tech Tress were never effectively used before, I can fix this behaviour with little to no fuss on the status quo. One can only freeScale towards an already unlocked scaleFactor.

The freescaling issue could be resolved easily no doubt.

But for the rest, it's not an error in the code, it's simply the core logic of how TweakScale works with techs, which is not capable of doing things in such a way that would make sense in the game (unless you write a very large number of SCALETYPES and/or part-specific patches, and then another very large number of patches for every other tech tree (like CTT or one of the others), and every mod, and so forth - it gets insane very quickly).

Quote

How about a Tech allowing to freeScale the part? The techRequired would unlock the diameter, as you specified. And another Tech would be required to allow freeScale between the diameters.

That would include a handicap also on parts that are already freeScale.

This could be a very interesting addition, actually - it wouldn't resolve the core issue, but I think it's a cool idea!

Quote

Or specify behaviours for groups of parts. The problem you are pinpointing appears to be already solved, besides not specifically to the Tech problem.

You can even specify different Techs for different parts - scaling a Engine would need a different set of Techs than scaling a Wing.

Yes, one possible logic would be to go by groups of parts - but even then, the way TS works right now would make certain things very very difficult to implement (needing almost one SCALETYPE per part, functionally).

Try this thought experiment: You have 5 engines (E125, E1875, E250, E375, E500) with diameters 1.25, 1.875, 2.5, 3.75, 5.0. They unlock at techs T1-T5, and there is another tech, T6, somewhere in the tree. You unlock scaling for these engines when you research T6 with this SCALETYPE:

{
	name = stack_techlimited_forEngines
	defaultScale = 1.25
	scaleFactors   = 0.625, 1.25, 2.5, 3.75, 5, 7.5

	techRequired   = T6, T6, T6, T6, T6, T6
}

This is not a problem if you are ok with how it works: All parts that have this SCALETYPE will all be able to scale to all of those values (0.625 through 7.5) as soon as this tech is unlocked. The moment you define different techs for each one of those scaleFactors, the resulting behavior for scaling certain parts become illogical in most cases.

But what if you want to be able to scale E125

But now: what if T6 is a "miniaturization" tech? What if you want to make it so that all of these engines can be scaled down (and only down, and only one size smaller than their original size - which ranges from 1.25-5m - so that the "miniaturization" tech doesn't magically let you make 5m engines 0.625m? Now you have to write a new SCALETYPE for every size of engine. Then you could write a SCALETYPE for wing parts using a relative type (like surface, or free), not a big deal.

But then - what if you don't want to be able to scale down really advanced engines (that appear at T7) until you research T8? New SCALETYPE for each engine size of advanced engines.

And then - what if you want to be able to unlock engines progressively, letting you scale your earliest engines bigger and bigger the more advanced you get in tech, but NOT allowing your newest engines to be scaled really big or really small until you research a couple tech nodes beyond theirs? Now you're writing a SCALETYPE for each part size that occurs in each tech node.

So if there were an additional logic introduced, where you could create limits relative to the part's original size and also relative to the tech node that unlocked the part, it would be a much more powerful and logical system in many cases, and a whole lot easier to write patches for. 

Only some of the problem can be solved by using scaletypes that are already relative (like surface or free), but that has an additional downside, namely that ratios are a lot more annoying to use than diameters with things like fuel tanks.

Don't know if that will clarify anything...

 

 

 

[Critter79606]

@Lisias Since I've been getting this error about ModuleB9PartSwitch and ModuleFuelTanks from B9 on several parts...

and knew that tweakscale disabled it's support too, I thought I'd try to chase some of these down and disable B9PartSwitch before getting this error, and restore TS support to some of these parts.

I had 80 parts that TS withdrew support for, now I have 55.

This is what I came up with and thought I'd share in case anyone else wanted some of the TS on parts restored.  Feel free to use it!

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[Heatshield]]]:Final
{
    // clean up B9partswitch Heatshield conflict w/ ModularFuelTanks
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[Heatshield]]{}
}
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]]]:Final
{
    // clean up B9partswitch fuelSwitch conflict w/ ModularFuelTanks
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]]{}
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[meshSwitch]]{}   
}

This favors ModuleFuelTanks over B9, but that is what B9 is doing anyway.

Hope this helps someone.

 

[kcs123]

10 hours ago, Critter79606 said:

@Lisias Since I've been getting this error about ModuleB9PartSwitch and ModuleFuelTanks from B9 on several parts...

and knew that tweakscale disabled it's support too, I thought I'd try to chase some of these down and disable B9PartSwitch before getting this error, and restore TS support to some of these parts.

I had 80 parts that TS withdrew support for, now I have 55.

This is what I came up with and thought I'd share in case anyone else wanted some of the TS on parts restored.  Feel free to use it!

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[Heatshield]]]:Final
{
    // clean up B9partswitch Heatshield conflict w/ ModularFuelTanks
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[Heatshield]]{}
}
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]]]:Final
{
    // clean up B9partswitch fuelSwitch conflict w/ ModularFuelTanks
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]]{}
    !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[meshSwitch]]{}   
}

This favors ModuleFuelTanks over B9, but that is what B9 is doing anyway.

Hope this helps someone.

 

I don't think that I ever used modular fuel tanks mod, so it may be that I didn't understand something properly. But, B9PSW mod does not do anything on it's own. It is other way around, some mod like ModularFuelTanks use B9PSW plugin to be able switching between multiple parts without need to clutter SPH/VAB editor with multiple part variants.

So, if I understand MM patch above, you have removed B9PSW module from ModularFuelTanks mod and with that you have cut off muliple part variants, leaving useful only one variant type active to be used in SPH/VAB.

This most likely comes with broken config files in ModularFuelTanks mod. And it become broken on recent KSP 1.9.x updates. So, true solution for issue would be to write proper configs on those ModularFuelTanks mod, not to completely remove it.

[Lisias]

8 hours ago, kcs123 said:

I don't think that I ever used modular fuel tanks mod, so it may be that I didn't understand something properly. But, B9PSW mod does not do anything on it's own. It is other way around, some mod like ModularFuelTanks use B9PSW plugin to be able switching between multiple parts without need to clutter SPH/VAB editor with multiple part variants.

The problem is that B9 deactivates itself when Modular Fuel Tanks is installed, but doesn't ignores TweakScale callbacks, and so things go through the tubes.

I didn't figured out a way to detect an inactive B9PSW in order to suppress the callback neither.

So the only solution from TweakScale point of view is to withdraw itself from the part when more than a (known) fuel switch is detected.

I published a patch last year removing Modular Fuel Tanks when B9PSW is also detected. I priorized B9PSW exactly due the problem you detected, you lose too much functionalities.

One must carefully remove only the fuel switching code - and then flag the part with an ISSUEOVERRULE so TweakScale doesn't touch it.

 

8 hours ago, kcs123 said:

This most likely comes with broken config files in ModularFuelTanks mod. And it become broken on recent KSP 1.9.x updates. So, true solution for issue would be to write proper configs on those ModularFuelTanks mod, not to completely remove it.

Every Fuel Switch (except IFS, that just overun stock resources handling and rewrote one for itself) will have its toes stomped by the Editor, unless it sends a KSP Recall event every time it changed something.

I think I have fixed a fork of mine, but didn't had the time to test it yet.

Other than that, perhaps some Unity objects being created or called on the wrong place - also easily fixable.

Few Add'Ons are so "invasive" and overarching as TweakScale (pretty noose this one), and that's makes it a perfect Miner's Canary : if it works, then it's usually easy to fix a Parts Add'On that broke; if TweakScake breaks, boy... We have a problem.

Edited May 14, 2020 by Lisias
Boy, I hate typing on a mobile - pretty useless damned things that autocompletes....

[Lisias]

I finally got it. (Not being able to take coffee makes my life a misery!! )

I see your point, but I'm not convinced (at least yet) that your way is the best way for the most parts - but, granted, if people were willing to use only the most common parts there would be no need for Add'Ons.  

Well, let's keep this brainstorming ongoing. It gave me some ideas.

 

22 hours ago, AccidentalDisassembly said:

But for the rest, it's not an error in the code, it's simply the core logic of how TweakScale works with techs, which is not capable of doing things in such a way that would make sense in the game (unless you write a very large number of SCALETYPES and/or part-specific patches, and then another very large number of patches for every other tech tree (like CTT or one of the others), and every mod, and so forth - it gets insane very quickly).

I think this is were you got it wrong. TWEAKSCALEBEHAVIOURS are only "macros" defined somewhere, it's a way to inject snippets of patches into parches. So, you in this case, you don't need a SCALETYPE for every combination of engines and tech required. You need a BEHAVIOUR for every tech required, and then inject the proper behaviour for that part .

Pending further tests, you can inject more than one BEHAVIOUR on a part - as long you write the second behaviour properly.

You will need a lot of thinking on the process - but usually good thinking render better results than brute force solutions, so I think it's the way to go.

 

On 5/13/2020 at 5:53 PM, AccidentalDisassembly said:

Or you could make TS recognize something like this:

@PART[thepart]
{
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 5.0 (or whatever)
		%ScaleUpTechs = TechNodeName, TechNodeName, TechNodeName... // first node allows one upward increment in the SCALETYPE, 2nd allows two, last unlocks embiggening completely
		
		%ScaleDownTechs = TechNodeName //If there's just one name here, then discovering this tech lets you do any scale < original
        // Or, if ScaleUpTechs and ScaleDownTechs aren't defined for the part, then it can scale freely from the start
        // Or, you could use a different logic, like:
        %ScaleUpTechs = 1 //One node after the part's node is required for each increase in scale defined in the SCALETYPE
	}
}

 

I have a problem with this approach: theres no real hard limit for the number of defaultScales a part can have - I choose to shove the same bunch of defaultScales for every part to keep things easy to be used, but one Add'On Author can choose to overrule me on this (to tell you the true, some indeed do it!), so we end up with a problem: there's no guarantee that the defaultScales will be standardised on different parts - think about the Steam Engine eras, when similar parts made on UK and on USA had different scalings, besides doing exactly the same thing.

So, a default scale of 5.0 can be the middle one, or can be the initial scale for some parts, of the last usable scale on others. In each one of these situations, you would need different ScaleDownTechs and ScaleUpTechs the same way.

So this approach , using ScaleUpTechs and ScaleDOwnTechs, will have the same problems it aims to solve - it only happens that such problems will not be noticeable on TweakScale standard patches.

However... Your idea gave me another idea: unlockScaleDownTech and unlockScaleUpTech.

In order to scale a part, you need to get both the unlockScaleDownTech and the requiredTech respective to the the new scale you want on the part. FreeScale would have to obey only to the unlocks, and the part would scale towards a defaultScale only if the respective tech is already opened (so one would not be able to rig the system by scaling near the locked scale).

An additional trick is to have requiredTechs predefined for each default Scale of a part.

And with that unlock* thingies and predefined requiredTechs on additional behaviours, I think we get the results you aim on a more flexible approach.

[Critter79606]

10 hours ago, kcs123 said:

I don't think that I ever used modular fuel tanks mod, so it may be that I didn't understand something properly. But, B9PSW mod does not do anything on it's own. It is other way around, some mod like ModularFuelTanks use B9PSW plugin to be able switching between multiple parts without need to clutter SPH/VAB editor with multiple part variants.

So, if I understand MM patch above, you have removed B9PSW module from ModularFuelTanks mod and with that you have cut off muliple part variants, leaving useful only one variant type active to be used in SPH/VAB.

This most likely comes with broken config files in ModularFuelTanks mod. And it become broken on recent KSP 1.9.x updates. So, true solution for issue would be to write proper configs on those ModularFuelTanks mod, not to completely remove it.

ModularFuelTanks doesn't use the B9 plugin, but competes with it when it comes to resource switching.  Before the B9 author put in the disabling code, I would get tank selection both from B9 (pre-configured selections), and MFT menu (custom configurable tanks).  When I accidentally used both on a part, I had to remove the part and put on a new copy, as the tanks would go crazy on the resource side.  I'd get multiple copies of resources that never went away... it was a mess.  Only the 2 combinations I created work, as I have a lot more #12 issue that have different combinations that I've not been able to resolve without some side affect (that you described).  Since the B9 is already disabling it's side, and I can't favor it over the MFT due to the way MFT changes the config, I figured I'd at least be able to restore the TS on some of my parts, especially unique ones I don't have multiple sizes of.  It's not removing variants, but the competing fuel type switch, which is covered by MFT.  B9 considers the heatshield ablator a resource, so that's why there are 2 separate #moduleID masks.  It in no way disables variants that aren't resource related that MFT isn't handling.  This would be a lot better (especially on Lisias) if mods would only use these types of resource switches on their own parts, instead of making broad changes across the board that are almost impossible to find.

 

[AccidentalDisassembly]

3 hours ago, Lisias said:

I finally got it. (Not being able to take coffee makes my life a misery!! )

I see your point, but I'm not convinced (at least yet) that your way is the best way for the most parts - but, granted, if people were willing to use only the most common parts there would be no need for Add'Ons.  

Well, let's keep this brainstorming ongoing. It gave me some ideas.

 

I think this is were you got it wrong. TWEAKSCALEBEHAVIOURS are only "macros" defined somewhere, it's a way to inject snippets of patches into parches. So, you in this case, you don't need a SCALETYPE for every combination of engines and tech required. You need a BEHAVIOUR for every tech required, and then inject the proper behaviour for that part .

Pending further tests, you can inject more than one BEHAVIOUR on a part - as long you write the second behaviour properly.

You will need a lot of thinking on the process - but usually good thinking render better results than brute force solutions, so I think it's the way to go.

 

I have a problem with this approach: theres no real hard limit for the number of defaultScales a part can have - I choose to shove the same bunch of defaultScales for every part to keep things easy to be used, but one Add'On Author can choose to overrule me on this (to tell you the true, some indeed do it!), so we end up with a problem: there's no guarantee that the defaultScales will be standardised on different parts - think about the Steam Engine eras, when similar parts made on UK and on USA had different scalings, besides doing exactly the same thing.

So, a default scale of 5.0 can be the middle one, or can be the initial scale for some parts, of the last usable scale on others. In each one of these situations, you would need different ScaleDownTechs and ScaleUpTechs the same way.

So this approach , using ScaleUpTechs and ScaleDOwnTechs, will have the same problems it aims to solve - it only happens that such problems will not be noticeable on TweakScale standard patches.

However... Your idea gave me another idea: unlockScaleDownTech and unlockScaleUpTech.

In order to scale a part, you need to get both the unlockScaleDownTech and the requiredTech respective to the the new scale you want on the part. FreeScale would have to obey only to the unlocks, and the part would scale towards a defaultScale only if the respective tech is already opened (so one would not be able to rig the system by scaling near the locked scale).

An additional trick is to have requiredTechs predefined for each default Scale of a part.

And with that unlock* thingies and predefined requiredTechs on additional behaviours, I think we get the results you aim on a more flexible approach.

I see what you mean, and my particular solution is really just a stab in the dark. I also don't really understand what TWEAKSCALEBEHAVIORS do and how they could be applied to tech limits, so there's that... Maybe this can already be done with TWEAKSCALEBEHAVIORS, but I think you'd still have to write a very large number to account for mods, different tech trees, etc. - but since I don't know how they work, maybe I'm WAY wrong...!

The underlying change I'm proposing can addresses exactly the problem you're describing. I'll try another example, maybe this will illustrate...

Let's say you have 10 tech nodes in the game (T1-T10) and only one part (Part, 2.5m diameter). Part is unlocked at T3, and nodes T4-T10 all depend on unlocking T3, so they're in T3's "line" (or however it's called).

If you allow TweakScale to consider 1) the tech node that unlocked Part, and 2) how many tech nodes beyond that node have been unlocked unlocked, then you could do this: 

T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
		Part unlocks	Part can now be incremented by one scaleFactor up and/or down (or two, or however patch defines). Therefore Part can be 2.5m, 1.875m (or whatever the next step down is), or 3.75m.	Part's size can now be incremented by additional scaleFactor(s) up and/or down (controllable by how the patch is written for Part)	etc.

 Now it doesn't matter how many scaleFactors there are, because TS is allowing the part to be scaled relative to its defaultScale, not linking specific sizes to specific techs. It's linking how much bigger/smaller to how much tech, and thus automatically takes into account the part's original size (defaultScale). Additionally, the user doesn't even have to know what techs are in the current tech tree (so modded tech trees just work, regardless of where the part is) -  the degree of scaling is based on unlocking tech nodes relative to the part's own techRequired. If a user wants to control things more arbitrarily, that can be done right now (because of how inheritance works on SCALETYPES and such).

If the part (still 2.5m) now unlocks at T6, as below, it doesn't matter, and the user doesn't even have to know that the part is in a different node now - they can simply define (via the original patch that applies TS to the part) whether the part can be scaled as soon as it is researched (and how much), how many additional tech nodes it will take to scale the part more (and how much more each node will allow), and so forth.

T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
					Part unlocks. According to settings, perhaps no scaling is allowed (yet). Or perhaps scaling up or down one scaleFactor is allowed even on unlock - however the patch writer determines it (on a part by part basis).	Part can now be incremented up and/or down by one "stop" in the scaleFactors list	Part can be incremented up/down two scaleFactors or can be scaled to any scaleFactor >= X and <= Y - if there are thousands of scaleFactors, include all scaleFactors between those values

To address the problem of users creating any number of scaleFactors, maybe it is possible to have the scaling logic work like so: "Allow this part to scale up or down by X scaleFactors, but if that doesn't allow the part to scale to size Y, allow all scaleFactors until size Y is reached". Or, the entire thing could be based on ratios only, where additional tech unlocks a higher maximum multiple of the original part size (and therefore all scaleFactors comprised therein).

Does that make sense? BUT: the specific way it works (how exactly tech controls scaling, which precise techs give what benefits, and so forth) is not what I'm trying to convey at the root. I'm just attempting to use arbitrary examples to show the underlying change in logic.The point I am trying to make is not to say that this specific system (one tech node = the part can go up and/or down one "size", or whatever) is good. The point is the relative logic that would make a system like this possible, as opposed to the current implementation, which requires a prohibitively large number of patches referencing specific tech nodes by name (and/or specific scaleFactors, and so forth).

With that underlying logic, a lot of other stuff could be done using inheritance (kind of like how things work now) - like, for instance, writing some parameters in only one SCALETYPE (stack, for example) that effectively say: "No part with this scaletype can be scaled down to a size less than half its original size until <some tech> is researched" while the user could override specific conditions within a Part's individual TS patch (like you can do right now).

Edited May 15, 2020 by AccidentalDisassembly

[Lisias]

Perhaps I had jumped into conclusions too hasty - had I mention that currently I'm on coffee withdrawal?

47 minutes ago, Critter79606 said:

ModularFuelTanks doesn't use the B9 plugin, but competes with it when it comes to resource switching.  

Exactly. I realised it the harsh way.

 

48 minutes ago, Critter79606 said:

Before the B9 author put in the disabling code, I would get tank selection both from B9 (pre-configured selections), and MFT menu (custom configurable tanks).  When I accidentally used both on a part, I had to remove the part and put on a new copy, as the tanks would go crazy on the resource side

And you are one of the lucky ones!

I got parts anchored in the 3D space and exploding due the stress of the whole craft compressing it, followed by the statics around going on the Kerbal way to space.

That was a riot...

 

52 minutes ago, Critter79606 said:

 Since the B9 is already disabling it's side, and I can't favor it over the MFT due to the way MFT changes the config, I figured I'd at least be able to restore the TS on some of my parts, especially unique ones I don't have multiple sizes of.  

Now I get it. You are trying to salvage the savegame.

On the KSP 1.4 era, when the Zero Mass stunt blew up on my face, KSP was not, yet, reinjecting the prefab on living crafts.

What you did worked because KSP now reinjects prefab data into crafts on loading - stunt that can be useful on certain situations (as yours) but surely broke my legs a lot of times - to the point I had to write KSP Recall when things started to get nasty again.

 

57 minutes ago, Critter79606 said:

  It in no way disables variants that aren't resource related that MFT isn't handling.  

Well, it was once. It's the reason I published a patch removing MFT (my favourite FS, by the way) at that time, as it was the safer way out before KSP 1.7 (I think, I didn't played 1.6 at all, so perhaps the stunt started there) because once you remove info from a living craft, it was gone for good.

Only now with the prefab being reinjected back your patch is safe.

Good to now, thanks for standing your ground on this - I would had missed some pretty interesting insights!

 

1 hour ago, Critter79606 said:

.  This would be a lot better (especially on Lisias) if mods would only use these types of resource switches on their own parts, instead of making broad changes across the board that are almost impossible to find.

I have mixed feelings on the subject.

Of course I would prefer having a easier life with TweakScale on the subject, but... I would not have MFT and some others interesting things as FAR available if Add'On authors had decided to refrain themselves due it.

So, having some trouble on TS is kinda a small price to pay for them, mainly because TweakScake users are engaged and help me a lot on the task!

As you did, by the way, giving me some light about the reasons some things had happened.

[Lisias]

1 hour ago, AccidentalDisassembly said:

If you allow TweakScale to consider 1) the tech node that unlocked Part, and 2) how many tech nodes beyond that node have been unlocked unlocked, then you could do this: 

T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
		Part unlocks	Part can now be incremented by one scaleFactor up and/or down (or two, or however patch defines). Therefore Part can be 2.5m, 1.875m (or whatever the next step down is), or 3.75m.	Part's size can now be incremented by additional scaleFactor(s) up and/or down (controllable by how the patch is written for Part)	etc.

 Now it doesn't matter how many scaleFactors there are, because TS is allowing the part to be scaled relative to its defaultScale, not linking specific sizes to specific techs. It's linking how much bigger/smaller to how much tech, and thus automatically takes into account the part's original size (defaultScale). Additionally, the user doesn't even have to know what techs are in the current tech tree (so modded tech trees just work, regardless of where the part is) -  the degree of scaling is based on unlocking tech nodes relative to the part's own techRequired. If a user wants to control things more arbitrarily, that can be done right now (because of how inheritance works on SCALETYPES and such).

If the part (still 2.5m) now unlocks at T6, as below, it doesn't matter, and the user doesn't even have to know that the part is in a different node now - they can simply define (via the original patch that applies TS to the part) whether the part can be scaled as soon as it is researched (and how much), how many additional tech nodes it will take to scale the part more (and how much more each node will allow), and so forth.

T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
					Part unlocks. According to settings, perhaps no scaling is allowed (yet). Or perhaps scaling up or down one scaleFactor is allowed even on unlock - however the patch writer determines it (on a part by part basis).	Part can now be incremented up and/or down by one "stop" in the scaleFactors list	Part can be incremented up/down two scaleFactors or can be scaled to any scaleFactor >= X and <= Y - if there are thousands of scaleFactors, include all scaleFactors between those values

 

Yeah, I'm getting it.

The problem is that we have fundamentally different views about how to handle the TechTree.

When a think on TechTree on TweakScale, this is more or less what I see (tech names are fictitious):

TWEAKSACEBEHAVIOUR[FUSELAGE_2_5]
{
	defaultScale	= 2.5
	scaleFactors	= 0.1, 0.3, 0.625, 1.875, 2.5, 5, 7.5, 10, 20
	techRequired	= techAtomicWelding, techUltraFineCasting, techPreciseTooling, techAdvancedLightMaterials, techWhatever, techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding
}

And this would be applied to any fuselage (with resources or not) those defaultScale would be 2.5 - techWathever would be some very basic tech from the current TechTree.

This is what I already have on TS (exception made by the possibility of rigging the system scaling to the nearest value close to a forbidden scale).

What you are proposing is:

TWEAKSACEBEHAVIOUR[FUSELAGE_2_5]
{
	defaultScale = 2.5
	ScaleUpTechs = techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding
	ScaleDownTechs = techAdvancedLightMaterials, techPreciseTooling, techUltraFineCasting, techAtomicWelding
}

What's only another way to write the same thing, I still have 4 techs on scale up, and 4 techs for scaling down, and I still need to adapt it to fuselages with defaultScale of 7.5 

Of course, Engines would need a new set of techs. Give a peek on the problems while developing the R-3350 Duplex Cyclone or the R-4360 Major Wasp engines (used on the Super Constellation). Heat dissipation is only one of the problems they had.

[AccidentalDisassembly]

7 minutes ago, Lisias said:

Yeah, I'm getting it.

The problem is that we have fundamentally different views about how to handle the TechTree.

When a think on TechTree on TweakScale, this is more or less what I see (tech names are fictitious):

TWEAKSACEBEHAVIOUR[FUSELAGE_2_5]
{
	defaultScale	= 2.5
	scaleFactors	= 0.1, 0.3, 0.625, 1.875, 2.5, 5, 7.5, 10, 20
	techRequired	= techAtomicWelding, techUltraFineCasting, techPreciseTooling, techAdvancedLightMaterials, techWhatever, techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding
}

And this would be applied to any fuselage (with resources or not) those defaultScale would be 2.5 - techWathever would be some very basic tech from the current TechTree.

This is what I already have on TS (exception made by the possibility of rigging the system scaling to the nearest value close to a forbidden scale).

What you are proposing is:

TWEAKSACEBEHAVIOUR[FUSELAGE_2_5]
{
	defaultScale = 2.5
	ScaleUpTechs = techAdvancedFrames, techHeavyTooling, techHeavyMachinery, techTitaniumWelding
	ScaleDownTechs = techAdvancedLightMaterials, techPreciseTooling, techUltraFineCasting, techAtomicWelding
}

What's only another way to write the same thing, I still have 4 techs on scale up, and 4 techs for scaling down, and I still need to adapt it to fuselages with defaultScale of 7.5 

Of course, Engines would need a new set of techs. Give a peek on the problems while developing the R-3350 Duplex Cyclone or the R-4360 Major Wasp engines (used on the Super Constellation). Heat dissipation is only one of the problems they had.

Yeah, that's one possibility - it was kind of a first try. But as a default behavior, you wouldn't have to write any tech patches with the system I was thinking of in my last post - only apply the TS module and make sure the defaultScale was correct. But it wouldn't stop you from doing exactly what you propose (by just doing what you've written). My more recent post had a better idea (IMO) than the first one with the ScaleUpTechs etc.

Edited May 15, 2020 by AccidentalDisassembly

[kcs123]

After reading all this, I'm still confused why the MFT have B9PSW module within part config file if does not use B9PSW plugin ? Very old MFT version or something within saved games ? Perhaps I will need to read everything again when I can properly think again. I just got home from work after exhausting day. I'm not saying that you are wrong, I just find it very odd.

[Lisias]

50 minutes ago, kcs123 said:

After reading all this, I'm still confused why the MFT have B9PSW module within part config file if does not use B9PSW plugin ? Very old MFT version or something within saved games ? Perhaps I will need to read everything again when I can properly think again. I just got home from work after exhausting day. I'm not saying that you are wrong, I just find it very odd.

Bad patching. You just can't have two fuel systems on the same part.

B9PWS tried to survive the mess by detecting and deactivating itself when MFT is also installed on the part (you can have both fuel systems on the same game, you just can't have both on the same part!), but there's no interface on Scale_redist.dll to probe if the module is active or not - so the only safe measure at the time was to withdraw TS from the part, what by its turn was kinda of throwing a pile of pieces of retangular papers in the turbofan  as was the norm at the time to kill the messenger.  

One could argue that B9PSW should be aware of its deactivation on its the Scale_redist handler , so it could take the ideal measures (being it not trying to scale its resources, or just returning the call after doing nothing), but since the root cause of the mess was, indeed, bad patching, the real solution for the mess is fixing the patches - so I settled up with the Sanity Checks and didn't bothered any module author with bug reports or pull requests.

IMHO, this is not something at fault neither on B9PSW, MFT or even TweakScale. It's just something that happens on the field and need to be coped somehow by third parties willing to have them all on the same savegame.

The easiest way out was to remove MFT from the parts with B9PSW, but there're people (me included) that prefers MFT for handling Resources. For these guys, a smarter patch removing Resource support from the B9PSW module would be the best approach.

[Lisias]

18 hours ago, AccidentalDisassembly said:

Yeah, that's one possibility - it was kind of a first try. But as a default behavior, you wouldn't have to write any tech patches with the system I was thinking of in my last post - only apply the TS module and make sure the defaultScale was correct. 

I will give it another try on the WeekEnd. I don't get it exactly why this system would be more practical than the one I'm proposing, but I really didn't a good try on it yet - it's a bit hard to "enter into the zone" late night, when I'm usually have time to KSP on working days.

 

18 hours ago, AccidentalDisassembly said:

My more recent post had a better idea (IMO) than the first one with the ScaleUpTechs etc.

One thing that I noted is that you are assuming a linear progression on the tech nodes needed. Perhaps this is where my mind is "refusing" to accept, as it's not how I see technology evolving - by experience, multidisciplinarity is way more applicable on generating new technologies than using an "academic approach", i.e., a linear path from where you start to the goal you aim.

So, using my FUSELAGE_2_5 example: in order to scale it down to 1.875, I need to develop first a way to obtain "Advanced Light Materials". But only that is not enough to get 0.625 scale, because I would need to develop too "Precise Tooling".

With Precise Tooling I could theoretically scale down to 0.625, but if I don't have "Advanced Light Materials", that scale is still unreachable because I don't have "Advanced Materials" yet.

The nice part of this proposal is that they are not locked into Fuselage. The Precision Tooling would be useful on Robotics also, and so perhaps the user would prefer to develop it first and "sacrifice" scaling down fuselages for while.

 

[AccidentalDisassembly]

1 hour ago, Lisias said:

I will give it another try on the WeekEnd. I don't get it exactly why this system would be more practical than the one I'm proposing, but I really didn't a good try on it yet - it's a bit hard to "enter into the zone" late night, when I'm usually have time to KSP on working days.

 

One thing that I noted is that you are assuming a linear progression on the tech nodes needed. Perhaps this is where my mind is "refusing" to accept, as it's not how I see technology evolving - by experience, multidisciplinarity is way more applicable on generating new technologies than using an "academic approach", i.e., a linear path from where you start to the goal you aim.

So, using my FUSELAGE_2_5 example: in order to scale it down to 1.875, I need to develop first a way to obtain "Advanced Light Materials". But only that is not enough to get 0.625 scale, because I would need to develop too "Precise Tooling".

With Precise Tooling I could theoretically scale down to 0.625, but if I don't have "Advanced Light Materials", that scale is still unreachable because I don't have "Advanced Materials" yet.

The nice part of this proposal is that they are not locked into Fuselage. The Precision Tooling would be useful on Robotics also, and so perhaps the user would prefer to develop it first and "sacrifice" scaling down fuselages for while.

 

I agree, but there are two things I'm proposing. One is simpler, and it is related to how TweakScale addresses exactly the kind of scenario you describe. I agree, tech is not linear. But look what happens in your scenario - the problem is that TweakScale does not allow for scaling the part <some degree> smaller than its original size when you unlock a tech, it unlocks a specific numerical value or multiple because it ties specific numerical scaleFactors (or percents, with free/surface) to specific techs. Your example illustrates the need for relative logic in TweakScale.

Scenario:

Assume you have unlocked FUSELAGE_2_5 and, as you say, you have not researched in the direction of Advanced Light Materials and Advanced Materials (for now), because the tech tree is not linear and you made choices. You unlock Precise Tooling. The problem: you CAN now scale FUSELAGE_2_5 to 0.625m, because the SCALETYPE defined the scaleFactor "0.625" as becoming available with PreciseTooling. Second problem: you can't solve the problem by using free or surface scaletypes either (which multiply), because Precise Tooling would unlock a specific multiplier.

Expanding:

1. You unlock FUSELAGE_2_5, then go for Precise Tooling. Logically, Precise Tooling applies to more than just fuselages, I agree. Nothing stops you from writing other SCALETYPES that reference Precise Tooling. Furthermore, logically, researching Precise Tooling should have some effect on FUSELAGE_2_5, because it lets you build smaller things.
2. But: there's already a problem. As you say, the tech tree is not linear, and you have opted for Precise Tooling (for now) instead of Advanced Materials/ Advanced Light Materials. Because Precise Tooling is assigned to the value 0.625 in the SCALETYPE (while AM is assigned to 1.875, ALM is 1.25), you can in fact scale FUSELAGE_2_5 down to 0.625m, but you can't scale it to 1.875m or 1.25m, because those are assigned to different techs. This makes no sense - how can your tooling let you make it 75% smaller, but not 50% or 25%...? How can only one of these three related techs allow for so much scaling?
3. It would seem reasonable that researching Precise Tooling should nevertheless allow FUSELAGE_2_5 to scale smaller than its original size (relative to its defaultScale) - let's say one size smaller (or whatever), or 1.875m. ("One size" here is defined by whatever increments are in the SCALETYPE) - but not already to 0.625m, because the other techs aren't researched. TweakScale simply can't handle this logic right now.
   1. Now let's say you research Advanced Materials (on your way to Advanced Light Materials). Advanced materials should give additional improvements in miniaturization: it should allow you to scale FUSELAGE_2_5 further, but not to some specific, arbitrary value. This is what I mean by relative logic. "Further" in this case is relative to how much you can already scale the part - you can already scale it down X amount / X steps, to 1.875m, so this additional tech should allow you to scale it further - to 1.25m.
   2. Then, you unlock ALM - now, finally, you should be able to finally scale it to 0.625m.
4. But because the tech tree is not linear.... what if you START with Advanced Materials? Here, the problem appears again from a different direction: it's not a question of writing another SCALETYPE or TWEAKSCALEBEHAVIOR - we need relative logic that allows for adding "more and more scaling" from tech research meeting some criteria (specific nodes, total science spent, whatever). This is why I am proposing the ability to allow a part to scale "by an additional amount in X direction," or "more / less," or "more scaleFactor increments", or whatever, by unlocking tech nodes - allow nodes to add an amount of additional scaling ability to the part, not a specific scale.

There is a second part to what I am proposing:

1. Another but: Assume the tech tree is linear enough to avoid the problem in that scenario. You now have to write many, many SCALETYPES to account not only for types of parts (fuselages responding to Precise Tooling, robotic parts also responding to Precise Tooling...), but also for specific sizes of parts, and also account for where they appear in the tech tree. The number of SCALETYPES/TWEAKSCALEBEHAVIORS is prohibitive, even with stock, let alone with mods/modded tech trees.
2. Continuing the scenario:
   1. You unlock FUSELAGE_25, but you're using a modded tech tree. Now, Precise Tooling, Advanced Materials, and Advanced Light Materials may or may not exist, and they may or may not be at positions in the tech tree where they make sense. That's a problem already, but not a big one; you could write patches to account for modded tech trees.
   2. But now do this for every part and every mod.. again, an astronomical number of configs. 
3. What if you had another fictitious part, ENGINE_50, and you wanted things to work like this?:
   1. Unlock ENGINE_50. Precise Tooling, AM, and ALM all allow for improvements to this engine - researching one of those allows scaling to 3.75m, then researching another allows 2.5m, and then finally 1.875m with the last one.
   2. But now, assume there is no specific tech node in the tech tree that makes sense in terms of making the engine bigger. And: with modded tech trees, I have no idea what tech nodes even exist in the tech tree, or where this engine is even located in the tech tree.
   3. So: I still want research to have an effect on how large the engine can be scaled... But the conditions for allowing larger scales need to be not absolute references to names of tech nodes: instead, something like "any tech node meeting certain criteria", let's say.
   4. One of those criteria could be: "if you research any tech node that branches off from the part's own tech node (a "later" related node, shown by an arrow in the tech tree), then you can scale ENGINE_50 up one more size (to 6.25m, maybe)".
   5. Or, another criterion could be: "If you research any tech node that costs more science than ENGINE_50's own tech node, then you've probably made some discoveries that are relevant; allow scaling up one (more) size (to 6.25m, or to 7.5m, depending on what else you have done)."
   6. Or, another criterion could be: "The next size up for this engine is unlocked after spending X total science on techs after unlocking ENGINE_50's tech node" (which also captures the idea of interdisciplinarity, non-linearity, etc.)
4. If you implement this kind of possibility (in addition to what is already in TweakScale right now), there is a side effect: you can have a default behavior for tech and size limits that works for every part regardless of tech tree and position in the tech tree:
   1. If you default to "allow this part to scale up or down one additional size / <x> additional percent for every tech node unlocked by and researched after the part's own tech node", then every part in the game has some kind of tech progression built in, it's all roughly logical, and every mod part in existence instantly CAN have tech limits applied to it without writing a million SCALETYPES/BEHAVIORS.

It's very hard to describe what I'm thinking in text without visuals and tone of voice, unfortunately, sorry! I am not asking for a restrictive change in how TS deals with scaling + techs, only an extension.

Let me know if there's some way I can be clearer, I am finding it very hard to describe what I mean!

 

 

Edited May 16, 2020 by AccidentalDisassembly

[Critter79606]

22 hours ago, Lisias said:

Now I get it. You are trying to salvage the savegame.

 

Actually, it's more of trying to salvage being able to resize unique parts.  I didn't care which (B9 or MTF) I kept, just so long as I got my TS back on several parts.

 

[Lisias]

15 hours ago, AccidentalDisassembly said:

Assume you have unlocked FUSELAGE_2_5 and, as you say, you have not researched in the direction of Advanced Light Materials and Advanced Materials (for now), because the tech tree is not linear and you made choices. You unlock Precise Tooling. The problem: you CAN now scale FUSELAGE_2_5 to 0.625m, because the SCALETYPE defined the scaleFactor "0.625" as becoming available with PreciseTooling. Second problem: you can't solve the problem by using free or surface scaletypes either (which multiply), because Precise Tooling would unlock a specific multiplier.

Not exactly... In order to reach 0.625, one need to be able to reach first 1.875, and to do that, you need "Advanced Light Materials" too.

You unlock ALM, you get 1.875. You unlock PT, you now get 0.625.

You unlock PT and not ALM, you don't get any of them.

I would need a small intervention on the current requiredTech code to implement this kind of limitation (ie, you can scale only to the nearest unlocked tech), but other than that, I think it fits both the need and the current implementation.

I will reread your posts tomorrow morning, I'm too tired for now to give it proper attention.

 

-- -- -- "Tomorrow Morning" -- -- -- 

15 hours ago, AccidentalDisassembly said:

Let me know if there's some way I can be clearer, I am finding it very hard to describe what I mean!

It's not you the "problem", the subject is pretty harsh and I  have too few "useful time" on working days to give this a decent thought.

I kinda understanding the problems you see, but I think I already have solutions for it - assuming, of course, I correctly understand the problems at first place.

I will come back to this later - I have some medicine hunting to do today (supply chain is problematic around here, besides still working).

 

-- -- -- POST "Tomorrow Morning" -- -- -- 

You have a point.

I think it's possible to make things simpler, and yet, do what I was meaning originally - with some little adaptations, hopefully satisfying both sides of this discussion.

Thank you for your efforts, you started a chain of events that will make TweakScale way better on this subject.

I will post a new proposition soon, so we can double check it.

Edited May 16, 2020 by Lisias
"Tomorrow Morning"

[AccidentalDisassembly]

13 hours ago, Lisias said:

Not exactly... In order to reach 0.625, one need to be able to reach first 1.875, and to do that, you need "Advanced Light Materials" too.

You unlock ALM, you get 1.875. You unlock PT, you now get 0.625.

You unlock PT and not ALM, you don't get any of them.

I would need a small intervention on the current requiredTech code to implement this kind of limitation (ie, you can scale only to the nearest unlocked tech), but other than that, I think it fits both the need and the current implementation.

I will reread your posts tomorrow morning, I'm too tired for now to give it proper attention.

 

-- -- -- "Tomorrow Morning" -- -- -- 

It's not you the "problem", the subject is pretty harsh and I  have too few "useful time" on working days to give this a decent thought.

I kinda understanding the problems you see, but I think I already have solutions for it - assuming, of course, I correctly understand the problems at first place.

I will come back to this later - I have some medicine hunting to do today (supply chain is problematic around here, besides still working).

 

-- -- -- POST "Tomorrow Morning" -- -- -- 

You have a point.

I think it's possible to make things simpler, and yet, do what I was meaning originally - with some little adaptations, hopefully satisfying both sides of this discussion.

Thank you for your efforts, you started a chain of events that will make TweakScale way better on this subject.

I will post a new proposition soon, so we can double check it.

Hooray! I think extending it will indeed make it a lot better, and also easy for people to write tech patches for their parts / mods / TS Companions too!

[KerbalSofaProgram]

hey there, just wanted to drop in and let you know nerteas near future solar pack and tweakscale arent getting along... showstopping and some other frightening text. i initially posted this over there first but some people thought i should let you know. i also forgot to save my log but i can reinstall nf solar and get a new one if you want. heres a snippet i posted last night to at least give you an idea.

Spoiler

[LOG 17:18:16.313] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-1 (OKEB-500 'Titan' Blanket Photovoltaic Array).
[LOG 17:18:16.313] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-1 (OKEB-500 'Titan' Blanket Photovoltaic Array) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

 

[Lisias]

18 minutes ago, KerbalSofaProgram said:

hey there, just wanted to drop in and let you know nerteas near future solar pack and tweakscale arent getting along... showstopping and some other frightening text. i initially posted this over there first but some people thought i should let you know. i also forgot to save my log but i can reinstall nf solar and get a new one if you want. heres a snippet i posted last night to at least give you an idea.

  Hide contents

[LOG 17:18:16.313] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-1 (OKEB-500 'Titan' Blanket Photovoltaic Array).
[LOG 17:18:16.313] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-1 (OKEB-500 'Titan' Blanket Photovoltaic Array) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

 

I will need the Full KSP.log for diagnosing this. In time, the TweakScaleCompanion_NFS is no more. By Real Life™ pressures, I decided to merge all NF support into one single Companion, TweakScale Companion for NF. Please completely remove the old one before installing.

[KerbalSofaProgram]

huh. my tweakscale has never had a companion... is that something i should have already been using? probably... ok thanks. hopefully i wont be back talking to the rockstars of the game world. that was flattery and i hope you liked it.

[Lisias]

12 minutes ago, KerbalSofaProgram said:

huh. my tweakscale has never had a companion... is that something i should have already been using? probably... ok thanks.

Update to the latest TweakScale too (if you didn't did yet). Please remember to completely delete the older version before update.

Keep an eye on the TweakScale Companion thread for news on new and improved support for third parties!

 

14 minutes ago, KerbalSofaProgram said:

ok thanks. hopefully i wont be back talking to the rockstars of the game world. that was flattery and i hope you liked it.

Welcome!

[Makuru]

it told me to go here

this is the log of the part of your mod

Spoiler

[LOG 03:39:17.108] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=IFSHexcanSolid, DryCost=-1.66893E-05 at error:0
[LOG 03:39:17.151] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-1 (OKEB-500 Großflächige Solaranlage).
[LOG 03:39:17.151] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-1 (OKEB-500 Großflächige Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.152] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-2 (OKEB-100 Großflächige Solaranlage).
[LOG 03:39:17.152] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-2 (OKEB-100 Großflächige Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.152] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-25-1 (NIV-30 Gekrümmte Solaranlage).
[LOG 03:39:17.153] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-25-1 (NIV-30 Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.153] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-375-1 (NIV-10 Gekrümmte Solaranlage).
[LOG 03:39:17.153] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-375-1 (NIV-10 Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.154] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-deploying-25-1 (SOL-A Ausfahrbare Gekrümmte Solaranlage).
[LOG 03:39:17.154] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-deploying-25-1 (SOL-A Ausfahrbare Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.154] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x3-1 (K5K 1x3 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.155] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x3-1 (K5K 1x3 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.155] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x4-1 (K7K 1x4 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.155] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x4-1 (K7K 1x4 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.156] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x4-2 (K12K 1x4 Hochdichtes Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.156] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x4-2 (K12K 1x4 Hochdichtes Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.156] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x5-1 (T14 1x5 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.157] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x5-1 (T14 1x5 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.157] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x5-2 (T22 1x5 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.157] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x5-2 (T22 1x5 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.158] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-1 (K55-XL Megalador Solaranlage).
[LOG 03:39:17.158] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-1 (K55-XL Megalador Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.158] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-2 (K30-SL Einzel-Solarmodul).
[LOG 03:39:17.159] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-2 (K30-SL Einzel-Solarmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.159] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x3-1 (K90-ML Trio-Solarmodul).
[LOG 03:39:17.160] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x3-1 (K90-ML Trio-Solarmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.160] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-circular-1 (YF8 runde Konzentrator-Photovoltaik-Anlage).
[LOG 03:39:17.160] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-circular-1 (YF8 runde Konzentrator-Photovoltaik-Anlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.161] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-static-truss-1 (PX-STAT 1x4 Photovoltaik-Träger).
[LOG 03:39:17.161] [TweakScale] ERROR: **FATAL** Part solarpanel-static-truss-1 (PX-STAT 1x4 Photovoltaik-Träger) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.161] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-static-truss-2 (PX-STAT 1x2 Photovoltaic Truss).
[LOG 03:39:17.162] [TweakScale] ERROR: **FATAL** Part solarpanel-static-truss-2 (PX-STAT 1x2 Photovoltaic Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[ERR 03:39:17.239] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.239] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[ERR 03:39:17.240] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.241] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[ERR 03:39:17.241] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.242] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.248] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=KspiCentrifuge, DryCost=-196671.6 at error:0
[LOG 03:39:17.251] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=kspiServiceModulSM500, DryCost=-0.0001525879 at error:0
[LOG 03:39:17.254] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.254] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.255] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.269] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=DiamagneticAntimatterTrap, DryCost=-1.3244E+09 at error:0
[LOG 03:39:17.270] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=HexCanLithium, DryCost=-5.00679E-05 at error:0
[LOG 03:39:17.281] [TweakScale] INFO: WriteDryCost Concluded : 1663 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 16 Show Stoppers found; 0 Sanity Check failed; 558 unscalable parts.

[Lisias]

1 hour ago, Makuru said:

it told me to go here

this is the log of the part of your mod

  Reveal hidden contents

[LOG 03:39:17.108] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=IFSHexcanSolid, DryCost=-1.66893E-05 at error:0
[LOG 03:39:17.151] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-1 (OKEB-500 Großflächige Solaranlage).
[LOG 03:39:17.151] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-1 (OKEB-500 Großflächige Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.152] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-blanket-2 (OKEB-100 Großflächige Solaranlage).
[LOG 03:39:17.152] [TweakScale] ERROR: **FATAL** Part solarpanel-blanket-2 (OKEB-100 Großflächige Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.152] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-25-1 (NIV-30 Gekrümmte Solaranlage).
[LOG 03:39:17.153] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-25-1 (NIV-30 Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.153] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-375-1 (NIV-10 Gekrümmte Solaranlage).
[LOG 03:39:17.153] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-375-1 (NIV-10 Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.154] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-curved-deploying-25-1 (SOL-A Ausfahrbare Gekrümmte Solaranlage).
[LOG 03:39:17.154] [TweakScale] ERROR: **FATAL** Part solarpanel-curved-deploying-25-1 (SOL-A Ausfahrbare Gekrümmte Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.154] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x3-1 (K5K 1x3 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.155] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x3-1 (K5K 1x3 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.155] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x4-1 (K7K 1x4 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.155] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x4-1 (K7K 1x4 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.156] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x4-2 (K12K 1x4 Hochdichtes Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.156] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x4-2 (K12K 1x4 Hochdichtes Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.156] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x5-1 (T14 1x5 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.157] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x5-1 (T14 1x5 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.157] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-1x5-2 (T22 1x5 Konzentrator-Photovoltaikmodul).
[LOG 03:39:17.157] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-1x5-2 (T22 1x5 Konzentrator-Photovoltaikmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.158] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-1 (K55-XL Megalador Solaranlage).
[LOG 03:39:17.158] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-1 (K55-XL Megalador Solaranlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.158] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-2 (K30-SL Einzel-Solarmodul).
[LOG 03:39:17.159] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-2 (K30-SL Einzel-Solarmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.159] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x3-1 (K90-ML Trio-Solarmodul).
[LOG 03:39:17.160] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x3-1 (K90-ML Trio-Solarmodul) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.160] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-circular-1 (YF8 runde Konzentrator-Photovoltaik-Anlage).
[LOG 03:39:17.160] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-circular-1 (YF8 runde Konzentrator-Photovoltaik-Anlage) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.161] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-static-truss-1 (PX-STAT 1x4 Photovoltaik-Träger).
[LOG 03:39:17.161] [TweakScale] ERROR: **FATAL** Part solarpanel-static-truss-1 (PX-STAT 1x4 Photovoltaik-Träger) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 03:39:17.161] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-static-truss-2 (PX-STAT 1x2 Photovoltaic Truss).
[LOG 03:39:17.162] [TweakScale] ERROR: **FATAL** Part solarpanel-static-truss-2 (PX-STAT 1x2 Photovoltaic Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[ERR 03:39:17.239] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.239] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[ERR 03:39:17.240] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.241] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[ERR 03:39:17.241] Cannot find config in file : KspieSIGINT

[LOG 03:39:17.242] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End/KspieSIGINT.End (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.248] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=KspiCentrifuge, DryCost=-196671.6 at error:0
[LOG 03:39:17.251] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=kspiServiceModulSM500, DryCost=-0.0001525879 at error:0
[LOG 03:39:17.254] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.254] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.255] [TweakScale] INFO: NULL ConfigNode for WarpPlugin/Parts/Electrical/PlasmaJetMagnetoInertialReactor/Plasma JetMagnetoInertial/PlasmaJetMagnetoInertialReactor (unholy characters on the name?). Trying partConfig instead!
[LOG 03:39:17.269] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=DiamagneticAntimatterTrap, DryCost=-1.3244E+09 at error:0
[LOG 03:39:17.270] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=HexCanLithium, DryCost=-5.00679E-05 at error:0
[LOG 03:39:17.281] [TweakScale] INFO: WriteDryCost Concluded : 1663 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 16 Show Stoppers found; 0 Sanity Check failed; 558 unscalable parts.

I need the FULL KSP.log in order to diagnose your problem. Please publish your full KSP.log on DropBox or something and link it here so I can help. I will probably need also ModuleManager.ConfigCache and will not hurt to send me your Logs/ModuleManager content.

See this post to see how to get them.