INSULINt

Members
  • Content Count

    229
  • Joined

  • Last visited

Posts posted by INSULINt


  1. 1 - I don't know if this would also be possible in OSX, but depending on how it handles shortcuts/symlinks it should be possible. AFAIK, impossible on windows.

    2 - This is more for people who use steam. Sure you can have multiple installs on steam, but then only 1 can use the steam overlay, add to your hours played amount, etc. All I can think is that this might save a minuscule amount of space for non steam people, or maybe be a little more organized?

    OK, now that that's out of the way, what am I talking about here? I'm talking about using symlinks in linux to have different GameData folders that you can launch the game with different part/mod configurations, but have a communal settings.cfg, and all your saves in one place. For the text part of this I'll stick to a dual stock/modded setup, but for mine I actually have 3: stock, some info/utility mods, and then modded to all craziness. First, lets set up the multiple GameDatas:

    1 - Choose a location for them, I picked ~/KSP.Installs, then create your subfolders there for each GameData (eg. Stock, Modded)

    2 - If your current install is modded I'd suggest cutting a pasting your GameData folder from your KSP install location into the Modded folder, then verify files in steam and cut/paste the new stock GameData into Stock. If you're running stock, copy/paste the KSP install GameData to both Stock and Modded, then add mods to Modded as desired.

    3 - Delete your KSP install GameData folder if it's still there. You won't need it, and it'll confuse the launch scripts if it's there.

    Now, to create the scripts. Create a file named something like KSP.Stock.sh and put this inside it:

    rm ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/GameData
    rm ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/PartDatabase.cfg
    ln -s ~/KSP.Installs/Stock/GameData ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/GameData
    steam steam://rungameid/220200

    Note that this assumes you put your stock GameData in ~/KSP.Installs/Stock, and that your have KSP/Steam installed in their default configurations. Now mark it as executable through the properties window or "chmod -x" and run it. If you run it in a terminal, there will be at least 1 error saying that ~/.steam/steam/steamapps/common/Kerbal Space Program/GameData isn't there, and that's fine, cus the folder shouldn't be. There should now be a symlink to the Stock/GameData folder in the KSP install directory, and it should load up as stock.

    For the Modded script:

    rm ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/GameData
    rm ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/PartDatabase.cfg
    rm ~/KSP.Installs/Modded/GameData/ModuleManager.ConfigCache
    rm ~/KSP.Installs/Modded/GameData/ModuleManager.ConfigSHA
    rm ~/KSP.Installs/Modded/GameData/ModuleManager.Physics
    rm ~/KSP.Installs/Modded/GameData/ModuleManager.TechTree
    ln -s ~/KSP.Installs/Modded/GameData ~/.steam/steam/steamapps/common/Kerbal\ Space\ Program/GameData
    steam steam://rungameid/220200

    And this should load up the game using the Modded/GameData folder. Now, the reason for the rm commands for PartDatabase.cfg, and all the module manager data files, is that I've found that when adding or changing parts even in a single install removing PartDatabase.cfg prevents buggyness when you load the game again. The same reasoning applies to the MM stuff. By deleting those files I'm hoping to prevent 99% of the problems when I start the game.

    Anyways, hope you all find this interesting at least, and here's some pics of the folders/scripts as reference:

    Javascript is disabled. View full album

  2. It's definitely something in the kerbolplus folder that kopernicus doesn't like.

    I now have a successful install of Trans-K, OPM+Sigma and K+, with everything from the latest zips, using K+'s Kopernicus system.cfg and dll, but using the KerbolPlus folder from the 2.0.5 zip.

    - - - Updated - - -

    Just found the problem. Line 53225 of output_log.

    Exception: "Ganag-Kal" not found.
    at Kopernicus.Configuration.Loader.Generate () [0x00000] in <filename unknown>:0

    at Kopernicus.Injector.Awake () [0x00000] in <filename unknown>:0
    UnityEngine.GameObject:Internal_AddComponentWithType(Type)
    UnityEngine.GameObject:AddComponent(Type)
    AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
    AddonLoader:StartAddons(Startup)
    AddonLoader:OnLevelWasLoaded(Int32)

    Looking at the configs (you added kal since 2.0.5?) Kal has "referenceBody = Ganag-Kal", but you've set the name in Ganag-Kal.cfg to "Ganag-Kal-Barycenter". Also, Ganag has "referenceBody = Sun" (possible typo?)

    EDIT: Changing "Ganag-Kal-Barycenter" to "Ganag-Kal" fixes the stuff not loading issue. Basically makes Kal a moon of Ganag tho. It makes sense now why there was 1 MM patch amount difference: You removed Calad, but added the Barycenter AND Kal, which loaded, but made Kopernicus angry because of grammar, basically


  3. I have the same problem. The Kopernicus config loader throws an exception at startup, and I get no planets with the latest Trans-Keptunian and OPM+Sigma. 2.0.5 works fine. In both cases I'm using OPM's Kopernicus system.cfg and dll.

    Logs: https://www./folder/b4u546vdp761b/Kerbol_Plus_Logs

    EDIT: hope this helps. I love this mod!

    EDIT: There is also 1 less MM patch when I switch back to 2.0.5.

    MOAR EDITS: It also seems Calad is no longer in the latest build?


  4. Not sure if this has been mentioned, but I realized after watching Scott's vid on the LV-N that the mk1 liquid fuel only tank is WAY underfilled. 150 LF in the same space as 180LF/220OX? Looking at the mk2 parts, the LF only tank has 400LF and the LF/OX has the same 180LF/220OX as the mk1 half tank. Easy MM fix, and it makes the tank actually weigh around the same as the LF/OX one, much like the mk2 parts, which also makes me think this is somewhat of a stock "forgot to carry the 1" type thing...

    @PART[MK1Fuselage]:FIRST
    {
    @RESOURCE[LiquidFuel]
    {
    @amount = 400
    @maxAmount = 400
    }
    }


  5. You have a narrow band scanner on those vessels too, right?

    That's an interesting bug. It's deactivating the SCANsat module on those parts, which removes the Ore scanning module from the SCANsat sensor, but doesn't affect any of the other modules.

    You can fix this for now by finding the resource scanner module manager config (GameData/SCANsat/MM_Parts/SCANsat_Resource_Scanner.cfg) and editing or removing the narrow-band scanner config. The narrow-band ore scanner is the first config in that file. You can either delete that config or change the activeModule line to true.

    Yes, both part are on those probes, and I stumbled upon why I had data from kerbin: I activated the narrow band on that sat, but not the others. I didn't even realize I'd activated the narrow on the kerbin one :/ Crazy bug for sure, but the basic "workaround" is activating the narrow band.

    Also realized I need the MKS orbital camera (MKS_Antenna part) to zoom in on the other resources, so I tested out the survey scanner with the MKS part. The MM patch for the MKS part doesn't kill the survey's ability to scan those other resources. Active module vs. not?


  6. Basically, I send up a probe with the stock folding dish scanner at at altitude of 250km, polar orbit, hit start resource scan. Every resource EXCEPT ore shows up. I've got insta scan and biome lock turned OFF. Now, without changing those options, I click perform orbital survey and all the stock overlay and everything shows up for all resources, INCLUDING ore. This is for the Mun and Minmus so far. Kerbin scans fine, which is really weird IMO. I really don't know how to make it clearer? I do have CRP and MKS/OKS installed.

    Here's an output_log from my latest KSP run: http://www./view/in2zflenbawggwz/output_log.txt


  7. Tried reducing the deflection %'s for Dynamic Deflection further? Mouse over any control surface, press 'K', reduce the numbers in the second column. (It sounds like the root cause of your issue is a small plane with significantly above average control authority so the defaults will probably be a little too light)

    Maybe. I am using mk3 wing parts and control surfaces on an mk2 fuselage....


  8. If Dynamic Deflection isn't sorting it, another possibility is fuselage flex constantly altering the relationship between the cockpit and elevators, causing them to go berserk in response. How big and wobbly is this thing?

    It's a small spaceplane. It uses the mk2 cockpit and it's only about 5 cockpits in length, 4 engines wide + the new large delta wings. It has dual vertical tail fins and canards on the front. It's also strutted and has 0 wobble. The whole plane oscillates as one piece without bending


  9. Dynamic Deflection helps, but the pitch oscillates WAY too much that the plane can't keep it's pitch heading at all. I literally have to constantly tap s to keep it going, but then when I hit a certain speed the oscillation blows the plane to bits :( I think the major problem is that pitch oscillates into the pitch-down range so the nose just keeps dropping. Changing the deflection only decreases the rate of nosing down, and I need it to just not be doing that.

    Pilot Assistant just causes a major kracken attack....


  10. So, as someone who installed this so I can use Trajectories, and basically not use MechJeb cus it doubles up way to much on what other mods do, what can I do to keep my SAS from freaking out?

    Like, pitch wobbles from min to max, even with fine controls. Is this a bug, or am I just totally doing it wrong and should just go back to MJ (I don't hate it, just hate its ui mostly....)?


  11. I'm trying to create an MM patch to make all dish antennas into omnis just so I don't have to edit all the cfgs LOL:

    @PART[*]:HAS[@MODULE[ModuleRTAntenna]:HAS[#Mode0DishRange[*],#Mode1DishRange[*]]]:FINAL
    {
    @MODULE[ModuleRTAntenna]
    {
    @Mode0OmniRange = #$Mode0DishRange$
    @Mode1OmniRange = #$Mode1DishRange$
    !Mode0DishRange = delete
    !Mode1DishRange = delete
    }
    }

    @PART[*]:HAS[@MODULE[ModuleRTAntenna]:HAS[~Mode0DishRange[],#Mode1DishRange[*]]]:FINAL
    {
    @MODULE[ModuleRTAntenna]
    {
    @Mode0OmniRange = 0
    @Mode1OmniRange = #$Mode1DishRange$
    !Mode1DishRange = delete
    }
    }

    It edits the right antennas, but doesn't add the omni ranges. Any ideas?