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.