Majiir

Kethane will run fine without it, but keep the following in mind: ModStatistics is very lightweight and won't impact your game's performance. The recommended way to disable ModStatistics is to use its settings.cfg file. This is because any number of mods could be distributing it, and unless you disable it in the configuration, it could still appear later and start running. You can try to remove ModStatistics from every mod you download, but something may slip through or be bundled with another DLL.

Kethane 0.8.6 has been released. The download link on the first post has been updated. This update makes notable improvements to the Kethane API, making it easier for third-party modders to extend and incorporate Kethane functionality in their mods. It also contains various fixes and improvements. Changes in this version: Enabled toggling of converters, detectors, extractors and generators from EVA. Thanks oobayly for the pull request. Resource selector buttons now wrap around the resource list at each end. Fixed a number of issues which could cause the grid overlay or other UI elements to render incorrectly. Added CellularResourceGenerator, an abstract base class which makes it much easier to write resource generator plugins for Kethane. See this post for an example. Changed visibility from internal to public for all Kethane API components. Only utility classes remain internal. Kethane will automatically delete the empty MMI_Kethane.dll file on startup, so it shouldn't clutter up debug logs any longer. Packaged ModStatistics 1.0.1 with the installation. Fixed an incorrect part configuration which cluttered the debug log with texture load errors. Removed obsolete fixes for old KSP bugs (ScaledSpaceFix and KSPAddonFixed). Made various improvements to the geodesic grid code.

I have not offered hosting for every half-baked repository site that comes around. Hosting is contingent on the quality of the produced site. If someone thinks they can self-host, then they can "compete", but in a sense there is already a decision-maker here.

JewelShisen and codepoet: Cheers. I'll appreciate you letting me know when you do end up releasing it so I can figure that into my query design. I ask modders to include a notice in their thread in a prominent place. This was done both as a courtesy to users and also to leave no doubt about compliance with the forum rules. I'm considering a popup, but I want to test a few different things first. I said some mods contact a remote server. (The very act of connecting transmits some information, but that's distinct from uploading application data.) Toolbar, for instance, contacts an update server. It can be disabled, but there aren't warnings plastered everywhere as with ModStatistics. -------- On another note: I've discovered an odd issue with report submission as of 1.0.0. The server logs show that a large majority of clients that are able to contact the server are not submitting reports. At first, I thought it was one or two users manually deleting the reports every time they were generated, but there are too many instances of the issue now for that to be the case. (Only one user has been able to submit 1.0.0 reports.) I'm working on a patch that will shed some light on the issue. In the meantime, if you're using 1.0.0, please give your GameData/ModStatistics folder a look and tell me what you see. In particular, I'm interested in whether checkpoint.json exists while KSP is running, and whether report-#.json files are stacked up. I suspect there's an issue with file write permissions that's preventing reports from being saved for transmission at all. (To be clear: I think this is an issue affecting all versions released thus far, but only 1.0.0 made it discoverable on my end.)

C# generally outperforms C++/CLI. I'm also not convinced P/Invoke is going to be faster. Remember, the CLR revolves around C#, even if it is built to be widely compatible. There's a big reason to use C# that has nothing to do with language features: It's what KSP uses. It's what the vast majority of mods use. Everything you're going to interface with was designed with C# in mind (even if Unity is bad at it). All the snippets of useful code you'll find are in C#. If you're interested in skilled modders peeking at your code and giving you advice or pull requests, you'll want C#. I do think C# has some advantages from a technical standpoint, but my point here is that you should not use a different language unless you have a substantial overriding reason to. "I don't know C#" isn't a strong enough reason, in my opinion; it's not an unusual or difficult language. There might be a particular language feature you need, but those situations are very rare.

This is why I notify users in a prominent place in this thread, and I instruct mod authors to do the same. This isn't the first plugin to contact a remote server; some are quite popular and don't even tell users about it. If you see a mod you want to play and it has ModStatistics, and you don't want to contribute, then run the game once, let ModStatistics generate the settings.cfg file, and change the disabled flag. No data is sent on the first run. I have offered my server resources for hosting a community-run mod repository. The coder of one of the candidate sites has already remarked that there's potential for integration between ModStatistics and their repository. I have a lot of "meta-modding" projects, and this is one of them. I think they're all useful on their own, but clearly there's a possibility they'll converge. It's far too early in any project to give it much serious thought, though. The performance impact will be truly negligible. The *.notdll idea is interesting, but there needs to be a plugin to load those in the first place. If I figure out a good way to clean up DLLs, I'll raise the discussion again and we'll see what works best. While I recognize this guarantees nothing, I'll say: If I wanted to do something malicious, I'd have already used Kethane or KAS as delivery mechanisms; or I'd have more aggressively pursued Replaceport with my own code to harvest passwords; or, years ago when I discovered a public-facing database with thousands of plaintext passwords, I'd have saved a copy instead of typing the drop-column command as fast as possible. Updating and reporting can both be disabled. ("update=false" in settings.cfg will prevent it from checking for new versions; I need to add that property to the default config file.) Honestly, lack of SSL is a far bigger problem than I ever will be. I did try a few times to add it, but Mono requires you to implement certificate validation logic yourself, and I'm loathe to include something with the appearance of security unless it's really secure. (Of course, if someone is MITM'ing your anonymous usage logs, you have bigger problems.) Yes. As of the latest version, files are generated only when the game closes, and they are sent only when the game starts. So you can run a session, close KSP, and inspect the file to see what will be sent.

I'm not sure what's so bad about it, but it doesn't matter anyway. Deleting them just cleans up the plugins that aren't running to begin with. If every modder puts the file in the same path as you suggest, modders need to constantly stay up-to-date with ModStatistics or they'll end up overwriting new versions with old ones. This is easier on modders because they can package it once and not worry about ModStatistics updating. (Another mod will probably come along with a more up-to-date version.) It's easier on users because they don't have to figure out how to merge the ModStatistics folder. (This would inevitably cause problems when users merge incorrectly or delete the old folder; or they'd delete the new one, and thus not receive an update. Directory merging has been a constant source of confusion.) I know that this is a little unusual, but as you say, it's a different use case. This is somewhat similar to ModuleManager and Toolbar, and the system I've designed solves many of the problems those mods have experienced. If you have specific concerns, let me know, but I think this will work quite well for all involved.

The issue here is this can cause the ModStatistics directory structure (or individual files within) to be overwritten when another mod is installed. Additionally, users are used to erasing such directories before installing mods; that can cause issues when a mod is distributed with an out-of-date version. Finally, pluginless mods cannot currently be detected unless a plugin (like ModStatistics) is in their directory structure. If the packaging instructions are followed, the user is unlikely to notice that multiple files are present. It would also be acceptable, for example, to put the ModStatistics DLLs in GameData/YourMod/Plugins, where other plugins are already distributed. ModStatistics is very small, so I don't think this is an issue. I will be adding configuration options in a future version, but for now there's nothing to put in those files. Only one instance of the latest version of ModStatistics will run. Note that I'm looking into ways to have ModStatistics erase duplicate versions, but that's a technical challenge. (Assemblies cannot be unloaded without unloading the entire AppDomain, so I'd have to do something like create a new AppDomain which runs a cleanup task, or maybe even spawn a separate process.)

ModStatistics 1.0.0 has been released. The download link in the first post has been updated. This is the first release suitable for redistribution. Details and best practices have been added to the first post. Please read that information thoroughly before including ModStatistics with your download. Additionally, the site has been revamped a bit, although there is now only one listing. I'll be expanding it over time. As before, if there is a particular stat you'd like to see, let me know. [EDIT] One more thing: A big thanks to everyone who tested the beta! Your feedback was immensely useful. The stats you contributed over the last three days helped a great deal as well. Changes in this version: Assembly title is now reported. This is a name contained by each plugin and not bound to the DLL filename, which will improve mod identification. (This should fix the ModuleManager categorization issues.) Reports no longer freeze the game while sending. Reports are now sent only when the game starts. This provides consistency between crash and non-crash reports and eliminates the delay when closing the game. On startup, the plugin installs the latest version of itself into the GameData/ModStatistics folder. This ensures that the plugin version is not bound to the mod distributing it. Removed the blank settings file from the download package and improved the instructions in the file that the plugin generates on first run. Reduced debug messages to avoid spamming the output log.

Do you have multiple ModStatistics.dll plugins present? It's possible that version negotiation is failing. Also: are you behind some kind of proxy or filter? There are some requests with a blanked-out User-Agent header, which are also rejected.

It would, yes. The plugin collections assembly file and informational versions, but unfortunately, it's hard to tell which of these is correctâ€â€if either. Yes, it's the average loading time of installations which include that mod. There are a few things going on with the current analysis. There's not enough data, so there are going to be irregularities here for a while; crashes aren't filtered out, so one person who let the loading screen sit there frozen for 22 minutes really skewed things; and most importantly, the analysis is flawed to begin with. It's not wrong, it's just not a particularly useful stat yet. With large volumes of data, we might see that certain mods stand out, but a proper analysis is more complicated. To expand on that: Ideally, we'd like to know how long each mod takes to load on average hardware. We have access to a list of installed mods and the total loading time. In principle, it's possible to work this out, but only if you have a lot of data. You can't very well use data that spans multiple users because users have different hardware. In effect, each user has a different load time multiplier. You could try to find users who have identical mod lists and compute the factor between them, but there will be few such coincidences. What you really have is a more complex system: lots of users which all overlap, and lots of runs for each user with potentially different mod combinations. The part that I don't know how to solve is the simultaneous over- and under-specification. The system is under-specified because some mods are never used alone, or not used in enough combinations to pin down their contribution to load time. It's over-specified because popular mods will show up a lot, and you need to be able to average those results. I may just be blanking on something I should know, but this seems like a difficult problem. Perhaps I can think of it as fitting a line to data in n-dimensional space where n is the number of mods, but then I'm not sure how different users play into it. (Maybe it should be n+1 dimensions? But then users need to be properly distributed along their dimension, and that's part of the challenge.) I'm not sure an analytics package is going to help here. Simple queries are easy, and harder ones are difficult to even conceptualize. If you can point me to specific capabilities, I'll give it a look. Right now I'm using MongoDB's aggregation pipeline, and it works nicely if you know what you're trying to compute. I could certainly use something else, but working with MongoDB directly keeps the whole thing simpler. Which version are you using? The server is only accepting reports from 0.0.3.

I'd rather not restrict it like that. It helps users to see which mods are unreliable. On that note, I also have an obligation to make sure the analysis is not misleading. What's up on the site right now is just exploratory, and every listing has some flaws. (If anyone has a stronger statistics and machine learning background, I'd certainly appreciate help!)

I'd rather not put the current version into the wild. It has a few issues and limitations. I could possibly have the next version ready for a first run with the public (although I might code in an expiration date so it doesn't cause problems too far into the future). Right now the only available information is what's on the site, but that will change daily. "This mod commonly goes with" is something that will be public. There might be stats available for author's viewing only, but I'm trying to keep all the stats as innocuous as possible, so there shouldn't be any need to lock certain information down.

Okay, some basic stats are up! By plugin name: http://stats.majiir.net/ By plugin folder: http://stats.majiir.net/folders Neither of these gives a very good picture, so I'm still thinking about how to best categorize plugins. This is mostly a test to make sure the data is structured well for querying. I'll probably have to change (again) how scene times are reported, but everything else seems fine. I'll be adding various tables as I go, but let me know if there's anything in particular you'd like to see. [EDIT] And here's crash info: http://stats.majiir.net/crashes [EDIT 2] And here's average total loading time: http://stats.majiir.net/loading So it turns out computing statistics is hard. Some of the more complex analysis will have to wait, especially because it's hard to work with such a small data set. I'm still not sure how to approach the mod categorization issue, so I'm still operating under the (flawed) assumption that plugins correspond to mods. The queries will work fine once that changes anyway.

Thanks for the (bug) report. I've sorted out a few issues with server parsing as well. Some of you probably have unsent reports stacked up, so those should be coming in soon. (The server was incorrectly rejecting them before.)

ModStatistics 0.0.3 has been released. The download link in the first post has been updated. This is another beta release. Note that reports generated by prior versions are no longer accepted by the server. That said, the server can now properly parse and validate reports, so data collected with this version can be analyzed. I'll be working on a simple website to serve as proof of concept. The plugin still needs some work, but I'd like to see how the whole system works before I develop it much more. Changes in this version: Crashes are now detected, and reports for the crashed session are sent at the next start. Crash reports send the same information as normal ones, but they indicate that a crash occurred. Several changes were made to the report format to make reports easier to parse, validate and process on the server. Fixed a minor discrepancy in how report end times are generated. Added assembly version to the user agent string.

It's true that version information is included, but getting versions is basically a one-liner (assuming the file version is correct, which it almost never is): AssemblyLoader.loadedAssemblies.Skip(1).Select(a => a.name + " " + assembly.assembly.GetName().Version); If someone needs a server to run an error reporting service, they're free to get in touch with me. I don't think error reporting is in the scope of this project. I'm not writing an error reporting mod. If there's some context in which reporting errors becomes easy or useful from a statistics point of view, I'll consider it. It seems you're frustrated because this is "almost" what you're looking for, but I think you're off in that estimation. Besides, if that's really the case, then it shouldn't take anyone more than an hour or so to put together what you want. I'd head to the requests forum. I'm working on a configuration and plugins system that will allow modders to customize how ModStatistics reports certain things. I'll also be considering part usage, but that could very well become a plugin to ModStatistics rather than a full-fledged component of it, at least at first.

ModStatistics 0.0.2 has been released. The download link in the first post has been updated. This is another beta release. Changes were primarily related to the reporting format. The plugin now has a dependency which is packaged with the mod; I'm interested to see how this fares on various platforms. Changes in this version: Reports are now sent as JSON instead of XML. Scene times are sent ordered by the GameScenes enumeration. This acts to hide the order in which the user entered scenes. The current time is now only sampled once during scene switches. This makes scene timers slightly more accurate.

Crash reporting is relatively easy to fit into the stats regime, mainly because it's a necessary feature. (Stats are collected when the game closes, but if it crashes instead, we need to detect that and report on the session as far as it got.) The problem with error reporting in a more general sense is that it vastly complicates the privacy issue. I don't want to have the mod send any data that could potentially include personal information, and error logs certainly could.

Uh? The average user probably won't care, if that's what you mean. There's nothing sinister here. Again I ask: Which collected data do you object to? It turns out it doesn't. With restricted redistribution, download counts give a reasonable upper bound, but it says nothing about how many people actually use the mod. What percentage of players update within a week of release? How many times on average does a user download the mod? Is it the same userbase, or is there a lot of churn? Usage stats combined with download stats can answer a lot of these questions, but download stats alone don't say much. (I have raw server logs for a number of mods, including some I didn't author. They're nice to have, but not as useful as you'd think.) Erm, what? It's a usage statistics mod. You're asking it to be an error reporting mod. You might as well ask me to make Kethane an autopilot. There is nothing special or hard about gathering a list of installed plugins; if you want, go ahead and make an error reporting tool. That's just not what this project is about. "Gosh, my game is crashing a lot. Why don't I check the stats site and see which of my mods has a high crash rate?" It's not very useful for a user to see his own data for a single session, but aggregate statistics (for a single user or the entire population) can provide insight. Have you not seen the hundreds of forum threads and Reddit posts titled "what are some popular mods I should download?" It would be nice to have some real data to answer that question. What are the most popular mods? Kethane and KAS? Interstellar and B9? MechJeb and KER? What mods cause loading time to increase? What mods do people tend to try for a minute and then immediately uninstall? What mods do people play with for hours on end? Are there mods that people leave running overnight? (Could be a bad thing!) This plugin can be useful for a lot of people in a lot of different ways. There are a lot of ways in which it can be improved; I just coded it yesterday. You don't see the value? Fine, but please don't spam my thread just because you aren't satisfied by the many good answers already given.

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.) 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. 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. 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?

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. 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!)

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! 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.

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? 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. A separate program kills usability; right now, it's completely automatic, and I can't see a viable system working any other way.

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.