Tebryn

It's past the part loading stage in your log file, and it's into module manager patching, somewhere around or after UmbraSpaceIndustries. honestly, the output_log file from your KSP_Data or KSP_x64_Data folder (depending on which you use) is much more useful. the NRE you have in that Log doesn't have any useful data that the output_log file has. But looking at everything else, It looks like you have KSPI and KSPI-Lite installed at the same time. you have /interstellar/parts and /warpplugin/parts/ being loaded in the log file. both installed at once will cause a LOT of problems. Right now, Delete your OpenResourceSystem, Interstellar, Warpplugin, UmbraSpaceIndustries and CommunityResourcePack folders and reinstall KSPI (Not lite, unless that's what you want, in which case your in the wrong thread). Then reinstall your USI mods (go get the latest versions using ORSX). This SHOULD clean up most of it. After that if your still having problems then come back with your output_log file. with KSPI and KSPI-Lite floating around in your gamedata folder there isn't any way to figure out what else is going wrong.

Bleh, coming from KSPI where 1EC/S = 1kW this makes thing confusing at times. But I have started to get used to doing the mental math when I am look at one readout or another. I think Near Future uses 1 EC/s = 1kW as well, but I don't use it. Just based off a quick look at the reactor configs.

nope, you don't delete ORS, it runs some core functions in KSPI. ORSX was designed to not step on ORS, so you're safe to run them both at the same time.

8 or 9 posts back.

I have had this ship destruction event happen a few times myself, but only a few times, so I never bothered to try and run down the cause. Thinking back though, it was almost always with KW engines and the problems I had might have had something to do with the fan patched hotrockets KW config I had. (I have since updated to a newer fan patch, as well as updating the smokescreen dll) but I'll see if I can't get it to happen again and get a logfile for it. I would have never made the connection to smokescreen if I hadn't stumbled into this thread. (I'd have likely just shaken my fist and blamed KSP again)

This is mostly in regards to the IXS KSPI version, but some things might also be true for the other versions. Got a few things, big one.. number one... could you please set your 'name = ' in the part.CFG to one word names with no spaces? you're currently using multiword names for the internal part identification name and that screws with the ability to identify the parts with modulemanager config files. (I don't know how or if this affects other things in KSP) http://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation#General_Parameters Fixing this will likely break existing saves. (unless you copy the renamed parts and on the original version set the 'TechRequired = Depreciated' and 'catagory = -1' this hides the parts from the VAB and R&D buildings. but existing ships can continue to fly without problems. This won't increase memory load significantly because the same texture files would be reused) Other things... Since your science experiment parts are so large (a one ton Gravioli detector just to match the looks?), you might look at combining multiple experiment modules into single parts. EG: Materials Science/Mysterious Goo; Gravity/Magnetometer/Thermometer/Seismic; Atmospheric/Barometer; Etc... Your LFO Fuel tank also holds more fuel than an Orange tank, despite being smaller... Some of your parts have the TechRequired nodes a little out of balance, with nodes that are earlier (significantly in some cases) than the KSPI equivalent tech unlocks. EG: main hull (with antimatter reactor) unlocks at interstellarTechFusionPower instead of interstellarTechAntimatterPower and IXS Q-Vac engine unlocks at interstellarTechFusionPower2 instead of interstellarTechUHEPhysics and was there a reason to include ModuleScienceContainer on the karbonite detector? it's not required to get the Karbonite Scan experiment to function... Once the names are fixed, it is significantly easier for other mod authors, or users to do things like adding SCANsat compatibility to the karbonite and Gamma Ray Spectrometer parts with a simple patchfile (or add things like TweakScale, or FireSpitter resource tank toggles) { MODULE { name = SCANsat sensorType = 15360 fov = 4 min_alt = 5000 max_alt = 750000 best_alt = 100000 scanName = Resource Scan power = 0.5 } } @PART[IXSKarboniteDetector]:FOR[KASA]:NEEDS[SCANsat] // KASA IXS Karbonite Detector - Add SCANsat Support [ORS Karbonite] { MODULE { name = SCANsat sensorType = 262144 fov = 4 min_alt = 5000 max_alt = 750000 best_alt = 100000 scanName = Resource Scan power = 0.5 } }@PART[IXSGammaRaySpectrometer]:FOR[KASA]:NEEDS[SCANsat] // KASA IXS Gamma Ray Spectrometer - Add SCANsat Support [ORS Water, ORS Uranium, ORS Thorium, ORS Alumina] I have a hefty MM patch file that does most of what I have mentioned. But I had to fix the part names to get it working. otherwise I would just post the full patch for anyone who wants it. (if the names were already sane, the patch wouldn't have broken any existing ships) Edit: I guess this might come across as all negative, but I want to say I really like the idea, and the work you have put into it. If I hadn't been interested in what you had done I wouldn't have bothered to put in the time looking at the balance of parts to fit it into my existing game. So thanks for pushing this out for the community!

check your ORS folder, if your running KSPI-Lite 12.3 you should have OpenResourceSystems_1_2_1.dll in the folder (and only that version). Extra versions, or wrong versions will break KSPI-Lite in the manner you have described. If you running karbonite (or MKS/OKS) then you should also have a copy of the ORS DLL that it installs in the ORS folder (v1_2_0 IIRC) you need to move this version from your ORS folder to the USI folder (if it doesn't have a copy there already) that should solve your problems. Also... there is a ORS_1_3_0.dll running around out there now that was pushed by FractalUK for his new version of KSPI. this version is actually Behind in features vs the ORS 1_2_0 and 1_2_1 versions that were pushed in his absence. don't use it with KSPI-Lite or MKS/OKS.

sounds like maybe an ORS conflict of some kind for the drills. you will want the latest ORS*_*_*.dll version you have in the ORS folder. You want to have a copy of the 1_2_0 dll in your USI folder (if this is missing, and you don't have ORS v1_2_0.dll in your ORS folder, your USI drills and many other USI modules break). SCANsat should have a copy of the ORS v1_1_0.dll in its plugin folder (removing or changing versions causes your big map to go blank when using ORS overlays) And I think this conversion adds the USI resource extraction method to the EPL drills, so an ORS conflict would likely break them too.

Just got done installing EPL and the conversion, While i can reproduce the MIA problem, I couldn't do so reliably... It generally happened after a scene change to KSC and back. sometimes after I returned the vessel from orbit, sometimes after I just hopped it from the launch pad to the grass. KSPi Lite 12.3 MKS/OKS 0.20.9 EPL 4.2.3 Karbonite EPL Conversion 16-7 TAC-LS 10.0.12 KAS 0.4.8 Edit: I noticed that the OKS module can and does tend to fall through the runway, but this doesn't seem to be limited to your part alone, as the USI modules do the same thing, so i edited out that bit. As far as the MIA issue, I am trying to get it to generate something in the Logfile for me to help debug the issue...

Put the ORS DLL that comes with KSPi-Lite in the ORS folder, remove all others from that folder. Leave the ORS 1.2.0 DLL in the USI folder, and leave the ORS 1.1.0 DLL in the scansat folder. That should get you running with all USI / KSPi-Lite / SCANsat

Which ever works, I was just under the assumption that the general move was to consolidate in one folder and not have a bunch of different Plugin versions flying around. Thanks for the Fix BTW.

I spent some time and figured out what caused this myself, You have an older version of OpenResourceSystems DLL in your gamedata folder. the latest version of KSPi-Lite requires version 1.2.1 (and only that version) in the OpenResources folder. This, on it's own makes KSPi-Lite work. But it also breaks all the drills in USI. After some back and forth with rover, we found that if you put the ORS V1.2.0 DLL in your USI folder, you can get USI working again, and still have KSPI Functioning as intended. Rover plans on changing his packs with the next release to fix this. (he also has me switch over to a hotfix ORSExtensions.dll from his dropbox. but this was when he was trying to get the new DLL to play nice with the old one in the ORS folder. If moving the old one to USI folder doesn't work, go try adding it Link) So the break down: 1.) go to GameData\OpenResourceSystem\Plugin\ and remove all OpenResourceSystem_*_*_*.DLLs except 1_2_1 2.) Go to your GameData\UmbraSpaceIndustries\ and copy (from your latest roverdude pack) OpenResourceSystem_1_2_0.dll into this folder. 3.) If your still having problems go HERE and get the HOTFIX ORSExtensions.dll and copy it over (overwrite) the existing file at GameData\UmbraSpaceIndustries\ If you want to follow the Issue I posted at Roverdudes Github about all this, it can be found HERE (I was honestly expecting just a recompile against the new ORS version, but got this instead for now) Edit: And i get Ninja'd by the dude himself as i am working this up. go figure.

you are operating under a really bad assumption. not everyone has the same driver set that you have. not everyone is running the same OS version as you (including hotfixes and builds). Many of these people will have hardware that isn't what you have. None of these automatically means that the person has a flaky machine. It means that Unity Winx64 version that Squad is building their game on is prone to random errors. These can be caused by software conflicts, hardware conflicts, or just bad code in the engine. None of which means that the person is running a broken down on it's last legs machine. The Software and Hardware that might cause problems with this one game engine can run perfectly clean code and be rock stable on it's own. So just because you happened to have a perfect environment to run KSP x64 on doesn't mean that other people are screwing up. And the number of people reporting problems pretty conclusively points to a problem with the game engine. https://yourlogicalfallacyis.com/anecdotal

ran into a error that crashed my FPS and spammed my log. had a vessel on the mun, no science containers or experiments, MKS modules (command unmanned) and a few attached mechjeb AR-202 modules (command unmanned) I didn't have the error the first few times I loaded the various docked vessels, but it started throwing the error below as I was bringing in the 4th vessel to dock with the rest (as soon as I got into physics range). loading my last quicksave, jumping to the space center and even reloading the game didn't help. I was able to stop the error by using KAS to detach all the mechjeb modules. As soon as the last one was detached, the error stopped. I didn't even need to store or delete the parts. Hopefully this is enough to figure out what caused it. (I still have the output_log file, but it's 122mb because of the spam) Output_log Parameter name: index at System.Collections.Generic.List`1[ModuleScienceContainer].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at ForScience.ForScience.TransferScience () [0x00000] in <filename unknown>:0 at ForScience.ForScience.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1)KSP.log [EXC 11:51:23.570] ArgumentOutOfRangeException: Argument is out of range. Parameter name: index Science Alert v1.7.1 (noticed I forgot to include this earlier) For Science v 0.24.2-1 MechJeb 2 v 2.3.1.0 Dev Build 316 USI Kolonization V 0.20.8 KAS 0.4.8 KSPi Lite V .12.2 (PFission reactor, Generator, deployable radiators and ISRU were part of the vessel involved. But I don't think it was related) If I get it to happen again, I'll try and get more information and a cleaner log file. Edit: It's been happening enough for me to try and find a conflict, Uninstalled all addons except Squad, NASAmission, and ForScience started a new save, and I still get the error. I load in, launch a fuel tank, nothing else, and the log starts getting the error spammed, I add a command module, and it goes away. tested on x32 and x64 Output_Log.txt from x32 test, no other mods. https://mega.co.nz/#!EZ0STCZY!xSpJ8mxv2uFpWQqNmCoktU5q_BDv_aBSc6vuq7-rVxA

I've used anti-node a few times when I had a vessel that was a puller design, and I forgot to (or for tech limitations couldn't) put a Probe/docking port aimed in the correct direction. Helps a lot when you're pulling a 3k ton asteroid under those limitations.

I doubt it would be a cause for a memory leak, but I guess it's possible. I have about 1400 MM part configs (150 or so that are hidden because I don't have the part it's looking for) that load when my game loads, and I don't see a significant memory load from that (all my load is coming from texture packs and the like). And in the end it may not be a MM CFG issue, it just looks and sounds a lot like a problem I had when I forgot to save a change to a part edit, and ended up with a MM file pointed at a part with no change being made.

@ghostshark27 I think you might have an empty or corrupt MM config file being loaded. it locks up while loading MM cfg files here : Config(@PART[Mark1-2Pod]:FINAL) SDHI/Service Module System/Parts/MM_configs/SDHI_SMS_MMPatch_Mk1-2Pod_umbilical/@PART[Mark1-2Pod]:FINAL I had a lockup in a similar manner when i had a MM config that was aimed at a part, but had an empty module for insertion (threw null error over and over in the log) your best bet is to crawl through all your module manager CFGs and see where one is screwing up. anything you have edited yourself would be prioritized. and then whatever mod you installed before you started having problems.

I just use F1 ingame, takes a screenshot at full resolution. I play at 2650x1600 though. I also never use photobucket. Do the screenshots look fine before you upload them? because photobucket is making it look like you play at 800x450...

Solar Collector system I started putting in, I have since upgraded to a newer design, but essentially the same idea. Just more power. At ~575km orbit I get 5.5GW of power. My newer systems (which I haven't made an album for yet) are single unit launches, no need for assembly in orbit (or refueling), and I should get about 18GW at the same orbit (NearFuture Solar) Mods used: Interstellar, UbioWelding, B9 Aerospace (.23.5 community fixes), MechJeb, Infernal Robotics, Kerbal Attachment System