kcs123

Have you tried to attach control surfaces only on one wing without symmetry ? After finishing positioning control surface, reattach whole wing in symmetry turned on. Not exactly bug solver, but similar thing helped me in other craft designs in the past.

Yep, that driffting bug is quite annoying. For that reason, I never create "perfect" satelite network, rather good enough for certain period of time. At begin of new career, I try to launch around 6 satellites around equator, more/less equaly distributed around 120-140 km. Note that I play without additional ground stations. Two additional satelite in polar orbit, with difference around 90 degree between those two polar satellies. Later on, I put at least one sattelite in geostacionary orbit just above KSC. And few additonal trough contracts that are geostat/geosync orbit, where I also put some good antenna on it, so it is not only for contract, it serve purpose later on for the rest of the game. At that middle stage game I also, put two additional satellite in polar orbit with high Ap, almost near Mun, that usualy cover all comunication needs. Also at that stage, I'm able to put some satellite around Mun and Minimus too. By that time, first 6 sattelite in orbit are driffted quite a lot, but no longer matter, com network is by then properly covered even without those. I only babysit that one satellite abve KSC in geostacionary orbit if it drift too much. Using precise node to set desired maneuver and kOS script to execute maneuver. I plan to develop script for setting maneuver nodes too, but too lazy for that and too litle time for playing lately too. If you want to make "perfect" network, it is possible to create some kOS script that will reposition drifted satellite, but you will need to "visit" such satellite and execute such script from time to time. For example, lower Pe for some amout to get exact wanted time difference, depending how much satellite drifted, wait couple of orbits for time difference between SOI rotation and satellite orbit take effect and then raise Pe again at previous altitude. It all depends how "perfect" it has to be for you.

I'm so sad to hear that bad things happening to good people. Personal health and family should always be priority no#1, moding can alwas wait. I hope that you will find some joy while working on it at least, might even help you to forget about health condition for short while. Anyhow, thanks for taking over maintenance of this mod, I wish you to get better as soon as possible.

I didn't looked into linuxgamer code, so take following with a grain of salt. Linuxgamer have forked KJR code from ferram (first author of KJR mod) and seems that forked version does not contain new code provided by Rudolf, or at least not all of it. In case of old KJR code, it is possible that you need to edit XML config file, to put IR next module in it, so KJR know what parts need to ignore. Forked version from Rudolf contains additional code that allow IR plugin to comunicate with KJR and allow or forbid KJR to put autostruts on IR or other parts. Even with latest one, though there is still some bug involved that prohibit movement of IR parts on some crafts. Unfortunately, due to licencing issues, debug version of KJR that allow to visualize autostruts is no longer available, so it is hard to say what exactly is going on. It is known issue and it is being worked on, just be patient about it, moders work on this on their limited free time.

Yep, I know, but it is even worse when you don't have anything to read . Some things can't be put into GUI, to be informative and intuitive, if you put to much help info trough tooltips and similar in GUI, it eventualy become counterproductive and harder to use. So, either, you put some effort to write instruction or answer same question over and over again. So, yes, even the people who read instructions are dying species, some still exist. At least some of them would not ask same question, but whatever drive your moding boat is fine to me .

B9PartSwitch does not depend on any other mod, it is other way around, cyroengine and other mods depend on B9PartSwitch for changing textures/meshes for different variants of same part. Like raised/lowered tail for example. B9PartSwitch on it's own does not use any key, at least to my knowladge, so most probably it isomething else in conflict. It is good to ask @blowfish what is going on, but you will need to provide log file, for better understanding what is going on. And welcome to forums, btw.

Hate to speak for others, @Rudolf Meier is one to confirm for sure on this subject, but since he is busy and I have followed development from begining, I will try to answer some of questions. "*_v3" should remain for IR next. It is chosen like that, so you can have (in theory) old version of IR plugin that work in a way like it worked before, and new version of IR next plugin that works in similar, but internaly in complete different way. Don't know if it will be possible to work at the exact same time, old and new version of assembly, but you could choose to have one or other for crafts created with old version and such. Now, it is not only "_v3" in assembly name, there is also changes in part module names too. That is most probably reason why kOS no longer "see" IR parts. Example: // --- Robotics Parameters --- MODULE { name = ModuleIRServo_v3 servoName = Extendatron - Basic // the rest of config is cut off } It will be remain like that even after beta, for sure, though there is still some stuff on "to do" list for Rudolf to iron out before full release. There is still some bugs involved with KJR when IR parts don't move while it should and probably some optimizations regarding joint strength, part mass and such that is more like polishing everything once all system work as intended. While there is major overhaul of code internaly, I don't think that there is major changes in API calls, though some pieces of codes in IR next was removed completely, can't tell if exact API needed for kOS still exist in IR assembly, I haven't looked in all of IR code fore that. Also, can't tell if there is need to make changes trough IR assembly or trough kOS side, to make things work again.

That is nice to know. Might be good to mention the same in BDA thread too. Didn't find a notice in BDA OP, sorry if it is already there.

There is problem with other parts. That is whole catch. It is issue that is hard to notice if you are not aware of. Sure, you can make a craft with those parts, sure it can even fly in some cases, depending on other parts used, but does craft behave like intended, to allow FAR calculating lift and drag properly over such parts ? That is why we love so much this mod, to calculate drag and lift on craft in more precise way to real life examples as much as possible. For me it is hard to belive that you will get good output data when you have wrong data on input, to start calculation. And for some reason FAR get wrong data on input for some reason when such parts are involved. If you read few posts above, I'm not only one that noticed this: Everyone can use parts from any mod in any way that fits in their game, but it is just something to be aware of and do not complain to either, ferram or to authors of other mods. FAR is not "officialy" updated to latest KSP, to tell that all issues are fixed from FAR side, so use it as it currently is, or don't use it at all. It is not nice to nag author of other mods to fix things on their side either, at least until it is discovered what exactly cause issues and be able to create MM patch on those parts to fix conflict. So, have to be patient and wait for proper FAR update first, before asking others to provide support. My best "educated" guess here is that is either, something configured in not ordinary way in config files, or colliders on part mesh were placed in some strange way to cause issue in voxelization. Only way ordinary users can help in meantime is try to identify parts that cause conflicts, so it will be easier to find exact issue and what parts would need some kind of MM patch to solve issue.

That only helps with wings and control surfaces, but not in case of cockpits, fuselages and similar parts. But at least it is something. For other parts you probably need to test it.

Are you using old IR hinge parts or new ones from ZodiusInfuser ? Some old parts not working properly (known issue for several KSP versions ago). Reason is changes in KSP/unity game engines and those parts need to be recompiled to adress this. Unfortunately original source files for those are lost (author no longer active) and there is low chance to be fixed. Have you tried using pivotron hinges (new white parts) from Zodiusinfuser ?

I noticed that issue only with Airplane Plus mod, with cockpits, fuselages and such, beside wing surfaces and control surfaces. I didn't investigate config files in more details to find out why. Usualy cockpits and fuselages should not influence FAR at all, due to voxelization shape based on colliders that FAR use for more accurate calculations. Usualy all other mods that are not wings and control surfaces work just fine with FAR. Must be that some mods use something extra in config files for drag cubes that confuse FAR somehow. Could also be some other mods around that cause same or similar things, but first indication that something is wrong is strange look and behaviour of CoL in SPH/VAB, even when you don't notice errors in log. I'm glad that it was useful to you and others to detect issues.

Do it in kerbal way then - with trial and error And be patient, take your own pace of learning, so it will be less frustrating. You will make huge learning steps when you enjoy learning at the same time.

I'm bit late for the "party", but, is there is some file missing from source code ? Or included licence (same as from forked source) is no longer valid or something ? https://github.com/meirumeiru/Kerbal-Joint-Reinforcement It looks like source code for me, but can't tell for sure if it contains all necessary files or not.

You need to hover over wing with mouse cursor and then press "J" (default key) to open menu for modification of PW parts. If does not work for you it can be that you messed up install somehow, or menu is showing outside of your visible display area.