linuxgurugamer

Hmmm. He actually made the PicoPort for me and decided to release it as it's own mod. He also hasn't been around since August Let me reach out to him, if he doesn't respond, I'll adopt it and fix that issue

Is it an active mod (ie: uptodate)?

I wasn't offended @RoverDude @Angel-125 Could you take a look at this link (2nd or 3rd in this thread) and add your comments here?

Anything is possible, open an issue on Github so I don't forget. But working on other mods right now

Sorry about that, it's slated to be moved up soon

Unfortunately, no

Only way to get rid of it is to backport the changes and recompile

First off, it's not necessary. There should never be two identically-named mods. Even if a mod is forked, the fork should (usually required by license) change the name, and therefore should also change the directory. Secondly, what about someone like myself (and others)? Should I create more than 160 directories inside a LGG directory? Many of my mods have been adopted, and have their own directory layout, which other mods are expecting. There is no need to change the layout of the GameData directory for static data (ie: parts, textures, etc). It will just cause problems.

That is a very old version, I don't support that. I think the current version is pretty much null-ref free, but it's for 1.5 and 1.4

They shouldn't do that, it just causes confusion I don't see how an upload/download site like Curse and Spacedock will be affected by this. and CKAN will work quite nicely with this, as long as the metadata is correct

Assuming that you dont install another version of the mod, nothing will happen. Even though I understand this, most people won’t. In fact, most people don’t even know what a symlink is, and in windows, you have to do it from a command line. So, for those who are confused, a bit of explanation: From Wikapedia: So what this means is that for people who want to use them, can create a library of files and directories, and rather than cluttering up your hard disk or SSD with multiple copies of the game and mods, you can simply use symlinks to create an install with symlinks and just use a minimal amount of space. It can also make it easier for developers to quickly throw together a new game install for testing purposes.

New release, 0.1.9.10 Fixed nullref when using the equals sign and at the end of the list of cameras. Added code to allow a docking node to be a target and have the docking info displayed on the docking camera

It's a "feature". Actually, it's an oversight. It was working only when the targeted object was a vessel, and not if it was a part. Easy fix, testing it now

What is KSPe ?

Refresh you CKAN, it should be fixed

Ok, I’ll take a look. Thanks for letting me know

I believe that the source of this is the fact that if you just use the game xml functions, then it writes the following: GameData/modname/dlldir/PluginData/dll.xml where: dll = the dll of the mod dlldir = directory where the dll is An additional advantage of using a common PluginData directory is that it is easy to backup. The proposed solution as I understand it is: KSPDIR/PluginData/modname/datafiles I would like to hear from some of the Squad people, such as @bewing, @JPLRepo and others, before any decision is made. So, I've written up some proposed guidelines. I will admit that items 3, 4, 5, 6 are how I usually set things up. I find that it makes it easier to find files with this kind of organization. Obviously, if a mod has only a single dll, there would be no real need for a plugin directory, although it doesn't hurt. Proposed Community Mod Install Guidelines Mods are installed into the KSPDIR/GameData/ directory (required by the game, put here for completeness) Dynamic mod data is in the KSPDIR/PluginData/modname directory It is strongly encouraged to have a .version file in the main mod directory. Forgetting anything else, this makes it easy to identify which version of a mod is installed It is recommended that all parts supplied by a mod be in a single directory called Parts. ie: KSPDIR/GameData/modname/Parts Files which are not to be read during the game startup can be put into a PluginData directory in the mod directory. ie: KSPDIR/GameData/modname/PluginData. This is a directory that is ignored by KSP during startup It is suggested that DLLs be put into their own directory inside the mod directory. Common use suggests that it be called Plugins. ie: KSPDIR/GameData/modname/Plugins/

What version of KSP are you running? When you installed it via CKAN, what were the compatible KSP versions set to? When was the last time you refreshed the mod list in CKAN (ie: Refresh button)?

Most likely not. Also, it's not working in 1.5 yet

Not sure who you are referring to. I was answering in general, not about a specific mod. I make a reasonable effort to contact the original mod author (or last maintainer) before adopting a mod.

Another aside, but directly related to KJR, @Rudolf Meier is planning on picking up his development of KJR soon.

I've created a new thread to continue this discussion, and avoid cluttering up the KJR thread here

This is a thread to discuss a recommended folder layout for mods. There has been discussion about this elsewhere

While not part of this discussion, I prefer to use CKAN for 99% of the mods I use, and CKAN updates mods without any problems; my main game has over 255 mods installed, so I speak from experience. I do recognize that not all mods are listed in CKAN, and not all people like to use CKAN On another note, if Squad were to come out with a recommended layout for mods, I would work at updating all my mods to support that.

My mods can usually be updated without deleting the folder, to avoid the necessity of deleting. Unfortunately, there is no consensus, and Squad provided no guidance or recommended standards/layouts. So we are stuck with a mishmash of layouts