Jump to content

NathanKell

Members
  • Posts

    13,340
  • Joined

  • Last visited

Reputation

5,965 Excellent

Profile Information

  • About me
    Keepin' it Real

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. i'm trying to open ksp with realism overhaul but the game frezes in loading parts upgrades

    i'm using the spanish version

     

    1. Nicolas xd

      Nicolas xd

      i'm using ckan

       

  2. Yup, that sounds wacked. I don't know how any of the KK code works, except the build errors I fixed to get things running on 1.12, but I can try to take a look this weekend and see if anything turns up.
  3. Looking at the log, it looks like what's going on is Kopernicus is loading a crapton of maps, and that causes things to die (you can see this at the bottom, where it loads map after map and then keels over). Assuming things do work correctly if you use the same modlist but remove (only!) KK, then my hunch is that KK requires things to not be loaded on-demand (which is usually how Kopernicus saves memory when you send it a crapton of planets with hirez assets), which is probably pushing you over. How much memory does this machine have, and how much RAM was free before launching KSP?
  4. Released v1.8.3 for KSP 1.8+ with the fix for 1.12.
  5. Sweet! Thanks for testing, folks! I'll make the release this evening.
  6. Ok, so the version of Unity used by KSP 1.12 finally hard-deprecates GUIText, it looks like. I replaced it with the suggested replacement (UI.Text) and recompiled, and it seems to work. Can you please test this? If it's good I'll make a release. https://www.dropbox.com/s/z191mfy69u2w31f/KerbalKonstructs.dll?dl=1
  7. If you are playing in sandbox, enable "Enabled All Part Upgrades in Sandbox" in your difficulty settings. PF diameter limits are set via upgrades, and for some reason Squad defaults to leaving that option defaulted to off in difficulty settings, meaning your diameters are locked in sandbox.
  8. You have "1.11" or "1.12" or both checked as compatible versions in CKAN and ended up with a version of Real Chute that is incompatible with 1.10. The same might be true for other mods. Make sure you have no compatibility overrides set in CKAN and try a clean install again. @OnlyLightMatters
  9. Yep, though I'm sure HebaruSan will get you sorted out. My guess is that it's either due to a permissions thing (having KSP installed in Program Files, which has some weird permissions stuff, so try copying your KSP install out of there, pointing CKAN at the new location, and trying again), or due to somehow having a program running that is accessing that file (either KSP itself, or maybe Steam, or another CKAN instance, or I dunno what). I highly, highly recommend getting that sorted out and using the express install option.
  10. Apologies, I've been fairly busy the last few days. I've updated the OP to mention that if you are installing manually you should also grab Custom Prelaunch Checks, and I've also updated the Readme/frontpage on the git repo. However, I do not plan to include dependencies in release archives, as I would prefer for the release archives to just be the releases for this mod, rather than also including other mods as well. If for some reason CPLC is updated and KK is not, I don't want to be in the business of still having a release archive with an outdated mod in it (honestly, this is one reason I absolutely adore CKAN as a mod author, it means there aren't zip files floating around with outdated versions, or at least there are fewer of them. ) EDIT: in particular, I linked our Custom Prelaunch Checks repository's releases tab (i.e. the KSP-RO fork), rather than linking to the 1.8 version. It's reasonably likely we'll need to make edits going forward, so that's the live repo to grab it from. This is exactly what I mean about versioning, it's a right headache! For the similar reason re: busyness I haven't a chance to address the 1.12 issues; I had hoped I would have time this weekend but I'm doubtful I will. I'll be looking into it ASAP, and again apologies for the delay.
  11. If there are any other fixes already done, please don't hesitate to PR them.
  12. v13.3.0 * Fixed thrust axis (for ullage etc) to use KSP 1.2+ support for multiple thrust transforms. * Fully hide B9PS switcher in flight. * Fix some issues with tooltips. * Fix EntryCostModifiers not interacting correctly with PartUpgrades. * Use independent throttle, if active, when determining if an engine is throttled up. * No longer include dependent mods in the archive - CKAN installs them for you.
  13. Sounds like incompatible mods--I recall that's the usual fail case on 1.12, so I'm guessing you're on 1.12. Note that right now RSS is blocked on CKAN for 1.12 due to ModularFlightIntegrator not being available, so I'd suggest downgrading to 1.11 meanwhile.
  14. The issue is the C# object can be non-null but the underlying Unity object can be destroyed (i.e. freed in C++). Example: // For some gameobject foo MonoBehaviour comp = foo.AddComponent("ComponentType"); GameObject.Destroy(foo); bool isNull = comp == null; bool isNullCast = (object)comp == null; Now, isNull will be true, but isNullCast will be false. That's because you have a C# reference to the component, so GC doesn't clean it up, but Unity has freed the underlying (i.e. unmanaged C++) memory. This is the very reason for the speed increase from casting to object, namely that you shortcircuit Unity doing its extra work to see if the (Unity) object was destroyed. In some cases this can be safe enough, i.e. when you know that a component will either exist (and not be destroyed), or not exist at all; but if there is a chance of it having been destroyed, doing the casting is unsafe because you will not get the correct answer.
×
×
  • Create New...