[0.23.5] Realism Overhaul: ROv5.2 + Modlist for RSS 6/30/14

[NathanKell]

Aazard: Cool stuff! Grabbed, will examine.

[mar117117]

i wonder if there is any way to calculate launch window for cassini style gravity assists

[The Russian 1021]

just wondering, is their any rss/ro mods for an ares 1-x, or just a regular ares lying about? or has anyone have any replica craft files of it?

[Guest]

Aazard: Cool stuff! Grabbed, will examine.

With all the work you and your fellows do for us, it was the my very minor contribution... note that i am teaching myself these edits and i know that editing "part.cfg"'s is abit of a sloppy way to do it. If it can be dont via the "@part" method like many RO fixes are (which i am just a tiny bit confused by), it would most likley be a cleaner method. Note that some parts has ECLSS oxygen resources that i needed to remove by deleting the entry, i am unsure if this could be done with out directly editing the "part.cfg" as i did

If you (or anyone else for that matter) can figure out probe RT2 stats, reaction wheel strength, power usage amount & battery supply amount for unmanned parts (probes) the addition of a "@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[0]]:Final" line could be added to apply this to probes/unmanned command sections across the board, while assigning every probe the same stat set in these areas might be abit simplified, it would make everything follow the RO mentality

i wonder if there is any way to calculate launch window for cassini style gravity assists

RSS launch window planner

http://abrhmsanchez.github.io/ksp/

Edited April 16, 2014 by Guest

[ANWRocketMan]

RSS launch window planner

http://abrhmsanchez.github.io/ksp/

Won't work. That launch window planner doesn't allow for multi-planetary transfers.

[The Russian 1021]

Also, if there a way i could make an srb throttle down, i dont like my kerbals accelerating at 6G near burnout XD

[NathanKell]

Use thrust limiter in VAB.

Or use HoneyFox's Engine Thrust Controller to give a thrust curve like real SRBs have.

[The Russian 1021]

Ok nathan, i have a problem, just restarted my game, and now whenever i come in on reentry from leo, i dont slow down untill about 47 kilometers, and its like hitting a brick wall, i slow down from mach 24 to mach 9 in about a half a second, and all my kerbals die, and my craft pretty much disintegrates.

I tried reinstalling FAR, but it didnt work. Any ideas?

[NathanKell]

Picture of your reentry vehicle?

[The Russian 1021]

the only part that reenters is the capsule, along with docking port, and heatshield, the 3.75 meter one.

http://s7.postimg.org/wkzunbdzv/screenshot64.png

[NathanKell]

Is the heatshield attached by the correct node? Sometimes that's a problem.

....oh. You need to use the "Heatshield for Mk1-2 pod (4m)" instead of a 3.75m heatshield (the pod is 4m!)

[The Russian 1021]

odd, becuase ive used that heatshield many times before and no problems, but ill give it a go.... brb

[The Russian 1021]

ok, im back, and the mk1-2 heatshield isnt 4 meters, its 2.5, and i mightve not explained my problem well enough,

what happens, is that i reenter with a peri of about 70k, and once i slow down enough, i hit about 47k still going about 7km/s and then like i hit a wall i slow down to about 2.5 km/s at about some 30g, and everything tears apart, including heatshield, dockingport, mj, and parachutes. All my kerbals die, and the capsule survives, and only the capsule. So all in all, my problem is that the atmosphere doesnt simulate drag as it should be, i have very minimal drag. then a ridiculous amount once i hit a certain altitude. its almost like my atmosphere isnt there for the first 100k of reentry.

[The Russian 1021]

ok, i got some pics that might be able to help you help me-

http://s14.postimg.org/b3tvmngz5/screenshot67.png

http://s7.postimg.org/kwsh6x1nf/screenshot68.png

http://s28.postimg.org/u5rdpxhj1/screenshot69.png

http://s21.postimg.org/4gm18rfxj/screenshot71.png

http://s1.postimg.org/ocgkx75hb/screenshot72.png

http://s29.postimg.org/af38qsoav/screenshot73.png

http://s30.postimg.org/nxmjlwuup/screenshot74.png

http://s3.postimg.org/qyls3nhqr/screenshot75.png

http://s24.postimg.org/6o1chb351/screenshot76.png

http://s29.postimg.org/nxf7076rr/screenshot77.png

[The Russian 1021]

now that i see the drag on the heatshield, its giving off minimal drag, maybe thats the problem? its not simulating the drag it should be?

[NathanKell]

No, there are *two* of those type of heatshield. 1 is 2.5; look lower in the partlist (where all the other RO parts are) for RO heatshields. Use the one that says "for Mk1-2 pod (4M)."

You need to attach it properly so that the shield's *top* node is connected to the pod, and the shield's *bottom* node is free.

[NathanKell]

Aazard: I've looked a bit at your configs, and I'm sorry to say it is kinda hard to follow what's getting changed. Doing them up as a ModuleManager patch would be (a) safer, ( clearer, and © more useful. They're not hard to make though. Here's how.

First, the original docs to ModuleManager are very useful. Here's the original thread.. But as a quick explanation, config values are the things like foo = bar, and confignodes are the things that are like

foo
{
	//values here
}

You modify things with @: @ will change the original node or value. You add things with no-operator (add a value to a node by doing

@node
{
	newvalue = foo
	newNode
	{
		newvalue2 = bar
	}
}

etc.

When there is more than one confignode of a given name (multiple PARTs in the game, obviously, or multiple MODULEs in a PART) you can tell MM which to modify by keying based off its name value (as opposed to the node name). For example, your average RCS module

MODULE // the confignode's name
{
	name = ModuleRCS // the name value inside the node
	foo = 5
}

To change foo, do

@MODULE[ModuleRCS]
{
	@foo = 10
}

CAVEATS: @ only works if what it's modifying is already there. no-operator will add things whether or not they're there. (i.e. @foo = bar will fail if foo doesn't already exist in the cfg; foo = bar will add another copy of foo if foo is already in the cfg). In these cases, use % which will change or add, depending on if the value exists or not.

[Guest]

So as an example to avoid needing to add electric charge, SAS + reaction wheels SPU and RT2 antenna to multiple part.cfg's without creating multiple entries, only adding if not present or editing if they are present, i would do this?? (using "@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1]]:Final" entry from pods_EnergyUsage.cfg as example)

 
@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1]]:Final
{

@MODULE[ModuleCommand]
    {
        !RESOURCE[ElectricCharge]{}
        RESOURCE
        {
            name = ElectricCharge
            rate = 0.2666666 // 0.1 for base systems, 0.1666666 for operation per kerbal
        }
    }

    %RESOURCE[ElectricCharge]
    {
        %amount = 64320 // 24000 base + 12h charge (including life support)
        %maxAmount = 64320
    }

}

%MODULE
	{
			%name = ModuleSAS
}


%MODULE
{
	%name = ModuleReactionWheel

        %PitchTorque = 0.01
        %YawTorque = 0.01
        %RollTorque = 0.03

        %RESOURCE
        {
                %name = ElectricCharge
                %rate = 0.001
        }
    }

%MODULE
{
	%name = ModuleScienceExperiment	

	%experimentID = crewReport

	%experimentActionName = Crew Report
	%resetActionName = Discard Crew Report
	%reviewActionName = Review Report

	%useStaging = False	
	%useActionGroups = True
	%hideUIwhenUnavailable = True	
	%rerunnable = True

	%xmitDataScalar = 1.0
}

%MODULE
{
	%name = ModuleScienceContainer

	%reviewActionName = Review Stored Data
	%storeActionName = Store Experiments
	%evaOnlyStorage = True
	%storageRange = 2.0
}

%MODULE
{
	%name = KASModuleContainer
	%maxSize = 20
}


%MODULE
{
	%name = ModuleSPU

        %IsRTCommandStation = False
    }

%MODULE
{
	%name = ModuleRTAntenna

        %IsRTActive = true
        %Mode0OmniRange = 0.0000001
        %Mode1OmniRange = 50000000
        %EnergyCost = 0.09

        %TRANSMITTER
        {
        %PacketInterval = 0.3
        %PacketSize = 2
        %PacketResourceCost = 15.0
        }
    }


%MODULE
{
    %name = FlagDecal
    %textureQuadName = FlagObj
}

}

// THE ABOVE FILE IS THE MOST COMPLEX FILE I HOPE TO CREATE, so its giving me the most confusion but once i am corrected, if need be, it should easy to create for #CrewCapacity 1 (0?) thru 12

If this is completely wrong, i hope it atleast details what i'm hoping to do > to make all crewed components of same crew # have: same electric charge/electric drain, SAS, the same reaction wheel strength with same power usage, an RT2 SPU(with 6+ crew having "IsRTCommandStation = True") and default 50K km (50MM) comms device, a KAS capacity of 20 per crewman (maybe too much??), having the ability to crew report and containing a science container.

From looking at link it seems i can remove or modify any default ECLSS resources/abilities and/or add command modules with a "TAC_Bobcat.cfg", "TAC_FASA.cgf", "TAC_FusTek.cfg", "TAC_B9.cfg", "TAC_Habitat.cfg", "TAC_Squad.cfg", "TAC_Warp.cgf", ect using the @part with "%" to add/modify and and "!" to remove? this could get the total number of files to roughly 10 cgf's all of which would go in the RO folder?

If i understand this correctly i think i can think i can whip up a few files to modify 1: components with command modules and 2: one each for Bobcat, FASA, B9, fustec, habitat pack, Squad, Interstellar, AIES and ALCOR parts to have command modules if needed and no ECLSS stuff so TAC functions correctly with them and select station parts having TAC LS scrubbers/filters integrated.

I could also bring sciencedefs from AIES, FASA and interstellar to the "no grinding" RPL base/cap equal values with one cgf file each (or would i just add missing entries to the RPL science tweak file?) as so: using interstellar's magnetospheric Experiment as example?

@EXPERIMENT_DEFINITION[*]:HAS[#id[magnetosphericExperiment]]

{

@baseValue = 22

}

** should i include line "@xmitDataScalar = 1.0" or would that be in a separate cfg file, like "AIES_SciTweak.cfg" or "WarpSciTweak.cfg" where i would modify xmitDataScalar value and stuff like "%dataIsCollectable = True, %collectActionName = Take Data, %interactionRange = 1.2, %rerunnable = True (for readings) or False (for samples)" via the @part method? Edit think i solved this in "2nd version" link

Any ideas on what power usage/power supply a probe core would have/require compared to jrandoms supplied numbers for manned components? If so this could also apply to uncrewed command components to give them the reaction wheel tweaking and RT2 abilities (although i dont know what a reasonable integrated comms range for a probe would be, although in RSS 50MM seems fairly "tame" and acceptable for basic comms) plus adding RPLprobeReport to all probe cores

EDIT: i think i cleaned this up so it makes sense and be semi-readable without causing insanity, i am sorry for all the run on ideas but i wanted to cover most of my goals in one post, i think the estimate i have is 13 cfg files total? If so i can create these files before end of the day and atleast tidy up the named mods to fit the RPL pattern/mindset (well for the features i have focused on in this post atleast)

Please forgive such an indepth question, but once i understand this i wont need to ask again and can just submit the files for approval

Edit2: ok wow, after looking at some RPL tweak cfgs and RO fix cfgs i think i get it, I will try to make the cfg files, but i will wait on hearing that i am either blind lucky correct, or sadly foolish and wrong

rough copy of "RPL_Tweaks_ScienceDefs_squad_warp_fasa_bobcat_scansat.cfg" made by editing "RPL_Tweaks_ScienceDefs_squad.cfg" in RPL tweak pack to see if i have the right idea

https://www.dropbox.com/s/k5z9w5t6uk1xn2l/RPL_Tweaks_ScienceDefs_squad_warp_fasa_bobcat_scansat.cfg

rough copy of "RPL_Tweaks_ScienceInstruments_Squad_FASA_Bobcat_Warp_AIES.cfg" made by editing "RPL_Tweaks_ScienceInstruments_squad.cfg"

https://www.dropbox.com/s/i6qfrozumdpmeo2/RPL_Tweaks_ScienceInstruments_Squad_FASA_Bobcat_Warp_AIES.cfg

This is a 2nd version of above to see if this would be a better/more effective cfg

https://www.dropbox.com/s/3lqjxrtnusxtlzc/RPL_Tweaks_ScienceInstruments_Squad_FASA_Bobcat_Warp_AIES_v2.cfg

If this is correct then, although slightly time consuming, i should easily be able to handle this

Edited April 17, 2014 by Guest
fixed what i think were errors...

[Hodo]

I have to suggest this plugin be added to the list for the RO.

http://forum.kerbalspaceprogram.com/threads/70008-0-23-Advanced-Jet-Engine-%28AJE%29-v1-0-3-28-14-Compatibility-fix

The Advanced Jet Engine mod does to jets what Farrem does to the aerodynamics and is a must have.

[Guest]

I have to suggest this plugin be added to the list for the RO.

http://forum.kerbalspaceprogram.com/threads/70008-0-23-Advanced-Jet-Engine-%28AJE%29-v1-0-3-28-14-Compatibility-fix

The Advanced Jet Engine mod does to jets what Farrem does to the aerodynamics and is a must have.

its currently added under the second post of thread, with various other RO files not in main download, but i agree its a must have

[The Russian 1021]

Ok nathan, i figured out the problem, its something wrong with my heatshields, i went into the atmosphere without a heatshield, andi deaccelerated normally, and my kerbals survived. No idea how to fix it, but will reinstall DRE.

[NathanKell]

I've already explained what your issues are...

Aazard: response coming.

[Guest]

I've already explained what your issues are...

Aazard: response coming.

Now i feel like i'm asking too much of you, i dont want to be a hassle, I am writing the cfg as i type this... i assume that fixing them if need be will be faster if i have already written them

I have them all done but bobcat and fasa (they would require the most add/remove/convert of existing entries, so i will do them last, once i know i'm on the correct path), i also need to setup the science labs from warp and squad and i "should" be good to go

My very random attempt to nail down unmanned/probe power supply/usage: **used only as place holder until i figure out just what "rate" time scale is

 
@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[0]]:Final

@MODULE[ModuleCommand]
    {
        !RESOURCE[ElectricCharge]{}
        RESOURCE
        {
            name = ElectricCharge
            rate = 0.01 // 0.01 for base systems (or should this be 0.0028935 to make it drain 250units in 24 hours, this part assumes rate = per second use(rate x 60 = minutes, minutes x 60 = hours, hours x 24 = maxAmount)
        }
    }

    %RESOURCE[ElectricCharge]
    {
        %amount = 250 // 250 base + 12h charge 
        %maxAmount = 250
    }

@MODULE[ModuleReactionWheel]
    {
        @PitchTorque = 0.01
        @YawTorque = 0.01
        @RollTorque = 0.03

        @RESOURCE
        {
                @name = ElectricCharge
                @rate = 0.001
        }
    }

    %MODULE[ModuleSPU]
    {
        %IsRTCommandStation = False
    }

    %MODULE[ModuleRTAntenna]
    {
        %IsRTActive = true
        %Mode0OmniRange = 0.0000001
        %Mode1OmniRange = 50000000
        %EnergyCost = 0.09

        %TRANSMITTER
        {
        %PacketInterval = 0.3
        %PacketSize = 2
        %PacketResourceCost = 15.0
        }
    }

%MODULE
{
	%name = ModuleScienceExperiment	

	%experimentID = RPLprobeReport

	%experimentActionName = Activate Probe Sensors
	%resetActionName = Clear Probe Data Banks

	%useStaging = False
	%useActionGroups = True
	%hideUIwhenUnavailable = True

	%dataIsCollectable = True
	%collectActionName = Collect Data
	%interactionRange = 2
	%rerunnable = True	
	%resettable = True
	%resettableOnEVA = True

	%xmitDataScalar = 1.0
}
}

Very sorry about taking your time and the rapid fire posts

Example of my attempt, the TAC_FusTek.cfg: (if this is semi correct, this should be a breeze to finish all cfg files before the RPL MS19 release)

https://www.dropbox.com/s/uieqgq5orbdbbad/TAC_FusTek.cfg

Everything but FASA/Bobcat and edited pods_EnergyUsage.cfg (i really hope this is correct lol, either way feels good to contribute)

https://www.dropbox.com/s/tdfmn2adr1er4ta/experimental%20cfgs.zip

I will need to download/view fresh copies of FASA & Bobcat's soviet historical pack to compare to mine, as mine are abit butchered with my own edits directly to part cfg's. this ModuleManager patch method is far better than my sloppy method!

Edited April 18, 2014 by Guest

[NathanKell]

Aazard: no worries.

Belated response that I just finished:

% really only works well for values; I'm not sure how (or whether) it works right for nodes. If it did, though, you'd have to do %NODE[node_name] not just %NODE.

Also, I'm really not sure why you're applying it to so many things? The flagdecal thing, for example, which your changing won't do any good (if a model already has such an object, you can bet that the cfg already supports that module; and if it doesn't, adding the module won't do any good). Further, these changes will overwrite the changes made by part-specific patches (like the FASA patch, or RealismOverhaul's patching of the Mk1, Mk1-2, and AIES pod). So in general, unless you really need to, I don't recommend using that kind of wildcarding.

What you might do is some kind of check for a module that you will know will be present if a pod supports RO, and not present if it doesn't yet; for example, checking if it has the oxygen resource, or a ModuleSPU--but both these aren't sure things.

If you have the patience, I'd highly recommend making patches for individual parts, using wildcarded patches only as the last resort.

(Hey actually, this might be a perfect usecase for tagging things: part-specific patches would tag their parts RO = true and then the generic patches, executed later, would only affect parts without those tags. Anyway.)

That said, here's what I'd suggest based on the clip you posted.

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1],!MODULE[ModuleSPU],testBLAH]:Final // or whatever the syntax and test you want.
{

	@MODULE[ModuleCommand]
    {
        !RESOURCE[ElectricCharge]{}
        RESOURCE
        {
            name = ElectricCharge
            rate = 0.2666666 // 0.1 for base systems, 0.1666666 for operation per kerbal
			// Depends on the pod, really, but 266 watts is probably fine.
        }
    }

    @RESOURCE[ElectricCharge] // it's gonna have EC
    {
        @amount = 64320 // 24000 base + 12h charge (including life support)
        @maxAmount = 64320
    }

	//rather than doing this (if you were worried about EC not existing),
	  // instead of using % (which may not work for nodes) you could do:
	!RESOURCE[ElectricCharge] // will remove if exists
	//then
	RESOURCE
	{
		name = ElectricCharge
		amount = 64320
		maxAmount = 64320
	} // which will add it back. This will work whether or not EC exists in the part...


	!MODULE[ModuleReactionWheel] // RO will be switching to totally getting rid of these.

	// snip stuff you're not changing...

	//if % doesn't work for nodes, you can do this this way
	!MODULE[KASModuleContainer]
	MODULE
	{
		name = KASModuleContainer
		maxSize = 20
	}

	// same for the RT2 stuff--I'm not sure what's a reasonable packet cost, check brooklyn666's configs.
}

I think that expirement thing will work, yes, but I'm not sure. I'm not so up on wildcards. You can ask in the current (1.5.6) MM thread.

MM tweaks can be in any file; all cfgs in GameData (excepting those in PluginData folders) are loaded by the game, and MM trawls through all confignodes loaded from cfgs.

....uh, I think I missed some edits and your new post. I'll respond to those too, gotta eat now.

[Guest]

Aazard: no worries.

Belated response that I just finished:

% really only works well for values; I'm not sure how (or whether) it works right for nodes. If it did, though, you'd have to do %NODE[node_name] not just %NODE.

Also, I'm really not sure why you're applying it to so many things? The flagdecal thing, for example, which your changing won't do any good (if a model already has such an object, you can bet that the cfg already supports that module; and if it doesn't, adding the module won't do any good). Further, these changes will overwrite the changes made by part-specific patches (like the FASA patch, or RealismOverhaul's patching of the Mk1, Mk1-2, and AIES pod). So in general, unless you really need to, I don't recommend using that kind of wildcarding.

What you might do is some kind of check for a module that you will know will be present if a pod supports RO, and not present if it doesn't yet; for example, checking if it has the oxygen resource, or a ModuleSPU--but both these aren't sure things.

If you have the patience, I'd highly recommend making patches for individual parts, using wildcarded patches only as the last resort.

Edit: following your example, this file below should be correct and much more conservative covering only basics of TAC/RT2/KAS for manned pods and probes, i should easily be able to do just pure TAC fixing cfgs for FASA/bobcat and non-CommandModule manned components (habitat/station modules & science labs), altering only there power amount/usage and life support resources (and CO2/waster water scrubbers for some Mir/FusTek/Habitat parts). There are not that many parts to do between whats left as long this file works out

https://www.dropbox.com/s/2lq5af9uu3r7pij/pods_EnergyUsage.cfg

(Hey actually, this might be a perfect usecase for tagging things: part-specific patches would tag their parts RO = true and then the generic patches, executed later, would only affect parts without those tags. Anyway.)

That said, here's what I'd suggest based on the clip you posted.

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[1],!MODULE[ModuleSPU],testBLAH]:Final // or whatever the syntax and test you want.
{

	@MODULE[ModuleCommand]
    {
        !RESOURCE[ElectricCharge]{}
        RESOURCE
        {
            name = ElectricCharge
            rate = 0.2666666 // 0.1 for base systems, 0.1666666 for operation per kerbal
			// Depends on the pod, really, but 266 watts is probably fine.
        }
    }

    @RESOURCE[ElectricCharge] // it's gonna have EC
    {
        @amount = 64320 // 24000 base + 12h charge (including life support)
        @maxAmount = 64320
    }

	//rather than doing this (if you were worried about EC not existing),
	  // instead of using % (which may not work for nodes) you could do:
	!RESOURCE[ElectricCharge] // will remove if exists
	//then
	RESOURCE
	{
		name = ElectricCharge
		amount = 64320
		maxAmount = 64320
	} // which will add it back. This will work whether or not EC exists in the part...


	!MODULE[ModuleReactionWheel] // RO will be switching to totally getting rid of these.

	// snip stuff you're not changing...

	//if % doesn't work for nodes, you can do this this way
	!MODULE[KASModuleContainer]
	MODULE
	{
		name = KASModuleContainer
		maxSize = 20
	}

	// same for the RT2 stuff--I'm not sure what's a reasonable packet cost, check brooklyn666's configs.
}

I think that expirement thing will work, yes, but I'm not sure. I'm not so up on wildcards. You can ask in the current (1.5.6) MM thread.

MM tweaks can be in any file; all cfgs in GameData (excepting those in PluginData folders) are loaded by the game, and MM trawls through all confignodes loaded from cfgs.

....uh, I think I missed some edits and your new post. I'll respond to those too, gotta eat now.

As its easy to see, i'm still trying to get the hang of this, as to why i attempted to use a wildcard at add/alter so many things >> i didnt know any better . But i hope the files i supplied show my intentions. The flagdecal thing, that was just cause i saw some parts didnt have it, i doubt thats important to realism though, so i will ditch it. I have the patience, I'll take the recommendation and make patches for individual parts (i only need one cfg per mod folder, like TAC_FusTek.cfg effecting each part with an @part line, not a cfg for each part separately?).

Very glad to hear reaction wheels in pods/probes will be removed, the remaining 2 immediate questions for you would be #1 what you feel an acceptable "built-in comms device" range would be (i have the RT2 RO file from brooklyn666 so i can use stats listed there) i basicly copied your settings from Mk1 pod RO fix and #2 what is a realistic KAS container size for a command pod by crew amount (if any at all).

Perhaps i shouldnt be doing this at all? I has hoping to atleast get TAC correctly working and RT2/KAS settings universally set for all pods/probes. I am happy to learn this correctly and write as many cfg's as are needed. The mods i tried to write files for should bring RO fixes for RPL to near completely fixed in the way of TAC/RT2/KAS support. I will test this but i think i can get away with wild carding some stuff (RT2/KAS) along with power/power use in pods_EnergyUsage.cfg

You say "What you might do is some kind of check for a module that you will know will be present if a pod supports RO, and not present if it doesn't yet; for example, checking if it has the oxygen resource, or a ModuleSPU--but both these aren't sure things." >> do you mean try looking at a part.cfg for ModuleSPU, and if its present not attempting to alter it in my cfg file or trying it and seeing if it works?

Just so its clear, this isnt a misuse of your skills/time in your opinion is it? I want to be helpful if i can to the RPL community and i didnt see anyone else working on these issues at the moment. i only need to make maybe 10 to 12 cgf's that would cover maybe 50 to 100 (at the most) parts, which i think i could handle in one afternoon/evening.

Thank you for your help, i will try to polish this up, starting with pods_EnergyUsage.cfg (only effecting power, RT2, KAS and, if it works, the RPL probe reading for all probes and crew report/science container for pods...that should be cleaner and more like your example) To get the TAC power usage to work it seems i need to have Modulecommand present in part.cfg, there is no harm in adding this to manned componets that lack it is there? (like some FusTek parts or the various science labs)?

woo hoo, alot closer to having this done now thanks to your advice, i hope i can make the files worthy of RO inclusion

Edit: file below is much cleaner/more conservative, if it works correctly should leave very few Bobcat, FASA, FusTek, Habitat pack and science labs/crew cabin parts to make TAC/RT2/KAS fixes for. thanks alot for your help, seems i need it lol

https://www.dropbox.com/s/2lq5af9uu3r7pij/pods_EnergyUsage.cfg

EDIT2 completed majority, i will link them below, when you have time to look at them let me know if i have managed to understand what i am doing. (i requested some advice/help in the MM thread aswell, so i can get this finished and submit the corrected 100% working files when i get them all done, below link is still wip)

https://www.dropbox.com/s/ppseuw6k1whuyon/expermental%20KSP%20cfgs.zip

Edited April 18, 2014 by Guest