Majiir

Vendan isn't running a server. He's using KerbalStuff, which has a privacy policy.

That's correct. It's possible that it just needs a recompile, but it might require more extensive changes. The permission granted allows those changes as well.

Because circumstances will have me unable to update KAS in a timely manner, I am temporarily allowing the distribution of the KAS plugin modified for 0.24 compatibility purposes. Please do not distribute any models, textures or other art assets, and please do not distribute any part configuration files. If you'd like to balance part costs, please use a ModuleManager patch. This permission applies to the plugin only. (The KAS project has a number of contributors, and it's always a challenge to ensure all creators' rights are respected.) Please link to modifications in this thread and avoid third-party sites like Curse. (Something like Dropbox or Google Drive for hosting is fine.) This exception shall expire as soon as I release an official update, so please bear that in mind. This is intended to allow volunteers to address compatibility issues for the players, not to otherwise grant distribution rights to the KAS plugin.

Hi folks, I would like to address all your questions and statements individually, but right now I don't have the time. Please see my statement here and watch that thread for updates. I'll ask the moderators to unlock it once I've prepared a detailed response. I am keeping in close touch with both the KSP forum moderators and members of Squad. We had a conversation yesterday, and we will resume discussion after the weekend. This is an important issue to discuss, but it's not an emergency that should pull Squad away from their well-deserved vacation. I speak frequently with members of Squad about QA, modding policies, legal issues and the game's API. We're all well aware and communicating. Cheers, Majiir

Just wanted to drop a note in here to explain this. KSP doesn't ship with a .NET 4.0-compatible runtime, so if you build against 4.0 or above, you'll often run into errors with KSP or other mods. ModStatistics runs a plugin version check that will fail if the mod isn't targeted for the right framework, and displays this notice so the mod author is made aware. You'll find that assemblies compiled for higher versions usually work at first, but they'll end up breaking in odd situations. It looks like you've fixed this now, but I just wanted to explain why ModStatistics shows this message. It's a helpful hint, is all.

As I have said before: There is an easy way to permanently disable the plugin, and I will be making it even easier in a future release. I don't understand what the concern is here. With the ID, I can know something like "a user that previously had KAS and Kethane installed is now only using KAS". This is a user profile, but in what way is that kind of correlation "not what the plugin was supposed to do"? What bad information could I get from this that I shouldn't be able to? You're correct that an IP address is there, but again, it's impossible to write a plugin that doesn't send an IP. (I really don't like that KSP offers a "don't send my IP" checkbox when that is simply not possible short of bundling Tor with the game, which I'd argue is even more egregious.) I suggest anyone who's concerned use a VPN or anonymizing service, since many web-based systems have things like session IDs, user IDs, et cetera. (I used to sell VPN service, as a matter of fact!)

I had to double-check the source on this. No, that will cause the plugin to run. However, if you deleted the entire ModStatistics folder each time, then it would indeed never send data. I'm not sure why someone would delete just the settings file each time and not the pending report files right next to it, so I don't think this is an issue. JsonFx is a third-party library for serializing object structures to JSON, which is the format used over the wire. Its source code is here: https://github.com/jsonfx/jsonfx

I think my post was plenty civil. I'm happy to explain my word choices if you'd like. If the plugin did not respect the config file, that would be a very different case. The fact is that it does, and that won't be changing. (If I did something like that, the disabler plugin wouldn't exactly work either.) Okay. You certainly don't have to join my project, but releasing the disabler was out of line. Not "civil" if you will. Indeed, and a number of people have argued to me that I shouldn't waste my time with it. There is one thing that's important to change for a dump, and that's the random number sent with each report. If a malicious entity were to inspect ModStatistics while it's running and fetch that ID, they could then have knowledge that some statistics data is associated with the currently running game. Now, I have no idea how you'd do anything bad with that, but I'd like to be cautious and prevent it from happening anyway. So, "sanitization" means replacing those with new random numbers. ModStatistics saves reports when the game closes, and it only sends them when you start it back up. You can look in the ModStatistics folder and see reports that will be sent on next start. It's in a human-readable format once you add some newlines. This is not the case. It will only send statistics the second time you start it. There is always a chance to edit the settings file before it matters. I don't really get angry. If forfeit really wanted to do some good, he could have released a version that adds a new UI so that users can disable the plugin without editing config files. Now, the moderators would still have removed the download and contacted me, but I'd be very likely to say "you really ought to have asked, but now that we're here, may I include this in the real build?" You're walking a fine line on a technicality, but the reality of your intent is clear. We don't have to play these kinds of games. As I mentioned earlier, I spent a while speaking with Squad and some of the forum moderators. At first, I was really ambivalent about the idea of mods disabling each other. I thought, who cares, the config option is there already. But as we discussed more, I realized this is a road nobody wants to go down. Do we really want to live out some hypothetical where Kethane distributes ModStats, MechJeb distributes a disabler, and then the two start eradicating each other? Do we want to set a precedent where that kind of interaction between mods is accepted? ModStatistics is controversial, which is to say that some people like it and some people don't. But I don't think anybody wants to see mods start fighting it out in GameData. I agree. You are notified about the presence of ModStatistics before you download a mod; you don't have to download it. If you do, you are notified about the presence of ModStatistics as you launch the game; you can disable it. I am hearing feedback that there should be a more obvious notification and that it should be easier to disable, and I will be acting on that feedback. I think it's important to set the record straight. I also think it's important to share my future plans with the community. Some people aren't interested in listening, but those who are should have the opportunity to know my thoughts and respond to them. And, of course, I have mentioned that I will be changing the plugin. It would be nice if the thread calmed down; I'd have more time to work on the code. That's a bit of hyperbole. The "ID" that's sent is a random number. So yes, when a user plays KSP multiple times, their reports are all known to originate from the same user. That's it. There is nothing sent that can actually identify a person. If you think this still presents a risk, please let me know why so that I can address it. It could be reasonable to hash the incoming IDs, much like passwords are encrypted in databases. I'd like to know what exactly your concern is, though. Regarding IP addresses: It is impossible to communicate over the Internet without "sending" your IP address. For those worried about geolocation: I tried locating one of my servers, and one source said it was in Dallas, TX; another said Chicago, IL; and yet another said New York, NY. The server is actually located in Washington, DC. [EDIT] And that server hasn't changed location or IP in five years.

Answers to some recent questions and statements: Does this have any impact on game performance? No. The plugin does very little, and certainly doesn't make flight more sluggish or anything of the sort. Network activity is non-blocking. Is an Internet connection required? No. If an Internet connection is unavailable, the plugin will simply try again later. Can we see some statistics? There have been 6,546 ModStatistics users on 0.24 so far. 3,580 of them have tried 64-bit KSP! Simple queries like that are easy to write, but making them efficient enough to put on the webpage takes substantially more time and forethought. I currently have less time than I'd like to work on the site. That said, there are two things I'd like to do: I've written a script which will scrub the raw data and prepare it for public release, and it just needs a little more work before it's ready to produce dumps. I'd like to hear from modders and other interested parties about what kinds of stats you'd like to see. This will help me plan the site and start with queries that will be most useful to the public. Just delete it from every mod! It's more reliable and more permanent to change the configuration file. If you change the settings file, you can go ahead and delete all the DLLs without harm, but leave the settings file. This way, if you accidentally install another mod containing the plugin, it will stay disabled and not even run once. Won't it slow things down to have all those plugins? Not really, no. Maybe if you had thousands or millions of them. Only one plugin will run, and it takes barely any time at all for the game to load all the plugins in GameData. Furthermore, I have requested features in the base game that will make it easier for ModStatistics to automatically clean itself up and remove duplicate DLLs. Why do you make us "jump through hoops" to disable it? This is not intentional. I would like to add a prominent button in the main menu screen (and maybe the settings screen too, just to be safe) that allows you to control everything the plugin does. It will also draw extra attention to itself on first run. The reason it doesn't have this currently is that I was planning to use the new App Launcher feature in KSP, but it doesn't support the main menu scene. If that support isn't added very soon, I will simply add my own button. This new UI will also make it more clear what ModStatistics does. Why don't you do that RIGHT NOW? My real-life situation is a bit busy at the moment, and I'm already spending more time than I should working on KSP mods. I will get it done when I can. Maybe if you ask nicely, people will have a warm fuzzy feeling? This is a good idea. I will consider this when I write the new UI. It could explain to users why this information is so helpful to modders. Why does it clone itself? This was done for technical reasons related to the only-run-once mechanism. In short, it protects against errors and other data integrity issues when users are frequently installing and removing mods. Correcting a few points of fact: Data is not sent to a third party. It goes to a dedicated server which I personally administer. (The domain name is stats.majiir.net, which I thought was a pretty good giveaway!) The plugin does NOT report OS version, CPU speed or GPU model. (I thought OS version in particular was too risky.) The only system information reported is OS type (Windows, Mac or Linux), number of CPU cores, amount of system memory, amount of GPU memory and the GPU vendor (Nvidia, ATI, etc). In the current version (1.0.3), the first-start popup does not ask for reporting preference. Regarding the infringing "disabler" plugin: I do think users should have the choice to disable ModStatistics. This is why I spent time to make sure the settings file would include instructions for disabling the mod, and it's why I encourage modders to notify users how to disable it. I understand that these measures may have been insufficient, and I will work to correct those. At the end of the day, I want the mod to be easy to use, and that includes making it easy to turn off, permanently. I think the disabler plugin is harmful in this regard. It's no easier to use than the original mod; it doesn't provide any information or UI to the user; and it disables the mod in a way that's unreliable and unpermanent. Furthermore, this kind of hostile mod interaction is not a good sign; it's much better for modders to communicate rather than wage a modding war. If the author of the disabler plugin (or anyone else) would like to improve ModStatistics, feel free to shoot me a message. [EDIT] A few more notes: I spoke at length with members of Squad and the forum team about the recent attention ModStatistics has seen. We exchanged thoughts, and we agree on some steps that should be taken. They seemed a little bummed out that the community has been dumping some frustration on them, so I hope you'll keep your thoughts civil and in this thread. They are well aware of everything and have been keeping me informed with their thoughts.

Yes. See my note in that thread for details.

This is what I came to mention. It might be possible to define the tank as having an initial capacity of zero, with the hope that the configured cost would be undisrupted, and then change the capacity (and contents) at runtime. It's fairly easy to make a resource "untouchable" to the base game, but it would indeed be messy to try and hide it. My opinion: Don't hide it. Make it obvious, make it ugly, and make it well known that this is something Squad needs to fix. This issue was known for nearly two months prior to 0.24 release. I suggest a resource name like GoshProceduralCostWouldBeNice or SeeTrackerIssue2619.

This fix is no longer necessary as of a few updates ago.

Regarding the 0.24 update: It will be another day or few. However, as others have noted, the 0.23.5 version may work fine in 32-bit KSP only. For this reason, I won't be releasing a recompile or an otherwise half-baked update, but rather a proper compatibility update for 0.24. I cannot guarantee 64-bit compatibility because of a known issue in the base game, but I will be investigating the possibility of a workaround implemented on the KAS side. For those giving praise: Please remember that KAS was originally written by KospY, who is indeed a talented modder! Also remember that Winn75 and zzz did some excellent part modeling and texturing work for the parts, and remember a.g.'s contributions to the plugin code in the recent updates. My role in KAS is quite limited and I function mostly as a proxy and advisor. (I do write code sometimes, but not enough to deserve some of the comments in this thread.)

I must second this. It's made worse by a lack of clarity. The title implies that this thread is about 64-bit compatibility, but that doesn't seem to be the case. There are also additional markers to indicate whether a mod's part costs are balanced, but its application is inconsistent or incorrect. (Kethane, for example, has balanced part costs, but this list seems to indicate otherwise since some entries are marked with three stars.) Misinformation hurts the community. Even correct information can hurt the community if it's easily misinterpreted. This thread has a lot of both.

Ask Squad to implement the features modders have asked for. I will continue to use Blizzy's toolbar because it does what I need, and the stock one does not.

Regarding the JsonFx issue: You should update KJR (Kerbal Joint Reinforcement).

It's much more permanent to change the GameData/ModStatistics/settings.cfg file to disable it.

Technically this happened shortly after 0.24 release, but it's been a busy day: ModStatistics 1.0.3 has been released. The download link in the first post has been updated. This is a KSP 0.24 compatibility update. It also contains miscellaneous improvements. This update has been pushed through the auto-updater, so it's not strictly necessary to update the version packaged with your mods. The update notice is primarily for the benefit of other mod developers. Changes in this version: Assembly information is only generated once (at startup). Steam use is now correctly detected. The old metric still exists, but it detected whether the game was launched from Steam. The new one detects whether that copy of KSP is installed in a Steam library. Assembly hashes (SHA2) are now reported. This aids in plugin clustering and version tracking for developers. Some system information is reported: number of CPUs, system memory, graphics memory and graphics vendor. (All those values are simply integers, with the last corresponding to a brand, but not to any particular graphics device.)

1. This is an issue related to ModStatistics. I'm looking into it. 2. This is a known issue with 64-bit KSP.

I very much doubt there will be any 64-bit issues with Kethane. It's all architecture-agnostic code. If mods have trouble running on 64-bit KSP, it's much more likely a KSP or Unity issue.

Indeed! During the initial rounds of 0.24 experimentals, we requested a number of features to make modding easier with the new update. Unfortunately, a number of those requests didn't make it in. Among them was the ability for Part and PartModule code to influence the cost of a part, both in the VAB (for purchasing) and in flight (for recovery). This is essential for KAS because the part containers can have a base value, but they can also contain other parts. At the moment, part containers essentially break the game by making some parts free in the VAB and worthless in flight. There is a possible workaround which I might be implementing in the next few days. It wasn't at all clear what would happen in the last few days of experimental testing, so I didn't want to spend a lot of time implementing something that would become obsolete soon after. So, at this moment, no update work has been done on KAS, and some structural changes (as well as the ordinary part cost balancing) will be necessary. Much of this could be made easier if Squad would release a 0.24.1 patch with the requested features. If proper part costs are of interest to you in KAS, please lend your support for a minor revision update to KSP.

It can indeed, but you'll find that there's more than one way to turn Kethane into cash. (Hint: check the new converter stats!)

Watch the KAS thread for info on that.

Kethane's update has rebalanced prices. I don't know if they're well-balanced, since I didn't have a large group of playtesters, but they were set with the 0.24 prices in mind.

I've patched this with Kethane 0.8.8. The warning itself is harmless in this particular case.