4x4cheesecake

Interesting. Didn't know that

I don't think MM can look for any folders. MM will just scan for .cfg and .dll files but as far as I know, those can be as many sub folders deep as you want. Do you mind to share what you are trying to do? There might be different solutions

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.

yes and it works well, which is luckily true for the majority of mods

Well, that's a surprise And its actually me who has to thank the community because without others contributing on this topic, it would be still this half baked solution I came up with originally and definitely not as helpful as it is right now. So thanks to everyone who contributed to it and especially @Lisias for pushing me to edit the OP, turning the thread into an actual useful collection

Because the idea was/is to solve the issue by manipulating the game launch options, not by writing a batch script. Of course, such script can be used as well but I guess it comes with the same caveats as other solutions: if you launch the game executable directly, it changes the working directory of KSP, thus breaking many mods which rely on it. So you could try using a shortcut to the executable in the script to circumvent that issue but that again, would break the steam features. Since you're already using a script, it would be possible to extend the script to manually attach the steam overlay to the game process but at that point, the rabbit hole got so deep you may want to look for a slightly simpler solution In the end, such script is just a different approach for the same issue, but it may look a bit more intimidating to less tech savvy people in comparison to a one-liner in the launch options. Might be just my impression though

Ok, rework of my OP is done and I hope I got it right when I tried to sum up the pros and cons of each solution. Also included my janky solution of using the windows CMD simply because I think its funny and catches the kerbal spirit

Oh, yeah... I feel you *hug* Hm... I don't know... my janky solution using the windows command line might work at least on windows, though I haven't done any extensive testing on that one (just checked the log to verify the working directory and if the steam overlay pops up). And apparently, its also possible to manually hook the steam overlay into the game after launching it from a shortcut but that probably requires some individual scripts on linux, mac and windows. Actually, the best solution would be if steam asks you if you want to play the game or start up the launcher. I've seen it in other games but right of the bat, I just remember Elden Ring having one of these pop ups: Though, I guess its on purpose this doesn't happen already. Don't worry about it, its fine. I should have given at least a little heads up that I wont be able to perform any big edits on my OP before the weekend to make it less frustrating for you, that's my bad. In the end, we both try to help others in the best possible way and I appreciate every input I've got from posts in this thread

Sorry, have been busy all week long I hear you guys, and even though I disagree that parts of my OP should be removed, I'll take care of it in a way it's still available but "out of focus". I just really dont like the idea of actually removing parts which where discussed in a thread and maybe even quoted, it kinda breaks the "archival" properties of a forum, IMO. KSSL might not have any collateral effects in terms of "it breaks something" but its a mod someone might don't want to install (or someone simply doesn't know how to use github) and you will even have to repeat the installation, if KSP actually gets another update. It is unlikely but nobody expected the 1.12.4 update as well. There is simply no "one fits all" solution but I'll try to edit my OP in a way to reflect the pros and cons of each possible solution, so everyone can decide which one fits best for them. I also dont mind to put them in an order of "most likely to be useful" with KSSL on the top. That being said, I'll keep it with a subtitle for today and start editing the whole thing tomorrow in the morning (I promise!) , I'm just too exhausted to do it right now

As far as I know, the changed working directory only breaks some modded games but not the stock game, therefore the suggestion is still perfectly fine and the easiest way to bypass the launcher. The big red subtitle "for mod users" should direct people who play modded KSP to the other suggested bypass. In my opinion, its valid to keep a simple solution available to those who feel less comfortable to mess with their game install instead of showing just a more complex "one fits all" solution. Though, I might add a different subtitle to make it easier to differentiate between stock and modded ksp

Sounds good to me I'll see what I can do on the weekend