It's important to have them, but here the real fun begins:. The result is that you eliminate installation problems: this way, the user is guaranteed to have the dependencies that your mod needs to function. Here's the real meat of the file: the installation instructions.
This section tells the client where it can download the file, and after that, what to do with the contents of the zip. And that's why this project is so great. Is there a way to "recommend" a package, but only if all of its dependencies are already present or being installed for another reason?
For example, if I were packaging Interstellar, I would like to recommend my resource-sharing pack if Community Resource Pack and ORSX are installed, but without causing those dependencies to become recommended if they're not. Being fan of Debian and using Terminal to install packages I really welcome what you have done. I was thinking about such a aproach before aswell. It would be great to do repository style mod installer where authors of mods will be able to upload their mods in a fashion that your plugin will be able to handle and install it in KSP with all dependencies or lets say if particular module cant work with other, dont allow installation or ask for removal of interfering module.
Also when Squad finnish the game they should consider adding this method of mod installing to KSP so its native. I want it to be installed by default like a regular recommendation if you install all of the packages that it bridges. That doesn't happen with a suggest. It dosent work for me so. This looks awesome, and I hope it takes hold. I'd much prefer a quick, easy and above all standardized way to install mods, especially if a way to easily and quickly check versions and things can be integrated successfully into every mod.
I went through and checked all of my mods versions last night. Took me like 30 minutes, and I only have 12 or so installed. The window closes because CKAN is done. You need to run CKAN from a command line so that its output stays visible after it's done i. But to help all new starters as I am, and avoid to spend one hour to make it work, here is what I have done.
After some research, and resetting installation, I found out that after "ckan ksp add default" you must add. Now you can use that window to use ckan.
Hey everyone! I've been off-line since the release as I've been celebrating with ice-cream, but I'll try to quickly respond to everthing Ippo hasn't addressed. D'oh, this is a bug on our behalf. If there's only a single install, it should use that automatically. I'll open an issue to track it, and with luck we'll have this nailed in the next release!
Alas no, but I absolutely see why you'd want to. That's a bit stronger than a suggests which isn't installed by default , but weaker than a recommends which installs something by default, including its dependencies.
Leave it with me, and I'll do some thinking about if there's a way we can nicely express that in metadata. Who's now going through the incredible number of submission for new CKAN mods from the last 24 hours.
I'm very much amazed by how many submission you get. That's awesome. Please help me how exactly the indexing works. I guess this is processed automatically by netkan. Is this done in "nightly builds" or when exactly? But as i understand, mod authors can also contribute directly into this repository, specifying specific a version plus downloads. And in this case mod authors have to update the data manually each time they have a new release, right?
Thank you! We definitely do want this running nightly, as well as being triggered on a repository change. Although I don't have to be the one who runs it, anyone on the core team has access. Advanced Search Search results for "module manager". Community Tech Tree. Community Tech Tree expands the stock technology tree to accommodate many community mods in an inclusive and extensible manner.
Kerbal Planetary Base Systems. It also supports the major life support mods. Kerbal Atomics. Fancy nuclear engines for fun and profit. Cryogenic Engines. High efficiency chemical engines. DMagic Orbital Science. New science parts and experiments. Helpful LED indicators to show status. Includes standalone parts and enhancements to existing ones.
Connected Living Space. This mod identifies areas within a vessel that can be crewed by Kerbals and through which kerbals can pass internally to reach other parts that can be crewed. Allows linking separate vessels without cooking them for the purposes of towing, lifting or resources transfer.
Configurable Containers. Configurable Containers converts all stock fuel tanks and other containers so that in Editor you can repartition them and change their resources.
Then in flight you can also change resources within predefined sets if a tank is empty. 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.
0コメント