Qyst

There seems to be a bug with the NIMBY mod. It works correctly (distance restrictions apply) when recovering a vessel from its flight scene or from the tracking station scene, but the restrictions are completely ignored when recovering from the KSC view. Looking at the console, in the situations in which the mod works its recovery function is being called and working properly, but when recovering from the KSC view it seems said function it is not being called at all. KSP version: 1.12.5.3190, Windows 10 x64 Mods installed: Module Manager 4.2.3 NIMBY 1.1.3.3 Reproduction steps: Set NIMBY recovery range around KSC to a small number. Create a new game, launch a new vessel, move it outside of recovery range but in view of the KSC. Attempt to recover from flight view, recovery will be blocked. Return to KSC, recover the vessel from its icon, recovery will not be blocked. Log: https://pastebin.com/H9uJes5t

Here they are: Bugged player.log: https://www.dropbox.com/s/x29sr6lo6r4o8kp/BugReport-TweakScale-2-4-4-5-DEBUG-Player.log?dl=0 Bugged KSP.log: https://www.dropbox.com/s/g6cqvsnx0wfsg5m/BugReport-TweakScale-2-4-4-5-DEBUG-KSP.log?dl=0 And just in case, the logs for when it's run with the working directory set correctly: Player.log: https://www.dropbox.com/s/zjiwhm3y6g3fhzr/OKReport-TweakScale-2-4-4-5-DEBUG-player.log?dl=0 KSP.log: https://www.dropbox.com/s/c1ggxjuiel5prcv/OKReport-TweakScale-2-4-4-5-DEBUG-KSP.log?dl=0

Okay so, I serendipitously found out that this problem is likely not from your mod, but indirectly and at least partly caused/exposed by the Linux file manager I use (Nemo). I was able to find the problem partly because of the extra information in the logs from your debug .dll, and partly because while testing different things, I found that in some circumstances the bug did not manifest. Some context: I have several KSP installations that I use for different purposes. Two left over from 1.9.1 for testing and safekeeping purposes (I'm trying to build a scenario/gamemode), and three 1.11.1: one is an untouched fresh install that I copy whenever I need to bug-hunt, another has all the mods I use, and a third one that has a reduced subset of mods for when I want to test things like MM patches without having to go through repeated 15-minute game loads. I keep them each inside its own folder, and all inside a bigger folder. The entire thing looks like this: You'll notice that my file manager has an integrated tree-style thing going on. That means I can open folders and then open files from inside those folders without having to actually navigate into them. I use this all the time. That's what's causing the problem. When I launch the KSP executable nested inside several open folders like that, its working directory is not the directory the actual file is placed in, but the directory that is currently open in the file manager. In the screenshot's case, that is the folder where I keep all my KSP installs. I found out because your debug library put this in my KSP.log file: This causes several issues and strangenesses; for example, the KSP.log file is placed in the root folder and not the game folder (I found that weird before but wasn't able to realize what the cause was). It also messes with specific mods. Tweakscale and Recall are two of them, but I've seen others have issues with the places they save their files to: BOSS, ResearchBodies, and TooManyOrbits specifically. There might be silent issues with other mods too. Everything works fine if I open the game's folder normally and then run the executable inside it, or otherwise pass the proper working directory. I have no idea what I should do with this, besides making sure to run the executable in a way that it gets its proper working directory from now on. Is this still an actionable bug or should we blame the file manager and move on? Do you still want those logs? Should I report this in those other mods I mentioned? Should I report this to my file manager's devs?

Really sorry for the delay! This does not fix the problem. I'll attach the new player.log file just in case there's valuable data in there that hints at some change, but on the user end it seems to be the same. I double-checked (more like quintuple because I'm paranoid) that the new dll was installed properly and it does show as v2.2.2.3 in the logfile: https://www.dropbox.com/s/qwxj1ltf6dpcw43/BugReport-Tweakscale-2-4-4-5-HotFix-Player.log?dl=0 In any case, take care of your tendinitis first!

Not sure about bug reporting etiquette: are reports welcome when running this mod on 1.11.1, or should I wait for the mod to be explicitly released for that version first? It seems to be working mostly fine but there's some weirdness going on when calculating the time to build a part when the workshops have engineers (3.5 hours for an EAS-1 seat) versus non-engineers (8 minutes for same part) in them. If it's okay I'll post the proper full report.

Glad to hear you managed to fix it and it's good to know it's safe to use. Thanks for your hard work on this really useful mod!

First of all, amazing work on this mod, it's beautiful. Now a bug report though: Opening the mod's panel in the flight scene without having a waterfall-affected engine on the focused craft creates mixed NRE and ArgumentException spam and heavy performance degradation, showing only an empty panel, until it is closed. This seems to be related to what was reported here: KSP Ver.: 1-11-1-3066 64-bit from GOG OS: Manjaro Linux 20.2.1 Mods (from CKAN): ModuleManager 4.1.4.0, Waterfall 0.4.1.0 How to reproduce: Create and launch a ship without engines, or with engines that aren't affected by Waterfall. Click on the Waterfall mod button to open the mod's panel. Result: Log file: https://www.dropbox.com/s/7h0vo71t3ufg9ck/BugReport-Waterfall-0-4-1-0-Player.log?dl=0 The mod seems to work fine otherwise.

So I'm having this problem but I don't know if it's a bug or I'm doing something wrong. It's affecting both Tweakscale and KSP Recall in exactly the same way: I tried installing from CKAN and installing manually the latest releases of each mod from their Github, on fresh installs of the game, with the same results. If my eyes don't deceive me, it would seem the "should be installed" and "currently installed" locations are the same. In-game Tweakscale seems to work just fine if I just hit Cancel (no idea how I would test KSP Recall) but the error messages are, let's say, ominous, so I thought I'd ask. Game Ver.: 1.11.1.3066 64-bit from GOG OS: Manjaro Linux 20.2.1 Mod Vers.: Module Manager 4.1.4.0, KSP Recall 0.0.5.0, TweakScale 2.4.4.5 Log file: https://www.dropbox.com/s/gg801ho7n23iqv3/BugReport-TweakScale-2-4-4-5-KSPRecall-0-0-5-0-Player.log?dl=0 As a side effect, both mods erroring together creates "You cannot show two modal windows at once" spam in the log file.

There seems to be a bug in the latest version of this mod: after entering VAB/SPH, exiting, and then entering again, be it from flight or space center view, every edit done to the ship will result in the game freezing for a half second. This is only fixed by restarting the game. KSP version: 1.11.1.3066 64-bit, installed from GOG OS: Manjaro Linux 20.2.1 Mods installed (from CKAN): StageRecovery 1.9.4.0, with the required ClickThrough Blocker 0.1.10.15, SpaceTux Library 0.0.5.0 (with bundled ButtonManager 0.0.1.0 and VesselModuleSave 0.0.1.1), Toolbar Controller 0.1.9.4, and Zero MiniAVC 1.1.0.1 Player.log file: https://www.dropbox.com/s/9c6pxbwvgvb3hcy/BugReport-StageRecovery-1-9-4-Player.log?dl=0 How to reproduce: Start the game with the listed mods installed. Create or load a save. Enter VAB/SPH then leave. Going into flight mode or back to the space center both work. Enter VAB/SPH again. Try to create or edit a ship in any way. Get a short freeze and this in the console: This behaviour does not seem to be present in version 1.9.3 of this mod.

There seems to be an issue/bug with both these mods. They are not recognizing kerbal experience obtained from stock sources such as orbiting. Formal report: The same happens with Training Lab. The expected behaviour would be that training would be done "on top" of whatever experience the kerbal already has. As it stands, unless a kerbal is being trained from scratch, there is wastage of time/science.

First of all, much thanks for this mod! I'm attempting to make use of the variety of resources you have added to asteroids to spice up a scenario of sorts that I'm building. However, since in-game the space rocks show only a single "Resources" reading when grappled, I thought at first that the mod wasn't working properly, until I looked into the save file and saw all the different resources were clearly there in the "vessel" entry. In the end I used ConfigurableContainers to make space for every resource that can be found in one of your custom asteroids in a single tank, and thus found out that the stock drills mine everything at the same time, at rates according to their abundance. However there is still one thing I don't think I can easily test, so I thought I'd just ask: what happens if I start mining a custom asteroid and I don't have tanks for every resource on it? Do those other resources still get mined and therefore wasted?

The latest version of this mod seems to have issues with specific engines when running on 1.9.1 (it didn't happen in the previous version 1.7.2.1). Tested with engines from different mods and even stock, and it seems the issue is with engines that use ModuleEngines instead of ModuleEnginesFX. The issue manifests in two different ways, so I'll add two reports: Here is a list of the affected engines from tested mods: I hope I have included all the information needed!

According to the syntax wiki on the MM Github the [*] actually restricts the range of the search to nodes that have a defined "name" field, making it equal to :HAS[#name[*]]. My personal patches file is decently large and uses exclusively @PART:HAS throughout, haven't had any immediately evident issues with it. In any case, that's besides the point, what I'd like to know is if there is truly no way to use wildcards for node selection, or a viable alternative. Because mods like ReStock, Plus, and CryoEngines make each engine use a differently-named running-mode node for each engine, making my personal smoketrail-removing patch rather excessively large and repetitive right now. In other words, I want to compact this:

No worries, I guess I could have been clearer. For the record, I've been using the following patch to get rid of most smoke trails: I'm just trying to see if there is a way to make the large block inside EFFECTS smaller with wildcards or that's not within MM's current feature set (which is why i tried "@running_*" ). Mostly because I'm seeing some mods I use escape my patch, and I wanted to see if there was a way to avoid adding fifty more entries to that list, hahaha.

I'd like to request some assistance: I'm trying to create an MM patch to remove smoke plumes from all engines (but not engine flames or other particles). While I have already made plenty of other patches I'm unsure about a particular detail of MM syntax/behaviour. Engines such as the stock Rapier have several running modes and each of them can (and does) have its own smoke trail configuration, for example: Now, if I got it right, both running_open and running_closed in that example are "nodes", right? And from what it's written in the MM Syntax wiki, wildcards can not currently be used with nodes. I'm assuming this is why it didn't work when I tried something like: @running_* { -PREFAB_PARTICLE,* {} } ... so instead I must explicitly and separately @ every differently-named engine running mode in my install in order for my patch to apply to all of them? Or is there a way I could do this in less lines with wildcards or something?