Crzyrndm

8th column, 4th node from the bottom in the stock tech tree

@PART[MiniISRU] { @MODULE[ModuleResourceConverter],* // IIRC, that hits every module of that type... { @GeneratesHeat = false } } Might want to fiddle with the thermal efficiency and stuff a little as well, but the getting rid of overheats is faster with ^^ than messing with overheat temps and heating rate

I try and avoid excessive proliferation of categories in the main distribution, so I don't feel like either of the requests should be integrated. However: MM patch to split stack/radial decouplers: @CATEGORY[Filter?by?Function]:FINAL // user customisation { !SUBCATEGORIES {} // delete existing node SUBCATEGORIES { list = 100,Adapter list = 101,Multi-Coupler list = 102,Stack Decouplers // split decouplers into stack and radial decouplers list = 103,Radial Decouplers list = 104,Docking Ports list = 105,Control Surface list = 106,Air Intake list = 107,Landing Gear list = 108,Landing Legs list = 109,Solar Panels list = 110,Power Storage list = 111,Data Transmitter } } +SUBCATEGORY[Decouplers] // copy existing config { @name = Stack Decouplers @Filter { CHECK // not surface attachable { type = profile value = srf invert = true } } } @SUBCATEGORY[Decouplers] // copy existing config { @name = Radial Decouplers @Filter { CHECK // not surface attachable { type = profile value = srf } } } Remote Tech specific parameters aren't currently accessible Any install should have a fuel tanks subcategory in Filter by Function as the second or third entry, and the default pack also includes a Fuel tanks category and subcategories with a more specific breakdown. If you don't have these I need to see logs and a MM cache

Some other common issues: 1) Incorrect install path. Many plugins use a specific GameData relative path for loading the icon. Make sure don't have nested GameData folders or anything like that 2) Reformatted icons. This happened a lot pre 1.0 and native DDS texture support with people changing these icons to DXT formats which could cause the same issue as 1) depending on how the icon was loaded

See EvilReepers explanation (I stand corrected)

There is support for blizzy's toolbar, it's a .cfg only switch though from memory. GameData / PilotAssistant / PluginData / PilotAssistant / Settings.cfg => Change "UseStockToolbar" to "False"

v1.12.4 * Fix direct throttle being affected by speed unit transforms * Scaled keyboard inputs for speed to retain consistency across units (eg. Z increases speed target by 100 of current unit) * RPM API extensions and fixes Just some minor updates while I have an hour or two to spare

https://github.com/Crzyrndm/B9-PWings-Fork/releases/tag/2.1 That would be the latest standard download.

He's got the modified version (not the one from this thread) that doesn't have size limits (I can't remember who modified it, but there was a few comments a couple of pages back and another thread somewhere) EDIT

If speed is an issue, a for loop on a basic array may give some minor benefits over the foreach loop, or a HashSet<Part> may be a better option than iterating over a collection (small average collection size counts against this method). That's only if you need the speed though, which really depends on how many parts this module will be active on and even then is probably not worthwhile (if it's on lots of parts, it would most likely be a better optimisation to approach it from a vessel level instead of from individual parts).

GameEvents.OnPartDie is the method I presume he is using from a PartModule

FAR toolbar button => Flt Settings => Change "Flt Data" Dropdown to "Air Spd" => Change units and reference to taste

How is it failing? Are you receiving a callback to that function from the GameEvent when a part is destroyed? Is it failing to recognise a dying part as the parent/child?... Presuming that it is the latter since it seems rather likely if the joints are already removed, you can try caching the connected parts during OnStart and comparing the destroyed part against that list which is then independent of whether a part is still connected (the cache will need to be refreshed for events which create and destroy joints (docking, joint break, etc.))

Best place to start with this would probably be the history of "on-rails" thrust mods such as this solar sail mod (alternatively Principia, while a much more complex mod, also deals with unfocused vessels). Somewhere in there will be the code for modifying the orbits of an on-rails craft and then you just need to work out how to apply it for your situations.

From a technical standpoint I can't see any reason for this to occur. Neither plugin does any work until much later, and it doesn't crash until it reaches Squads texture loader (plugin and audio files successfully loaded). It does appear to crash out while going through FE's icons, but there is no discernible reason for it to do so, no errors printed to the log, and it works every other way.

Probably either because no one has asked for them to be added, or they are too strongly linked to the AP functions to be reliable Because it makes it easier to read? Past the first ~1000 dV atmospheric is normally not useful information, so why display it constantly? http://wiki.mechjeb.com/index.php?title=Manual/Blacklisting_modules

That's not quite true. You can use any external class that inherits Monobehaviour (which any class interfacing with KSP must do) like this to get access to Coroutines (note: the function is just a shortcut so I don't need to change the syntax)

blowfish would be correct

Monodevelop (and SharpDevelop and a couple of others) is just an alternative to Visual Studio. Visual Studio tends to be the default for windows development though

This should do what you need. You'll need to compile it though (I can't do that atm) and I've probably forgotten something using System; using System.Collections.Generic; using System.Collections; using System.Linq; using UnityEngine; namespace ThisIsNotTested { public class ThrottledResourceConsumer : PartModule { [KSPField] public float Rate; // consumption per second at max throttle [KSPField] public string Resource; // the resource to use public override void OnStart(StartState state) { if (!Highlogic.loadedSceneIsFlight) return; // do nothing in the editor if (part.Modules.GetModules<ModuleEngines>.FirstOrDefault() == null) Destroy(this); // only want this module to work on parts that have an engine as well. Kill it if no engine module is present } public override void OnFixedUpdate() { if (!Highlogic.loadedSceneIsFlight) return; // do nothing in the editor // pull EC based on the throttle being used for this vessel part.requestResource(Resource, Rate * TimeWarp.fixedDeltaTime * vessel.ctrlState.mainThrottle); } } } And the module manager patch to add it to a part @PART[<insert your part name here>] { MODULE { name = ThrottledResourceConsumer Rate = 10 // 10 EC per secon at max throttle Resource = ElectricCharge } }

The best source of information on this stuff is here but I don't think there's anything in the stock module that allows ISP to be modified by velocity. velocityCurve is not a valid parameter as of 1.0 (it was a parameter pre-1.0 so you will see it mentioned every now and again). The best way I can see to do this is a separate module that bases power draw on current throttle and any other parameters you want. You'll probably need something custom for that, There aren't many stock modules that vary based on throttle

FE is as far as I could make it, fully compatible with any mod (or can be made so without any changes to the plugin). Of course, the problem with being overly generic is that it can't look for a lot of specific things (about 90% certain it can't tell surface and orbital scanners apart for example). The majority of what it does is just look for a certain module and either include or exclude by the presence of that module (and then the other 20 odd identification methods augment that where possible). The trick here is that I'm using subcategories that ship with the mod to identify things for your subcategories that already work with a large number of mods. Categories go in the first column, subcategories in the second. They turn up under the stock ones If (big if) I can add a third layer to the 1.1 UI, I will do so and rewrite the shipping FE configs to take advantage of that. If I can't do that but someone else does, I will try to support that. That's all I can do at the moment.

+1 For atleast one more layer of categorisation. Two forces there to either be too many parts in a selection, or too many categories to find what you need

May be of interest (although it doesn't solve the small SRB issue...):https://github.com/Crzyrndm/VariableThrustLimiter/releases

Another issue with the code block, tabs are larger when inserted into a post (4 spaces in editor, 8 in post) This was tabbed out two times This was spaced out to match it