ModStatistics 1.0.3 - Anonymous mod usage statistics - Now for public distribution!

[Majiir]

ModStatistics

(Looking for the website? Statistics are available at: http://stats.majiir.net/)

This plugin compiles anonymous mod usage statistics and submits them to a server for analysis. The goal of this project is to provide players and modders with accurate usage data. The plugin is designed to be distributed with other mods in order to improve accuracy. You can also download it as an individual user to contribute data.

-------------------------------------------------------------------------

Download ModStatistics 1.0.3 (Link removed)

Last updated July 17, 2014 (KSP 0.24.0) (release notes)

Source code

License: You may redistribute unmodified versions of ModStatistics. All other rights are reserved.

-------------------------------------------------------------------------

NOTE: This plugin sends information to the server at stats.majiir.net. There is an opt-out mechanism (see the FAQ below) which disables all logging and reporting functions. No personal information is collected, and the plugin does not access any information outside of KSP.

-------------------------------------------------------------------------

Mods distributing ModStatistics:

[TABLE]

[TR]

[TD]

• Ferram Aerospace Research
  
• Kerbal Isp Difficulty Scaler
  
• Kerbal Joint Reinforcement
  

[/TD]

[TD]

• Kethane
  
• Neophyte's Elementary Aerodynamics Replacement
  
• SCANsat (dev release)
  

[/TD]

[/TR]

[/TABLE]

-------------------------------------------------------------------------

Distribution Instructions

Both part- and plugin-based mods can include ModStatistics. If you are a mod author, please consider including ModStatistics with your mod to increase the accuracy and coverage of statistics. Keep the following in mind:

• The plugin detects other copies of itself and only runs the latest version it finds. It also manages its own directory structure, so you should not place it in GameData/ModStatistics within your download. Instead, place it in your own mod's folder (e.g. GameData/YourMod/ModStatistics/ModStatistics.dll). This ensures your mod is properly detected, even if it is a pluginless mod.
  
• You should inform your users (e.g. in your thread's first post) that ModStatistics has been included. BBcode snippet:
  

  [noparse]NOTE: This mod includes [url=http://forum.kerbalspaceprogram.com/threads/81764-ModStatistics]ModStatistics[/url], an anonymous mod usage statistics plugin. See the ModStatistics thread for more information and opt-out instructions.[/noparse]

  
  

• The download includes two DLLs, ModStatistics.dll and JsonFx.dll. Both are required. The file names are not important, but you shouldn't need to rename them. The second DLL is JsonFx, an open-source library for parsing and generating JSON strings. It's used to communicate with the statistics server.
  

-------------------------------------------------------------------------

Frequently Asked Questions

How do I opt out?

If the file GameData/ModStatistics/settings.cfg contains a line with "disabled = true" the plugin will cease all recording and reporting functions. This file is created on start-up, and it also contains instructions on how to opt out. Note: You may remove all the ModStatistics DLLs, but do not remove the settings.cfg file if you wish to stay opted out.

What gets collected?

• Session start/end time
  
• Whether the session ended in a crash (but no crash details)
  
• KSP version
  
• ModStatistics internal version
  
• Total time spent in each scene (main menu, tracking station, etc)
  
• List of plugins detected and their versions
  

Where is the data sent?

I'm operating the statistics server at stats.majiir.net. Some summary statistics are viewable at that address. Improvements to the website are coming next.

Does this collect personal information?

No. Only information from within KSP is collected, and care has been taken to ensure no other information is sent, and that none of the information collected could be personally identifying.

Why is this opt-out instead of opt-in?

Opt-in schemes tend to result in low participation rates. I have taken care to not collect any personal or identifiable information, and there is an easy opt-out system in place for those who still wish to not participate.

When are statistics sent?

The plugin generates reports when the game closes and saves them to disk. The next time the game starts, it attempts to send any outstanding reports to the server. If reports could not be sent (e.g. because of a server error or no Internet connection) they are saved until they can be sent another time.

What are mod usage statistics good for?

As a developer, it's difficult to determine how many people use your mod, let alone what other mods they use it with. Even a simple set of statistics like this gives modders insight which aides in development-related decisions. This data also helps identify issues with crashes, load times and update rates.

Who should use this mod?

ModStatistics is primarily intended for modders to package with their own mods. You may also install it as an individual.

What happens if multiple mods come with ModStatistics? How are version conflicts handled?

The plugin is built on the same core as CompatibilityChecker. If multiple versions are present, they will negotiate amongst themselves, and only the latest version will execute. It is therefore suggested that modders distribute ModStatistics in their own mod directories, not in the GameData root.

Edited September 4, 2014 by diomedea
removed DL link, not compliant with add-on posting rules

[Yilmas]

Seems like an honest idea, though I would really love it if you were (at some point) able to build a common framework through the website for issue tracking...

So that user would be able to see not only the popularity but also the frequency of updates and the risk of failure.

I'm well aware that you have currently signed it off as non-viewable by the common the user, but I still believe something like this could be very helpful to not only the end-user but also the modders. Especially anyone that wants to go over the border between stock to modded.

[Justin Kerbice]

One question not in FAQ: how do the plug-in accurately recognize a mod ?

If a "mod" is just a parts set lie in GD: KPS/GD/somepart, and the folder name is not related to the mod itself (/GD/afunnyname)

For the slow submission: why not split the job in two part: one plug-in which count and do the maths, a separated program which do the sending (not writing in C# and/or not using KSP/Unity things which make it slow and prevent KSP from closing), it makes use of HTTPS protocol easier also.

[Majiir]

Seems like an honest idea, though I would really love it if you were (at some point) able to build a common framework through the website for issue tracking...

So that user would be able to see not only the popularity but also the frequency of updates and the risk of failure.

I'd like to build a website for analyzing statistics. That said, I'm not sure what you mean by "issue tracking" in this context. How would the tool compute the risk of failure?

One question not in FAQ: how do the plug-in accurately recognize a mod ? If a "mod" is just a parts set lie in GD: KPS/GD/somepart, and the folder name is not related to the mod itself (/GD/afunnyname)

It only reports plugins. To be precise, it reports assemblies as listed by KSP's AssemblyManager. Since KSP has no concept of a "mod" it would be difficult to report on non-plugin mods without risking privacy leaks. An alternative I'm considering for a future version is to allow part-only mods to include a config file that ModStatistics can read and include with the report.

For the slow submission: why not split the job in two part: one plug-in which count and do the maths, a separated program which do the sending (not writing in C# and/or not using KSP/Unity things which make it slow and prevent KSP from closing), it makes use of HTTPS protocol easier also.

A separate program kills usability; right now, it's completely automatic, and I can't see a viable system working any other way.

[Yilmas]

I'd like to build a website for analyzing statistics. That said, I'm not sure what you mean by "issue tracking" in this context. How would the tool compute the risk of failure?

First, when ever a user needs to report an issue, they first need to locate the mods forum thread, which is really annoying to do with the way searching functions here on the forums, after which some writes it in the forum while others goes the next step and puts them on the github, again having to spend time to find it. And in this process a lot of issues are lost because of the complexity or rather the time needed to report such an issue can become a long one.

Second, if a mod contains many unsolved issues combined with no recent updates the user will become aware of its inactivity and may be persuaded to think twice before installing (and submitting yet another issue for something that already is submitted by others, wasting more time.) Though this can also work in the advantage of old mods, if it has no clear signs of issues, even if it is outdated, users might wonder "Does it still work" and try it out.

As far as I'm aware of, Github contains an API which you can use to embed the issue tracker of a certain project.

An alternative I'm considering for a future version is to allow part-only mods to include a config file that ModStatistics can read and include with the report.

Generally, I would really love it if Squad would go out and make it a requirement for ANY mod that goes in the GameData folder to include a settings.cfg, which includes basic information about the mod. ie, name, version, forum link, license and so on..

[Justin Kerbice]

A separate program kills usability; right now, it's completely automatic, and I can't see a viable system working any other way.

It's depend on what you can do and what you want to do (generally speaking).

On Unix* systems, a script can be scheduled each day/week/month to read files, aggregate them, and send data, then dispose the files (can be run at night if computer is 24/7 up).

On windows system, you can add a shortcut or something (a little batch script) which launch KSP, wait it to end, then launch the second program. Or use also the scheduler way but windows is windows .

On macos... mmm...

It only reports plugins. To be precise, it reports assemblies as listed by KSP's AssemblyManager. Since KSP has no concept of a "mod" it would be difficult to report on non-plugin mods without risking privacy leaks. An alternative I'm considering for a future version is to allow part-only mods to include a config file that ModStatistics can read and include with the report.

ok.

Why not reading GameData contents and at least get folders'names, matching them with an internal list (I understand what you means here by privacy leaks), it may depend of list and matching implementation as list/tree in KSP tend to become slow to process (big craft, big number of crafts in a folder, having more than ~10 saves for example)

Edited June 2, 2014 by Justin Kerbice

[Faark]

Interesting. DL stats are nice, but usage statistics ofc a lot better! How are reports intended to be? Mod devs contact you and get access to only their own mod stats? Or public stats? I wonder whether some mod authors would have a problem with that.

The other day I was about to pm you about a concept of a mod that gathers error reports, since it is ultra annoying getting error reports from users where other mods spam exceptions all over the place, but wanted to sleep about it hadn't yet found the time to finish it.

Hey Majir,

do you still have spare server resources? What about an error reporting service for KSP (mods)? Its kinda annoying to get error reports with thousands of exceptions caused by other mods you have to ignore just to find the one line that's related to the actual problem the player is complaining about. I did something similar for a now dead javascript project some years ago and think it really helped to improve the quality of that code.

A first concept could look like:

- user downloads a separate error reporting mod for KSP to install in GameData

- mod downloads a white list every few days for known or unfix-able errors, e.g. those caused by KSP itself

- mod hooks into KSPs / mono's error handling and collects info

- if there are exceptions or warnings to report user gets a "issues found, click to report" button.

-- can or will contain additional info (full output_log, installed file info or whatever)

-- can review submitted info

-- can add additional comments

-- screenshot?

-- gets a report id once submitted that he give to devs

- user can submit a report without exceptions but comment in case he experiences issues. Thus no need to manually collect and upload it

- report can be shared and viewed online via its unique, randomly generated report id

- reports have to forwarded to the developer of the respective mod causing it and might be white-listed, at least for some time

- once the developer thinks he has resolved the issue reports and ignore logic can be deleted. Also old reports automatically, ofc.

- if it identifies mod, it can probably even list recently added mods...

- since its a separate "you have to install this" mod, the initial user-base and thus initial workload for the maintain should be manageable. Especially since he doesn't have to fix the actual errors himself^^

- privacy shouldn't be a concern since the user has to install this mod manually and manually submit reports

Problems i see so far:

- old mod versions. Version checks would be great but don't see a good way to do this right now. Maybe such a project would help in that regard

- its a manual system. i don't see a good way to automatically distribute reports, at least

- abuse. I don't see a lot of incentive to abuse this system above any other, but still it would be a [specialized] file upload service.

So what do you think? Is something like this worth your support/server resources?

Regards,

Faark aka [..]

Do you think this statistics mod could one day be expanded to include sth like this? Both tasks share at least the requirement to identify installed mods. And error info could be way more useful when refined with usage info, so they might rly benefit each other. But ofc would make the mod way more complicated, possibly even shifting the focus of this project to it wasn't supposed to be or sth you just don't want for this project. Do you think it could be worth expanding this mod to also log errors?

[Majiir]

How are reports intended to be? Mod devs contact you and get access to only their own mod stats? Or public stats? I wonder whether some mod authors would have a problem with that.

Stats are private while the plugin is still in beta, and they will be public thereafter. Some things need to be filtered out from the public view. (For example, stats from the experimental team.)

[EDIT] I should note that the more activity the beta sees, the sooner I'll feel comfortable releasing it. So far, the server has seen no reports!

The other day I was about to pm you about a concept of a mod that gathers error reports, since it is ultra annoying getting error reports from users where other mods spam exceptions all over the place, but wanted to sleep about it hadn't yet found the time to finish it.

Hey Majir,

do you still have spare server resources? What about an error reporting service for KSP (mods)? Its kinda annoying to get error reports with thousands of exceptions caused by other mods you have to ignore just to find the one line that's related to the actual problem the player is complaining about. I did something similar for a now dead javascript project some years ago and think it really helped to improve the quality of that code.

A first concept could look like:

- user downloads a separate error reporting mod for KSP to install in GameData

- mod downloads a white list every few days for known or unfix-able errors, e.g. those caused by KSP itself

- mod hooks into KSPs / mono's error handling and collects info

- if there are exceptions or warnings to report user gets a "issues found, click to report" button.

-- can or will contain additional info (full output_log, installed file info or whatever)

-- can review submitted info

-- can add additional comments

-- screenshot?

-- gets a report id once submitted that he give to devs

- user can submit a report without exceptions but comment in case he experiences issues. Thus no need to manually collect and upload it

- report can be shared and viewed online via its unique, randomly generated report id

- reports have to forwarded to the developer of the respective mod causing it and might be white-listed, at least for some time

- once the developer thinks he has resolved the issue reports and ignore logic can be deleted. Also old reports automatically, ofc.

- if it identifies mod, it can probably even list recently added mods...

- since its a separate "you have to install this" mod, the initial user-base and thus initial workload for the maintain should be manageable. Especially since he doesn't have to fix the actual errors himself^^

- privacy shouldn't be a concern since the user has to install this mod manually and manually submit reports

Problems i see so far:

- old mod versions. Version checks would be great but don't see a good way to do this right now. Maybe such a project would help in that regard

- its a manual system. i don't see a good way to automatically distribute reports, at least

- abuse. I don't see a lot of incentive to abuse this system above any other, but still it would be a [specialized] file upload service.

So what do you think? Is something like this worth your support/server resources?

Regards,

Faark aka [..]

Do you think this statistics mod could one day be expanded to include sth like this? Both tasks share at least the requirement to identify installed mods. And error info could be way more useful when refined with usage info, so they might rly benefit each other. But ofc would make the mod way more complicated, possibly even shifting the focus of this project to it wasn't supposed to be or sth you just don't want for this project. Do you think it could be worth expanding this mod to also log errors?

A few people have suggested that this tool include error reporting, and your proposal is by far the most detailed. I will say it is definitely outside the scope of this project, and it introduces a number of privacy issues. ("Error encountered in C:\Users\<real name>\KSP\...") It would be neat to have a tool that collects logs and other diagnostic information and compiles it into a single report for a modder to view; but that is not this tool. There's nothing fancy about listing installed plugins, so someone else could certainly start working on an error reporting project.

Edited June 2, 2014 by Majiir

[codepoet]

So is your suggestion that other modders include this dll in their mod, and it then reports on all mods installed on that system? Presumably then you only need adoption by a handful of popular mods (which you likely are already working closesly with ), and you would be able to report on the majority of the userbase.

[Ippo]

You should have received my report, it was sent just a moment ago.

Btw, I had never realized I had 40 assemblies loaded... I'm starting to think that in reality I don't really like KSP at all.

[Majiir]

So is your suggestion that other modders include this dll in their mod, and it then reports on all mods installed on that system? Presumably then you only need adoption by a handful of popular mods (which you likely are already working closesly with ), and you would be able to report on the majority of the userbase.

That's the idea. For a mod to ensure its entire user base is covered, it will need to include ModStatistics, so I'm hoping that's incentive enough for it to see a lot of use. I'm planning on including it with Kethane and KAS, so there will be a good base to start with.

You should have received my report, it was sent just a moment ago.

Btw, I had never realized I had 40 assemblies loaded... I'm starting to think that in reality I don't really like KSP at all.

Yep, got yours and someone else's as well. These are much bigger than my own test report (where I had just Kethane and KAS installed). I'm working on server-side parsing now, so I'll be taking a look at these to see if there's anything obvious that needs to be filtered. Cheers!

(By the way, someone spent 3 minutes, 8 seconds at the loading screen!)

[Ippo]

EDIT: I was *****ing about something that was totally my fault for not reading carefully what I was agreeing to and was clearly written in the first post.

Sorry.

Edited June 2, 2014 by Ippo

[xEvilReeperx]

A few people have suggested that this tool include error reporting, and your proposal is by far the most detailed. I will say it is definitely outside the scope of this project, and it introduces a number of privacy issues.

It's only an ego tool, then. If it isn't designed to help improve the user's experience and it doesn't help modders improve their mods, there's really no reason for anybody to include it with their distributions.

[Justin Kerbice]

It's only an ego tool, then. If it isn't designed to help improve the user's experience and it doesn't help modders improve their mods, there's really no reason for anybody to include it with their distributions.

Good point IMHO, and a bad thing to original concept, here is an example:

I have installed Kethane (took on purpose ), NovaPunch, Spaceplane+, modA, mod B, mod C, mod Z

I play only with the brand new mod A which is awesome, but my play time will be counted on all mods, right ?

So after spending 1000h with this mod A, 1000 h will be added to all mods ?

What if I use a single Kethane tank with stock part for a long range mission ? All mods gets time ?

Or you get only all parts use on the current vessel (tricky when it comes to docking with a vessel containing other parts) ?

[codepoet]

It's only an ego tool, then. If it isn't designed to help improve the user's experience and it doesn't help modders improve their mods, there's really no reason for anybody to include it with their distributions.

I think it is of general interest to the modding community to see how people run their KSP install. How many mods do people use, which ones are most often used together etc. I would be interested to know how many users that use mods I work on, are using another mod that it might integrate with, to assess the potential userbase.

[Ippo]

Also, I can kinda see the point of knowing the user-base of each mod: let's say that I want my mod to integrate into a life support mod... which one should I target? Do I do TACLS or IonCross first? Is it worth my time to support that other mod I really like, but has no active users?

Stuff like that.

[xEvilReeperx]

I think it is of general interest to the modding community to see how people run their KSP install. How many mods do people use, which ones are most often used together etc. I would be interested to know how many users that use mods I work on, are using another mod that it might integrate with, to assess the potential userbase.

Assess how? With no error reporting, all you'd be able to tell for certain is that your mod likely works with certain other mods because your user didn't uninstall it due to a conflict. That doesn't help you write better mods. That helps you pander to a larger download count. That only matters if you're the type that wanders around bragging about download counts

Also, I can kinda see the point of knowing the user-base of each mod: let's say that I want my mod to integrate into a life support mod... which one should I target? Do I do TACLS or IonCross first? Is it worth my time to support that other mod I really like, but has no active users?

It might be handy, but is that a reason to distribute this statistics plugin with your own mod? If it's going to be included in Kethane and KAS, surely that'll be a plenty large enough sample? There's no incentive for you to distribute it yourself and you don't have to worry about users who might complain about being what is at this point a plugin specifically designed to spy on their installations

[JewelShisen]

I think it is of general interest to the modding community to see how people run their KSP install. How many mods do people use, which ones are most often used together etc. I would be interested to know how many users that use mods I work on, are using another mod that it might integrate with, to assess the potential userbase.

I agree with you. I would like knowing what my users also use so that I can better design the mod. If I know that 90% of my user base uses FAR then it helps me know that I should look into making/improving the usage with FAR.

[JewelShisen]

Assess how? With no error reporting, all you'd be able to tell for certain is that your mod likely works with certain other mods because your user didn't uninstall it due to a conflict. That doesn't help you write better mods. That helps you pander to a larger download count. That only matters if you're the type that wanders around bragging about download counts

Ok I am going to butt in here and give you an example of where you are potentially wrong. I run the Hooligan Labs Airships mod and I know for a fact that it doesn't work well with FAR, due to bulky parts and just general FAR not liking things with such large size and low mass. However that is no reason to redo the entire model base if I am the only one combining them. But if 90% of my users have FAR and HL Airships installed then that gives me a large incentive. That is where this mod would be useful.

[Majiir]

EDIT: I was *****ing about something that was totally my fault for not reading carefully what I was agreeing to and was clearly written in the first post.

Heh, it's just a little freaky because the number is precise. There isn't actually much information; it doesn't even track scene switches, just total time spent at each. (Although that could change, if someone can articulate its use.)

What if I use a single Kethane tank with stock part for a long range mission ? All mods gets time ? Or you get only all parts use on the current vessel (tricky when it comes to docking with a vessel containing other parts) ?

The idea is mainly to see how many people are using a mod each day, and which mods go togetherâ€â€and which don't. It would be neat to track actual mod usage down the road, but it varies with each mod. Part-oriented mods might care whether you include the part on your vessel, but something like Kerbal Alarm Clock cares more about other usage. I might include something like statistics extensions in the future so mods can define their own reporting data, but that raises additional concerns I'd rather not worry about right now.

Assess how? With no error reporting, all you'd be able to tell for certain is that your mod likely works with certain other mods because your user didn't uninstall it due to a conflict. That doesn't help you write better mods.

This mod isn't about quality control; there are other mechanisms for that. That said, statistics can play a role. Suppose you have a lot of bugs and you're fixing them at a constant rate, but you're not sure how often to release an update. It's annoying for users when they have to update, and more versions in the wild makes false bug reports more common. On the other hand, you don't want to make users wait around for your fixes. How do you strike the right balance? It would be great to have statistics to see how quickly your users notice when you release a new version. Maybe that rate is different right after a KSP update. Maybe it's faster on weekends. Right now, we have no idea, and that lack of knowledge is what prompted me to write this plugin.

Now consider that you might be thinking about an update that breaks compatibility with a certain mod. Do your users have that other mod installed? Maybe you currently have optional Toolbar support in your mod, and you're thinking of making it mandatory. How many of your users use Toolbar? You want to add more parts, but you might push people over their memory limit. Do your users tend to have lots of memory-hungry mods installed? How many? Which mods? You can start to get a very good picture of the environment your code is running in with data like this. And let's not forget: we can make guesses about what kind of data we'll see, but inevitably data reveals surprises, things nobody had thought of.

I'm not sure why you're so quick to condemn ego. You don't think that plays any part in modders' motivation to program for free? I use download statistics to estimate my user base, and I put that on my resume. In interviews, I'm asked where I got that number. It would be great if, instead of saying I pulled it from my server logs, I could say I wrote a statistics engine that counted active users. I do a lot for the KSP community, and the least it can do for me is tell me how many people use my mods.

It might be handy, but is that a reason to distribute this statistics plugin with your own mod? If it's going to be included in Kethane and KAS, surely that'll be a plenty large enough sample? There's no incentive for you to distribute it yourself and you don't have to worry about users who might complain

There are incentives in both directions. Consider this: If it's only distributed with Kethane and KAS, then 100% of those mods' users will participate, but maybe only 20% of MechJeb users and 10% of Interstellar users. Those mods are thus underrepresented. If you want accurate stats for your mod, you'll need to include the statistics plugin, because there's always the chance someone uses your mod and doesn't use Kethane or KAS. Ego is a useful tool here: If the statistics say Kethane is fifty times more popular than Interstellar, that might prompt Fractal to include ModStatistics so he can improve that stat. There are all kinds of reasons to want accurate statistics, so I'd say there's plenty of incentive to redistribute the plugin. The only incentive against is possible fallout with your users, but it's easy to opt out of. It's also been designed so that even if you install multiple mods with ModStatistics, you only have to opt out once, in one place. Even if every KSP mod includes ModStatistics, it's no more onerous to the user.

Besides all that, I must ask: What data is being collected that you're uncomfortable with?

[xEvilReeperx]

But if 90% of my users have FAR and HL Airships installed then that gives me a large incentive. That is where this mod would be useful.

It would work exactly the opposite the way you think. If 90% of your users were having problems with your mod, most of them will uninstall it and you'll just see an apparently small percentage of people that use your mod with FAR leading you to the wrong conclusion: not many people use my mod with FAR, therefore it's not a big issue.

You'll hopefully be reading bug reports and comments you get from your users but if you used the statistics to determine how widespread the bug is as you say, it might lead you to the wrong conclusion again.

[JewelShisen]

It would work exactly the opposite the way you think. If 90% of your users were having problems with your mod, most of them will uninstall it and you'll just see an apparently small percentage of people that use your mod with FAR leading you to the wrong conclusion: not many people use my mod with FAR, therefore it's not a big issue.

You'll hopefully be reading bug reports and comments you get from your users but if you used the statistics to determine how widespread the bug is as you say, it might lead you to the wrong conclusion again.

No it won't. If I used this I would get the mod lists from even just that one time it was run, allowing me to see the common link among them all. And if players don't want to have my mod installed then that is there choice and it won't skew the stats either way.

I am with Majir on this one. Some stats are better than nothing. That is part of why I supported the shift to CurseForge, so I can get download stats and see how large my user base roughly is at a glance.

[B4rberblacksheep]

I have to say this seems like an incredible idea that I'm honestly astonished hasn't been engaged before!

And I have to say if there's a way of publicly releasing the statistics (not sure about the legality in terms of privacy there) that would be incredible, will start making this the first thing I install, even if it's just to see how high I can make the numbers go >

[xEvilReeperx]

If I used this I would get the mod lists from even just that one time it was run, allowing me to see the common link among them all.

How do you figure? No personal information is collected (and if it is, this could arguably be called spyware) so you couldn't filter out one-time reports. With all the reports being mixed together it would look like people getting tired of your mod as it decreased day by day, not a serious gamebreaking error that you'd missed that's causing users to rage-delete your mod folder after it crashes KSP

The only incentive against is possible fallout with your users, but it's easy to opt out of.

I can picture a twinkle in your eye as you write that. We both know the average user.

How do you strike the right balance? It would be great to have statistics to see how quickly your users notice when you release a new version. Maybe that rate is different right after a KSP update. Maybe it's faster on weekends. Right now, we have no idea, and that lack of knowledge is what prompted me to write this plugin.

Download tracking can and does get you this information, if you have an accurate counter. Writing a plugin like this but saying that the most obvious, useful function that plugin could do is somehow not in its scope is silly and makes the real reason obvious.

My opinion is that you need to consider some way to make it useful to the user. If it were me, I'd add a button somewhere logical (options?) that lets a user type an anonymous short message with some tags and an option to attach their compress verbose game log (personally identifying info stripped out). That would make it very useful for every modder everywhere and users wouldn't have to go searching for correct log files or posting the wrong ones and so on. That would make this a slam dunk

[JewelShisen]

How do you figure? No personal information is collected (and if it is, this could arguably be called spyware) so you couldn't filter out one-time reports. With all the reports being mixed together it would look like people getting tired of your mod as it decreased day by day, not a serious gamebreaking error that you'd missed that's causing users to rage-delete your mod folder after it crashes KSP

Because as it is designed now, the plugin sends the info each time KSP closes. Also no personal info is ever needed or collected.