blowfish

@warranty45 that probably points to a ModuleB9PartSwitch wit no subtypes. It will most likely say which part right above that in the log.

I'll look into it. It seems that KSP attempts to compress all images now. They can be excluded by putting them in some PluginData folder, but then whatever code needs them has to explicitly load them, and I'm not sure that RPM does this. Is this a specific question about the B9 IVAs not being connected to the external cameras, or a general RPM configuration question?

They should, it's part of the Firespitter plugin ... maybe make sure that is installed and up-to-date

I'll take another look, there may still be room to tune the parameters. One other thing is that the nozzle exit area is probably set for cruise conditions in real life, whereas in AJE it's fudged somewhat - what this means is that at idle AJE engines may be producing more thrust than they should due to the nozzle being closer to the ideal shape for that exit pressure. This would not be a trivial problem to solve unfortunately, but I can look into it.

Yeah, check this thread:

Yeah unfortunately there's no generalized way to convert between AJE and stock engine modules. It really depends on the exact part and how it's configured.

Oh, that's probably somewhat more difficult. You'd have to write a patch that replaces the AJE engine module with a normal one. It might be missing some parameters that are necessary though, hard to say.

Remove the AJE patch that modifies it?

What’s special about 1/1000? I would think the resource calcs should be able to use full precision from end to end E: sorry to quote a very old post but there was some new discussion about it which surfaced this particular aspect.

Okay, here's your problem. You have a (seemingly empty) FerramAerospaceResearch folder in GameData. The key difference between those two logs is that you have ModuleManager installed in one of them, which will see that FerramAerospaceResearch folder, and patches that should only apply if FAR is present, and apply them. The B9 Legacy pack was definitely not the only difference between those two - all of its dependencies were added too. You can't really pin it on a particular mod if you're installing others as well.

Yeah. That surprises me since there's really nothing but parts in that pack. Are you sure the only difference was that, and not some dependencies as well?

@Oracle255 I set up a mirror here: https://s3.amazonaws.com/blowfish-ksp-b9aerospace-release-builds/index.html#releases/ Still looking at the HX cargo bay shielding issue. I'm away from my main computer right so might not be able to work on it for a couple of weeks.

It looks like you din't shared the files so they're not accessible? (pretty sure the public URL will be something much longer too). Could you also try with just B9PartSwitch and none of OPT's other dependencies? Just trying to narrow it down as much as possible.

Yeah I would look at other mods first - B9PartSwitch doesn't touch any key bindings.

It just provides an interface for other mods to hook into. Doesn't do anything to any parts by itself. You need something that configures it.

It's however KSP decides they should be sorted (ModuleManager doesn't do this explicitly). Probably ends up being whatever order things are in when each directory is listed. You can check the log to see what order things ended up in. In general though I'd say it's best not to depend on alphabetical order within a particular pass. If you need patch X to run before patch Y, put them in different passes.

Put a different way, do you have any examples of .version files that seem to have the extra characters?

This: https://github.com/linuxgurugamer/KSPAddonVersionChecker/commit/1fa681d3fb9f81aaf912fa7a666f1114b452feb6#diff-5b98a2e62ce1a2ba69744bbaef2c9dfaR49 And glad to hear the symbolic link stuff worked finally. I don't recall having issues like the ones you're describing but maybe I've been creating symbolic links for so long that I just forgot.

The link is from somewhere outside the Git repository to somewhere it it. Git isn't even aware of its existence.

Also, it looks like a lot of the build depends on specific paths in your system. The AssemblyInfo templates can use the relative path of the .version file, but the post-build is another matter. Would it be reasonable to replace the hard-coded KSP path with a symbolic link from that KSP install to the output directory? (i.e. mklink /D R:\KSP_1.4.1_dev\GameData\KSP-AVC D:\Users\jbb\github\KSPAddonVersionChecker\Output\KSP-AVC). I've used this approach extensively myself and I've found it to work well. Also, what's the purpose of all the test case .version files?

@linuxgurugamer can you elaborate more on the issue where Github was returning extra characters at the beginning of the file?

@linuxgurugamer what C# version are you targeting for development? I only ask so that I don't accidentally introduce new syntax that will break something for you.

Makes sense. I'll look at implementing this. I think it should be pretty simple - if the root JSON element is an object, parse a single version, and if it's an array of objects, parse each one as a version and choose the highest one that's compatible with your KSP version.

To clarify, 2 and 3 wouldn't require there to be info on Github, just to use it if it's there. And also I forgot to mention I didn't expect you to implement any of this. I can do it and submit a PR.

@linuxgurugamer Continuing discussion from the B9PartSwitch thread. What I want to be able to do is have AVC be able to figure out what the most recent mod version for your particular KSP version is, not the most recent overeall. I looked at the code and I see 3 possible solutions: Allow the remote .version file to contain an array of metadatas. If it's an array then it will choose the highest version that is compatible with your KSP version. Use Github releases. Scan the title (and maybe description) of each release for something like "KSP x.x.x" and if it exists, assume that release is only compatible with that KSP version. I put the KSP version in every release title so this would work for me. It looks to me like the Github code will only run if there's also a remote .version file so that might have to be fixed up. Use Github releases. Look for a .version file artifact in each release and if it exists download it and parse it for the KSP version. This could potentially be slow if there are a lot of releases, might have to test some. And the same part about the Github code not running without a remote .version file applies here too. Do any of these sound reasonable to you?