kcs123

Most probably not. KJR works just fine for lot of people and it is hard to help others without enough info(mods installed, logs, reproducing steps, craft files ...).

No worries, it is easy to create such mistake and it is even easier to fix, so less things for Rudolf to worry about.

Do you have only blue dot for COL or you have arrow, like in stock game without FAR. If that is the case, then you have on your craft parts that are not patched properly for FAR. Screenshot or two might explain situation better. I have noticed few posts in PW thread and APP thread about symmetry issues, but I haven't encountered those for myself. KSP 1.7.3 with FAR seems to work just fine for me, I don't have either proper KSP 1.8.x with mods installed yet. For coding questions, you will have to wait for someone else to answer. AFAIK, FAR code is kind of spaghetti mess that need to be refactored, so it can use some of advantages of unity game engine. See few posts above (or one-two page back) where it was explaind in better detail.

That same looking part comes in two variations. Uncontroled and powered. IIRC, first one that is available to unlock is uncontroled variant, but I speak from top of my head about it, so take this info with grain of salt. If G-00 hinge part works properly, others should work too. I'm pretty sure that you are using uncontroled part by mistake. You can try to create similar craft in sandbox game with all parts unlocked, so you can see difference by yourself. It is hard to tell from look of the part is it powered or not, you need to pay attention on part name and description.

What structural parts you have used between IR parts ? You must ensure that those parts allows fuel crossfeed. That property is not only for fuel but also for electricity. For example, I beams does not allow crossfeed, but truss allows it. You also have to ensure that your craft have control probe as minimum and enough battery or battery + EC generator(solar panel, RTG...). Also, there is two different IR parts. Controlable and uncontrolable. Controlable parts are using motors to allow moving to desired directions while uncontroled parts allows free moving by help of outside forces, like gravity or air drag etc. Picture of craft with opened PAW that is used on craft can help to find out what is issue in your case.

Maybe it will be good idea to put same piece of code on github too, along with AtmosphereAutopilot. Source might be lost from someone private google drive if current maintainer get bored, need more space on private cloud or for whatever other reason. Then it will be again difficult to track down what this piece code is used for, if someone need to check it for some reason in the future.

That looks like messed up mod install. There should be much more options on PAW GUI, but it shows only scaling options. Based on picture I can only assume that you got TweakScale installed. It could be that TS is not installed properly or some other mod have messed things. For a better help you will need to provide log files. You can find info about that in this thread: It also does not hurt to read how to install mods properly, regardless if you are using CKAN or manual installs. Neither of methods is not completely foolproof. I can only suggest to do clean re-install of KSP and mods and if that does not help, provide log files for further support. It is hard for anyone to help you without those just from guessing what might be wrong.

You can find previous releases on both, github and spacedock sites. https://github.com/DMagic1/Orbital-Science/releases https://spacedock.info/mod/128/DMagic Orbital Science On spacedock you have "Changelog" page where you have marked each version of mod and coresponding KSP version.

Compatibility for KSP 1.7.x was added after update for KSP 1.8.x. Info about it is on previous page: On spacedock web page click on changelog and you will see there proper version to download. Or you can use CKAN, whatever you prefere. You may also want to use additional compatibility patches from community, posted in this thread after release if you use some of mods that are not already covered by default.

Maybe this post from few pages back can answer your question: Maintaining TS at current state already take too much time, so support for any other mod have to be included trough that mod. In your case it should be done on "Tantares" side. Things are still messy due to improper implementation of TS patches from various mod authors. Plenty of issues are already discovered and solved, but it will take some time until each rogue patch is ironed out. Hopefully, any new mod TS support will follow guidelines how to write TS patches, so such issues will be avoided in future.

Take your time, real life job and family always have to be highest priority. If that one is not under control then all of volunteer moding work will go south.

I can only tell from my last "stable" KSP 1.7.2. install that I didn't noticed any significant slowdown while having button pressed or not. Although, I have noticed stutters every 30 sec. or so when using certain KF parts. Probably garbage collectors doing it's job at those intervals. Those things are more likely for stock KSP to blame and it supposed to be improved with KSP 1.8.x. However, it will be some times until my "essential" mods are updated for KSP 1.8.x.

Sort of. You need to search trough this thread several pages back, when BG DLC was published for the first time. In short, FAR need proper trigger that it can hook on, like animation start/end or pilot input and similar. For example, Infernal robotics does that properly, whenever IR parts is moved it call FAR API to recalculate voxelization and drag/lift forces in apropriate manner. However, official KSP DLC does not do that, it is not "aware" of FAR mod and does not call any FAR API to recalculate anything. It has to be other way around, FAR need to know when is something changed to recalculate forces properly. Unfortunately, KSP does not provide any way trough their API to be able to do that. Therefore, BG DLC can't be supported by FAR. What you see on the picture, that forces are changed is due to random events(triggers) in the game that caused FAR to re-calculate something. So, you can get wrong impression that DLC parts work, but you don't get expected lift/drag/thrust forces. You got wrong calculated values because FAR was not able to calculate everything on time.

IIR, @jrodriguez, you were the saviour of this mod too when shader/texture rebuild was necessary several KSP version ago when SQUAD was switching game engine. Am I right, or I no longer recall things properly ?

@Commodoregamer118, @StoneWolfPC, the most important thing is to understand how mods in KSP works and how MM allows to be so many mods installed at time without each mod stomping on other mod toes. Then it would be much less issue if you are doing manual install or trough CKAN. CKAN is great tool, but not without flaws. To use it with least amount of possible issues it is important to know it's limits. Just to link what I wrote in other thread, to not repeat myself: Does not hurt to read OP of linked thread even if you are using mods in KSP for a long time.

Looks to me that you have button below "Realibility" title where you can switch between standard and high quality engine option. After switching if B9PS is configured properly you should get different engine name and diferent properties for the engine.

https://github.com/dkavolis/Ferram-Aerospace-Research/releases There are listed all previous releases. IIRC two releases before latest one is for KSP 1.7.x, you will have to search trough this thread to find out about exact KSP version compatibility. And I doubt that latest one recompiled for KSP 1.8.x will work properly on KSP 1.7.x due to unity game engine version change in KSP 1.8.x, but I didn't tried for myself.

" zzzUnKerballedStart " is probably leftover folder name while this mod was in development. Since that folder does not exist in published release, MM command BEFORE and AFTER are just ignored and patch is applied by order of UnkerballedStart name inside of GameData folder. "FOR" command is deprecated and should be avoided and since you don't have either, Snacks or MH, MM patches for those are not applied at all. I learned that while I was creating MM patches for personal use. Despite those mistakes, mod works as intended. New tech tree is presend in R&D building and parts are re-arranged trough tech tree as intended. If it does not work for you then you must have missing some dependency, like Ctt or something.

It is being updated: Might be issue with install or with some other mod interaction ?

Now you have reminded me about something else, but similar. I don't think that ferram ever solved that issue, because RO mod authors are developed KJR continued, almost direct copy of ferram KJR but with updates for new KSP and some bugfixes without any major improvement. There is mention of launch clamps in KJR continued change log, quoted same thing for different reasons: I never used RO for myself and never encountered that issue, even with ferram's original KJR. Again, I can only guess that same issue is solved in KJRn long time ago because Rudolf said it was solved and users that use RO and KJRn at the same were not reported any issues. Of course, there is always chance that something is broken with KSP 1.8.x release. There is also chance that if you have tried different versions of KJR that some file is left behind from previous install. It will be good if you can reinstall KJRn. Meaning, to ensure that you have deleted "KerbalJointReinforcement" from "GameData" folder before you do fresh install of KJR Next.

No, have no idea, I never used FASA launch clamps by myself. As I said, I can only speculate and create assumptions that something is different. I don't see any other reason why they would not work properly unless it is something different from stock launch clamps. Perhaps joints are named in different way than stock and for that reason KJRn may handle it in different way. But, that is again only guessing. If that is not handled trough 3rd party plugin than there is always "dirty" way to exclude those parts with MM patches. Sorry, can't help you much more. I hope that I have at least pointed at right direction, for more than that you will have to wait for @Rudolf Meier to answer.

@Rudolf Meier is one that should give offical answer, but he is busy lately, so I will try to help until then. Short answer - yes. It is possible to do something about it. Slightly longer explanationa follows, but I need few questions answered first. Based only what I can see on pictures from linked thread, it seems that you are not using stock LaunchClamp and decouplers. Solution is based on assumption that answer is that you are not using stock parts. Have you tried using stock launch clamps and if you did, does craft behave properly later on ? Meaning, does decoupling stages works properly after that ? I'm asking this because there was strange issue in the past with KJR and decoupling that was solved long time ago. Now, a bit of history of KJR, to better understand what is going on. Original KJR made by ferram was using additional XML file to exclude specific parts/joints from KJR to reinforce them. Meaning, whenever any 3rd party mod got issue with KJR, new module or part have to be added in that XML file on list. Sometimes weeks were passed or even months between KJR updates before such 3rd party mod is supported by KJR. Meanwhile, each user of both mods was on it's own to edit that XML file for himself. Not everyone was have enough knowladge how to do that properly and on next KJR update, if problematic mod is not supported, you will need to do that again. With KJRn it is no longer the case. But, some colaboration between mod authors is still necessary. Following is based on assumption that BDB mod use it's own plugin or dll for clamps, decouplers and docking ports. I didn't ever use BDB, so I can only speculate and made assumptions. If that is the case, then the best solution will be if @CobaltWolf, author of BDB provide support for KJRn. You see, new feature of KJR Next is that it provide interface for other mods to "tell" KJR when to exclude problematic parts from reinforcement and when to allow KJR to include such part to reinforce craft again. Example of such scenario is IR mod and DockRotate mod. There is also option if problematic parts does not use any other plugin, to exclude such part trough MM patches. So, instead of nagging KJR author to include problematic parts on exclude list, each mod author can write his own MM patch and deliver it to users along with other config files. If for ever reason mod author don't want to provide support, each user can write such MM patch by himself. Example of such patch is in spoiler section, just keep in mind to use proper part names, because I writting this from top of my head. You will need such MM for each problematic part. However, much better solution is if KJR joints are disabled/enabled as needed trough new KJRNext interface. Info for developers how to do that are described in WIP thread: Under spoiler section of OP from WIP thread there is info how to do it for both, trough interface or trough MM patch. Again, best solution would be if @CobaltWolf can/will provide support for KJR trough his mod. @peteletroll might be able to help if there is any other questions, since he has already did that for DockRotate mod. But any further discussion is more apropriate for linked WIP KJRn thread as it is meaned for mod developers. I hope that I was able to help with all parties involved.

"development" thread is used for new ideas, reports for beta releases, testing new features, perhaps custom MM patches and similar. This thread should be for latest official release. It is being said multiple times in both of threads that KJR Next is marked to support any new version of KSP as it is not suspected to be anything new in KSP code that might break things. One of latest post about it: That being said, noone knows for sure until you try it. I just guessing here that there might be issue with debug version of KJRn, due to UI changes in latest Unity version and KSP, but it is just speculation. I have yet to download latest KSP 1.8.1 and chase down proper mod versions and possible bugs in my list of favorite mods. So, can't tell yet from the first hand if something is broken or not in KSP 1.8.1.

I was writting in the rush, so I didn't explain everything what was on my mind with "easiest way from coding perspective". Not only is it doable to code, but also interaction with stock and other mods in the future. Basicaly, what @DStaal wrote just in few seconds before I wrote my post: And not only that, have to think about firespitter switcher too. Many of other mods use it and along with mods that prefer B9PS. And, yes, if SQUAD ever deceide to fix stock issue it may make this override piece of code obsolete, but again, noone knows if they will ever fix that issue or how long it will take to fix it. And one other concern is, what option will be easier to maintain in the future ? In my opinion, if option #3 is done properly, you will have little to change whatever path SQUAD take in regards with PAW UI. All of those are valid concerns, but if that can be solved in meaningful way, from user perspective it will be better option #3, to have all resources listed toghether. In the long run humans are prone to "automatization", meaning we are not actualy reading everything on UI, just looking on specific spot on UI, looking on analog size of slidebar, rather than reading exact numbers. Having resources toghether and if drawing of those resources on UI is always in same way, regardless of part type and resource type, would help a lot to not make mistake when build craft. Just my opinion, you will have to weight out all of pros/cons before making final decision, you are the one that will have to do all hard work and maintain it later on.

I'm noob when comes to blender and pretty much useless when comes to unity. But, I think that you will get most useful info in KSP forums, to get it right for KSP needs: https://forum.kerbalspaceprogram.com/index.php?/forum/15-modelling-and-texturing-discussion/