Crzyrndm

I don't think you can actually modify a value directly in a ConfigNode (atleast, I've never tried to). I'm always either creating a node from scratch or adding/removing values from one Some examples of reading ConfigNodes: https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/FerramAerospaceResearch/FARSettingsScenarioModule.cs#L178-L224 https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PresetManager.cs#L184-L193 https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/ConfigNodes/customSubCategory.cs#L24-L39 (all constructors here take a ConfigNode, and they all have a ToConfigNode method as well for writing) Some examples of writing ConfigNodes: https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/FerramAerospaceResearch/FARSettingsScenarioModule.cs#L151-L168 https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PresetManager.cs#L207-L217 https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/ConfigNodes/customSubCategory.cs#L65-L77 Resource switching example: https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/B9%20PWings%20Fork/WingProcedural.cs#L3066-L3080 (function above that deals with propagating to sym counterparts, and the one above that modifies existing resources)

For future reference, Module Manager thread is a better location for these Q's - Added '[*]' to check the conditions against all parts - NEEDS goes last - value check uses '#' in HAS - extra pair of curlies at PART level @PART[*]:HAS[#vesselType[Probe]]:NEEDS[ProbeLowPower] { MODULE { name = ProbeLowPower lowPowerRatio = 0.005 } } I would also suggest that a check for ModuleCommand as well with a minimum crew value of 0 would be a more reliable way of detecting probe cores (or rather, parts that can control a vessel without a Kerbal present) @PART[*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]]:NEEDS[ProbeLowPower] And if ProbeLowPower is the mod you are distributing it as, that should be a FOR, not NEEDS

This is setting off all sorts of alarm bells for me (I haven't actually looked at the code linked at this stage) Originally, my impression was that you wanted to load saved data before any operations were performed on it. Easy enough, delay Onstart() functionality using a coroutine. Once the data is loaded, we then let OnStart do its thing which then unlocks execution any other functions (eg. FixedUpdate). Now you're saying that a craft loading into physics range that isn't the active vessel is a problem because scenario.OnLoad doesn't run at this time. That indicates to me that either scenario.OnLoad method is doing more than just unpackaging saved data, or the "live" data is not always in the same location. I think Diazo is correct in recommending a design change, because something smells very fishy Somewhat obvious, but ensuring that the sequence is load->start->update is not difficult Save : ScenarioModule { public static bool hasLoaded = false; // set true at end of OnLoad, set false by OnDestroy //... } Module : PartModule { public bool hasStarted; public void OnStart(StartState) { if (!Save.hasLoaded) StartCoroutine(delayed); else delayed(); } public IEnumerator delayed() { while(!Save.hasLoaded) yield return 0; // I forget the exact syntax... // stuff you wanted after load hasStarted = true; } public void FixedUpdate() { if (!hasStarted) // lock out fixed update until data has been loaded and processed return; // do stuff } }

Some more ideas: (probably) easy but slightly hacky way out, use a coroutine to delay the functionality currently executing in OnStart for 1-2 frames to put it after the scenarioModule is loaded Assign to a static variable in the scenario module from the partModule to tell it that data is already loaded and the data from OnLoad can be discarded Read through the source of scenario modules from other mods to see if any similar situations have already been dealt with(eg. FAR, TACLS, ...) It sounds like you're trying to do something odd though as I'm not quite grasping why the bad data is ever being used if it already has good data

A lot of stuff is in different namespaces now, including ConfigNode

1) Not sure what your issue is here, I've switched between planes while flying in the atmosphere before (and/or debris after things go wrong...) 2) It requires the mod to be written slightly differently but its not hugely difficult to do post 0.90 or 1.0, I forget which (my own mod, Pilot Assistant, runs an instance per loaded vessel. Other mods have implemented as well (MJ probably, BahamutoD's Burn Together, etc.)). Implementing the change will be up to the mod author though unless you find someone to fork it

There will be no public releases of any of my mods until after 1.1 is actually released. There may be some github activity when I get around to working on things but any of that will all be at user risk. I'm not going to try supporting something that is listed as being "frequently updated" (still haven't decided whether I will bother with the pre-release at all...) Post-release, I will be pushing hard to get updates out, just not before

Thanks to @Kerbas_ad_astra, this (1, 2, 3) is probably the most complete listing of different cross sections, although he would be the best one to ask about which mods they come from

Probably should. Such a tiny change, it'd take more effort to justify not doing it Post-1.1 of course

Tongue in cheek poke at Imperial units as a whole Except the *flight scene* uses the same mass as KER does its simulation on. Only the engineers report/career limits use a different number. If KER was giving incorrect numbers, the mod author would hear about it rather quickly >.>

@NathanKell Better than the current system where things are read from two different places (and the interface only affects the report/career limits. There's no obvious functional issues if you miss it). If you aren't told about how the engineers report works currently you won't know how to do it properly and you'll probably never know there's a problem until much later (how likely is it that a mod maker isn't using KER/MJ :P)

1) The discrepancy exists because of how mods have to modify part masses currently. It has to be done in two places to match up the real weight and the engineers report. Post-1.1 this won't be a thing so hopefully the engineers report will match up properly 2) KSP uses the tonne/metric ton (1:1000kg) not that weird imperial unit I would be significantly more suspicious of the engineers report as it requires an additional step that doesn't affect flight performance. IIRC IFS was having an issue with that a month or two ago

Not directly. You can make one that is an inverted subcategory check that lists all the other subcategories you want to compare against SUBCATEGORY { name = Undefined icon = stockIcon_fallback FILTER { CHECK { type = subcategory value = sub1, sub2, sub3,... invert = true } } } Space center => Options window (looks like a black screen outline. Terrible icon I know) => "Sort parts by folder in manufacturer tab (requires restart)" That'll get Squad parts into 2 folders: Squad and NASAmission and will do the same for any mods as well (so you find the mods base folder name, not the manufacturer)

Any *.cfg file in GameData will work. The issue was around there being no parts in the subcategory until some were forced in so it got filtered out before the forced acquisitions were accounted for

@PART[*]:HAS[@MODULE[MissileLauncher]:HAS[#missileType[bomb]]] { MODULE { name = PartModuleFilter filterAdd = Bombs } } SUBCATEGORY { name = Bombs icon = test FILTER { CHECK { type = name value = bahaClusterBomb } } } @CATEGORY[Filter?by?Function] { @SUBCATEGORIES { @list = Bombs } } This appears to work (gets 4 parts with a fresh BDA download). I guessing you tried to do it with no Filter/Check node in the subcategory and run afoul of a sanity check that wasn't properly updated. I will get that fixed (and probably add a check for the module in some shape)

@01010101lzy I really don't know, it's not something I've seen before. I would be tracing back from when UpdateGeometry() is called to figure out why a detaching/detached wing needs to be updated

I've been debating back and forth over adding AoA hold it as its own control type (tl;dr it should be a thing, but the UI is already going downhill fast and I need to find another way of presenting the different modes or a new way of presenting the input information such that mode handles itself...).

Direct Github Download. You won't even see the site. Not currently, and doing so is somewhat awkward and error prone, so I don't have any plans to do so directly at this stage. What I do have is a part module which you can add with Module Manager (and module manager can identify those parts easily enough). eg. @PART[*]:HAS[@MODULE[xy]:HAS[#maxTurnRateDPS[z]]] { MODULE { name = PartModuleFilter filterAdd = // comma delimited list of subcategories to push this part into by name. eg. Engines, Fuel Tanks filterBlock = // comma delimited list of subcategories to block this part from by name. eg. Engines, Fuel Tanks } } You will need to use this .dll version for that to work though

Not quite. Only the functions that the button calls need to be static (which then need to reference atleast one static member to make changes to the live instance, ...). The way he has it setup, its probably easier just to destroy the button on leaving the scene.

No editing from right click is expected. They're a known cause of memory leaks and I appear to have trimmed them a while back while cleaning up (I think at the time I was intending to add a proper editing UI, then got busy with other stuff). This would be the latest version with them still active

It's on CKAN, or it was last time I checked. Please go ask someone over in the CKAN thread why it's not working, because I don't know why it's not

Make the functions static too (they point to a dead instance currently) Alternatively, you need to destroy the button instance on leaving a scene, which I don't have any examples at hand for because I just use a static class for the toolbar now (I find it more trustworthy when other mods start throwing exceptions around...)

Make appLauncherButton static. Every time you switch scenes, the instance of the class you have is destroyed along with your reference to the button. Going back to the space centre, you have a new class instance and a null button variable, and so another is created. Making it static means it wont be null after you've created it, so your null check here will do its job