Majiir

Not from the KAS side. The KAS plugin is fully managed code. It's agnostic to CPU word size. In other words, KAS doesn't have anything to fix; it would run just as well on a hypothetical 128-bit architecture. If 64-bit KSP is causing issues with KAS, that means there's either a bug in 64-bit KSP/Unity (highly likely) or a bug in 32-bit KSP that KAS is inadvertently depending on (less likely). If you can dig up more information that shows certain KSP/Unity functions are unreliable in 64-bit, it might be possible to pick alternatives, but my guess is not.

I'd like to point out it's difficult to know what "average" is without data. 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. The data is quite skewed at the moment. I don't know of any mods aside from Kethane that have distributed the plugin. 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. 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. 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.

Kethane flows like monopropellant. It doesn't need a connection as long as it's on the same vessel.

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