kcs123

Thanks for maintaining it until now. It is "normal" to get burned out or bored with mod development at some point. Nice thing in this community is that there is almost always someone willing to take torch and continue work. Thanks to @Lisias for taking the burden of future maintenance too.

Me too, (when play at all). Have 1.4.x intalled for teting other mods only, but that one is on hiatus too. There is info in KSP release notes that theys were fixed/tweaked landing gears and landing legs, to no longer bounce and explode etc. Have yet to try stock 1.5 game first and then with mods. My "educated" guess would be that this mod is still quite useful even if no longer necessary due to different behaviour or aproach how to fix/workaround of that bug. I think that it is more unity game engine issue than too bad game design issue. Does that mean that you tried version 1.4.x in KSP 1.5 ? Or you have recompiled for yourself and then tried it to see if works ?

Agree on what is said above. Mods that have high dependency requirement for other mods out there should have highest priority like Click trough blocker and Blizzy's toolbar. After that mods that have great impact on gameplay quality. For me it is RCS build aid then precision maneuver node. Never used other quality change mods like Janitor's Closet, but seems to be useful for a lot of people, so, yes, those shoul dbe next. On third row of priority list should be mods that are more/less easy to update (simple recompile if it is enough). Reason is to give community as much as possible updated mods and soon as possible. After that things should be more calm and be less pressure when comes to bugfixing things. Those can be tiresome at times. Just my two cents on this, pretty much what I would do if I have to provide support on so many mods. Other than that, take your own pace with updates, how much time you can devote for it and what gives you most joy when working on it. Moding does not have sense if you don't enjoy a bit while doing it.

I think that you no need to worry much about shiny/metalic textures. It may be a bit off in comparison to current stock parts, but that may be changed on next KSP release. At least Stayputnik is changed to be more shiny in future: Despite being a bit too shiny(that also depend on someone personal taste), new textures looks very nice to me.

Instruction how to change config files to fix errors due to MM changes are given in december. Everyone can adjust files for himself and use it, but distributing changed files are forbiden due to ARR licence. Violating ARR licence, no matter how stupid it sounds would do more harm than good on the long run. Until Yemo resond on forum or patreon page, only thing possible to do is provide "how to" instructions to made adjustments and install extended config files on top of that.

Stock SAS have changed a lot since those patches was actual. Claw is no longer around and I don't know if anyone taken over some of those fixes and maintain it under different name. I doubt that using latest available would give you any good on newer version of KSP. Anyhow, I would suggest that you rather fix oscilation problem on craft in different way. Adjusting min/max gimbal angle on engines, deflection angle on control surfaces and different position of control surfaces on craft. You can also try with all moving control surfaces vs fixed wing+control surface or build in control surface. You didn't say if you have issues with rocket or plane. I assume that you have issues with plane.

Yep, that application catched my attention too, but I postponed buying licence until I can afford it and have more texturing tasks to do. From data available to see capabilities, it seems to be easy to use application, especialy for people who don't like/have skill for standard PS based texturing work but need to do small changes on 3D model (create variations of same model and similar). Another good tool that catched my attention is Character Creator 3D. Have to grind some money for that one too. It makes modeling job much faster and easier even for those who are familiar with maya, 3DMax and similar applications. Considering the average price of 3D character models, it should be pay off quickly. Sorry for being offtopic for a bit.

Having same or slightly better ISP than NERVs, but with additional need of extra power charge ? So wor very long burns you also need either, extra batteries or reactor on board. Some kind of futuristic engine that is fussion of NERV and EMV drive. It is probably not much in-line with real life science, but we are speaking of SCI-FI engine, so in gamebalance terms it should cover some gap between existing stock parts and parts from other mods. Just idea.

Is it complain that there is not much to complain about ? No worries, with 1.5 coming soon, there will be a lot "Are we there yet ?" questions, at least

I'm on Windows 10 and Firefox 64-bit too, so it have to be something else in the middle Anyhow, nice pics, thanks for re-upload.

I suppose above should be picture ? Neither it looks like link for something or some kind of data in hex format, too many latters for hex, that one use only up to "F" Forum do funny stuff sometimes.

Yes, I know that there was some small drama about it, but don't know all of details. Thanks for clarificatrion, @linuxgurugamer. As said, I was not unsure what piece of code was merged and what not. My best guess is that is main issue is lack of free time for further development, issue could be on either, IR plugin code or KJR piece of code, have to be patient about it and wait for response. Can't blaim anyone for it, heck, I don't even have enough time to play game properly. Attempting to lurk forums, regardless, to help where I can, in hope that my own free time will be improved once again too.

You are more probably set engines in a wrong way, so it could not change properly thrust. Check out alistas videos, I'm pretty sure that at least one explains meaning and usage of additional TCA engine thrust options. As for PIDs, it is thing used quite a lot in automatization. If you are not much for reading documentation of it, here is short video that explain it in easy way: And here is link for wikipedia too, if you sometime find it interesting to read and learn more about it: https://en.wikipedia.org/wiki/PID_controller For some people there is more than half of fun to learn new stuff along with playing this game, including scripts, real life math behind ti etc. But, yes not all folks around is for it, some just play the game and learn by trial and error. Everyone has it's own representation of fun, it is understandable if you just want "all in one" solution where you just click and everything "just work".

Some tips regarding VTOLs: - in atmosphere, limit vertical speed up to 10 m/s. Even 10 m/s of vertical velocity can be too high on some crafts, aerodynamic forces can easy tip over your craft, engine thrust balancing may not be enough to keep your craft stable - consider using kOS or similar autopilot. Simple script that use PIDs to control is more/less easy to create and you can learn a lot and have fun with those when creating your crafts. You may use it along with TCA, not necessary without TCA.

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 ?