TheDog

Nice! Actually: great stuff! How come modders with access to Harmony can devise such useful things, and developers with complete source code cannot for years

@bjaebjochI actually havent done anything on this for a while, but pull requests are always appreciated, will integrate them!

Seems to be a stock bug affectung all sort of fuel switchers (not only configurable containers, but also ifs, firespitter, wbi, ...). I just happened to notice first with CC: I have filed a bug report with squad: https://bugs.kerbalspaceprogram.com/issues/26988

Indeed. I am running most of the USI stuff, most of Nertea's things, and many wildblue mods. Nertea's mods, especially station parts, always fully supported USI-LS and integrate very well. With his latest things (farfuture) you have to carefully look if you want to switch over to the systemheat approach (heating topic) and the space dust (resource distribution topic). That could potentially conflict with usi, or you have 2 things running side by side. Wildblue is a different story, but i have my own solution for that.

Yeah, honestly, I am also curious, and dont have a clear idea where it'll be going with that topic. In general my idea is more to adapt Pathfinder etc to USI, as that is my "leading" setup. So in the near future i suppose i'll be adding USI konfrabricator to WBI mods that currently have OSE workshop, and thus add stock inventory space (if angel-125 is not going that route anyway). We'll see

And it is now on CKAN! Lots of thanks to @HebaruSanfor making this possible. Due to him CKAN now recognizes and supports conflict-free installation of WBI Playmodes!

The only thing that stands out in the logs is a fsfuelswitch error about parsing a resource amount, and i believe that shouldnt be there. Could you maybe just replace the bundled firespitter with a fresh version from the individual mks download?

Not discounting Nertea's work, but for me it doesnt work very well (doesnt account for a lot of ec consumers) and is a frequent source of nullref spams in my logs...

Please forgive me, I am cross-posting this from @allista's configurable containers, see Posts #1 and #2: I am experiencing an oddity with KSP 1.11 and mods that can switch tank contents, such as CC and IFS: * if a tank content is switched to something other than its original contents, then the resources drained in VAB, vessel launched & immediately recovered, the recovery funds are off - part value for the recovered tank can even go negative in case of expensive resources such as from the community resource kit, but can be verified with stock resources such as MonoProp. Hence you pay for recovery instead of getting funds. * so far havent seen this in pure stock, but definitely with part switcher such as CC, IFS and WildBlue mods

More observations and more weirdness: 1. Stock install (no configurable containers): Rockomax X32, LFO, resources emptied before launch, launc+immediate recovery: ->The recovery funds are 100% correct 2. With Configurable Containers (otherwise just stock): Rockomax X32, 100% as LFO tank, resources emptied before launch, launc+immediate recovery: ->The recovery funds are 100% correct 3. With Configurable Containers (otherwise just stock): Rockomax X32, 100% as MonoProp tank, resources emptied before launch, launc+immediate recovery: ->The recovery funds are incorrect (negative value for the tank) Hence: * not quite a pure stock problem * not related to CRP or custom resources * related to tanks being re-configured by CC to another tank type other than the original tank. I guess this effect is reproducible with B9PartSwitch, FireSpitter or IFS, but havent done that (yet) [UPDATE: confirmed it also happens with IFS]

Something is extremely fishy in KSP 1.11... See also screenshots: * configure a tank with an expensive resource. (Vessel price with FLT400 full of rare metals would be >300.000 kredits) * empty the tank. vessel will cost a few bucks * launch vessel, immediately recover from launchpad. I get a negative refund, effectively I have to "pay" for over 300k in "missing" rare metals...!! what! Actually, I am not even sure that is related to Configurable Containers - seems more like a KSP bug. Anyone can confirm/having seen that?

At least in USILS this represents the complete LifeSupport supplies: meals, water, oxygen, toothpaste, ... I find it more unrealistic (too easy) that supplies->mulch is mass conserving. But it is a reasonable abstraction.

I am "a bit" late to the party, but if anyone is still interested, here you go...

@m4v its analyzed: You could indeed not repro it, because in MOLE's "standard playmode" after installalation, "ClassicStock", the engine (Fulcrum in this case) is configured as a multi-mode engine, and indeed has 2 usable modes. So no problem here (see screenshot #1). If the playmode is changed, e.g. to "CRP", then there is a problem on the engine config: it is still declared in the part config as multi-mode, but has actually only one usable mode. This confuses RCSBuidlAid and leads to that nullref spam (see screenshot #2). Showing the situation: 1) no problem, and 2) problem https://imgur.com/gallery/fqlpMcg So the root cause is definitely a misconfiguration on the part. Question is if that could maybe be handled more gracefully by RCSBuildAid, now that the cause is known?

Interesting, i'll have a more detailed look in a trimmed down install (currently at 80+ mods, not good for finding root causes...). Will get back to u!

update: playmode switching may not be good for ckan in case of updates, sorry...

Getting VAB nullref spam with the latest 1.0.4 version, but for some engines only (all mod delivered ones, such as the "Fulcrum" engine from WildBlueIndustries MOLE). In the log it says: [EXC 18:27:46.863] NullReferenceException: Object reference not set to an instance of an object RCSBuildAid.EngineForce.getThrust () (at <d47c6305c5d444f8ac716df736136b89>:0) RCSBuildAid.EngineForce.getThrust (System.Boolean asl) (at <d47c6305c5d444f8ac716df736136b89>:0) RCSBuildAid.EngineForce.Update () (at <d47c6305c5d444f8ac716df736136b89>:0) RCSBuildAid.MultiModeEngineForce.Update () (at <d47c6305c5d444f8ac716df736136b89>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Was previously using the LGG maintained version which did not have that behaviour, so that must contain some sort of fix for that...

## Community “Playmode USI” for Wild Blue Industries mods ## What is does I love the Wild Blue Industries (WBI) mods – MOLE, DSEV, Pathfinder, Buffalo. Great models, useful parts, attention to detail, and lots of good ideas which enhance my gameplay experience, such as the configurable templates. In all my long-term career saves I am also pretty much committed to the Community Resource Pack and Umbra Space Industries (USI) ecosystems, particularly Life Support and Kolonization. Most of the parts I am using (e.g. lots of Nertea’s stuff) have some support or compatibility for CRP and USI. At some point there was at least basic USI-LS support, but then one day the USI config mechanics changed (towards swappable bays with swsapoptions), and those patches became outdated. I used to roll my own, also very basic, based on the CRP playmode in WBI. That, however, is also no longer actively developed. So, instead of trying to patch something that itself might become outdated, I have bitten the bullet and present you the results of my work… integrating USI support (focusing on Life Support and Kolonization) into the WBI mods as a dedicated playmode which can thus be switched on or off as desired. “So it is just some MM patches for Pathfinder etc, not really a mod!” You could say so. It is basically “just” configuration files which are mostly applied using module manager. However, I am utilizing the awesome and powerful “playmode” feature of WBI to do more than just swapping out a part module here and there. With this feature, defining a “playmode” gives broad control over which templates are applied to the different parts, allowing to disable or change a lot of things (which would be totally possible with MM patches alone, but a lot more work). This playmode is built upon the existing “CRP” playmode, with some items adapted also from ClassicStock, but disables, changes and adds some modules (habitation, life support), templates or converter recipes. ## Design Considerations WBI and USI are based on somewhat different philosophies and design principles: * Long-term colonization, especially with closed-loop resource flow, is hard vs. * Early stations and flexible space-camping, short-term habitation expandable to long-term colonization Personally, I do enjoy both approaches and I do not see them as conflicting, but rather as highly complementary for my playstyle. To integrate (Pathfinder/MOLE/etc.) well with USI LS and MKS, balancing the capabilities to account for the different philosophies is important, ensuring that the parts fill a specific niche and are not generally overpowered or useless. What’s In Based on the existing “CRP” playmode, with some changes and additions Specifically, adds in USI-LS as life support system: LS recyclers, LS habitation, WBI greenhouses produce supplies (via agroponics or cultivation), Supplies/Mulch/Fertilizer as resource where appropriate, … Some changes to templates/omniconverters to be closer to the MKS production chains where appropriate Production parts acting as MKS efficiency modules where appropriate Integration of WBI resource sharing/distribution and MKS logistics on the table (see ROADMAP) WBI parts generally don’t enable closed-loop long-term colonization and are usually less efficient than comparable MKS/USILS parts. Keep in mind, though, that WBI parts are already very powerful and useful on their own with their template switching abilities and general capabilities. What’s Out This is not a scientific dissertation about perfectly balancing colonization parts. I have used as-is parts analysis, best judgement, personal preferences as well as the official MKS balancing guidelines. Most things “feel right” to me. Some may be a bit off. There might also be some mistakes on my part. If you think something is vastly off scale, let me know and we’ll discuss it. No repackaging all of MKS’ functionality in WBI parts. It is not my goal to create WBI templates for the complete MKS production chain, for instance. I want the parts to complement, not replace, each other. Some overlap is normal, and some Pathfinder and MOLE modules give you much earlier production capabilities than MKS – but at a cost of generally being less efficient. No “total conversion” of WBI. Pathfinder remains Pathfinder, and MOLE remains MOLE. E.g the greenhouses work totally different from USILS/MKS (you have to wait some time for a harvest, and the yield might be lower than anticipated), and that’s what I like about them as complementary things for my stations and bases. No changes to Tech Tree placements (Stock and CTT). Current placements mean that MOLE & Pathfinder parts come much earlier than MKS (especially in CTT). This makes sense in the overall design (early stations, camping before colonization), fits my playstyle, and I don’t intend to do any changes here. ## Is it safe to drop into an existing game? Short answer: most likely NO! Long answer: it depends. It is based on the existing CRP playmode, but there are some changes. Your active stations and bases WILL be impacted – some positive (LS and habitation functions), some negative (converter recipe changed or outright no longer available). Upon first activation and switching to a vessel there is a high chance of nullref spam. It might be repairable (->see Common Issues and Resolutions), but in a worst case that vessel is no longer usable and has to be terminated. If you are using ClassicStock playmode, DO NOT SWITCH TO THIS PLAYMODE! It is NOT compatible with ClassicStock – absolutely everything is different! All your classicstock resources will be gone, your production chains useless, and your bases decorative only! USI is basically CRP with specific production chains as in MKS, and life support from USI-LS. ClassicStock is very different from this, and fundamentally makes not a lot of sense to forcefully combine with USI. TLDR; Make a backup of your save before activating this playmode! If you are using CRP playmode and have few active stations/bases, give it a try. If you are using ClassicStock playmode, DO NOT activate this for your current save! ## Download, Installation & How to use Install prerequisites (ModuleManager, not bundled!). Any WBI and USI mods are technically not a dependency, but what do you expect this one here will do without them? Download and install mod from the github releases: Install path must be $KSP_DIR/GameData/WildBluePlaymodeUSI !Any other folder path will lead to the templates not being properly found and switched by the WBI Playmode Switcher! Start KSP (your WBI playmode is something <> USI). Use the WBI playmode switcher to switch to playmode USI. DO NOT CONTINUE PLAYING, THE SWITCHED PLAYMODE IS NOT YET ACTIVE! Immediately exit and restart KSP. Your playmode should now be USI. UPDATE WARNING: *YOU MUST TREAT UPDATES AS NEW INSTALLS!* Download new release Delete previous folder completely: $KSP_DIR/GameData/WildBluePlaymodeUSI Unpack new release. Start KSP, LOAD A BLANK NEW SAVE (not your precious long-term career one with active flights!) Playmode switcher will indicate you are in USI (which is not correct, but it doesn’t know), switch to “CRP”. Klick OK. Immediately open playmode switcher again, switch to USI. Klick OK. Exit & restart KSP. You’re good to go now! ## Common Issues and Resolutions ## Support and Contribution Prerequisite: reading the design considerations, what’s in scope/out of scope, as well as common issues and resolutions. If you think something should be added/changed/removed: (Good) make a concrete proposal here on the forum (i.e. “make part x be a hab module with following kerbalmonths” instead of “part x is no good”) (Better) write and test the appropriate configuration / MM patch and post it here (Hero!) make a github pull request And especially regarding issues/support: This mod is community developed, and is in no way endorsed or supported by Angel-125 (WBI) or RoverDude (USI)! DO NOT GO TO WBI OR USI THREADS WITH SUPPORT ISSUES OR QUESTIONS REGARDING THIS PLAYMODE! If I find out that Angel-125 or RoverDude are pestered with stuff from this mod, I might have to consider pulling this. Thanks for your comprehension. ## Credits WBIPlaymodeUSI builds upon and existentially requires the excellent "Wild Blue Industries" mods by @Angel-125. Config files in this mod are based on, adapted from, or outright copied from, config files which are the creative works and intellectual property of Michael Billard, and are licensed under the GNU General Public License, v3. Wild Blue Industries is a copyright trademark of Michael Billard. All Rights Reserved by him. See: https://github.com/Angel-125 WBIPlaymodeUSI builds upon and existentially requires the excellent "Umbra Space Industries" mods by @RoverDude. Config files in this mod are based on, adapted from, or outright copied from, config files which are the creative works and intellectual property of Robert Palmer, and are licensed under the GNU General Public License, v3. Umbra Space Industries is a copyright trademark of Robert Palmer. All Rights Reserved by him. See: https://github.com/UmbraSpaceIndustries ______________________________________________________________________________________ ## ROADMAP [done] bring onto CKAN Evaluate integration of resource sharing/distribution/logistics mechanisms o Side-by-side running, or o Integration, or o Complete replacement of one system with the other More work on the production chains and load/efficiency thing Evaluate support for BARIS Supporting upcoming features in USI Konstruction and LifeSupport (USI's Workshop and DeepFreeze alternatives)

Basically yes, just for OPM, gotta check if indeed that has been updated, that'd be godsend

Lots of mods used to have beautiful and great kspedia pages. Then, in 1.5 or 1.7 or so, the required internal format somewhat changed, and as creating and updating thes kspedia pages is a massive pain to do, most mods have not yet bothered to do so. I especially miss the opm deltav maps, but you gotta live with it (unless you know unity and wanna help out the modders)...

Oh, I should have mentioned: it works absolutely fine in a newly created save, spawning asteroids and comets. I guess I'll try manually cleaning up my old save's sfs file and will remove any potatoroid vessel, and maybe also alter the rng seeds, maybe that'll help...

Sorry if this is already a known issue: using this bleeding edge version for 1.10.1 with latest OPM on an pre-existing save (from ksp 1.8 times, or maybe even older). All asteroids that were spawned have meanwhile disappeared, and no new ones are spawing (also no comets). In KSP.log I noticed: - absolutely no mentioning of anything like "new asteroid" or "new object found", or something called "spawner", ... - the following two lines (in scenes like tracking station, flight) may be related to the problem [LOG 17:40:48.279] [Kopernicus] ScenarioDiscoverableObjects successfully removed. ... [LOG 17:40:49.037] [Kopernicus] ScenarioDiscoverableObjects is removed, scrubbing SENTINEL contracts. Anything I can do on my end to fix this?

But there is, via giving parts such coating capabilities: https://github.com/PapaJoesSoup/BDArmory/wiki/1.2.4-ECM-configuration-&amp;-stealth Or do you envision it to work differently, and if so, how? Position, angle, engine heat variation, and lots of luck...

"stack in efficiency" is not the correct wording to describe it, its like: each radar functions individually on its own. So, having one that is excellent in airborne detection at long range, one that is excellent at ground based detection (low ground clutter factor), and one that is excellent at locking multiple targets, then yes, you have access to all those capabilities at the same time. It is not stacking in that sense because e.g. your long range detection radar might detect targets further away than your super-duper AESA multi-lock radar can track & lock them, meaning you still cannot fire at max detection range. But each individual radar contributes its performance characteristics to the overall vessel, simultaneously, yes.

Has anything changed regarding usage of FloatCurves as KSPFields? While the partmodule compiles fine with KSP 1.4, it is getting a loading error from the part loader: Any (semi-)official advise what needs to be changed? DISREGARD, no changes here, problem was different.