The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]

[politas]

[quote name='TheMustacheGuy']Hey there. I have CKAN and I can't find ckan.exe. Where do I find it?:wink:[/QUOTE]
Wherever you extracted it. Try running this command from a terminal window.
[code]find ~ -iname "ckan.exe" [/code]

[COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

[quote name='Auriga_Nexus']When attempting to install Kerbal Planetary Base systems via CKAN I get a 404 error. The KerbalStuff page has it up however, and the link in the 404 error appears to be correct. Also the mod version listed is not the most current, but there is no option to upgrade.[/QUOTE]
Please include the exact error text you get. Edited November 20, 2015 by politas

[BlackHat]

Hmm, Checked CKAN today and saw before Refresh I had 399 Compatible mods. After Refresh I had 436 Compatable mods. (27 mods updated and 9 new ones in repository)

So once again I am scrolling up and down the list of compatible mods trying to "figure out"/"identify" which mods have been updated to be compatible with 1.0.5.

I would like to strongly suggest one of the following:
1. Include a new column showing the date a mod had its metadata updated in CKAN.
2. Add a new filter showing Updated mods since last refresh. (Similar to the New in Repository filter)

Trying to find the 27 new mods added to the compatable list in a list of 436 mods is getting tedious and annoying. Edited November 20, 2015 by BlackHat

[IntoSpaceAgain]

There's already an 'upgradeable' filter in the GUI.

Edit to add: Also there's a button to add all upgradeable mods automatically.

If you're using the command line, simply use the "upgrade --all" flag and CKAN will install all available updates. Edited November 20, 2015 by IntoSpaceAgain

[BlackHat]

[quote name='IntoSpaceAgain']There's already an 'upgradable' filter in the GUI.[/QUOTE]

That ONLY lists mods I have installed that are upgradable to a newer version.

I want a new filter that will list ALL mods that have been "updated/upgraded" since the last refresh.

[Octa]

Is "Supported KSP Version 1.0.99" just a workaround for the developer to say that the mod should work until 1.1/in all 1.0.x-versions?

Also a few mods haven't been updated yet and not listed as compatible, but accorrding to the threads they work in 1.0.5. Can i force the installation via CLI?

Edit: I support BlackHats suggestion. We already have a "Recently added"-Filter, so a "Recently updated" filter would be a nice addition. Edited November 20, 2015 by Octa

[Auriga_Nexus]

[quote name='politas']Wherever you extracted it. Try running this command from a terminal window.
[code]find ~ -iname "ckan.exe" [/code]

[COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]


Please include the exact error text you get.[/QUOTE]


Sigh.. it's a bloody 404 error how much more exact do I have to be?!

Though I guess more details can't hurt. Basically the metadata package points to version 2.7b as the most current, but that download is no longer available on KerbalStuff. On top of that I have been using KSP v1.0.4 still - I'm waiting for the official 1.0.5 release of MechJeb before I make the switch.
I actually looked at the metadata entries and they show all the way up to version 2.10, but 2.8 and up are listed for version 1.0.5. I think this has to do with the version-compatibility rules for CKAN - but it's weird because the mod still shows up as compatible on my mod list. It just refuses to recognize any version of the mod that doesn't match the current KSP version, so it won't update to the latest version available - and the current version is no longer listed on KerbalStuff. Hence, HTML error 404, location not found.

[BlackHat]

[quote name='Octa']Is "Supported KSP Version 1.0.99" just a workaround for the developer to say that the mod should work until 1.1/in all 1.0.x-versions?[/QUOTE]

Yes that was a workaround, the incremental updates Squad was doing (1.0.1,1.0.2,1.0.3,etc) Meant that each time a new version came out for some mods there was no changes needed and the modders would need to update the metadata to say it would work for the new version so CKAN would allow it to be listed as compatible.... So to avoid having to do that every couple weeks some modders put the 1.0.99 so they would not need to change the metadata with each update.

[TheMustacheGuy]

I found ckan.exe
It was in my Downloads folder

[politas]

[quote name='Auriga_Nexus']Sigh.. it's a bloody 404 error how much more exact do I have to be?!

Though I guess more details can't hurt. Basically the metadata package points to version 2.7b as the most current, but that download is no longer available on KerbalStuff. On top of that I have been using KSP v1.0.4 still - I'm waiting for the official 1.0.5 release of MechJeb before I make the switch.
I actually looked at the metadata entries and they show all the way up to version 2.10, but 2.8 and up are listed for version 1.0.5. I think this has to do with the version-compatibility rules for CKAN - but it's weird because the mod still shows up as compatible on my mod list. It just refuses to recognize any version of the mod that doesn't match the current KSP version, so it won't update to the latest version available - and the current version is no longer listed on KerbalStuff. Hence, HTML error 404, location not found.[/QUOTE]
Well, you said in your original post that the link in the 404 error message was "correct". So clearly, you had more information that could have helped. Generally, when reporting a problem with a volunteer-supported program to web forum where everyone trying to help is doing it on an entirely voluntary basis, it helps to give more information than is necessary, rather than less.

It looks like the mod author has pulled the 2.07b version of the mod and changed 2.0.8 to be KSP 1.0.5 only. CKAN has some old data. Not sure how to clean that up. It's difficult when mod authors change things that way. I've raised an [URL="https://github.com/KSP-CKAN/CKAN-meta/issues/836"]issue[/URL], so it should get sorted out as best we can. Everything should be fine on KSP 1.0.5 when you do upgrade.

[COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

[quote name='BlackHat']Hmm, Checked CKAN today and saw before Refresh I had 399 Compatible mods. After Refresh I had 436 Compatable mods. (27 mods updated and 9 new ones in repository)

So once again I am scrolling up and down the list of compatible mods trying to "figure out"/"identify" which mods have been updated to be compatible with 1.0.5.

I would like to strongly suggest one of the following:
1. Include a new column showing the date a mod had its metadata updated in CKAN.
2. Add a new filter showing Updated mods since last refresh. (Similar to the New in Repository filter)

Trying to find the 27 new mods added to the compatable list in a list of 436 mods is getting tedious and annoying.[/QUOTE]
It has been [URL="https://github.com/KSP-CKAN/CKAN/issues/1519"]raised as an enhancement request here[/URL], since you last asked. Might not get implemented in time to be useful for 1.0.5 at all, but hopefully for 1.1 (Where it's going to be very important.)

[Workable Goblin]

CKAN seems like a great idea to me, buuuut...I can't install it on my Mac (iMac 14,2, running OS X 10.11.1; I can provide full system details if requested). When I attempt to run mono ckan.exe, I get this error message:

[code][FONT=Menlo]exception inside UnhandledException handler: Object reference not set to an instance of an object[/FONT][FONT=Menlo]
[/FONT]
[FONT=Menlo][ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.WindowsFormsSynchronizationContext ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeEngine ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeWin32Classic ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: /opt/local[/FONT]
[FONT=Menlo] at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)[/FONT]
[FONT=Menlo] at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] --- End of inner exception stack trace ---[/FONT]
[FONT=Menlo] at System.Drawing.KnownColors..cctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] --- End of inner exception stack trace ---[/FONT]
[FONT=Menlo] at System.Drawing.Color.get_Black () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.ThemeWin32Classic..cctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] --- End of inner exception stack trace ---[/FONT]
[FONT=Menlo] at System.Windows.Forms.ThemeVisualStyles..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.ThemeEngine..cctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] --- End of inner exception stack trace ---[/FONT]
[FONT=Menlo] at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.Control..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:.ctor ()[/FONT]
[FONT=Menlo] at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] --- End of inner exception stack trace ---[/FONT]
[FONT=Menlo] at System.Windows.Forms.Control..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.ScrollableControl..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.ContainerControl..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at System.Windows.Forms.Form..ctor () [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at CKAN.Main..ctor (System.String[] cmdlineArgs, CKAN.GUIUser User, Boolean showConsole) [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at (wrapper remoting-invoke-with-check) CKAN.Main:.ctor (string[],CKAN.GUIUser,bool)[/FONT]
[FONT=Menlo] at CKAN.GUI.Main_ (System.String[] args, Boolean showConsole) [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at CKAN.CmdLine.MainClass.Gui (CKAN.CmdLine.GuiOptions options, System.String[] args) [0x00000] in <filename unknown>:0 [/FONT]
[FONT=Menlo] at CKAN.CmdLine.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0[/FONT][/code][FONT=Menlo]

I believe I am running the latest version of mono:

[code]Mono JIT compiler version 3.12.1 (tarball Fri Nov 13 12:40:55 CST 2015)[/code][/FONT][code]
[FONT=Menlo]Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com[/FONT]
[FONT=Menlo] TLS: normal[/FONT]
[FONT=Menlo] SIGSEGV: normal[/FONT]
[FONT=Menlo] Notification: kqueue[/FONT]
[FONT=Menlo] Architecture: amd64[/FONT]
[FONT=Menlo] Disabled: none[/FONT]
[FONT=Menlo] Misc: softdebug [/FONT]
[FONT=Menlo] LLVM: supported, not enabled.[/FONT]
[FONT=Menlo] GC: sgen[/FONT][/code][FONT=Menlo]

I do use MacPorts, not Homebrew, if that's important.[/FONT]

[politas]

[FONT=arial][SIZE=2][quote name='Workable Goblin']
I believe I am running the latest version of mono:

[code]Mono JIT compiler version 3.12.1 (tarball Fri Nov 13 12:40:55 CST 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: normal
SIGSEGV: normal
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen[/code]

I do use MacPorts, not Homebrew, if that's important.[/QUOTE]
No, you really aren't:
[code]Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Nov 12 09:52:44 UTC 2015)Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
[/code]
Mono V3 does not support elements used by CKAN; it is not a .net 4.5 framework. You'll need to go to mono-project.com and get the actual latest version.[/SIZE][/FONT]

[Workable Goblin]

[quote name='politas'][FONT=arial][SIZE=2]
Mono V3 does not support elements used by CKAN; it is not a .net 4.5 framework. You'll need to go to mono-project.com and get the actual latest version.[/SIZE][/FONT][/QUOTE]
Ah, thanks. It seems that macports doesn't have the latest version. I tried installing it from the link on the download page after I first encountered this error, but it seems it got overruled. Fixing everything now...

[steve_v]

So, what's the ETA on sorting out (or just getting rid of) the mime handler installation? it's broken at [URL="https://github.com/KSP-CKAN/CKAN/issues/1510"]least[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1509"]three[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1498"]ways[/URL], and much as I'd love to use CKAN for 1.0.5, up with an application that corrupts my desktop configuration every launch I will not put.
Can't we just kill this already? It's not hard to add a file association through the provided desktop tools, for those few who will actually use this.
Aside, I'm not overly excited about ckan tampering with files it does not own (and without prompting) in general. Please leave my desktop alone so that I can use this again.


----
As a workaround I'd like to use the command-line client, how do I change the filter from 'compatible' to 'all' on the CLI?
CKAN will not show mods that haven't been updated for 1.0.5, or allow one to install them without guessing the exact version, despite said mods being known to work... and this issue is getting rather old. Edited November 23, 2015 by steve_v

[zeb_]

Hi, I just noticed this morning that "Chute Safety Indicator" is missing from the list (it was installed with CKAN on my KSP). I checked it is still present in CKAN Meta [URL]https://github.com/KSP-CKAN/CKAN-meta/blob/master/ChuteSafetyIndicator/ChuteSafetyIndicator-1.0.2.ckan[/URL] so I do not know where the problem is. I cleared the CKAN cache, but this did not fix it. Am I doing something wrong?

EDIT: just realised that this mod is considered as Incompatible, and thus filtered out by default. Using the Filter buton, I was able to display it. I suppose that Max KSP version is the parameter, which determines if a mod is compatible. Edited November 23, 2015 by zeb_

[PmThay]

hi. when i try to run "ckan.exe" on the KSP folder, i get a "Detected Trojan" warning from my anti-virus(360 total security).
the Trojan name is: HEUR/QVM03.0.Malware.Gen
can you confirme this?
is it a problem with my anti-virus?
can i ignore the warning?

[Guest]

[quote name='PmThay']hi. when i try to run "ckan.exe" on the KSP folder, i get a "Detected Trojan" warning from my anti-virus(360 total security).
the Trojan name is: HEUR/QVM03.0.Malware.Gen
can you confirme this?
is it a problem with my anti-virus?
can i ignore the warning?[/QUOTE]
As an amateur virus 'expert' (not really expert) something likely attached to your download.

Try downloading it again, then running a test on it. Have you downloaded a lot, say from softonic or other 'freeware' sites?

[URL]http://blog.mitechmate.com/remove-heurqvm03-0-malware-gen-completely/[/URL]

Also, it seems that Windows 10 has been blocking non-malware as malware.

[COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

Also, I wouldn't ignore the warning. This piece of malware is very nasty.

[Zeggpold]

I'd like to copy my mod list over from my old 1.0.4 installation to the new 1.05 version. I can export the list from 1.0.4 as a ckan and try to import it using the gui in the 1.0.5 directory, but as soon as ckan sees an incompatible mod, it just stops, reporting just that mod. Is there a way to either (1) get it to ignore the incompatible ones, or (2) provide a complete list of incompatible mods (not just the first)? I tried removing the incompatible ones one by one but gave up after about five.

I also tried the readme hack to claim the version was 1.0.4, but that just gives me different mods listed as incompatible, so it doesn't help. Also, in at least one case (Astronomer's Pack), I get a message that it's incompatible, but it's available to check in the installation list, which seems odd.

[antiwesley]

So I decided to try out CKAN today, and it loads, but doesn't find my KSP folder, even when I have it installed in said folder.

My stats:

KSP updated,
current CKAN
Windows 10, latest Net 4.5 installed.

The command box opens, followed by the GUI, asking for me to select the KSP folder.
I select the correct folder, KSP_win. and "KSP_win" is not the proper folder error.
I've run it as admin, Win 7, Win 8 compatibility and normal Win 10.

Running from a command line, I can run the program, a second window will open and quickly close and nothing will display on the first window.

Thoughts?
Thanks.

[politas]

[quote name='Zeggpold']I'd like to copy my mod list over from my old 1.0.4 installation to the new 1.05 version. I can export the list from 1.0.4 as a ckan and try to import it using the gui in the 1.0.5 directory, but as soon as ckan sees an incompatible mod, it just stops, reporting just that mod. Is there a way to either (1) get it to ignore the incompatible ones, or (2) provide a complete list of incompatible mods (not just the first)? I tried removing the incompatible ones one by one but gave up after about five.

I also tried the readme hack to claim the version was 1.0.4, but that just gives me different mods listed as incompatible, so it doesn't help. Also, in at least one case (Astronomer's Pack), I get a message that it's incompatible, but it's available to check in the installation list, which seems odd.[/QUOTE]
Open your exported .ckan file in a text editor and change "depends" to "recommends", and you should be able to get just the compatible mods when you install from it.

[politas]

[quote name='steve_v']So, what's the ETA on sorting out (or just getting rid of) the mime handler installation? it's broken at [URL="https://github.com/KSP-CKAN/CKAN/issues/1510"]least[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1509"]three[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1498"]ways[/URL], and much as I'd love to use CKAN for 1.0.5, up with an application that corrupts my desktop configuration every launch I will not put.
Can't we just kill this already? It's not hard to add a file association through the provided desktop tools, for those few who will actually use this.
Aside, I'm not overly excited about ckan tampering with files it does not own (and without prompting) in general. Please leave my desktop alone so that I can use this again.[/quote]The reality of the situation is that there is a limited amount of time the small group of CKAN developers have to put in to CKAN. When a new KSP version comes out, a lot of work is needed on metadata, so work on the client slows. With KSP 1.1 expected in December, I'd be surprised if a new version of CKAN is released this year. I would suggest writing a wrapper script for CKAN that copies CKAN Handler.desktop and mimeapps.list before running CKAN, then restores the files from the copies after CKAN closes as a workaround that is much better than the ones I suggested previously.

[quote name='steve_v']As a workaround I'd like to use the command-line client, how do I change the filter from 'compatible' to 'all' on the CLI?
CKAN will not show mods that haven't been updated for 1.0.5, or allow one to install them without guessing the exact version, despite said mods being known to work... and this issue is getting rather old.[/QUOTE]I'm not sure that you can. From CKAN's perspective, installing incompatible mods is a Bad Thing. If there are mods that are known to be compatible but CKAN is not reporting them as such, why not post a list of such mods with links to evidence for each (just someone saying "I've tested it" would generally be enough) and do something helpful?

[steve_v]

[quote name='politas']From CKAN's perspective, installing incompatible mods is a Bad Thing.[/QUOTE]
I get his, I really do. But as I understand it, CKAN exists to make life easier - in this scenario it's just getting in my way, and it happens with [i]every[/i] new KSP version.
If I want to do a Bad Thing, I'll install the mod manually anyway - is it not better to have it handled by ckan, or are we operating under the assumption that Users Are Stupid and making life difficult on purpose? (something that I find [i]extremely[/i] aggravating).
IMO it'd be far better to just provide a --force option with a Big Fat Warning, the number of times this has come up speaks for itself.

Envisaged workflow:
$ ckan versions <mod>
<lists all tracked versions>
$ ckan install <incompatible version>
Not compatible, go away.
$ ckan install --force <incompatible version>
Are you sure you want to do this silly thing? [y/N]

Every package manager I have ever encountered (with one obvious exception) has a non-frustrating, documented way to override such sanity checks - take an example from apt/dpkg (for a potentially system-brickingly stupid request):
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'

Why is it such a big deal to include this in ckan?

[QUOTE]why not post a list of such mods with links to evidence for each (just someone saying "I've tested it" would generally be enough) and do something helpful?[/QUOTE]
Sure, but why not let the user override compatibility checks at own risk in the mean time?
I see no logical reason not to, and that way we can test for compatibility without having do manual installs - if it wasn't such a pain I'd be far more likely to do such testing myself.
Or are we coming back to the Users Are Stupid/CKAN Knows Best attitude? because it's been shown many times that it doesn't. :huh:
As it stands, I'm very near the point of "screw CKAN, this is no easier for me than manual installs." Why should I use (or "do something helpful" for) a [I]tool[/I] that won't do what I tell it to? Edited November 24, 2015 by steve_v

[damerell]

[quote name='steve_v']Sure, but why not let the user override compatibility checks at own risk in the mean time?[/QUOTE]

It's about ten seconds in a text editor to convince CKAN you're running a version you're not, FWIW.

[steve_v]

True, but if you mean modifying the release file, it's not a fix, it's a dirty hack to work around an obvious issue with CKAN.
If you muck with the games release file to say '1.0.4' What happens to mods that are compatible with 1.0.5 only?
How about other things that may expect that file to be correct?
So you're saying that I should screw with the rest of my install to accommodate CKANs bugs, like I have to work around it borking my desktop mime cache?

[damerell]

[quote name='steve_v']If you muck with the games release file to say '1.0.4' What happens to mods that are compatible with 1.0.5 only?[/QUOTE]

Who knows? A moment ago you wanted this so you could test mods and get their metadata updated, so presumably that wouldn't be a concern.

[QUOTE]So you're saying that I should screw with the rest of my install to accommodate CKANs bugs[/QUOTE]

No, both because the lack of a desired feature is not a bug and because I didn't say you _should_ do anything. I just observed that a user who really does know what they're doing can work around it (in less time than you've spent writing about it here, to boot.)

[politas]

[quote name='steve_v']I get his, I really do. But as I understand it, CKAN exists to make life easier - in this scenario it's just getting in my way, and it happens with [I]every[/I] new KSP version.[/quote]
This is really only an issue for a small group of users, those that install a fresh copy of KSP with every version who also use CKAN. Users running Steam get their KSP updated in-place, and CKAN doesn't uninstall their potentially-broken mods. Of the two situations, I think that is a bigger potential problem for CKAN developers to work on than yours.

[quote name='steve_v']If I want to do a Bad Thing, I'll install the mod manually anyway - is it not better to have it handled by ckan, or are we operating under the assumption that Users Are Stupid and making life difficult on purpose? (something that I find [I]extremely[/I] aggravating).
IMO it'd be far better to just provide a --force option with a Big Fat Warning, the number of times this has come up speaks for itself.[/quote]Well, I would counter that the best thing for clever users like you is for this sequence to happen:
* Install desired mods manually
* check that they work
* Report functionality of mods to the mod author's contact option (forum thread, home page, whatever)
* Report functionality of mod to this thread (or by raising an issue on the CKAN Github)
Then, a CKAN contributor (which there is very little preventing you from becoming) does:
* Edit the .netkan file to change the KSP Max Version field.
Then you can manually remove the mod and re-add it through CKAN, with the benefit for all other CKAN users that they can now easily use CKAN to do it.

You doing a --force option to avoid the metadata update is the selfish alternative.

Now, I don't know whether a decision has been made to not include a --force option in order to encourage this cooperative workflow, or whether it is just something that they haven't gotten around to.

Either way, you have two options. You can continue to complain about things not working the way you want them to, or you can be helpful and make CKAN work better for all the users, either by testing, metadata editing, or even contributing code to add a --force option if you really, really want that option.

If you had simply started by providing a list of the mods that you know work and need to be updated, I could have submitted changes by now. Instead, I'm spending my limited time responding to your complaints.