4x4cheesecake

At this point, I got the feeling this is not

It certainly got the ability to add colliders to scatter added through kopernicus. The Stock Visual Terrain mod made use of it back in the days. It's not an option which is simply toggled on and off in some settings but requires a MM patch, either written by yourself or provided by a mod which uses it. By default, it should be disabled, as far as I can tell by the stock config.

You sure about this one? Maybe I misunderstood something but other contract packs actually still use spaces for the agent name field and it works fine. For your multi-waypoint issue: I got no idea for myself but maybe take a look at JNSQ-KSRGAP (probably applies to every GAP contract pack but its the one I'm using and know about) since it offers "Multi Flights" where you start at one airport and continue to two different airports while also creating a waypoint for each airport. This works just on bases you have opened, so there must be some kind of progress tracking list in the background of which 2 airports can be picked at random. I personally don't understand these configs on a level to derive a solution to your problem but maybe you do

Does the cheat menu on the xbox version also provide a console? If so, it might be a bit easier to check for weird issues going on. To open the cheat menu, according to a quick google search, you need to pause the game and You should be able to just keep the menu open, switch to the SPH or VAB and try to save the subassemly again. If an error pops up in the console, take a picture for us In the mean time, you can also try to re-root the subassembly to something else. Again, not sure about how things are done on xbox but there might be a "re-root" tool in the editor, similar to the ones you use to rotate or offset parts. At least on PC, the whole "built your subassembly on top of a docking port" isn't t rue anymore. IIRC it used to be that way since the subassembly couldn't include the root part but it's possible by now. Whatever it might be, simply re-rooting might be worth a try. Oh, and another question: have you tried to save a very simple craft as a sub-assembly, just to check if it works at all? KSP can behave a bit odd when it comes to complex crafts, so maybe try to save something with like 2 or 3 parts, just for testing?

Did you simply miss the "@PART..." during copy&paste or is it actually missing? That could be a reason why. Beside of that: what are you actually trying to accomplish? Why do you need such a specific but still generic filter to target an ISRU? If it is just the stock converters you want to target, you can simply address them by their names using @PART[ISRU] and @PART[MiniISRU]. That would simplify your patch by a lot and even if you want to target more converters, I would still recommend to start small and expand later. You can write a working patch for both stock ISRUs now just to get it up and running and expand it to "every ISRU in the whole universe and beyond" later. That would also help you to experiment with all the other stuff you want to change instead of going back and forth just trying to target the correct part in your patch.

I certainly would at least until now. Took me a hot minute to understand what you're saying. Now that I think about it, that might be how I stumbled upon it the first time. And for everyone else being as slow as me: you can't target a node using a wildcard, if the node doesn't have any "name" key in the first place. It's basically NULL vs 0.

Oh, interesting... that's why some links in CKAN are broken as well. Mostly applies to older mods and I thought their threads might got deleted at some point but adding the "https://" in front of the link gets me to the actual thread now.

Hey there Just a quick heads-up: got 4 MM errors after installing the update: [ERR 20:11:13.250] Error - node name does not have balanced brackets (or a space - if so replace with ?): RationalResources/Deployment/Pack_FarFrontiers/+PLANETARY_RESOURCE:HAS[#Tag[AtmGasII]:NEEDS[FarFrontiers] [ERR 20:11:13.250] Error - node name does not have balanced brackets (or a space - if so replace with ?): RationalResources/Deployment/Pack_FarFrontiers/+PLANETARY_RESOURCE:HAS[#Tag[[SrfIceWater]]:NEEDS[FarFrontiers] [ERR 20:11:13.250] Error - node name does not have balanced brackets (or a space - if so replace with ?): RationalResources/Deployment/Pack_FarFrontiers/+PLANETARY_RESOURCE:HAS[#Tag[[ExoIce]]:NEEDS[FarFrontiers] [ERR 20:11:13.252] Error - node name does not have balanced brackets (or a space - if so replace with ?): RationalResources/Deployment/Pack_FarFrontiers/+PLANETARY_RESOURCE:HAS[#Tag[[AtmGasIII]]:NEEDS[FarFrontiers] Its a missing closing bracket in all 4 cases

Well, yes... that's exactly why this one is a bit weird. Since the INPUT_RESOURCE node got no name, you need to target all of them and then filter by their keys. And like you said, [*] brackets does target all the nodes, so you would expect that: @PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE[*]:HAS[#ResourceName[Ore]]]] should do the same as @PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]] but for some reason, it doesn't. In both cases, you tell MM to target every INPUT_RESOURCE within every PART which got any ModuleResourceConverter but once you include the brackets after INPUT_RESOURCE it doesn't work anymore. And I personally like to include all the brackets, it's just easier for me to read and understand what a patch does and where certain parts start and end. It also helps me to not forget any required ones while writing patches

Not even going to try to decipher the first filter How exactly do you define an ISRU though? I guess, you are not going just for the stock ISRUs because it would be much easier to address these parts by their name instead of coming up with a filter. Judging by the next 2 filters, you are looking for ISRU which consumes ore? If so, you can use this: @PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]]:FINAL { //do stuff } Yes, it looks like there are missing brackets after INPUT_RESOURCE but trust me, it only works this way but doesn't if you add the brackets. I honestly don't even remember why, just that I came across the same issue of "deep filtering" a while ago and that seems the way to go. This is also why your second filter doesn't work and the third is lacking a "HAS" for the resource. You last filter will find any converter, including fuel cells. Is that something you actually want to cover or just AI going wrong?

I'm running Tourism Expanded myself and as far as I can tell, it works perfectly fine despite the error message. The error is based in the .dll which comes with Tourism Expanded to provide some custom features like calculating contract rewards based on dV required for a mission (which of course requires to calculate dV requirements in the first place). As far as I can tell, the mod still runs perfectly fine though. Depending on the difficulty you are looking for, you may want to reduce the reward modifier though, compared to any other tourism contract, the rewards are way too high by default. Like the underwater adventure would reward me with 400k+ funds but can be easily done in early game. You can do that by either using the ingame menu for tourism expanded (in the difficulty settings) or by running a MM patch, which is what I do. Wouldn't recommend to do both @CONTRACT_TYPE:HAS[#group[TourismExpanded]] { @BEHAVIOUR[SetRewardFunds]:HAS[#multiplier] { @multiplier *= 0.15 } @BEHAVIOUR[SetRewardFunds]:HAS[~multiplier] { multiplier = 0.15 } } (some contracts got the multiplier key and some don't, that's why it needs to be added for those)

wild guess: you got "research bodies" installed which hides celestial bodies... I dont know how it does the hiding part under the hood but it kinda looks like it hides them well enough for contract configurator not being able to find them either. Should be easy to try: backup your savegame, uninstall research bodies, and check if the error persists. Don't know how the game reacts to removing the mod, that's what the backup is for. The "RO" part probably just appears there in the box because the latest version is hosted on the KSP-RO repo

Ngl, I misunderstood the original question and just now, when you quoted me and I re-read the thing, I realized the question was about rolling back the KSP version instead of allowing CKAN to install 1.8+ mods Thanks for picking up my slack @Grenartia

Nice, thank you guys I remember checking the label menu before, just didn't notice you can attach properties to them. Yep, wasn't there for me but easy enough to create it myself

Hi there Quick question because I can't find anything about it: Is there a way to prevent certain mods to get updates through ckan? I've done some customization to a few mods and don't want to loose those. Right now, it seems the only way is to check the mods which should receive an available update manually or uncheck those which shouldn't update after using the "update all" button.