kcs123

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.