[1.11.2] B9PartSwitch v2.18.0 (March 17)

[blowfish]

@airwolfpiskin FYI I did post a prerelease version of B9 for KSP 1.2 (you can find it on the releases page on Github).  It has up-to-date versions of the dependencies (although RasterPropMonitor has released another beta since)

Edited November 2, 2016 by blowfish

[Jiraiyah]

@blowfish

sir did you hard limit the plugin to 1.2 or will this work with 1.2.1 without a need for another compile?

[blowfish]

2 minutes ago, Jiraiyah said:

@blowfish

sir did you hard limit the plugin to 1.2 or will this work with 1.2.1 without a need for another compile?

I have never placed any version limitations on my plugins (if it doesn't load it's because something actually changed in a breaking way).  Based on the changelog (which only appears to contain minor bugfixes) my guess is that it will work with 1.2.1 but I haven't tried it yet.

[Jiraiyah]

2 minutes ago, blowfish said:

I have never placed any version limitations on my plugins (if it doesn't load it's because something actually changed in a breaking way).  Based on the changelog (which only appears to contain minor bugfixes) my guess is that it will work with 1.2.1 but I haven't tried it yet.

cool, thanks sir

[airwolfpiskin]

9 hours ago, blowfish said:

I have never placed any version limitations on my plugins (if it doesn't load it's because something actually changed in a breaking way).  Based on the changelog (which only appears to contain minor bugfixes) my guess is that it will work with 1.2.1 but I haven't tried it yet.

you were right firespitter was the problem so i updated it

also it does work in 1.2.1 but my game crashes after about 30 minutes im not sure why or if it has to do with mods. 

 

[PickledTripod]

I have an idea for a feature: add modules in subtypes. For example a subtype of a crew pod could have a ModuleCommand with minimumCrew = 0  (adding a probe core), another subtype would have ModuleEngineFX (adding landing engines) and yet another could remove crew capacity and add a ModuleKISInventory to make it a cargo version. I have no idea how difficult this would be to implement, maybe it's not even possible or maybe it's actually trivial, but I think it would be a cool idea.

[blowfish]

1 hour ago, PickledTripod said:

I have an idea for a feature: add modules in subtypes. For example a subtype of a crew pod could have a ModuleCommand with minimumCrew = 0  (adding a probe core), another subtype would have ModuleEngineFX (adding landing engines) and yet another could remove crew capacity and add a ModuleKISInventory to make it a cargo version. I have no idea how difficult this would be to implement, maybe it's not even possible or maybe it's actually trivial, but I think it would be a cool idea.

I've thought about this, and I think it might be possible, but there's a very good chance it wouldn't work for every module, just because some aren't set up to handle this.  Simpler ones would probably be fine though.  At the very least though, this would have to come with no warranty - either a module works or it doesn't, as there's no way I could add custom handling for every module that required it, particularly mod modules.

[Jiraiyah]

@blowfish Hi sir

I have a question, in one of my parts i will have tons of attach nodes for a circular space station, well like 80 for out ring, 80 for inner ring. 80 for top etc. etc.

now here is the question, if i bind two modules like this on the part how would they behave ?

MODULE
{
	name = ModuleB9PartSwitch
	moduleID = NodeSideToggle
	
	SUBTYPE
	{
		name = NodeRingOutToggle
		title = Out
		node = Outer
	}
	
	SUBTYPE
	{
		name = NodeRingInToggle
		title = In
		node = Inner
	}
}
MODULE
{
	name = ModuleB9PartSwitch
	moduleID = NodeDegreeToggle
	
	SUBTYPE
	{
		name = Node90Toggle
		title = 90
		node = _0
		node = _90
		node = _180
		node = _270
	}
	
	SUBTYPE
	{
		name = Node45Toggle
		title = 45
		node = _0
		node = _45
		node = _90
		node = _135
		node = _180
		node = _225
		node = _270
		node = _315
	}
}

What i am after is for the top module to toggle the nodes that are on the out ring for example, then on those nodes i use the lower module to only toggle the nodes that are 90 degree angles or 45 etc etc

will these two modules work hand in hand or will they compete with each other?

by the way, my node geometry and node names would look like : Outer_90, Inner_45 etc

these pics may give you better idea why i need this

Edited November 11, 2016 by Jiraiyah

[blowfish]

@Jiraiyah It won't work like that.  Only one module can manage any particular node.  I think you'll just have to have a separate subtype for every configuration you want.

[Jiraiyah]

1 hour ago, blowfish said:

@Jiraiyah It won't work like that.  Only one module can manage any particular node.  I think you'll just have to have a separate subtype for every configuration you want.

got it, thanks sir

[blowfish]

22 minutes ago, Jiraiyah said:

got it, thanks sir

Because I might revisit this in the future, I'm curious what you were hoping for here.  Did you expect that if both modules thought the node should be enabled, then it would be enabled (but otherwise disabled)?

[Jiraiyah]

8 hours ago, blowfish said:

Because I might revisit this in the future, I'm curious what you were hoping for here.  Did you expect that if both modules thought the node should be enabled, then it would be enabled (but otherwise disabled)?

yup, for example if i would set the top module for OutRing and bottom one for _90, then i would want to see Out_0, Out_90, Out_180, Out_270 alone, something like an and operator between modules i think.

[komodo]

Question: I had a look through the source, but I couldn't find an answer... It doesn't mean it isn't there, though: Is there a way to specify for a part, "Total volume is V, but only fill to V-n"? This would mirror the stock config solution of 

amount = V - n
maxAmount = V

I don't think there is a way to do this currently, but I figured it wouldn't hurt to ask. Thanks much!

[blowfish]

18 minutes ago, komodo said:

Question: I had a look through the source, but I couldn't find an answer... It doesn't mean it isn't there, though: Is there a way to specify for a part, "Total volume is V, but only fill to V-n"? This would mirror the stock config solution of 

I don't think there is a way to do this currently, but I figured it wouldn't hurt to ask. Thanks much!

No way to partially fill tanks currently, sorry.

[Bonus Eventus]

Anyone know if this module will allow me to switch between different internal spaces? I have a command pod that I want to have multiple setups for.

[blowfish]

4 hours ago, Bonus Eventus said:

Anyone know if this module will allow me to switch between different internal spaces? I have a command pod that I want to have multiple setups for.

It won't, sorry.

[Bonus Eventus]

4 minutes ago, blowfish said:

It won't, sorry.

That's kinda what I expected, thanks.

EDIT: I just thought of something—as long as the switching of the internal model happens in the editor (since internal models don't load within the editor scene), isn't switching the internal model just a matter of overwriting the INTERNAL { name = the_name_of_the_iva } ? Or is this an issue with persistence? 

Edited November 13, 2016 by Bonus Eventus

[blowfish]

9 minutes ago, Bonus Eventus said:

That's kinda what I expected, thanks.

EDIT: I just thought of something—as long as the switching of the internal model happens in the editor (since internal models don't load within the editor scene), isn't switching the internal model just a matter of overwriting the INTERNAL { name = the_name_of_the_iva } ? Or is this an issue with persistence? 

I haven't looked, to be honest.  There might be some setup that KSP does when the part is first loaded.

[Bonus Eventus]

1 hour ago, blowfish said:

I haven't looked, to be honest.  There might be some setup that KSP does when the part is first loaded.

Tell you what, I'll write a simple module that tests this and report my findings. 

EDIT:  

part.CreateInternalModel calls part.AddInternalPart(), sending it an internal configNode accessed via part.partInfo.internalConfig. assigning to part.parInfo.internalConfig a different configNode while in the editor scene will change the iva once in flight. However, this change is not persistent (expected as much). KSP expects this to be set by PartLoader when the GameDatabase is initialized. If the persistent.sfs file recorded internalConfig path or did a lookup each time based on internalModelName, one could just overwrite the node once upon onProtoPartSnapShotSave. That said, if a user were to not fill out the INTERNAL { name = the_name_of_the_iva }, instead adding this info from within ModuleB9PartSwitch, then the iva would not auto load. The module would need to spawn the iva each time through FixedUpdate, because unfortunately when the active vessel is switched, internalModels are removed and then added again when the vessel is active. Since, auto spawning the iva is circumvented, I'd just do this:

public void FixedUpdate()
{
  	if(!Highlogic.LoadedSceneIsFlight)return;
	if(hasInternalModel)
    	{
      		if(part.internalModel == null)
			{
				part.CrewCapacity = crewCapacity;
				part.crewTransferAvailable = true;
				part.SpawnIVA ();
				//internalModel.SetVissible is false when there is no internalModel
				//if the iva overlay is present the internalModel mesh will be hidden 
				//unless this is set to true
				part.internalModel.SetVisible(true);
			}
    	}
}

Overhead isn't much especially since not all parts will have an iva.

Edited November 13, 2016 by Bonus Eventus

[blowfish]

On 11/13/2016 at 9:48 AM, Bonus Eventus said:

part.CreateInternalModel calls part.AddInternalPart(), sending it an internal configNode accessed via part.partInfo.internalConfig. assigning to part.parInfo.internalConfig a different configNode while in the editor scene will change the iva once in flight. However, this change is not persistent (expected as much). KSP expects this to be set by PartLoader when the GameDatabase is initialized. If the persistent.sfs file recorded internalConfig path or did a lookup each time based on internalModelName, one could just overwrite the node once upon onProtoPartSnapShotSave. That said, if a user were to not fill out the INTERNAL { name = the_name_of_the_iva }, instead adding this info from within ModuleB9PartSwitch, then the iva would not auto load. The module would need to spawn the iva each time through FixedUpdate, because unfortunately when the active vessel is switched, internalModels are removed and then added again when the vessel is active. Since, auto spawning the iva is circumvented, I'd just do this:

*snip*

Overhead isn't much especially since not all parts will have an iva.

It might be possible to just have no default IVA on the part, detect when the active vessel is changed, and spawn the correct IVA with code.  I think this is getting into special use cases that are a bit outside the scope of B9PartSwitch though...

[Bonus Eventus]

1 hour ago, blowfish said:

It might be possible to just have no default IVA on the part, detect when the active vessel is changed, and spawn the correct IVA with code.  I think this is getting into special use cases that are a bit outside the scope of B9PartSwitch though...

After some consideration, I came to the same conclusion. Guess I'll make another utility plugin so I can get these guys up and running.

[blowfish]

B9PartSwitch v1.5.2

• Recompile against KSP 1.2.1

[Bonus Eventus]

@blowfish I looked through the source code yesterday to see if there was anyway to set a PartResource isTweakable property to false and I didn't find anything. In a last ditch effort, I thought I'd just ask. I'm making an inflatable fuel tank and it's resource starting amount should always be zero. If the tweakable property is set to true then the player can set the starting amount to whatever they want.

[blowfish]

3 hours ago, Bonus Eventus said:

@blowfish I looked through the source code yesterday to see if there was anyway to set a PartResource isTweakable property to false and I didn't find anything. In a last ditch effort, I thought I'd just ask. I'm making an inflatable fuel tank and it's resource starting amount should always be zero. If the tweakable property is set to true then the player can set the starting amount to whatever they want.

There's no way to do this currently.  I don't think it would be hard to implement, but it would require new code.  I think there are really two features here:

• Ability to only partially fill tanks.  You are not the first person to request this, so I'm somewhat more inclined to look into this now.
• Ability to override the resource's tweakable option

In both cases I think it would be defined on the tank type.  Something like this

Spoiler

B9_TANK_TYPE
{
	name = MyMod_LFO_Inflatable
	tankMass = 0.00005
	tankCost = 0.5
	
	RESOURCE
	{
		name = LiquidFuel
		unitsPerVolume = 0.45

		filled = 0
		tweakable = false
	}
	RESOURCE
	{
		name = Oxidizer
		unitsPerVolume = 0.55

		filled = 0
		tweakable = false
	}
}

 

(note for anyone reading this in the future, this is a prototype and not necessarily how the feature would look)

I'd definitely like to hear some feedback on how you would expect this to work, also from @komodo who also requested the ability to partially fill tanks (and anyone else who is interested in these features, of course).  Specifically, a couple of questions still remain in my mind:

• In both cases, would you prefer the setting to be per resource or per tank type?
• For partially filled/empty tanks, how would you like it to be defined.  It could be a proportion (0-1), a percentage (0-100), or the number of "units per volume" that would be filled (so if unitsPerVolume = 0.45, the range would be 0.0-0.45)?

 

[mbartelsm]

Hello, is there a way to hide parts only if this mod is installed? What I want is for part A, B and C to be available in the part catalog by default, but when this mod is installed then B and C would disappear as they are now accessible as a subtype of A