kcs123

Your issue and looks similar to this one: You are also have FilterExtensions mod that was culprit in shown case. However, you have also use mods over steam install. Tips given in linked post can be useful in your case too. Read few posts before and after linked post.

Most probably your mod combo. It is either, that you use mod that have no MM patch at all for usage with CTT (meaning that those parts are placed in stock tech tree nodes), or for some reason you have MM patch that placed parts in unconvinient tech tree node. I can only speculate that is first case. Anyhow, you can move parts to different tech tree node with custom MM patch. Following example is created for UKS mod: @PART[R8winglet]:NEEDS[CommunityTechTree]:AFTER[zzzUnKerballedStart] { //@TechRequired = earlyAviation @TechRequired = stability } Please note, that if you are not using UKS, you need to replace "AFTER[zzzUnkerballedStart]" with some other mod name that you have installed. For examle "AFTER[Restock]" (also might not be exact mod name as defined in game for MM). You have to find out exact part name used in config files that you want to move and exact tech tree node name where you want to move that part. Also aftrer creating such MM patch it is advided that you start new game. Otherwise you might have same part on multiple tech tree nodes. You can also look in other tech tree node mods, like UKS, that move parts to other tech tree nodes for examples.

It is not possible to use jet engine underwater too, but it works in KSP. Considering that stock game never planed any of BDA features, it is amazing how BDA performs in KSP.

Yep, that one. It is not compatible with FAR (due to different physics calculation) and there is no need for that because FAR provide it's own graphs. But, for people that like stock physics more than FAR, for whatever reason, I would recommend that mod. It provide much more data over stock game that, once you figure out how to use it, saves a lot of time and much less test flights.

Even more easier aproach if you use FAR is to read graph files instead of rotating craft in SPH. It gives you all necessary data for each AoA. I usually need a very small tweaks after first test flight if I need to tweak something at all. Building stable craft is mandatory for me, because of playing on keyboard. There is mod that gives you similar graph data as FAR, but for stock physics. Just giving extra info without changing stock physics. Sorry, I forgot mod name.

You are welcome. I have found later on some more possible issues. That might be sorted out after removing miniAVC, but you should check log again after sorting out other discovered issues. [HighLogic]: =========================== Scene Change : From MAINMENU to SPACECENTER (Async) ===================== (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Unloading 2 Unused Serialized files (Serialized files now loaded: 9) Uploading Crash Report NullReferenceException at (wrapper managed-to-native) UnityEngine.Renderer.set_enabled(UnityEngine.Renderer,bool) at scatterer.SkySphereContainer.Cleanup () [0x0000e] in <8a7e85ab53e34a8ea72ad172e9ac0f8f>:0 at scatterer.SkyNode.Cleanup () [0x00075] in <8a7e85ab53e34a8ea72ad172e9ac0f8f>:0 at scatterer.ProlandManager.OnDestroy () [0x0000e] in <8a7e85ab53e34a8ea72ad172e9ac0f8f>:0 at scatterer.ScattererCelestialBodiesManager.Cleanup () [0x00027] in <8a7e85ab53e34a8ea72ad172e9ac0f8f>:0 at scatterer.Scatterer.OnDestroy () [0x00056] in <8a7e85ab53e34a8ea72ad172e9ac0f8f>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) I think that one comes from scatterer mod, so better double check if you have installed that properly and/or maybe scatterer is in conflict with some other mod you have installed. Beside kerbal foundries, there were parts from some other mods that were also hidden/uninstalled. This piece of log tells me that: Contract Log: ContractDefs prebuilt craft at D:/SteamLibrary/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/Squad/Contracts/PreBuiltCraft/RoverContract/Contract Rover 1a.craft invalid. (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Vessel Contract Rover 1a is missing part roverBody.v2 Vessel Contract Rover 1a is missing part externalTankRound Vessel Contract Rover 1a is missing part domeLight1 Vessel Contract Rover 1a is missing part longAntenna Vessel Contract Rover 1a is missing part stripLight1 Vessel Contract Rover 1a is missing part roverWheel2 and several other crafts that were "live" in your kerbal universe with similar issues of missing parts. If you still have that nullreference error in log from scatterer after reinstall, bring new log file in scatterer thread. It would be offtopic for kerbal foundries, but good example for others to help themselfs if someone encounter similar problem.

Belive me, even veteran players can found useful tips in that thread, it is easy to create silly mistake on install, even if it is not your first time installing mod. I didn't go trough all log file yet to pinpoiont exact culprit, but I have already found several issues on the begining of log file. 1st issue is that you are using moded game over steam install folder. Sooner or later steam verification can screw your installs on updates. To avoid this, rather keep stock game clean on install and once you have only stock game and stock DLCs in steam folder and nothing else, copy that to some other folder. You can have multiple KSP instances without issues except maybe for HDD storage space. That way, even on regular KSP updates your moded KSP instance will reamain stable (as much as KSP and mods can be stable). After official KSP update, steam will rewrite your files and there is good chance that some mods would not work properly on first day of KSP update. In log you have several lines like this one: Cannot create config from file 'D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\WarpPlugin\Patches\EnginePlacement.cfg'. Depending on mod, it may or may not be issue to prevent some mods working properly and it may interfere with other mods too, to not work as intended. For some mods such thing may be harmless, for some mods not, though. 2nd issue is that it seems that you have several instances of miniAVC installed. That is known that can cause issue on few latest KSP releases. It can prevent other mod plugins to load properly. Try to install zeroAVC to remove those legacy miniAVC that can cause issue. ADDON BINDER: Cannot resolve assembly: MiniAVC-V2.XmlSerializers, Culture=neutral, PublicKeyToken=null MiniAVC-V2 -> Assembly: D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\EasyVesselSwitch\Plugins\MiniAVC-V2.dll Above is new AVC version, but you also have older AVC plugin: MiniAVC -> Executing: MiniAVC - 1.4.0.2 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) MiniAVC -> Assembly: D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\FShangarExtender\MiniAVC.dll You also heve a lots of MM patches from "000_FilterExtensions", deleting some part nodes etc. I can't say what was intended and what not as I didn't used that mod, so take that with a grain of salt, I may be wrong on that one that can cause issues. I have found some possible conflict between filter extensions and BDArmory mod: [Filter Extensions 3.2.0.3]: BDArmory: No subcategories valid, abandon instantiation of BDArmory Sorry, I have run out of available time to search further, if I'm on your place, I would create clean KSP install trough steam. Copied that clean KSP instance elsewhere on HDD and install mods over that instance. Backup your savegame files before doing that, of course. After that install zeroAVC to remove all deprecated miniAVC plugins that are bundled with some mods that you are using. I suspect that Filter extensions is in conflict with KSP foundries and some other mods, but I'm not certain due to lack of time to inspect logs more thoroughly. Maybe somene with even more experience with reading logs and mods that you are using can help you better.

Most likely you have some mistake on install process. This thread may help you to better understand how mods work in KSP and how to avoid install errors, regardless if you are using CKAN or manual install: If that does not help you then upload your KSP.log file on some cloud service and give a link for it. Then it will be easier to help you further, to narrow down issue.

Any text editor will do a job. If you are using windows, I recommend notepad++. It is free and powerfull tool. When you open craft file with text editor it looks something like this: ship = #autoLOC_501174 //#autoLOC_501174 = Aeris 3A version = 1.2.0 description = #autoLOC_501175 //#autoLOC_501175 = The Aeris 3A is a small and nimble one-seater plane, mostly used as a training craft for fixed-wing flight, and to annoy ground staff by 'buzzing' the space center facilities. ¨¨ type = SPH size = 8.54607391,3.10917664,8.48044586 PART { part = Mark1Cockpit_4294820102 partName = Part pos = 0.206589505,10.3309603,3.15244007 attPos = 0,0,0 attPos0 = 0.206589505,10.3309603,3.15244007 rot = -0.707106829,0,0,-0.707106829 attRot = 0,0,0,-0.999999881 attRot0 = 0.707106829,0,0,0.707106829 mir = 1,1,1 symMethod = Mirror autostrutMode = Off // ... snip You need proper mods installed if you have anything other than stock parts on that craft file. And, of course some knowledge about each module in file, part names, etc.

It should only be possible if some other mod patching stayputnik part and add SAS to it. ModuleManager.ConfigCache file and your KSP.log file should be able to reveal what mod is culprit for this. UKS for certain does not add SAS to stayputnik probe. Stock config file "probeStackSphere.cfg" and "probeStackSphere_v2.cfg" also does not provide SAS. So, only logical explanation is that some other mod add SAS to stayputnik or mybe even all probes, or you have your own custom patch file that does that and you are not aware of it.

1) Always, when testing new craft design. If I can't safely land on runway, I probably have flaws in craft design. Hint: Marking runway (begin and end) with waypoint can help a lot to align properly when you aproach runway. Using flaps to allow slower landing velocity helps too. 2) For the most rockets, aerodynamic is not much concern if you gently steer rocket (less than 5 degree from prograde vector). Once you are above 20 km you can take somewhat sharper turns, but steel have to be more careful than with stock physics. Fins for first stage that goes trough atmosphere can help, depending on rocket design. My first career rockets that are capable to reach orbit are usualy ugly, but they do the job, considering part and weight/height limits on first levels of VAB/launchpad and unlocked parts in tech tree. I didn't find to design crafts harder than with stock, but you have to create them in different way and you have to control them in different way than with stock physics.

True. But history of KSP releases have teached us that all new cool features become fully functional only after few more releases and if nothing else become broken too. That includes not only KSP itself, but also someone favorite mods that may or may not work properly on lateast releases. So, yeah, it us not usually good idea to jump on new release imediately, but it is also bad idea to wait for a long time to switch on newer release too.

Basicaly, yes, just be careful that you not nest gamedata folder within gamedata folder. Quite common mistake that is easy oversighted. You can find more useful tips how to install mods in this thread, to avoid any doubts of properly installled mods: That being said, you should not avoid installing KSP recall on KSP 1.10.1., it is marked as dependency of tweakscale for a reason.

Yes. There is example in kOS documentation about it. Trick is to create endless script that react on events or triggers, like action groups. For example: // showing GUI on demand by pressing action group on AG4 { Aircraft_GUI:show(). preserve. // ensurance that AG is triggered again on demand }. Note that is just small snipset from larger piece of code. Without it it does not make much sense, but good enough for example. When showing GUI become available in kOS, I prefer to use events on GUI buttons pressed, released, etc. Using only one action group to toggle GUI window. Rest of AGs are used for other craft controls. You can use those events as you see how it fits your purpose, though.

Custom Barn Kit is used in UKS to increase allowed part numbers in level one buildings. AFAIK, Custom Barn Kit on it's own does nothing. Instead, it allows others to write MM patches to customise each KSC buildings behaviour. Issue you have mentioned more likely comes from someone else MM patch that deliberately prevents some upgades, rather than it is unintended bug. UKS does not change buildings in that way.

Yes, something like that. You need probe in the arm due to docking/undocking on both sides. Without it you may lose control over candarm. And you need electicity for both, probe and hinges and/or other IR parts. There was a bug with IR and this kind of mechanism, when you dock/undock candarm, you may revert orientation on some parts. What you have assigned as "left" rotation, may become "right" or something similar. Exception is, that such candarm does not need engines, fuel, etc. Like regular craft. But, docking/undocking and merging two crafts in KSP was always a bit buggy, even without IR.

AFAIK, neither of contact mods have caused FPS drops and being CPU heavy. There is barely any calculations in editor, except going trough all craft parts and find if craft have required parts. Even when some of contract mods become broken between KSP updates, I don't recall that there was ever issue with FPS drops because of it. I would never claim that is impossible, but it is highly unlikely that some contract mod have caused FPS drops. More probably that something else is culprit with some strange interactions between mods. To find real culprit, instead of removing mods one by one, rather create clean install and add mods one by one and test between if you have reproduced bug. Reason is that you can easy create some mistake by uninstalling and thinking that you have proper working mod installs while it is not true. Adding mods over clean install reduce chance that you have did something wrong on installs. If you didn't already, read trough following thread, even veteran players can find good tips how to avoid mistakes on installing mods:

No. You need double docking head on candarm, though. I don't know if "magnet" docking port still works or not, but you can use claw or ordinary docking ports too. You will need probe, some batteries and maybe power source in middle section of Candarm to replicate funcionality within game. Threre is some old video about it how someone acomplished it several KSP versions ago. I belive that trick used on that video still works. Can't recall author name that might help you to search for more info.

Not at the moment, as I'm aware of, but there is plan for it: https://github.com/dkavolis/Ferram-Aerospace-Research/issues/55

On that github page look for releases link: https://github.com/tetraflon/B9-PWings-Modified/releases Be aware of download link marked as "pre-release". It may or may not have bugs. Usualy it does not mean that is not broken, rather it is not fully tested. Sometimes you may find in changelogs or read trough issue/pull requests to figure out if there is any known unsolved issues.

Based on provided picture, culprit part is MK3S1 Tail Connector B. AFAIK, FAR use part 3D mesh and/or mesh colliders for voxel calculations. There was some changes in code when FAR use mesh and when it use coliider, as much as I can recall, but I no longer know details about it. For some reason, most probably because the how culprit part is created in blender or similar editor, FAR voxel algorithm fail and throw exception.

Someone more like to write "&", others prefers more "," sign when writting patch. Meaning is same, but all of included patches are not created by same person, therefore are differences in writtngs. You can found more about that syntax on MM wiki page. To be more specific, this piece from that page: As explained, MM was not created by one person either, and for certain not at once. Therefore multiple operators were supported for same thing as there was already a lot of patches created in one way. Excluding support for older operator would break a lot mods that use legacy syntax.

Good catch. I missed that version numbers in folder names. In my defence I can only say that it was late in night and I was tired when I wrote that post . However, my guess was right that something is wrong with install, as it it most common mistake. And your linked thread explains in great detail how mods works in KSP, what can go wrong when you install mods and how to prevent mistakes. So, it is easier to put link on that thread than explain everything what could possibly go wrong on mod install. You are welcome. I'm glad that you are able to solve your issues, despite the fact that I missed what was wrong from picture.

It is hard to tell from picture only, but it seems OK. Only from log files should be possible to tell. Does not hurt to read this thread, though, to check if you done everything to avoid install mistakes and to understand better how mods works in KSP: In this thread you can find info how to search for log files: With slight disclaimer, though. In that thread is mentioned how to find unity game engine log files, some moder developers still prefer "KSP.log" file located in same folder as KSP executable. In gamedata folder you can also find useful file: "ModuleManager.ConfigCache" that tell more about order of installed mods in case of some conflicts. One silly question at the end, though. Have you started new game after installing UKS mod or you have tried on already saved game ? Asking because all of tech tree related mods take effect only on new game, to change layout of tree nodes. If that is not the case, upload your KSP.log file on some cloud, like dropbox, google drive or similar and put link to that file on forum. A lot of hastle, but you have put some effort, so that others can help you.

Hmmm. How about doing oposite ? Allow to parts be stackable only if their resources are completely empty. That way all of allowed stackable parts will be identical and no need to worry about resource costs. Also no need to track down each part exact properties. Only one set of properties would be required, that could improve performace for a bit too.