ragzilla

If you've unlocked most of the tree already, what's the issue? From what I could glean from the SETI-UbM MM configs, these seem to be the differences between US and SETI-UbM tree placement, honestly I'd probably keep the US2 placement in most cases, also including the PbC placement, because why not. The engineering101 for the cores might be inaccurate, also I guess there could be differences between US2 and US1 placement but I'm assuming @Paul Kingtiger kept things pretty consistent: Name BaseTechRequired SETI-UbM Requirement PbC Requirement USThermoBaroWedge spaceExploration engineering101 USFluidSpectroWedge scienceTech electronics USGooBayWedge scienceTech precisionEngineering USAccelGravWedge advScienceTech USMatBayWedge spaceExploration basicScience USSabatier electronics shortTermHabitation logistics USWaterPurifier electronics recycling logistics USElektron advExploration hydroponics logistics USDoubleProbeCore precisionEngineering USKASRadial spaceExploration generalConstruction USKASWedge spaceExploration generalConstruction USEVAX electronics USFoodWedge spaceExploration storageTech storageTech USWaterWedge spaceExploration storageTech storageTech USGreyWaterWedge spaceExploration storageTech USSolidWasteWedge spaceExploration storageTech USCarbonDioxideWedge spaceExploration storageTech USRadialTanks survivability fuelSystems survivability USAdaptorShroud1500 specializedConstruction engineering101 advConstruction USCylindricalShroud0625 generalConstruction engineering101 engineering101 USCylindricalShroud125 advConstruction engineering101 generalConstruction USAdaptorShroud1875 specializedConstruction engineering101 specializedConstruction USCylindricalShroud250 specializedConstruction engineering101 specializedConstruction USAdaptorShroud0625 advConstruction engineering101 stability USOctocore specializedConstruction engineering101 specializedConstruction USPenticore specializedConstruction engineering101 advConstruction USHexcore specializedConstruction engineering101 specializedConstruction USQuadcore advConstruction engineering101 generalConstruction USACD1500 specializedControl specializedConstruction USACDLarge specializedControl advMetalworks USACDSmall advFlightControl advConstruction USACDTiny advFlightControl generalConstruction USACDMedium specializedControl specializedConstruction USFuelCellSmal spaceExploration basicScience recycling USRTGWedge experimentalElectrics experimentalElectrics USBatteryWedge electrics advElectrics USGuidanceComputer specializedControl USFuelCellMedium advExploration shortTermHabitation USOxygenWedge spaceExploration storageTech storageTech USHydrogenWedge spaceExploration basicScience storageTech USHydrazineWedge advFuelSystems fuelSystems advFuelSystems USAerozineWedge fuelSystems fuelSystems advFuelSystems There's also some discussion over at the SETI-UbM thread, one person appears to have made a continuation/extended mod.

Seems more like any CTT modifications for US2 would be better handled in another pack that reorders the tech tree, like SETI-UbM, or Probes before Crew. Otherwise US2 has a hard dependency on CTT. What techtree config are you using @garwel? I know PBC has US2 support (but likely not for the new modules especially if they're using DMagicScienceAnimate).

I'm guessing they're doing something hilariously bad w/r/t urlencoding where your + is interpreted as a space and then trimmed off the string.

Mentioned on page 909, and 900.

Pick the rocket up by the root part, and rotate it using shift-wasd, you'll likely see the center of lift moving back to/through the CoM which will increase aerodynamic stability as AoA increases. Remember to un-rotate when you're done.

Adopting the compatibilitychecker style version check would solve that problem, and allow for all DLLs to be in the same location (making it easy for the user to manage). I believe that code's available under BSD 2-clause.

Modulemanager, while not as sophisticated as compatibilitychecker, does implement code to ensure only a single instance is running so it doesn't cause issues.

So the million dollar question, why was it bundled in other mods gamedata directories in the first place? The only reason I can think of is to deceptive/hide from the users, which are hostile actions and helped contribute to this fiasco.

Why is it even necessary to have multiple copies of Modstatistics outside of its own gamedata directory? What makes it so much more of a special snowflake than firespitter or modmanager which are distributed in the gamedata root, or their own gamedata folder?

The dialog is to disable auto updating, it defaults to checked I believe and thus can be misclicked to accidentally opt into updates (kind of like ask toolbar and raptr). -edit- That is to say, the checkbox enables updating, and is checked by default.

From the modder's perspective, it's wrong for the user to download something without reading all the fine print. From the user's perspective, it's a violation of faith/trust in the modder to provide the mod the user's looking for and nothing more. And we're right back to do you want to be right, or do you want to be effective.

This is what Modstatistics in it's current form is capable of doing. In the example of DNS poisoning/HTTP interception against Curse user interaction is required. Modstatistics (as I understand it, once you opt-in for auto-updates) has the capability to download anything it's instructed to to any location on your local filesystem that KSP can write to.

I haven't looked at other auto updating mods, but I assume most of them would use a similarly exploitable system (but maybe they wouldn't have the write-anywhere issue people claimed Modstatistics has). Do you have any examples of other auto-updating mods?

The auto-updater in Modstatistics is opt-in (don't remember if it's default checked or not), but it's implemented with absolutely no regard to security and is trivially exploited through DNS poisoning, HTTP interception, or a hack of Majiir's server. If it helps avoid situations like this I'd be surprised if they hadn't at least considered it. The difficult part is the enforcement since it's so subjective w/r/t definition of a functionally necessary dependency. A possible compromise here would be that bundled plugins must be in their own gamedata folder (e.g. how firespitter and modmanager are distributed), and not bundled in with the mod you're downloading's gamedata folder.

I think we can all agree that it is the modder's right to bundle whatever they want with their plugin (license permitting), but don't be surprised when there's a backlash from your users. Right vs effective etc. Personally I feel that only hard dependencies providing essential functionality (jsonfx, firespitter, kae, etc) should be bundled, but I don't think we're likely to get community consensus on that point. And I don't think Squad wants to make a rule on that point.

RoverDude's comments on being right vs. being effective seem appropriate here, a lot of capital and trust has been burned during this whole event, and for little to no gain. The whole thing was a violation of the principle of least astonishment for me. I've always used FAR and trusted that the code didn't do anything malicious or unethical. So when I suddenly get a popup about modstatistics (which I had no interest in running) wanting to update itself, after I updated FAR for 0.24, I was annoyed to say the least. You can take the righteous stand all you want (FAR has a disclaimer on the forum page, why didn't you read what you were installing?) but now you've thrown away the trust you've cultivated with that set of users for years just to get a statistics mod of questionable utility installed on your users PC.

Now running and disabling plugins in other scenes. First round on the SpaceCenter GUI but re-using the popup I used during the load phase is causing issues since it's a non-modal popup (so clicks go through it to the spacecenter scene if the user's cursor passes through a clickable object on the way to the dialog).

The goal here is something to enforce opt-in, not shut off networking as a whole (that's easy enough to do in the Windows firewall). I agree but this gets well beyond the current inspection (and isn't something I'm even sure is possible in Windows these days). Back in the days you could patch the call table but that's harder to do nowawdays with security features like ALSR. Usually to hook all network traffic from a process you need to do so at the kernel level, and there you lose visibility of what inside the app is initiating the traffic. I don't see a good way to handle this, and will instead admit it's a weakness in the current plan. There's too many valid uses of reflection (ToolbarWrapper, and other API wrapping interfaces) to blacklist that (without digging into the operands to find what methods people are using) and inspecting pinvoked code is too much work (that's straight up dll disassembly rather than CIL inspection that Mono.Cecil enables, or at least inspecting the imports, but not sure if there's C# code around for that- not something I particularly feel the need to write), so I'm tempted to leave those around as known caveats.

Thanks! After thinking this through (half dismembered code) I think I'm going to revise to not re-enable the Monobehaviours after users whitelist, and I'm going to require a KSP restart (at which point the whitelist will tell GOMN not to disable them in the first place). Currently this inspects all methods in all types deriving from monobehaviour in the assembly, and if network code is found anywhere it disables all monobehaviours in the assembly to prevent the mod being half enabled/half disabled (not tested in other scenes yet, still needs some work on this front). Not sure I've ever had my programming called skillful before, I'm more of a bang two rocks together until something works kind of guy. Re non-Csharp, I talked about this with a few other people and this isn't really a be-all end-all, people can obviously get around it, if they want to (non Csharp libraries, reflection and invoke) but at that point the code is being deliberately obfuscating which will hopefully reflect on the author of said code (if you deliberately try to bypass something like GOMN you're actively trying to be sneaky). Currently if people want to block all network traffic from KSP it's trivial enough to do so in windows firewall, this is trying to provide an option halfway between blocking everything and blocking nothing. Another item with the false positives I've been considering is embedding a whitelist of known false positives, and plugins which implement responsible opt-in behavior (popup on first load, space center scene applauncher functionality) and implicitly whitelist those for being well behaved or false positives (would need some community help on that since I don't run a lot of plugins).

It pops up when it's detected and gives the user a chance to whitelist it. Then it'll re-enable the monobehaviours (not sure if KSP/Unity call Start() on them at that point or not). Restarting KSP would cause the monobehaviours to start as normal though (GOMN loads user whitelist from config). -edit- Mods messing with other mods for the sake of it seem to be against the rules, but fulfilling a purpose (enforcing opt-in) seems to be ok, the SBTS thread is only locked due to arguments (hence the request for people to keep arguments out of the thread and keep things civil).

Repo: https://github.com/ragzilla/GetOffMyNetwork License: GPLv3 + KSP linking exception What it does: Attempts to run early in load order to inspect (using Mono.Cecil) all other plugins loaded into the KSP AppDomain. Does CIL inspection to determine if any plugins are using methods or classes inside System.Net, UnityEngine.Network, or UnityEngine.WWW and if references are found disables any instantiated monobehaviours to prevent them from running (so long as GetOffMyNetwork starts first this will prevent their Start() method from being called, afaik there's no way to prevent them from calling Awake()). Still to do: Ensure we run in other scenes to disable monobehaviours instantiated after initial KSP load (right now I've only tested it works during the initial load). (complete 20140731) Interface in the Space Center scene to re-enable disabled plugins (rather than digging into the config file). Develop framework for whitelisting certain usages of the classes (I'm getting some false positives from plugins which use, for example, UnityEngine.WWW to load Sounds from disk). Why: Confirmation and enforcement of the future opt-in rule, except it works now and enforces it at a code level so even if a developer forgets to prompt for network access this plugin will. If you have oppositions/reservations and want to start an argument I ask that you do so through PM to reduce moderator workload. But what about rule 7: Rule 7 specifically states the plugin may not work outside of the GameData folder, and the checkAssemblyForViolations method does check for this (if gamedata is not found in the assemblies path, it doesn't inspect the assembly and just returns no violation). Changelog: 20140731 - Refactor Start() to be more modular Now instantiate in every scene (catches assemblies which don't run immediately), if enabled assemblies are found cancels all coroutines/pending invocations then invokes OnDestroy to cleanup anything the addon did in Awake(). Doesn't seem to be any way to catch code before it enters Awake() that I can find Don't restart stopped monobehaviours. Currently looking for feedback on implementation (what stupid things have I done here that I shouldn't), and if I missed any Unity or CLR classes which contain classes/methods which can access the network. I'm not providing a binary build yet (want to wait until I have the dialog working in the Space Center scene), think of this as a developer preview at this point.

I Am Not A Lawyer (it's kind of an old abbreviation) That would probably require a Squad interpretation. I would assume so since you're distributing a DLL which violates forum rules so they would close your thread and remove download links until you brought it into compliance.

IANAL, the following does not constitute legal advice or create an attorney-client relationship. I'm not an expert on software law (and especially not international law), but you're distributing his software under his license, so I would expect he would be found to be liable for all criminal or civil issues arising from abuse of the software (and since he's ARR, with no limitations on liability in the license, and it's distributed by him personally not an LLC, that could be an interesting civil suit). However if you're distributing your software in regions with restrictions on data collection the argument could be made that you should not have bundled the software/library that's in violation of that region's privacy laws.

Only a single instance of Modstatistics runs (it doesn't really have an API for plugins to report statistics to, to report those to the server on the plugin's behalf), it just reports on all assemblies loaded into the KSP address space/.net appdomain. There's no way for your plugin to opt-out of it's statistics collection (other than compiling against .net 4.5 like the Squad/KSP assemblies, in which case Modstatistics crashes itself and possibly your plugin- I forget if both crash or not).

Selection bias/users are notoriously bad at self reporting. Automated statistics gets you a decent cross section of people and no bias in the reporting (I don't want to admit I use mechjeb auto ascent/maneuver/landing features in public, so I'll say the only thing I use is orbit/surf info and they're great!)