This makes install of addons using it easier since you don't have to check date on the file when overwriting it. There is also some code to warn you if an old version of MM or my MMSarbianExt is present and to ask you to delete them. Version 2. Documentation update is in progress.
This version parse your save game just before the main menu. It can take some lot of time if you have a bunch of olds saves. I'll try to find a way to limit that. I strongly advise to delete any 2. You'll see the info message a bit later in the loading process.
The cache is deleted if any. If you get "Exception while checking needs" lines in your log please report them. Cleanup the Exception interceptor code and remove the double exception logging and improve the badly worded warning.
Version not listed here? Check the Jenkins Server. If it is there then you can use it without fear of triggering the end of the world. A Documentation Wiki is in progress. Post on how to use variable in MM. Community examples and useful patch. Be careful when you delete or add node as the index will change. It's quite a useful feature, but won't change much for mod use. No promise for this.
I had something working but it failed at the second reload. KSP code makes this quite hard. I may took the easy way out and just add a button. Then you can put you patch. I would create a folder for your personal patch, but it's up to you. As mentioned earlier you can have multiple version of it. But you can clean up too. You can now override specific lines in a ConfigNode what the game's code calls the format inside a.
The new format looks like this:. The change with :Final are applied after all others are done. If there was already a node of type 'NODE', now there's two of them. So if you do. Right now 'tag' isn't being used by anything, but in the future if you need to add multiple nodes, adding a 'tag' field isn't a bad idea.
It'd look something like this:. Change for v2. On the other hand, if you use periods to specify your mod's version, then "MyMod. These apply to ,! I'm a little concerned about needing to have a copy of the ModuleManager.
My reasoning is that I have seen several mods which do not use ModuleManager themselves, but provide ModuleManager config files to ease inter-operation with other mods.
This will silently fail under the new scheme unless the user either adds a copy of ModuleManager. I think that ModularFuels compatability is likely to be the biggest one, here, but there could well be others. However, I completely understand the concern regarding addons dropping older versions into the GameData root, and messing up the entire install.
As an alternative, how about simply including the dll version number in the filename? You would then still be able to process the entire tree from a single instance of your DLL, and users could be told to simply delete all but the newest version number from GameData?
Anyhow, thanks for working on this, I don't quite know what I would do without it I'll be testing the new one out tonight carefully, and installed in 3 places, as needed , and I'll give feedback if I find any problems. Otherwise we need to copy the plugin to lots of mod folders, which is quite tedious, much tedious than manually checking the version and judge if older version should be replaced. Would it not be best for ModuleManager and ALL module manager cfg files to have their own dedicated folder, like other mods do?
The user is left with one copy of ModuleManager to update, and one folder to view all cfgs, removing the risk of having lots of distributed cfgs or dlls that could be conflicting. The moduleManager. User has 3 mods which all come with module manager cfgs. Each individual mod would come bundled as follows:. That just makes it more work to remove a mod, since it is no longer totally contained in its own folder, and does nothing to resolve the issue of installing a mod that comes with an old version of ModuleManager.
Many users are put off by having to track down dependencies that they see as "should be bundled", so mod authors who depend on MM for their functionality will want to and rightly so bundle the MM version that is current at the time they created their mod. I just want to chime in about the new subdirectory plan--I too think, while it's a neat idea, it'll cause more problems than it solves. That shouldn't be necessary, those mods should have their own copies in their folders already, and you shouldn't replace them, since they may be dependent on the particular version they shipped with -- replacing them with a newer version is begging for problems.
It's like replacing a library DLL that ships with a program with a newer version of that library -- it might work, but it's generally a very bad idea.
If it was designed to run with version X, don't replace it with version Y. Leave well enough alone First off, let me strongly applaud the work on ModuleManager. It has become a really important addon to KSP for me. Well done. This version seems to have a lot of bugs as expected perhaps , but I may also be doing something wrong.
I found it got very messy, very quickly to have the mod in all the required subdirectories 5 in all. I think it was better to have just one in the GameData folder.
Unfortunately, the reload of the database on the debug menu function did not appear to work. It would be so good if it was reliable.
I was unaware of the earlier wildcard extension. It's awesome! I have fallen back to using that for now. I can confirm that this is working for me at the moment. Works as advertised for that. I only have 1 or 2. One of the things that was great about ModuleManager was it only augmented the way config files worked. It didn't alter the behavior on such a fundamental level. Config files are supposed to function no matter where they are.
Also, one use of MM config files is as tweaks. I think quite a few of us as non-modders keep our tweaks in a separate sub-folder i. Now I'll need to copy the dll in there even though it's located elsewhere and should be functional? I submit that the issues that these changes are intended to address were never very serious issues to begin with and didn't merit such a drastic response.
Leaving well enough alone would have been a great response to not making such sweeping changes to ModuleManager to begin with. Accidentally overwriting files when installing over them has always been a risk with software. It requires some caution when installing software and nothing more. If it's not enough to direct the burden of resolving versioning issues onto the modding and player community and a fix really is required which I re-affirm that I don't think one is because the problem is non-existent.
It's easier to resolve a version issue for a plugin living in a single location than one that resides in multiple locations. Because sooner or later, with this system, players will have to worry about resolving version issues only they'll have to do it individually one by one across multiple mods. Right now, how many version of ModuleManager are there that we think we have to worry about?
By now they should really be down to two. The latest official one which practically everyone is using and Sarbian's version from a few months back which corrected an issue where the plugin might not execute properly or cause other plugins not to execute.
And of course his extensions. Aside from that, it shouldn't be an issue at this point in time. And, going forward, how much updating do you anticipate doing, Sarbian? Aside from fixing bugs in the software or fixing future compatibility issues arising from KSP updates there really shouldn't be much updating going on. If there is, then let the plugin 'phone home' as Kerbal Alarm Clock does. And update once at a single location rather than updating many.
There is the phrase "do not let the animals run the zoo. Only allowing the local instance of MM to apply config from its local source does not prevent conflict since the locally-sourced config is applied globally. Changes-after-changes to the same value is a feature of the MM system.
To prevent undesirable out-of-order config overwrite what is needed is a robust and open versioning scheme which is able to reliably discriminate "first" and "second" config patches without hindering the natural open-endedness of the design. Instead, put the sequencing information into the cfg patches themselves. This way a modder can opt-in to enforced sequencing for data integrity purposes. For example the config patch for Kethane 0. Then MM can compare the config patches, see they are the same patchClass, then compare version numbers to see if it should apply or not.
I cannot see how to expand data protection beyond this level without unfairly allowing one modder to lock down the data for others which is against the MM purpose. Now I don't know anything about C but for World of Warcraft addons in Lua when we ran into the shared library issue we created a method of detecting during loading if the shared library was already loaded and only loading the rest of the file to replace it if we had a newer version.
Can you also fix it so it would work with part names containing spaces i. BobCat's mods? Maybe use quotes to indicate where strings starts and ends, like it's common in OS's command shells? It's a Unity3D issue with ConfigManager. It does not like whitespaces. Step 1: Find a mod that you want. Step 2: Check if the mod has any dependencies or conflicting mods.
If there are any dependencies, you need to install those too so that the mod works properly. If there are any conflicting mods, make sure to not get those mods for as long as you have the mod. Step 3: Open the zip file s and look for the mod itself. For most mods, the zip file will contain a GameData Folder and some other files. Drag the mod's GameData folder and put it on your desktop.
Step 6: Start KSP and enjoy! Check it to make sure that there aren't any of the dependencies already in there. If they are in there, you don't need to download the Dependencies separately! If they are not in there, you need to download the dependencies separately. It is a software that installs mods for you! Click on the first link. Then scroll down till you see the downloads. Launch it after it is done downloading, andit should detect your KSP install automatically.
Then, you can type mods into the search bar and click the checkmark next to a mod and click apply changes at the top. Then you will have your mods installed!
No need to worry about conflicting mods and dependencies, CKAN will automatically install them, and it will not let you install it if there is a conflicting mod in your mods folder.
Please note that CKAN doesn't have every mod out there. For those few mods, you need to install them manually. Also note that the mac version might be different, and its a bit buggy. If this helped, please comment below and like this post! Thank you for reading! IsaQuest [author] 15 Feb pm. Share to your Steam activity feed. You need to sign in or create an account to do that. Sign In Create an Account Cancel.
0コメント