Recommended Posts

@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)

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

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

Share this post

Link to post

Share on other sites

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)?

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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!

Share this post

Link to post

Share on other sites

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!

Share on other sites

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?

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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:

publicvoidFixedUpdate(){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);}}}

Share this post

Link to post

Share on other sites

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...

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

@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.

Share this post

Link to post

Share on other sites

@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

(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)?

Share this post

Link to post

Share on other sites

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