Akira_R

Members
  • Content count

    610
  • Joined

  • Last visited

Community Reputation

160 Excellent

About Akira_R

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

904 profile views
  1. I don't really understand exactly what the problem you are having is.... BUT I can tell you that if you want your fairings shells to jettison you have to use the "payload" fairings. If you use the other fairings (I think they are called structural fairings) they do not have a decoupler and will not jettison, they are meant to create permanent hollow shells. I usually set up an action group that jettisons the shells and decouples the top node and I have never had any issues with the interstage fairing part. Also in regards to your earlier questions regarding dV readouts if whatever tool you are using there behaves anything like KER then anything that has to be decoupled manually will do that, basically if staging doesn't detach the parts then your dV utility won't know that those parts will be detached and it will calculate your dV as if those parts are still attached. I know that I have this issue with the SSTU interstage decouplers since they use a custom decouple module that jettisons the bottom node and then a few seconds after the ullage motors burn out it jettisons the top node. @yobeeb That is not the correct way to do that. what you want is multi adapter attached to upper fuel tank, engines attached to that, then the interstage adapter attached to the middle attach node on the multi adapter, and then the big orange tank attached to that. You may need to use the offset tool to get the adapter and everything sunk down into the fairing but it should work just fine.
  2. WOW..... These look absolutely amazing.... I'm going to have to come up with some head canon as to why all of our stations need to be scraped so I can install the update. Maybe something about faulty coatings on the modules not protecting the metal from degradation due to ionizing radiation resulting in potential structural weakness that could lead to catastrophic rapid decompression, that sounds good.
  3. @Tau137Just a wild theory here. So while the GPU doe the main work of rendering what you see, the CPU still has to tell the GPU what to render and how, from my limited understanding these are draw calls and they can be very CPU intensive and usually make up a fair chunk of the CPU load in a game. My theory is that the added graphical mods increase the number of draw calls, now I know that for a single object if it is affected by multiple lights it will have multiple draw calls for that single object (4 lights 1 object 4 separate draw calls). Based on how KSP handles things I suspect that each part is essentially an object and that maybe the graphical mods are not just increasing the number of draw calls but increasing the number of draw calls per part which from my understanding will have a huge impact on performance. Another possible scenario is that with a high part count ship the CPU is already being taxed and the added draw calls from the graphical mods results in a loss of performance, but when you have a low part count ship the CPU is under far less strain and so the added draw calls have little effect on the performance. Just spit-balling some ideas here based on my limited understanding of how these things work and applying a little bit of logic. If I am making some wrong assumptions here or if my logic is flawed I would love to here some feedback as to how and why. I am at work right now so i can't give you any performance numbers for my set up but I will see what I can do when I get home
  4. I'm pretty sure the aggressive version also down-scaled most of the texture files as well, doesn't change the fact that with nearly identical mod setups I will crash out with full RAM in post 1.0 but pre 1.0 with ATM it loaded and ran fine (fine here being relative lol) @Norcalplanner, this actually wasn't with GPP, I'm not really sure how KSP manages VRAM currently. In the past if you forced OpenGL or DX11 it was supposed to reduce your system RAM usage because they would properly fill up the VRAM first and then start using system RAM while DX9 wasn't doing this properly, at least that was my understanding from reading other people talking about it, I don't actually know if that is accurate or not. I do know that in old pre 1.0 versions using OpenGL did reduce my RAM usage on my laptop even though it doesn't have a discrete GPU so no VRAM sooooo....?
  5. It's at times like this (when I'm playing on my laptop not my super computer) that I miss the good old days with Active Texture Management, a (nearly) identical mod load out from pre 1.x would run ok on my laptop but will use up all of the available ram and crash out in 1.2
  6. When you say the craft is corrupted what do you mean? Does the game freak out when you try to load it? If that is the case could you load up the game, go into VAB and try and load the craft, after game freaks out go ahead and Alt-F4 out of the game. Then upload your output log not your ksp log. if you follow the link I posted it will tell you where to find that log file.
  7. @SlayerNebula Alt - F12 will show you the console, you might still have NRE spam if it's really laggy. Yeah one of the many reasons why I personally dislike CKAN and highly recommend that anyone interested in seriously modding KSP learn how to mod manually. It's actually very very very easy to figure out and will save you a world of headaches.
  8. Kopernicus is spamming your log with NREs, so there is likely an issue with a planet pack or something, the only planet pack I see in your GameData folder is OPM, although there are a few folders there that I don't recognize. You can use more than one planet pack but as far as I know that requires a significant amount of end user tweaking. So if you do have other planet packs remove them first and then remove OPM. If after removing OPM your problem goes away I would recomend trying to reinstall Kopernicus and OPM manually. I personally greatly dislike CKAN, not to put down it's authors or anything, they have done some great work. I just see far to many issues pop up that could have been easily solved by a manual install. Unlike other games that I have modded (mostly Beth games) KSP is very intuitive and simple to mod manually. It is my recommendation that if you really want to run an extensive mod list like yours that you take the time to familiarize yourself with manual modding and how MM and KSPs cfg file system works, it may be intimidating at first but is actually really quite simple. You will be able to identify most problems pretty quickly on your own and generally be able to fix them as well, also eventually you will be able to use more mods and make them work better together by writing your own MM patch files.
  9. It will be a lot easier to figure out what's happening here if you include your entire log file and a list of mods you are using.
  10. Yeah NREs (Null Reference Exception) are generally bad news, especially if it is spamming the log, in which case it will massively slow down the game and eventually crash it. Given that the NRE is referencing Kopernicus the problem likely lies in a planet pack or something of that nature. What planet packs are you using? It is always helpful to post your mod list and an output log when seeking support. My current install has 100+ mods and sits around 20Gb RAM usage at the main menu (mod it tell it crashes baby, then buy more RAM and mod it some more!!) so I can assure you the game can handle it.
  11. In the Sigma Dimension config there is a value you can tweak to help with this. The landscape parameter can be used to rescale the height of terrain features when rescaling a planet. You will have to mess around with it a bit but I was able to get my 3.2x rescale to look pretty good, obviously it's not super effective at 10x + but for 6.4x and under it is more than adequate.
  12. If any one uses Station Science I made a patch adding some of it's functionality to a few of the SSTU parts. StationScience compatibility patch Current functionality: Research Lab added to BDB MOS-LS lab Research Lab added to SSTU-SC-COS-LAB parts Research Lab added to SSTU-SC-DOS-LAB SSTU-SC-DOS-FEM duplicated and made a new zoology bay I plan on including USI parts in this patch in the future. I have no current plans to add functionality to any other BDB lab parts (if there are any) as I do not use them (I play with a cut down BDB install, only use the Mercury and Gemini pods and accessories) RE balance: a small attempt at balance was made, mostly based off of research node placement (in CTT) and size of the part, the StationScience lab and zoology bay were disabled as well. If you wish to change the balance the .cfg is well commented and it should be fairly easy to see what I did and what to change. If anyone has any patches they would like to include in this please feel free to PM me.
  13. Well i went ahead and started my own patch. StationScience compatibility patch Current functionality: Research Lab added to BDB MOS-LS lab Research Lab added to SSTU-SC-COS-LAB parts Research Lab added to SSTU-SC-DOS-LAB SSTU-SC-DOS-FEM duplicated and made a new zoology bay I plan on including USI parts in this patch in the future. I have no current plans to add functionality to any other BDB lab parts (if there are any) as I do not use them (I play with a cut down BDB install, only use the Mercury and Gemini pods and accessories) RE balance: a small attempt at balance was made, mostly based off of research node placement (in CTT) and size of the part, the StationScience lab and zoology bay were disabled as well. If you wish to change the balance the .cfg is well commented and it should be fairly easy to see what I did and what to change. If anyone has any patches they would like to include in this please feel free to PM me. @tomf you are welcome to link this in the OP or include it in the down load if you so desire.
  14. Here is the Kopernicus forum thread And GitHub https://github.com/Kopernicus/Kopernicus And Sigma Dimensions (the mod to apply the scaling change) forum thread And GitHub https://github.com/Kopernicus/Kopernicus
  15. Some how Kopernicus is able to modify the in game clock to use a different day length (for instance 12 hours instead of the usual 6 hours), it also affects maneuver nodes and contracts, any chance we might see KAC able to reflect this type of change by pulling it directly from whatever Kopernicus is changing, or allow the user to manually set the day length some how in a cfg? Just FYI it looks like it is just the UI that is off, for instance an auto generated alarm for a maneuver node will go off at the correct time, it just counts down by 6 hour days on the UI. I haven't tried to manually set an alarm yet.