DaniDE

Members
  • Content Count

    178
  • Joined

  • Last visited

Everything posted by DaniDE

  1. Hi - I have installed KSP again after....over a year and I am still a bit rusty with the mod quirks. I was already in the middle of a career game and remembered I never reached all planets of OPM, so I was happy to see @Poodmund made a new version, many thanks for that I would love to use it in conjunction with the Spectra visual overhaul mod that I already use. Does anyone already have a ready to use OPM EVE config that works with Spectra, that I can shamelessly steal? Thanks
  2. Works fine for me with both installed. Most likely culprits are things like B9 Partswitch, tweakscale or Interstellar Fuelswitch.
  3. Hi folks. I decided to use New Horizons the first time for my new playthrough - What is the recommended CommNet setup in the difficulty settings for this?
  4. Wow, this is a nice one @allista - tested it and love it. Thanks
  5. Thanks, just a quick fyi, you forgot to change the download link to the 1.0.2 zip :-)
  6. @Nils277, good news, on the stock copy with the modified KRnD and KPBS only, the exceptions are gone and KRnD works normally now. @-MM- on my regular copy with *all* the mods I keep getting a broken KRnD, so I guess I need to keep digging what else is conflicting.
  7. @Nils277 @-MM- - I have to clarify my posting a bit. I did not have an EVA problem, I also do not personally use TAC LS, I originally started an existing save after updating a few mods and got spammed by exceptions when I entered the VAB. Every single part I had installed was listed with the before mentioned error message and KRnD could not be applied to *anything* anymore. Then I made a copy of stock KSP, using only stock Squad folder, Modulemanager 1.7.4 and KRnD and tested mod after mod in the order of the last updated ones (obviously also always deleting mm cache and parts database and then starting a new career game for testing) until I found the one that caused the exceptions in conjunction with KRnD. So the only mods installed before I verified and posted the error here where KRnD and modulemanager 1.7.4 and Planetary Base Systems(+CCK). I will test the new version now on my test copy and see if that fixes the problem. Thanks
  8. I am getting the exact same error (no original-stats for part 'xxx' (xxx=seemingly all the installed and qualified parts are being reported with this into the log) at KRnD.KRnD.updatePart (.Part part, KRnD.KRnDUpgrade upgradesToApply) [0x00000] in <filename unknown>:0) now with the current version of "Kerbal Planetary Base Systems". Only fix I found is to remove Base Systems. I spent some time looking through the files and tried to blacklist things, but nothing worked. I have no idea what @Nils277 changed that could cause this
  9. Hello @Waz, would you consider renaming the EVE release files with a version numbering, so we don't have to compare download date on the last downloaded mod file with the current release date on github everytime? Obviously a convenience request, the mod works fine anyway Thank you for keeping this alive
  10. Make sure you really deleted the correct thing, then go to the gamedata directory and remove all modulemanager cache files (everything starting with modulemanager *except* the ModuleManager.2.7.2.dll itself). Restart the game, and check in sandbox mode what is required to build rockets from an EL workshop.
  11. @Padishar thank you for this wonderful mod. I have one simple question, do you have to apply the padding manually everytime you restart the game? I have noticed padding = false is set by default, and I am not sure if that is safe to turn on and if you still should manually invoke it by alt-end after a while even if that is set to true. (I am just assuming here that this setting does the auto-applying :-). Thanks
  12. I use this patch to do sort the smart parts into control, because I am to lazy to change all the configs again on updates: @PART[km_smart_alt_low,kb-fuel-breaker1,kb-fuel-breaker3,kb-fuel-breaker15,kb-fuel-breaker2,FuelController,km_smart_fuel,km_prox_sensor,km_valve2,km_valve,km_smart_time,km_smart_speed,km_smart_radio]:AFTER[SmartParts] { @category = Control } Maybe it saves one of you some time :-)
  13. My 2 cents on the whole compatability thing: If you dont want compatability problems, you need to manually take care of it yourself. Mod Authors cannot foresee the combination of mods a user has. Its not as easy as using some mod manager software, but its also not so complicated you could not do it yourself. As for compatability, you need to be in control of what modules get applied to which parts. I delete the inclusion patches that come shipped with tweakscale and only apply tweakscale to certain parts like structural stock parts and Infernal Robotics with my own tweakscale MM patch. Sometimes Mods come with tweakscale configs included and you might want to check if you really like to keep those or not. I got rid of interstellar fuel switch which is way too invasive in its implementation - for some reason, the author decided it would be a good idea to apply it to @PART[*] instead of defining the parts that would receive it. I personally had IFS back then for Fuel Tanks Plus, which recently dropped IFS as a dependency and lets you use Firespitter instead, which does NOT include itself to all parts and is therefore a recommended alternative for all texture switching parts. (Nertea uses B9PartSwitcher for Near Future Tech, which also is not as invasive as IFS and should also not give you trouble controlling it). What I mean is - decide yourself what parts tweakscale and other Part changing mods apply its module to and check if you really need Interstellar Fuel Switch - If you do, you can basically not *prevent* it from getting applied to all qualified parts, instead you can only try to make a custom mm patch that should *remove* the applied IFS module from a tank/engine that you dont want or need it on by something like this (no guarantees, I bascially wrote that out of my memory, not tested :): @PART[FuelTank]:BEFORE[KRnD]:AFTER[InterstellarFuelSwitch]:NEEDS[InterstellarFuelSwitch,KRnD] { !MODULE[InterstellarFuelSwitch]{} } (What this does is telling Module Manager to remove the module [InterstellarFuelSwitch] from the part [FuelTank] before KRND is run, because it needs to do it beforehand so KRND has not already blacklisted the part, and after IFS so the IFS module applying has already happened. Otherwise IFS would be removed but KRND might not get applied anyway. Only run this Patch when both mods are actually installed.) If you have done the work once, you can place all your custom module manager configs in a separate folder that you can back up for reinstalls, so you dont have to do the same work twice. In the end, you should only have parts that have a part changing module on it, that you decided on beforehand. And if you ever see a part ingame that has two conflicting modules on it, you can patch it with a variant of the above example patch. Remember to delete the Module Manager cache files in your /gamedata/ folder (ModuleManager.ConfigCache, ModuleManager.ConfigSHA, ModuleManager.Physics, ModuleManager.TechTree) when you made changes, also delete "PartDatabase.cfg" in the Kerbal Space Program folder when you changed your partlist (at least when you delete a part or a mod with parts).
  14. Would using the arithmetic function of modulemanager: PartStats { mass *= 0.99 } not prevent any negative mass problems? This example would reduce mass by 1%, not a plain number. Thanks, Dani PS: The quoting and code box function of this forum software is a crime against usability.
  15. Thanks @linuxgurugamer This will become especially helpful when kopernicus has been updated :-)
  16. Before there goes more hearsay into this, I would like to point you to a source. The default behavior of PartStatsUpgradeModule seems to be replace, there is an additive update function in there too though. Quote: " the "IsAdditiveUpgrade__" field. This field tells the PartModule Load to add the UPGRADE nodes additive. If it is false the nodes will overwrite each other this is only applicable to the PartStatsUpgradeModule. " Another Quote that is important: " The PartUpgradeManager ScenarioModule handles the Upgrading. Mods can Interface to this to modify the stock upgrade behaviour and extend" You can check this out for more info: