Aelfhe1m

@Vorg No you're correct that shouldn't be there.

It sounds like you've got a duplicate install of USI tools somewhere. Try opening your ksp.log file in a text editor and searching for USITools.dll. There should be only one entry at GameData\000_USITools\USITools.dll. If there are any others you'll need to remove the extra folder from your install.

Example: https://github.com/allista/ThrottleControlledAvionics/blob/master/GameData/ThrottleControlledAvionics/TCATechTree.cfg

This patch will apply to ALL mods that use the custom categories kit and remove their parts from the stock categories: @PART[*]:HAS[#tags[*cck*]]:FINAL { @category = none }

@KerbMav I haven't played around with FireSpitter tanks much (I prefer MFT) but a little experimenting suggests that in order to get the same dry cost for each tank type you need to set the tankCost based on the amount of resource and the cost per unit for that resource. A simple example: @PART[fuelTankSmallFlat] // FL-T100 { MODULE { name = FSfuelSwitch resourceNames =LiquidFuel;Oxidizer;XenonGas;MonoPropellant resourceAmounts = 100;100;100;100 initialResourceAmounts = 0;0;0;0; tankCost = 80;18;400;120 // unit costs per resource are 0.8, 0.18, 4 and 1.2 as defined in /GameData/Squad/Resources/ResourcesGeneric.cfg basePartMass = 16 tankMass = 0;0;0;0; hasGUI = true } } The tank should always cost 150 funds empty but the price full will be that plus cost of 100 units of the chosen resource

That patch first sets each item in the tankCost list to 5000 then the second line multiplies each item in the tankCost list by the part's mass (16) so end result as you see is every value in the list set to 5000 * 16 = 80000. What are you trying to get it to do?

I think part of what confused me in these examples to begin with is that it's mixing two types of indexing. The first example is about modifying multiple lines that all have the same key name key = value1 key = value2 key = value3 Then the next two lines are about modifying specific parts of a single line with multiple values (sarbian calls this a vector in the explanations following each example which to me were clear enough) Finally the last example does both and just to make things more unobvious is doing it on a set of space separated vectors (without actually mentioning thats what the comma space in the brackets is for) key = value1 value2 value3 key = value4 value5 value6 key = value7 value8 value9

@micha A couple more small typos in last version: https://github.com/mwerle/OrbitalMaterialScience/blob/master/GameData/NehemiahInc/KerbalLifeScience/Resources/KLS_Experiments.cfg#L31 (#ne_kls_spiu_title) https://github.com/mwerle/OrbitalMaterialScience/blob/master/GameData/NehemiahInc/KEES/Resources/KEES_Experiments.cfg#L30 (it's #ne_kees_odc_title in the dictionary)

The control surfaces - elevons for example - do not have a tweakable setting to control their direction, only the "deploy" direction. Therefore there is nothing for MM to work with. Sorry.

You don't need to decompile the Squad code which is against the license terms. You can learn a lot about what fields and settings are available by the API web documentation and looking at the class signatures in Visual Studio (or other IDE):

Try opening the GameData/ModuleManager.ConfigCache in a text editor and searching for the parts by name (MKS_Processor125, MKS_Processor250 & MKS_Processor375) you can then check the techRequired value to find where they should be in the tree.

ModuleDataTransmitter (on antennae) doesn't have any fields that seem to be relevant and poking around in various "global" settings files didn't turn up anything obvious either. Of course there might be something with a non-obvious name or that doesn't get a default value so you need to look in the code to find it.

Of course. Sorry if I seemed to be implying otherwise. I wouldn't have mentioned the Karibou except that I could swear it used to work in an earlier version. But they do say that memory is one of the first things to go...

That's a pity. Although I noticed in VS that AvailablePart includes manufacturer and tags properties so it may be possible to construct most of the USI (mostly defined by manufacturer name) and CCK (tag based) categories myself. I'd need to look at other large part mods on a per case basis. There's also the partUrl property on that class. If it contains useful info then I might also be able to do a "filter by folder" categorisation (sort of like Filter Extensions manufacturers categories in the editor).

That's the Orbital Utility Vehicle mod - sadly not updated recently. Although there is a user submitted update for 1.2 that should still work in 1.3 (haven't tried it yet myself although I may add it to my current game once I've progressed a bit further in building up infrastructure).

Thanks Alashain. Those are a good looking set of icons and I may very well use them as part of a UI refresh/update. I must admit that as a long time AGX user I've never really looked at AGM. By the way have you looked at the question of reading custom part categories outside of the editor? I'd really like to break up the "none" category into something more manageable.

Good point. I've just checked the workshop module code and the available volume is only calculated during OnStart even though it hooks into onVesselChange for something else. I'll add it to my to do list.

I haven't looked into it from the coding side yet. I was just speaking from a player's perspective.

This seems to be a common issue with KIS attached parts skipping large chunks of their initialisation routines - attaching to USI switchable node connectors is another example where you don't see the alternate geometry until you re-visit.

I know what you mean. I wrote a MM patch to reduce the trusses' stored volume (I role-play it as collapsing down to a pair of flexi-tubes and some folded metal struts) for shipping but I still end up making a lot of them on site.

Line breaks are essential. They (and comments) mark the end of each key value pair. Your syntax looks about right although I'm not sure what you're trying to add since Uranite etc. are already in the first snippet (unless the first snippet is a combination of original patch plus desired changes) Anyway here's a simplified test case I tried focusing just on modifying the lists:

Should be easy enough. Open the save in a text editor and find the vessel. Then find the reactor part. Then ModuleB9PartSwitch. It should look something like (example is prometheus reactor with lots of lines omitted to focus on essentials): FLIGHTSTATE { ... VESSEL { pid = e4eed219472b40548053f25d7299d3ae name = Reactor Test ... PART { name = reactor-25 ... MODULE { name = ModuleB9PartSwitch isEnabled = True currentSubtypeIndex = 0 stagingEnabled = True currentSubtypeName = Inline moduleID = meshSwitch ... } ... } ... } ... The important bit is currentSubtypeIndex = 0 - changing the value will switch to different model variants. You can also change currentSubtypeName if you want as well. Edit: And of course remember to backup your save first!

So that's a yes to the "am I blind?" question.

The Orca command pod is from the USI FTT mod not MKS and like @Alshain says it unlocks near the end of the tech tree as do other very large parts from the same mod.

I don't see any radiators in those images (maybe I'm blind) could it be an overheat issue?