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

[Hadlock]

What's next? An opt-out mod that will mine bitcoins and send them back to the mod author while you're in time acceleration?

Opt-out is always bad for the user, this is a terrible policy. Please stop destroying the mod community of KSP, this is a bad idea.

[klyith]

Perhaps the place should be on first ksp startup? It seems to me that most users will not have read this thread if somewhere in the future they load up a mod that includes your software.

It should be possible for you to cause a popup right? And that way you've solved all ethical issues.

This. You can save that information, it would not be difficult. And the default should be that no information is collected without the user saying yes. A data collection plugin should be surfaced to average users, not just the ones who read forums and license files.

I'm not against your concept, though I'm pretty ambivalent about it being a 3rd party initiative rather than an official Squad thing. But you really should not be doing it opt-out and silently.

[sumghai]

Look interesting, but I'm still a bit confused by the whole deal.

I'm an add-on author who mainly authors part packs, but it seems the current version only supports plugins, so I'm not sure how I would get ModStatistics to track usage of said packs...?

(ASIDE: Apparently, FusTek is only used by 8 people, and SDHI is not listed)

[Ippo]

1) ModStatistics is the most used mod of all! (... obviously: maybe it makes sense to hide it?)

2) Why are the correlation data hidden? I remember I could see the correlation for each mod some days ago, now I can't anymore. Did I miss something?

3) How's the correlation computed anyway?

4) Honestly, I really believe this should be either opt-in or have the popup on the first run. I know that you already answered to this point, but well, just my 2 cents. The average user won't bother reading the license, and I can see many users that will literally lack the skills to opt-out.

All in all, I'm not against the general idea, but as it is right now many users will submit data without knowing and I don't think it's fair.

[Nereid]

4) Honestly, I really believe this should be either opt-in or have the popup on the first run. I know that you already answered to this point, but well, just my 2 cents. The average user won't bother reading the license, and I can see many users that will literally lack the skills to opt-out.

All in all, I'm not against the general idea, but as it is right now many users will submit data without knowing and I don't think it's fair.

I agree. And I will surely not use it until it has an opt-in scheme.

[DMagic]

SCANsat will be including this in future updates (though I'm not sure exactly which update will begin to include it). I'm also considering including it with DMagic Orbital Science.

I think a popup similar to the one Squad uses when you first run KSP is a good idea.

[Justin Kerbice]

Don't remember what the 1st time pop-up on KSP was but I think IMHO something like:

"blah blah blah, do you really want to enable it ?" Y/N, if N => cfg updated with disabled, for ALL modstatistics (just say it, I know only one run and take over the others).

Unfortunately, names are not precise enough, like Goodspeed (tweakscale + pump plugins), for plug-in, library's name should be use (without the extension), for parts... very very hard to impossible .

Impossible because we can make as much as mess as we want, as long as we do it with KSP directory structure respect.

For my parts, all are under one single name, and various parts set are not easy to identify, example:

my AMUG/AMEG parts are in Kerbice Group\Parts\Utility\AMEG_and_AMUG

the plane parts I'm working on are in Kerbice Group\Parts\Plane (but split in various set: inline air intakes, mk2 misc parts, nose cones and mk2 engines)

Unless I give a little help to modstatistics, it won't be able to sort it out by itself.

[Majiir]

A data collection plugin should be surfaced to average users

I'd like to point out it's difficult to know what "average" is without data.

I'm an add-on author who mainly authors part packs, but it seems the current version only supports plugins, so I'm not sure how I would get ModStatistics to track usage of said packs...?

Drop ModStatistics in your mod's folder. It will report that there's a plugin with a path like GameData/YourMod/ModStatistics/ModStatistics.dll. The server will filter out the ModStatistics part and figure it's named YourMod. There may be future improvements to better identify parts, but it should work for now.

(ASIDE: Apparently, FusTek is only used by 8 people, and SDHI is not listed)

The data is quite skewed at the moment. I don't know of any mods aside from Kethane that have distributed the plugin.

ModStatistics is the most used mod of all! (... obviously: maybe it makes sense to hide it?)

I might include a little note explaining that this doesn't really mean anything, but I'd like to keep it visible because it provides a baseline.

2) Why are the correlation data hidden? I remember I could see the correlation for each mod some days ago, now I can't anymore. Did I miss something?

3) How's the correlation computed anyway?

It was bugged, so those pages weren't useful. I need to rewrite a few queries to support the larger volume of reports coming in, so the analysis might stay as-is for a few days.

Unfortunately, names are not precise enough, like Goodspeed (tweakscale + pump plugins), for plug-in, library's name should be use (without the extension), for parts... very very hard to impossible .

Impossible because we can make as much as mess as we want, as long as we do it with KSP directory structure respect.

For my parts, all are under one single name, and various parts set are not easy to identify, example:

my AMUG/AMEG parts are in Kerbice Group\Parts\Utility\AMEG_and_AMUG

the plane parts I'm working on are in Kerbice Group\Parts\Plane (but split in various set: inline air intakes, mk2 misc parts, nose cones and mk2 engines)

Unless I give a little help to modstatistics, it won't be able to sort it out by itself.

There comes a point where authors need to pick sane naming schemes. ModStatistics can handle GameData paths like /Author/Mod/Plugin.dll, /Author/Mod/Plugins/Plugin.dll, /Mod/Plugin.dll, /Mod/Plugins/Plugin.dll, /Plugin.dll, and maybe a few others. It can't handle Mod/Author/Plugin.dll (because that makes no sense). For what you described, it would decide the mods are named "Utility" and "Parts" but you've picked a very unusual way of structuring things. Even /Author/Mod/Plugins can be hard to detect because the server needs knowledge of at least two mods from the same author to work out that the author isn't the name of the mod.

[sumghai]

I'm an add-on author who mainly authors part packs, but it seems the current version only supports plugins, so I'm not sure how I would get ModStatistics to track usage of said packs...?

Drop ModStatistics in your mod's folder. It will report that there's a plugin with a path like GameData/YourMod/ModStatistics/ModStatistics.dll. The server will filter out the ModStatistics part and figure it's named YourMod. There may be future improvements to better identify parts, but it should work for now.

I see!

Just reading up on what you've mentioned to Justin Kerbice, it sounds like certain folder structures may cause problems. Of the add-ons I've authored, I have as their respective top-level folders:

GameData/FusTek/Station Parts/

GameData/SDHI/Service Module System/

This is because one day I want to also do GameData/FusTek/MSEV/and GameData/SDHI/Payload Farings/

So assuming I have the following:

GameData/FusTek/Station Parts/ModStatistics/ModStatistics.dll

GameData/FusTek/MSEV/ModStatistics/ModStatistics.dll

GameData/SDHI/Service Module System/ModStatistics/ModStatistics.dll

GameData/SDHI/Payload Farings/ModStatistics/ModStatistics.dll

Would all four part pack add-ons be tracked properly as separate listings?

[Majiir]

ModStatistics 1.0.2 has been released. The download link in the first post has been updated.

This update has further fixes based on feedback in this thread and elsewhere. I've also included the changelog for 1.0.1, since I never got around to updating the thread with that download. This update has been pushed through the auto-updater, so it's not strictly necessary to update the version packaged with your mods.

Changes in this version:

• At startup, the user is prompted for their auto-update preference.
  
• 64-bit KSP is now detected and reported.
  
• Mac OSX is now correctly detected.
  
• Fixed output log spam when some assemblies couldn't be read properly.

Changes in 1.0.1:

• Platform type (Windows, Linux, etc.) is now reported.
  
• Fixed a critical issue which caused most reports to fail with an error.
  
• Fixed an issue where the user agent wasn't properly set.

[Justin Kerbice]

There comes a point where authors need to pick sane naming schemes. ModStatistics can handle GameData paths like /Author/Mod/Plugin.dll, /Author/Mod/Plugins/Plugin.dll, /Mod/Plugin.dll, /Mod/Plugins/Plugin.dll, /Plugin.dll, and maybe a few others. It can't handle Mod/Author/Plugin.dll (because that makes no sense). For what you described, it would decide the mods are named "Utility" and "Parts" but you've picked a very unusual way of structuring things. Even /Author/Mod/Plugins can be hard to detect because the server needs knowledge of at least two mods from the same author to work out that the author isn't the name of the mod.

I see.

But IMHO, if you want modders to use your plug-ins, which is its only goal, you have to manage all "features" KSP allow, even if it doesn't make any sense at all.

Remember the talks about versioning thing, some modders would have some stats about their work but if it means to them to do too much drastic changes (words are relative here , but changing directory structure can be understood as "too much work for too few returns" and not done).

I think a config file is the best way, because no code, no matter how smart it is, even HAL9000 , can link files to part sets on the case I told about before.

It can be as simple as:

modABC=/my dir/modABC

to

modXYZ=/my dir/parts/structural/A,/my dir/parts/utility/B,/my dir/parts/engines/partA*

or any other way to name the parts themselves if needed (wildcards + list)

Such config file could also be auto-build by small script (python for ex) used on release directory.

[Drew Kerman]

Hrm, somehow I've ended up with a ModStatistics folder in my main /GameData directory and a ModStatistics folder inside /GameData/Kethane

which one should I keep?

[Majiir]

Hrm, somehow I've ended up with a ModStatistics folder in my main /GameData directory and a ModStatistics folder inside /GameData/Kethane

which one should I keep?

This is normal, and it will work fine with both. If you want, you can safely remove the one in the Kethane folder.

[Drew Kerman]

ah, no bother then. Good to know

[Unto the Cruel]

What other mods are making use of this tracker, or plan to?

Edited June 15, 2014 by Unto the Cruel

[Woodstar]

Sorry wrong thread.

Edited June 16, 2014 by Woodstar

[Ippo]

What other mods are making use of this tracker, or plan to?

My mod is still way unfinished, so it's a premature talk for me: however, I decided that I will not include it in the download, but I will still reserve a paragraph in the post to redirect here so that my users can choose to participate if they want to.

[DMagic]

A new SCANsat update has been released with this mod: http://forum.kerbalspaceprogram.com/threads/80661-Jun-11-DEV-SCANsat-v7-0rc2-3-Real-Scanning-Real-Science-at-Warp-Speed%21?p=1217732&viewfull=1#post1217732

[Donziboy2]

Now if it would only tell me which mod is creating a huge memory leak which once it gets to around 3GB the game starts screwing up craft when I go to them (usually making them unflyable as they get NaNed to death). It has not crashed since it renders craft unplayable before it overflows...

[Ippo]

Hi Majir, I'm here to bother you once more.

Would you mind a quick status report? The mod listing has been disabled for a couple of days now, I'm getting curious.

Is it anything we can help with?

[Paul Kingtiger]

This looks very interesting, any plans to include an opt out button on the loading "you have recently installed..." UI?

An in-game opt out option might make privacy people a little more comfortable.

[Unto the Cruel]

Making it be opt-in would be a better measure.

[Taki117]

Will this work with currently installed mods? I have a lot and I don't really want to reinstall them all.

[Ippo]

Will this work with currently installed mods? I have a lot and I don't really want to reinstall them all.

You don't need to do anything like that, just drop the plugin in its own folder and you are good to go

[Majiir]

Hi Majir, I'm here to bother you once more.

Would you mind a quick status report? The mod listing has been disabled for a couple of days now, I'm getting curious.

Is it anything we can help with?

A few metastatistics: There are 39,242 reports in the database, weighing in at 542 megabytes. That's not a ton of data, but it's enough that the mod listing query takes way too long to run. This is because it clusters all the different plugins it detects into mod names. (For example, Kethane.dll and KethaneToolbar.dll are both considered "Kethane".) The clustering query works fine for a few hundred reports, but it wasn't built to scale. At this point, none of the queries are particularly scalable. So, I need to spend some time working out which statistics will be computed and then build more efficient queries for all of them. This will involve a lot of precomputation. For example, if I wanted to query how many times people have launched KSP in the last month, I might have a precomputed stat for each day, sum up those days, and then add in the remaining reports since the last 24-hour checkpoint. This is certainly computationally faster, but it reduces flexibility, and that slows development. I'm still experimenting with different queries, so the site isn't progressing much at the moment.

If you'd like to help, you could always help with the site. If you're not a coder, it would be great to hear what kinds of statistics you'd like to see, how you'd like to be able to filter and match them, et cetera.

One thing I don't lack is data; it's coming in steadily and we've found some interesting patterns in the crash data. (The crash stat is also potentially flawed, but that's not certain yet.) While the server is struggling a little with inefficient queries, it seems to be handling the network traffic just fine, so I have no concerns about increasing coverage. I don't expect to see stability issues before ModStats hits 100K users.