[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

Sigma88 · June 12, 2016

2 minutes ago, CoriW said:
Alright, thank you.

Slight change in the calculation as it didn't occur to me that SRB's don't have a mentioned total mass, just dry mass. Since SolidFuel weighs in at 7.5kg / unit we can just use that accompanied with fuel amount, located here:

So amount * 7.5 will give us the fuel mass, then we'll also need the Newtons of thrust, as well as the Isp, both of which are located here:

Now the maxThrust is listen in kN, so we'll have to multiply it by 1000 in order to convert to N, so maxThrust * 1000. As for the Isp, that can be located in the first key in the atmosphereCurve... I'm not sure how you'd go about reading that key so for sake of putting together a reference calculation I'll just call it "key" for now.

Alright so with all of that we now have our calculation, which is referencing parts of the config. (amount * 7.5) / ((maxThrust * 1000) / (key * 9.81)) , in this case it would be (140 * 7.5) / ((192 * 1000) / (165 * 9.81)) = 8.8519921875 and I would need that key to be put into a floatCurve as a key value.

For clarity sake, I'll also provide the part of the cfg where I need the calculation to be placed.
MODULE
{
      name = TestFlightReliability_EngineCycle
      ratedBurnTime = (CALCULATION)*1.5
      cycle
      {
            key = 0 15.0
            key = 5 1.0 -0.8 0
            key = ((CALCULATION)*1.5)+5  1.0 0 0
            key = (((CALCULATION)*1.5)+5)*1.5 100 0 0
      }
}

quick question, just to make sure...

you don't expect this value to change when the fuel gets consumed, do you?

because MM would only do the calculation once, when starting KSP and not continuously during flight

CoriW · June 12, 2016

2 hours ago, Sigma88 said:

quick question, just to make sure...

you don't expect this value to change when the fuel gets consumed, do you?

because MM would only do the calculation once, when starting KSP and not continuously during flight

That's correct. Basically I just need the number once to tell TestFlight when the engine will start losing reliability/fail.

EDIT: Just re-reading this, I've realized it could be interpreted incorrectly.. When I said "That's correct", I meant "That's correct, I don't expect this value to change when the fuel gets consumed and only need the calculation to be done once when starting KSP and not continuously during flight"

Edited June 12, 2016 by CoriW

autumnalequinox · June 12, 2016

Is there a way to write a simple MM config to universally decrease the amount of EC solar panels generate? I'm still new to making configs I typically just copy/paste or write CTT configs.

I'm thinking something like reducing it either from /secs to /minutes or simply reducing their EC production by 50% or so.

Starwaster · June 12, 2016

11 minutes ago, autumnalequinox said:

Is there a way to write a simple MM config to universally decrease the amount of EC solar panels generate? I'm still new to making configs I typically just copy/paste or write CTT configs.

I'm thinking something like reducing it either from /secs to /minutes or simply reducing their EC production by 50% or so.

I use this. I think I based it off of Realism Overhaul or something... or maybe I just pulled that number out of thin air.

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleDeployableSolarPanel]
	{
		@chargeRate *= 0.1523889
	}
}

autumnalequinox · June 12, 2016

On 6/12/2016 at 2:56 PM, Starwaster said:
I use this. I think I based it off of Realism Overhaul or something... or maybe I just pulled that number out of thin air.
@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleDeployableSolarPanel]
	{
		@chargeRate *= 0.1523889
	}
}

Thanks! I DLed realism overhaul and scoured the cfgs and couldn't find anything easily recognizable. I can totally work with this thanks Starwaster!

Edited June 12, 2016 by autumnalequinox
server squirrels

panourgue · June 14, 2016

Hi everyone. Not sure if this is the right thread, but I'm in desperate need of help

I am playing RP0. Basically there are parts in VAB in career mode that are grayed out, but I can't buy them (there is no button for buy), but if I go into RnD there are actually two instances of the same part. If I buy both of them next time I go into RnD there will be three and so on... No matter what I try I cannot use these parts in VAB.

I looked into ModuleManager.ConfigCache and discovered that both of these parts occur in there two times. Like this:

UrlConfig
{
	name = HECS2_ProbeCore
	type = PART
	parentUrl = Squad/Parts/Command/probeCoreHex/probeCoreHex
	url = Squad/Parts/Command/probeCoreHex/probeCoreHex/HECS2_ProbeCore
	PART
	{
		name = HECS2_ProbeCore
		module = Part
		author = Ven
	...
	}
}

And

UrlConfig
{
	name = HECS2_ProbeCore
	type = PART
	parentUrl = Squad/Parts/Misc/AsteroidDay/HECS2
	url = Squad/Parts/Misc/AsteroidDay/HECS2/HECS2_ProbeCore
	PART
	{
		name = HECS2_ProbeCore
		module = Part
		author = RoverDude
		...
	}
}

Is this a correct behavior?

I'll be grateful for any ideas :blush:

Starwaster · June 14, 2016

1 hour ago, panourgue said:
Hi everyone. Not sure if this is the right thread, but I'm in desperate need of help

I am playing RP0. Basically there are parts in VAB in career mode that are grayed out, but I can't buy them (there is no button for buy), but if I go into RnD there are actually two instances of the same part. If I buy both of them next time I go into RnD there will be three and so on... No matter what I try I cannot use these parts in VAB.

I looked into ModuleManager.ConfigCache and discovered that both of these parts occur in there two times. Like this:
UrlConfig
{
	name = HECS2_ProbeCore
	type = PART
	parentUrl = Squad/Parts/Command/probeCoreHex/probeCoreHex
	url = Squad/Parts/Command/probeCoreHex/probeCoreHex/HECS2_ProbeCore
	PART
	{
		name = HECS2_ProbeCore
		module = Part
		author = Ven
	...
	}
}
And
UrlConfig
{
	name = HECS2_ProbeCore
	type = PART
	parentUrl = Squad/Parts/Misc/AsteroidDay/HECS2
	url = Squad/Parts/Misc/AsteroidDay/HECS2/HECS2_ProbeCore
	PART
	{
		name = HECS2_ProbeCore
		module = Part
		author = RoverDude
		...
	}
}
Is this a correct behavior?

I'll be grateful for any ideas

@Ven you gave the stock hex probe the same name as the one from Asteroid Day??? Duplicate part names are BAD. And no panourgue, this is not normal behavior.

Edited June 14, 2016 by Starwaster
correcting self

lextacy · June 15, 2016

I have some parts that have spaces in them like "IUSXNP_lft_ 3322HORTx23" from chaka monkey. Is there a way to get these to patch?

blowfish · June 15, 2016

35 minutes ago, lextacy said:

I have some parts that have spaces in them like "IUSXNP_lft_ 3322HORTx23" from chaka monkey. Is there a way to get these to patch?

Replace the space with ?

lextacy · June 15, 2016

10 minutes ago, blowfish said:

Replace the space with ?

IT WORKED!! im so shocked , i thought i was gonna have a nightmare of renaming parts all night

Drew Kerman · June 16, 2016

19 hours ago, lextacy said:

i thought i was gonna have a nightmare of renaming parts all night

For future reference if such a scenario pops up again, search "fnr.exe" and sleep well

Hremsfeld · June 19, 2016

Hi, I'm having trouble with what I thought would be a straightforward .cfg - I'm trying to double the range at which science experiments such as thermometers and crew reports can be interacted with, simply add a range if it was forgotten/omitted, and then turn all the data-measurement experiments transmit all their science (i.e. the experiments that don't rely on bringing something back, such as the thermometer transmitting a temperature reading as opposed to the goo being goo)

Here's what I have:

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
	@interactionRange *= 2
}

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[!interactionRange]]
{
	interactionRange = 5
}

@PART[!GooExperiment,!science_module,!dmSolarCollector]:HAS[@MODULE[ModuleScienceExperiment]]
{
	@xmitDataScalar = 1
}

Any advice? Did I mess up when to put an @ in front of a variable?

Edited June 19, 2016 by Hremsfeld

blowfish · June 19, 2016

59 minutes ago, Hremsfeld said:

Hi, I'm having trouble with what I thought would be a straightforward .cfg - I'm trying to double the range at which science experiments such as thermometers and crew reports can be interacted with, simply add a range if it was forgotten/omitted, and then turn all the data-measurement experiments transmit all their science (i.e. the experiments that don't rely on bringing something back, such as the thermometer transmitting a temperature reading as opposed to the goo being goo)

Here's what I have:

*snip*

Any advice? Did I mess up when to put an @ in front of a variable?

For starters, you're trying to change the value on the part, not the module. In the first example, you would want something like

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
    @MODULE[ModuleScienceExperiment]
    {
        @interactionRange *= 2
    }
}

For the second one, you want ~, not ! - ! is for nodes

For the third one, I don't think you can exclude parts like that. You would need something like @PART[*}:HAS[~name[GooExperiment],~name[science_module],~name[dmSolarCollector],@MODULE[ModuleScienceExperiment]] (and again, change the value on the module and not the part

Hremsfeld · June 19, 2016

Worked like a charm. Thanks! If anyone wants to use it, the "final" form is:

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
    @MODULE[ModuleScienceExperiment]
    {
        @interactionRange *= 2
    }
}

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[~interactionRange]]
{
    @MODULE[ModuleScienceExperiment]
    {
        interactionRange = 5
    }
}

@PART[*]:HAS[~name[GooExperiment],~name[science_module],~name[dmSolarCollector]]:HAS[@MODULE[ModuleScienceExperiment]]
{
    @MODULE[ModuleScienceExperiment]
    {
        @xmitDataScalar = 1
    }
}

blowfish · June 19, 2016

18 minutes ago, Hremsfeld said:

Worked like a charm. Thanks! If anyone wants to use it, the "final" form is:


@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
    @MODULE[ModuleScienceExperiment]
    {
        @interactionRange *= 2
    }
}

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[~interactionRange]]
{
    @MODULE[ModuleScienceExperiment]
    {
        interactionRange = 5
    }
}

@PART[*]:HAS[~name[GooExperiment],~name[science_module],~name[dmSolarCollector]]:HAS[@MODULE[ModuleScienceExperiment]]
{
    @MODULE[ModuleScienceExperiment]
    {
        @xmitDataScalar = 1
    }
}

I don't think multiple HAS blocks are allowed. That patch will still work because you're only modifying ModuleScienceExperiment anyway.

Hremsfeld · June 19, 2016

6 minutes ago, blowfish said:

I don't think multiple HAS blocks are allowed. That patch will still work because you're only modifying ModuleScienceExperiment anyway.

Looks like they might be, unless I misunderstand what you're trying to say; I took the goo out of the exception list, made a quick testrocket, put it on the pad, and checked one of the goos:

http://i.imgur.com/fTHtfJa.jpg

One quicksave/exit/re-add to exceptions later, and on running the other goo I got this:

http://i.imgur.com/jKhg1il.jpg

Incidentally, it seems experiments are saved with the transmit/recover percentages that apply on being run, even if those change.

Waxing_Kibbous · June 19, 2016

I'm curious if MM can do a simple life support system using only EC. Pods, command seats, and habs will consume x amount of EC per kerbal, when there is no power for y time they die. I'm not too concerned with EVA but that'd be a bonus to give EVA suits a time limit too.

blowfish · June 19, 2016

1 hour ago, Hremsfeld said:

Looks like they might be, unless I misunderstand what you're trying to say; I took the goo out of the exception list, made a quick testrocket, put it on the pad, and checked one of the goos:

http://i.imgur.com/fTHtfJa.jpg

One quicksave/exit/re-add to exceptions later, and on running the other goo I got this:

http://i.imgur.com/jKhg1il.jpg

Incidentally, it seems experiments are saved with the transmit/recover percentages that apply on being run, even if those change.

The result is probably that :HAS[@MODULE[ModuleScienceExperiment]] is ignored. Which doesn't have an effect because you're only modifying ModuleScienceExperiment anyway

52 minutes ago, Waxing_Kibbous said:

I'm curious if MM can do a simple life support system using only EC. Pods, command seats, and habs will consume x amount of EC per kerbal, when there is no power for y time they die. I'm not too concerned with EVA but that'd be a bonus to give EVA suits a time limit too.

ModuleManager can't affect how things work in-game - this would require a plugin. ModuleManager can only modify things before KSP loads them. To put it another way, anything that can be accomplished with MM could also be accomplished by manually editing all the .cfg files (but of course that would be very painful).

vosechu · June 19, 2016

I've been hunting around for about 2 hours and not making much headway, maybe this is impossible, but any advice would be recommended.

I've been trying to make a patch that would warn me if I'm using any non-stock parts (or just hide them in the editor). Ven's wonderful VensStockRevamp makes my stock parts way more beautiful, but it adds a lot of parts and in this last upgrade it bit me until Ven's was back up and running on 1.1.

So I created a dumb patch that hides all the VSR created parts. But then I started thinking about other mods that do this, MechJeb, KER, etc.

It got me thinking about whether I could hide anything which doesn't have the assembly name of Squad. Alternatively, I would love to add a bit in the description about which assembly a part came from. I thought about using Author, but Porkjet is one example of a Stock author who also mods (and there are others).

I've been hunting for a while, but there's nothing special about the squad PartConfig files, and I can't find anything in the KSPAPI that would allow me to do something like:

@PART[*]:HAS[#assemblyName[Squad]]:AFTER[Squad] {}

or maybe

@PART[#assemblyName[Squad]]:AFTER[Squad] {}

Any advice or other ideas would be greatly appreciated!

blowfish · June 19, 2016

@vosechu All(?) of the new parts in Ven's are in the "Part Bin" folder - you can just delete that. ModuleManager doesn't currently have a way to figure out where a part came from (that information exists, but it's not accessible to patches).

vosechu · June 19, 2016

Just now, blowfish said:

@vosechu All(?) of the new parts in Ven's are in the "Part Bin" folder - you can just delete that. ModuleManager doesn't currently have a way to figure out where a part came from (that information exists, but it's not accessible to patches).

Yeah, that's pretty much what I did. One nice thing about having the mod installed but not showing it is that it won't deorbit my craft that I haven't been able to update; I just won't send up new craft with that particular problem.

In the end I did this, but VSR isn't the only one I want to do this to, I'd like to find a way to make it generic:

// Disable the new Vens Stock Revamp parts.
@PART[1x3SPanels|1x3WPanels|45DegreeRCS|Angledpanel|basicCanard|CryoXBig|CryoXendButt|CryoXmed|CryoXnoseCone|CryoXsmall|fuelTank1-5|HeatShield0|HeavyRcs|InflatableHAB|InlineRCS|KerbCan|largeFixedAntenna|LargeInflatableHAB|LargeOMS|largeTrussMount|LGLadderUtility|LongDeployableAntenna|LongLadder|LVT15|mediumFixedAntenna|MedLadder|MedLadderUtility|MicroEngineB|microIbeam|MicroInflatableHAB|MK1Cargobay|MK1LFOFuselage|MK2VApod|OCTOs0Adapter|OCTOServiceBay|OCTOTank|OscarAtank|OscarDtank|OscarEtank|parachuteRadial_Drogue|parachuteSingle_drogue|ParaDockingPort|PoodleM|RadialavionicsHub|RadialLF|RadialLFLong|RadialLFO|RadialLFOLong|RadialMonoMini|RadialReactionWheel|rtgMini|ShieldCapLarge|shortDecoupler1-2|size0PulseJet|size2nuclearEngine|size3ReactionWheel|SmallFixedAntenna|SmallInflatableHAB|smallISRU|SmallPointLight|smallRadialDecoupler|SmallSpotLight|SmallStripLight|SMLadderUtility|SnubOtron|softTankMK1|softTankMK2|softTankMK3|softTankMK4|softTankMK5|strutCube3way|strutCube90|strutCubeLarge|strutCubeMedium|strutCubeMountingPlate|strutCubeOCTOAdapter|strutCubeS0Adapter|strutCubeSmall]:NEEDS[VenStockRevamp]:AFTER[VenStockRevamp]
{
	@TechRequired = Unresearcheable
	@category = none
}

DStaal · June 19, 2016

Also, a better place to start is probably with Filter Extensions. (In fact, I think it has what you want - a category for stock parts only - built-in...)

vosechu · June 19, 2016

2 minutes ago, DStaal said:

Also, a better place to start is probably with Filter Extensions. (In fact, I think it has what you want - a category for stock parts only - built-in...)

Shoot, I realize that one thing I didn't mention is that KSP actually refuses to let me launch if I have one of these parts hidden in my craft. It's still loadable because I didn't delete the models, but it's not visible in the editor and if I try to launch KSP will tell me that I have an unresearched part. I found that I was often missing a stray communotron32 or AR202 hidden somewhere in some science bay tucked out of the way.

Also, this tells me from the loading dialog whether there are parts that I need to fix to make my crafts stock compatible. Very nice during upgrade season.

Edited June 19, 2016 by vosechu

DStaal · June 19, 2016

Filter Extensions doesn't hide the parts from the game - just it gives you more control over category tabs and such in the VAB/SPH. One of the tabs is 'Squad' - only Squad's parts, so you can see what parts are stock and which aren't.

vosechu · June 19, 2016

Just spitballing here, is there anything that could be done with load order? Like, could I force Squad parts to load first, then apply my patch to all parts in an `:AFTER[Squad]`, then load the rest of the mods?

[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation