• Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Marandil

  • Rank
  1. I rolled back with this to 1.6.1, reinstalled all the mods and still the ksc++ is scattered all over the damn island. Anything I may be missing? Should I ask in another thread instead?
  2. I'm trying to setup a minimal working modpack with GPP rescaled to x3.2 and KK (for GPP_KSC++). However, I must be missing something because I'm getting the upgraded KSC scattered all around the place as if KKtoSD was not installed. My setup: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManager v4.0.2.0 GPPTextureChecker v0.0.0.0 KerbalRenamer v1.0.0.0 SuitProg v0.0.0.0 Sigma88LoadingScreens v0.4.0.0 KerbalKonstructs v2.0.0.0 / v1.4.5.64 Kopernicus.OnDemand v1.0.0.0 ModularFlightIntegrator v1.0.0.0 / v1.2.6.0 Kopernicus.Components v1.0.0.0 Kopernicus.Parser v1.0.0.0 Kopernicus v1.0.0.0 SigmaDimensions v1.0.0.0 KKtoSD v1.0.0.0 MiniAVC v1.0.3.2 Sigma88LoadingScreens v0.4.0.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 Folders and files in GameData: GPP KerbalKonstructs KKtoSD Kopernicus ModularFlightIntegrator RESCALE Sigma Stock folder: Squad KSP.log file: Thoughts?
  3. A couple more errors related to Kerbalism: I've posted the full log here: Hope that helps
  4. I'm trying to compile a set of mods for 1.7 and Kerbalism (after renaming the .bin and shaders to 17) throws a cascade of NRE: 67791 NREs total, 45371 with OnGUI and 22416 with Update. Is this expected?
  5. Marandil

    Mods for a stockalike hardcore-style career

    @Tyko: I may give ReScale a try. I was reluctant to it because it used to break stuff. I posted the problems to highlight the issues I had in the current run and would like to avoid in the future. So far it seems that dropping SSTU and OhScrap is the way to go (AFAICT the issue with Kerbalism is more complicated and requires wait for a next release anyway). I'm rather looking for suggestions on what to drop & what to add to make this work .
  6. I'm pretty sure you're talking about procedural thrust plates, but I'm not 100% if that was the right mod with them:
  7. tl;dr: I'm looking for a set of mods for a hardcore-ish/real-ish/stockalike-ish career, because my old set is not really playing well together. Full: For a month or so I have been playing a career campaign focused on "Iron man" or "Hardcore" style - no quicksave, no reloads, no reverts to launch; no 3-rd person view during launch/manual steering, only cameras or map view, etc. I am quite happy with the experience, but it turns out the mods selected do not always play well with each other. I listed my concerns below. I am looking into restarting with a new set of mods (and possibly on a new KSP version) and would like to hear your suggestions regarding mod selection and interactions. Note: I'm not really into bumping the challenge by simply making the game extremely hard or going full RO; instead I want to be forced to plan ahead. Try and experiment, but with consequences. E.g. no manned flights, unless I'm certain I have an emergency plan and so on. I'm currently playing with the following mods (+/- dump from `ckan list`) KSP Version: Installed Modules: - B9PartSwitch v2.6.0 - BluedogDB v1.5.2 - ClickThroughBlocker - CommunityCategoryKit - CommunityResourcePack - CommunityTechTree 1:3.3.6 - ContractConfigurator 1.27.1 - CrewQueueTwo - CryoEngines 1:0.6.5 - CryoTanks 1.1.1 - DeployableEngines 1.0.0 - DMagicOrbitalScience 1.4.2 - DMagicScienceAnimate v0.21 - DockRotate v1.6.1.32 - DynamicBatteryStorage 2: - EasyVesselSwitch 1.10 - EditorExtensionsRedux 3.3.20 - FerramAerospaceResearchContinued 3: - FirespitterCore v7.12.0 - FMRSContinued - Galileo's Planet Pack - HeatControl 0.4.10 - HullcamVDSContinued 0.1.11 - KerbalActuators - KerbalAlarmClock v3.10.0.0 - KerbalAtomics 1:1.0.0 - KerbalAtomics-NFECompatibility 1.0.0 - KerbalChangelog v1.1.4 - KerbalConstructionTime - KerbalEngineerRedux - Kerbalism 2.1.2 - KerbalRenamer - Konstruction - Kopernicus 2:release-1.6.1-2 - kOS 1: - KRASH - KSPRescuePodFix - KSPWheel - MagiCore - ManeuverNodeEvolved 4.0 - MarkIVSpaceplaneSystem 3.0.4 - MechJeb2 - MechJebForAll - ModularFlightIntegrator - ModuleManager 4.0.2 - NearFutureConstruction 1.0.6 - NearFutureElectrical 1.0.0 - NearFutureElectrical-Core 1.0.0 - NearFutureLaunchVehicles 1.1.10 - NearFutureProps 1:0.5.0 - NearFuturePropulsion 1.1.0 - NearFutureSolar 0.8.15 - NearFutureSolar-Core 0.8.15 - NearFutureSpacecraft 1.2.2 - OhScrap - RasterPropMonitor 1:v0.30.6 - RasterPropMonitor-Core 1:v0.30.6 - RecoveryController - RemoteTech v1.9.1 - SCANsat v18.10 - ScrapYard - ScrapYard_ContractConfigurator - Sigma88LoadingScreens (unmanaged) - SpaceXLegs (Kerbal Reusability Expansion) 2.8.4 - SSTUTools - StageRecovery 1.9.1 - StationPartsExpansionRedux 1.1.0 - SuitProg - TexturesUnlimited - Toolbar 1.7.18 - ToolbarController 1: - TrackingStationEvolved 4.1 - Trajectories v2.2.2 - UniversalStorage2 - USI-ART 1: - USI-Core - USI-EXP - USI-FTT - USITools - WaypointManager 2.7.5 - [x] ScienceContinued 5.20 Some of the problems I've had: SSTU/Kerbalism - apparently Kerbalism doesn't properly model SSTU solar panels and they simply don't work if the vessel is unloaded. ( OhScrap! - it would be cool if the part failures were somewhat integrated with Kerbalism; instead I observed they only happen on loaded vessels, which creates 2 problems: Easy to cheat by only loading vessel to perform an action When I had to keep a vessel loaded for a longer period of time (actually because of the previous SSTU issue with solar panels on unloaded vessels) my whole probe became a shining red lightbulb within real-time seconds (in-game month), even on tested parts . SSTU/RemoteTech - apparently SSTU probe cores are incompatible with RemoteTech and therefore totally ignore the RT requirements/model and are always controllable. This totally ruins balance and because so many SSTU parts have the probe core functionality, this became quite a weird ballache . Kerbalism - with the current mod pack I'm stuck at 2.1.2, because updating to 2.2 basically breaks the game to a point where it crashes upon save load. This is most likely a weird interaction with one of the other mods (likely `[x] Science!`, but not for sure: I might have some problems with missing GPP + Kerbalism configs, but didn't run into them yet. Has anyone else tried this kind of experience? What mods did you choose? Any recommendations?
  8. I see this mod is currently listed as 1.5.*, but it's a hard dependency for Oh Scrap, which is listed as 1.6.x. Are there any issues with running it on 1.6? If not, could you update the version requirements, because currently one cannot install either mod via CKAN on a 1.6 install, without messing with the compatibile versions matrix. Thanks in advance
  9. Have you checked the actual mass, or just the numbers in the parts menu? I had a problem where several tanks reported their original mass in the parts menu, but SMURFF'd one in "part info" (I think it is a KER extension, but dunno). Long story short, just verify this first
  10. I was sure the real Dragon 2 had crew capacity of 7 [source], but thanks for clarification.
  11. Nice pics One minor question about the Rodan pod, why does it have 5 seats in IVA, but only 4 available? Can we unlock the 5th seat somehow?
  12. @damonvv @JadeOfMaar (I'm not sure whom to ping in this case) File Patches/Extra_ResourceDefaults.cfg, lines 117-118 // Gojira II BFS-3800 Tanker Pod @PART[TE_18_BFS_TANKER]:NEEDS[B9PartSwitch,!Pathfinder] I assume should be: // Gojira II BFS-3800 Tanker Pod @PART[TE_18_BFS_TANKER]:NEEDS[!B9PartSwitch,!Pathfinder] (This got me into yet another SMURFF config conflict; I'm trying to create a dedicated SMURFF patch for Tundra btw, but still testing it on my setup ) Edit: @Gryphorim check if this helps your case as well Edit 2: it seems that @Crossman found the same issue, but his post was stuck in the "new poster" queue
  13. I need some help with debugging why the SMURFF patches don't apply to Tundra Exploration tanks and how to fix it (on either side). A simple comparison (I made a minimal install with CryoTanks, FuelTanksPlus, ModularRocketSystems, Tundra and SMURFF+RSS just to get the numbers): Size 2 Tanks: Ghidorah K2-81 Tank LFO 2160/2640 Dry/Wet 4.143 / 28.143 MRS 3/4 Jumbo LFO 2160/2640 Dry/Wet 0.714 / 24.714 Stock X200-32+16 LFO 2160/2640 Dry/Wet 0.714 / 24.714 W/out Cryo Tanks installed: FTP X200-48 LFO 2160/2640 Dry/Wet 0.600 / 24.600 W/ Cryo Tanks installed: FTP X200-48 LFO 2160/2640 Dry/Wet 0.714 / 24.714 Size 1 Tanks: Mothra B1-21 LFO 720/880 Dry/Wet 1.048 / 9.048 Mothra B2-S2 LFO 360/440 Dry/Wet 0.274 / 4.274 FTP FL-T1200 LFO 540/660 Dry/Wet 0.179 / 6.179 Stock FL-T800 LFO 360/440 Dry/Wet 0.119 / 4.119 I think the problem is with Tundra using patches for everything, including "no fuel switch" case and/or using B9PartSwitch in my setup. I've uploaded my KSP.log and ModuleManager.ConfigCache to gist (, either download them or click on "Raw"/"View raw" as they are quite huge and gist truncates them in webview). I think it may also have something to do with the previous issue that was causing SMURFF errors with TE (the one with addedMass), but I'm not sure yet. Any help would be appreciated .
  14. AFAICT, with SMURFF the tanks have a way too much dry mass right now, so I guess some SMURFF patches are not kicking in for Tundra like they are for other mods. I'll try to investigate this once I find some time spare time
  15. @damonvv cheers! I must have missed that one (recall reading about additional dependencies, just not this one).