AccidentalDisassembly

FYI - the procedural parts patch will throw module manager errors. Possibly related to doing @Priority = 1 -- if there is not already a "Priority" defined in the VABORGANIZER node, I'm guessing that's the source of the error..

Sounds good! With a little luck, maybe I got close on my attempt at wrangling Visual Studio and the Unity editor... More realistically? I'll be very glad for the guidelines so I can start over from scratch.

Any pointers on compiling the source? I think I've tracked down all the .dll references, but do I also need an "Animated Vegetation Ultimate Pack" in order to get things to compile? (Spoiler: although familiar with Python, I don't know what I'm doing with C# or the whole compilation process in general, really...)

@Nertea I think there's an issue in NF Construction with /Patches/NFConstructionCRPTrusses.cfg - I noticed in the most recent version, all the meshes/textures for three tank variants are visible in the editor (when CRP installed): truss-hex-01 truss-hex-02 truss-octo-02 The patches for those three trusses in NFConstructionCRPTrusses.cfg look like this: @PART[truss-octo-02]:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction] { !MODULE[ModuleB9DisableTransform] {} @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[tankSwitch]] { %SUBTYPE[LH2OCryo] // ... etc. etc. The B9PartSwitch moduleID in the configs for those three parts appears to be "meshSwitch" -- changing the referenced moduleID to "meshSwitch" seems to fix the issue (tried it out and don't see any obvious problem with doing that). If there aren't any other ModuleB9PartSwitch-es being added elsewhere, I guess you could take out the whole :HAS instead...? FYSA in any case

Yes - it's quite easy. You can create a custom category like this: ORGANIZERSUBCATEGORY { // My Fancy Category name = myFancyCategory // Used to refer to this category in patches Label = The Fanciest Freakin' Parts Priority = 80 // Think this controls the order of categories in the editor CategoryPriority = 10 // ... Or this does } Then you can create a patch for whatever parts you want like this: // If you do an :AFTER[VABOrganizer] here too, presumably it would overwrite whatever VABOrganizer did/didn't do @PART[MYPARTNAMEHERE]:NEEDS[VABOrganizer] { %VABORGANIZER { %organizerSubcategory = myFancyCategory } } You can put both those things in the same .cfg file wherever you want, or do the categories separately from the patches.

No problem for me, I just used the patch in the meantime to get the juicy, juicy categorization ahead of time

I've written a patch that may cover a fair amount of ReStock(Plus) - if anyone wants to include it in a patch (and maintain it! :)) people are 100% free to take this and do with it as they please:

Small note - apparently there's an error in one Avalanche patch, says MM: [WRN 18:47:42.482] more than one :NEEDS tag detected, ignoring all but the first: Avalanche/Configs/Bluedog_Design_Bureau/Titan_III_Booster_Nozzle_Patch/@PART[bluedog_UA120*]:NEEDS[Bluedog_DB]:NEEDS[Waterfall,Bluedog_DB,!zRealPlume]:AFTER[Bluedog_DB]

Huh, weird - would that same thing work for the Kopernicus solar panel module too? And/or the NearFuture curved solar panels? I.e., something like this: TWEAKSCALEEXPONENTS { name = KopernicusSolarPanel chargeRate = 2 temperatureEfficCurve = 2 } TWEAKSCALEEXPONENTS { name = ModuleCurvedSolarPanel chargeRate = 2 temperatureEfficCurve = 2 } TWEAKSCALEEXPONENTS { name = KopernicusSolarPanelCurved chargeRate = 2 temperatureEfficCurve = 2 }

FYI - it appears scaling does not have an effect on solar panel output, only size - both for vanilla and with Kopernicus' solar panels patch. Additionally, trying to set up scaling for MKS drills, there is the appearance of an underlying issue with the way TS is handling TWEASKCALEEXPONENTS or applying them to various modules, and/or something in the way I've configured things doesn't work correctly. Thoughts? Here's the TWEAKSCALEEXPONENTS I set up for the MKS drills: TWEAKSCALEEXPONENTS { name = USI_Harvester ImpactRange = 1 // Should affect how far away drill registers having ground contact - seems to work... INPUT_RESOURCE { Ratio = 2.5 // should affect EC consumption; has no effect } } TWEAKSCALEEXPONENTS { name = USI_HarvesterSwapOption Efficiency = 2 // seems to have an effect, but not the right one } The consequence of this is: Normal-sized MKS radial drill: Collects 2.79 dirt/s. Half-sized drill: it definitely collects less, but too much less. It should should collect ~0.7, but collects 0.075 (seems like there's an extra 0 in the math somewhere, but it's not off by a factor of exactly 10...) Drill scaled up to 200%: larger drill collects less than the normal drill - 2.41 dirt/s. Expected: ~11.16. EC use is unchanged (also true if you try the same TWEAKSCALEEXPONENTS with the other flavor of TweakScale, in case that's relevant) Stock drills (ModuleResourceHarvester) do not exhibit the same scaling problems with harvest rate, but they do exhibit the unexpected thermal behavior from below Thermal stuff also seems a bit wonky for this drill test - they use ModuleCoreHeat. Here's what I observed: The normal-sized and 2x scaled-up drills each could run at full tilt and be cooled by a single large deployable thermal control system. However, the 0.5x scale drill overheated very quickly - true for both MKS and stock drills. Scaling down the part seems to make it impossible to cool, even with a radiator that ought to be overkill. Scaling up the part doesn't seem to have the same outsized effect.

At least some of them do - I am currently using some exploration, bases, aircraft-based contracts and many seem to work appropriately on the rescaled system. I'm not sure what would happen if the stock contracts reference specific bodies... probably would still work. $.02

I'm excited for better performance!

OK, I was able to reproduce the problem on a log less than a couple hundred MB, so... hooray? To trigger it, it seemed to require launching a craft; I didn't see the exception in the log until I had loaded KSP, loaded a save game, constructed a craft, and launched the craft: https://www.dropbox.com/s/umzt9cz39lx2iaq/ts_log_after_launch.zip?dl=0 EDIT: Out of curiosity, I tried removing TS 2.4.6.23 and replacing it with Beta 2.5.0.52 (because I happened to have downloaded it previously) - the same problem does not occur on .52, although a new problematic behavior does - unable to launch directly from launch pad with Beta 2.5.0.52 (have not tried with 53), i.e., click on launch pad, select craft, click launch - but can launch from VAB. When launching from VAB, beta .52 does not create the same TS-companion-Waterfall related nullref spam... FWIW EDIT EDIT: I tried Beta 2.5.0.53 as well - a change between 2.5.0.52 and 2.5.0.53 (which, based on Github, seems to be similar to a change on the main branch) is the cause of the Waterfall-companion-related nullref spam - although .53 corrects the behavior of being unable to launch directly from the launch pad. In other words: changing nothing but version .52 to .53 introduces the Waterfall-companion-related problem.

https://www.dropbox.com/s/bb6ve6xbm1rhwn8/mysterious_ts_waterfall_2023_02_08.zip?dl=0 True to KSP form, of course the error does not occur in the log I generate to send... Who knows why anything happens on KSP, really.

Something seems to be going haywire between the Waterfall companion with the newest .23 tweakscale - sorry, full log was much too large to share due to tens of thousands of the following exception; I think the relevant exception is: