JH4C

No idea, I don't use either pack. It should be in their instructions as to whether those EVE .cfg files should go in the main EVE folder or in the AstronomersVisualPack folder; generally you don't want to be moving stuff around unless explicitly told to do so.

You're in the clear, it was me; I grabbed all the others I use, but somehow overlooked that pack.

Hm, I thought I did; I spent all afternoon updating things today. I'll re-install anyway; sorry for the (probably) unnecessary report.

@Nertea, there's a bug being flagged by B9, although it's not a show-stopper: B9PartSwitch has encountered a serious warning. The game will continue to run but this should be fixed ASAP. Subtype has no name: PartSubtype Duplicated subtype names found on ModuleB9PartSwitch (moduleID='meshSwitch3') on part truss-spinal-01: Please see KSP's log for additional details Despite the last line there's no further information in the log about the error.

This error is back; I've only just got around to moving this into 1.5.x as almost everything else had updated, and on boot I found the exact same issues as before. As I still don't use RealPlume, I'm just gonna edit out those parts of the patches for my own use, but they really need another look when someone who knows more about everything involved has a chance. ETA: inspection of the log file shows that the problem appears this time to be related to the pathing within the RealPlume patches, even though those versions of the patches shouldn't be getting applied on my system. Example: [ERR 23:32:44.649] [ModuleManager] Error - Cannot parse variable search when inserting new key localRotation = #$../../../PLUME[Turbofan]/localRotation[0]$,$../../../PLUME[Turbofan]/localRotation[1]$,$../../../PLUME[Turbofan]/localRotation[2]$ There was discussion before about issues when using NEEDS: and FOR: in the same line, and that's part of the checks used to apply these sections of the patches.

The error B9 throws up would be very useful to see; they're pretty good at explaining what's gone wrong. However as B9 isn't any kind of dependency for this mod, it's likely to be some other add-on that's causing this.

Do my eyes deceive me? An addon for cometary bodies that doesn't require Kopernicus? Oooh...

Oh, I fully understand that - the issue I'm reporting is that there is a Crew Report experiment built into the part that cannot succeed, which I doubt was the intention. There seems little purpose in fitting a component that will never function.

Just been doing some playing. The airbags seem to work as intended so the .dll probably only needs a refresh. The Meadowlark cockpit with its two command seats simply requires "CrewCapacity = 2" to gain modern function, but the Crew Report function is still inaccessible - "Crew Report requires the {part} to be manned." Probably best to delete that module from the part, along with the accompanying science container definition because it appears to be inaccessible - right-clicking the part offers no data storage/retrieval options. I'll submit all this to the GitHub as an issue.

Have you tried it in 1.5.x? I've not experienced any problems, nor has anyone else reported anything; I'd say it's safe to assume it works just fine. Really, it's so much simpler to just try something out to see if it still works...

I've been eagerly following this, time for a test flight!

The dependencies never share the same name as the parent mod. However, the point of dependencies is that many things use them to make things work more easily, and so you'll find the same folders in multiple downloads. In your example above it sounds like you're unnecessarily downloading EVE as it's already included in the other download. A more accurate real-world example: Nertea's Near Future Technologies add-ons. Inside all of them will be a Gamedata folder (as is standard), and inside that will be the specific folder for that mod (let's say this one's called "NearFutureCandyDispensers") as well as "B9PartSwitch" and "NearFutureProps" which are required dependencies. If you already have another of Nertea's addons, such as NearFutureSolar or StationPartsExpansionRedux, they will have already installed the same dependencies - so what you need to do is see if the copy you have installed is newer than the one that came with the add-on being installed. In this example "NearFutureCandyDispensers" is an older mod, and the dependencies you already have installed are much newer, so you only need to install the main folder and can ignore the others. If you know how to merge folders on your operating system, that'll usually put everything in the right place. Alternatively, you might find it easier still to use CKAN, which will do all the worrying about dependency location for you.

@Gordon Dry: If Squad's using "Unresearcheable" then even if it is a nonsense word, I'd rather not use a patch to change it. That strikes me as a way to cause more unexpected issues; the correct way of handling it would be for those addons that haven't spelled it the same way to be patched to match the stock implementation.

I don't recall if this works the exact same way on Windows, but on MacOS I can open the Gamedata folder, Select All, Copy, then Paste that into a text document and it'll turn into a list of the folder names. Another option would be to install the full-fat version of AVC, which would report on everything that has a .version file. And of course there's always opening KSP.log and copying the list of loaded mods from there. Open the file in your text editor of choice and search for Mod DLLs Found; you'll have a list of all the add-ons that use DLLs first, then all the folders within Gamedata follows directly behind. Of course not every mod uses a dll, and some share common folders, but that's about as close as you'll get to everything with minimal effort needed to fill in any missing details.

It might be an idea for you to look through the thread more thoroughly, as you're suggesting some parts that are either already included or that have been listed as likely to be excluded due to similarities to existing models. Just have a play with what's already been made, see what you can come up with; the idea here isn't to emulate every aspect of a flightsim, but to allow us to build something new.

There's an unofficial 1.5 update on the last page of the KJR thread as well.

There's no plugins to recompile, it's just parts; as such, it should work just fine...

FYI the GitHub link points to the 1.0.0 release directly rather than just the Releases folder; savvy downloaders should be able to find their way but it may be better to tweak the link.

Sorry, didn't mean to confuse the issue; I didn't mean to suggest that I'd adopt it, just to get that part working as now intended in my own game - it was a vote of support for your suggestion to keep it alive, poorly worded. And as you can see from the other replies, we're not alone in this! That said, I first started using it after reading @Daniel Prates's post, which meant I only ever installed it in 1.4.5 and the parts I used worked as I expected/wanted. I believe the configs for the lights are referring to getting them functional under 1.4.5 (which I don't think I was concerned about) but I believe @Mecripp would know that better than I. I'm in two minds about a rebuilt IVA; the unconventional crew layout is part of its charm, I just cope that can be retained.

I love the vertical mk2 cockpit from this, and I really should add the new codes to use the open cockpit in 1.5.x...

Nice to see you back @Li0n. Love the look of the new settings sheets, the Morse page alone will keep me entertained for days! Looking forward to the updated version, but not in any rush for it

How very useful! Thanks for figuring it out

It has been tried. First result for "KSP ring world": Putting a habitation ring all the way around a planet has major issues, not least because of the render physics distances required to even try to make it stable. Someone scaled up a single part to encompass Kerbin and it cast a shadow, but you can't do anything with it because you're considered "too far away" from the centre for it to be rendered when you approach any of its surfaces... Which is a good way to end up dead very fast.

Considering the post above yours praises the IVAs, I would be interested in learning why you find them so terrible. I assume you did install the associated Near Future Props dependency? I just made a test "station" using every single habitable unit (requiring me to hire 70 additional Kerbals!) and every single one of them was sat properly in a seat, nothing was clipped through anything. There's obviously something not right with your install. OT: Everyone's entitled to an opinion, but if you're gonna offer criticism try and be constructive about it instead of just ripping something to shreds with no suggestions as to how it might be improved, or even basic investigation that it's been properly experienced. Uninformed posts like this are how we lose people from (or worse, drive them out of) the community.