kcs123

It does use TS if it is installed. It does have additional configs for upsaled/downscaled parts if you don't have TS installed. That being said, I didn't checked if those additional config files were published or not (I have cooperated with Zodiusinfuser when he worked on it).

That is possible. If some parts are renamed or got "upgrade" variants it is possible that upgraded part does not have proper FAR config. However, IIRC, parts without proper configs were not causing NREs before, just not providing expected lift/drag. I can only guess for now that something else is culprit.

Another interesting thing is that it is landed diagonally on runway. Fighting with side wind that is also changed direction few times trough landing (check red flags in bottom left corner). It is not too obvious due to camera angle, though. It i salso noticable "flaping" of tail controls in few frames. By looking on flag it does not seems to be high wind, though, but significant enough to cause issues.

There some threads in challanges forum regarding BDArmoury and various setups (WW2 era crafts, generation 5 fighter crafts etc.). IIRC, in those there was detailed description how to setup AI vs AI combats for validate challange. It should worth to look in some of those threads.

Ah, sorry, I have missinterprated your question. I don't know about other mods, I use kOS scripts for such purposes. I prefer to write my own autopilot scripts over "all in one" solutions offered by other mods. It was not most advanced things that can be found on internet, but it does job reasonable good enough, to automate a lot of tedious things and I always learn something new when upgrading/updating my own scripts.

I haven't played with RT for a while, but I keep tracking this mod and I did not notice anything in change log regarding behaviour, how it is used. But, it was never requirement to phyisically rotate whole craft(antenna) toward certain SOI or other craft, for communication. It would be impossible to maintain rotation of all crafts in game, because most of them are not even loaded in memory(crafts on other SOI, for example). You just need to select on antenna where it is "pointed" to establish communication and mod will do "magic" calculation in background if it is possible to establish communication or not. Slightly less immersive, but within game liminations to calculate things in simple way like that.

Spink Akron's idea behind it (discussed in old UKS thread) is to use few smaller engines first, before going with single 1.5m engine. Making History DLC offer engine plates parts that can help you building rocket. You can also use small cube or octagonal truss to help you with engine placement. I have ended creating scaled down 1-2,1-3 and 1-4 adapters. Might still have MM patch for this somewhere. It is not needed for users that have Making History DLC.

I'm not sure if itis meaningful or not to report bug on KSP bug tracker. Very few reported bugs are solved and on each update there is high chance to something else become broken.

It have effect on vanilla orbital rescue missions too. Even worse, if you are using mods that have cockpits without exit door. You can only rescue those kerbals if you are having discovered claw or similar part from mods that allow you to "dock" with stranded kerbal. Randevous maneuver need to be quick too. Somethnig to put in consideration when you are about to accept rescue missions.

You can find info about log files and required info in this post: KSP.log file can be found in the same folder where you have installed KSP and where KSP_x64.exe is nested too.

FAR offers some challenges in rocket designs too, if you seek for it. It is not only for planes. You may need to reconsider how you build rockets and even more important, how to steer it trough atmosphere (you should avoid deviating from prograde more than 5 degree when steering). There is also need for different re-entry strategy. All in all, I would not claim that it is harder or easier to create crafts with FAR. But it is different than to build it with stock physics.

Don't be afraid of "failed" flights. Put some science instruments on first rocket and transmit science before rocket crash on the ground. Put some early uncontrolable fins on angle, so the rocket will spin in flight and become more stable, capable of higher and longer flights. Unlock RCSs. On light rocket reduce RCS thrust power, so it does not consume much propelant and oversteer your probe rocket. It is harsh, chalanging, but doable. I played hard career mod (everything but saves/loads disabled) without any ground stations, only KSC and I reached Duna beofre I put that career game on hiatus (due to real life reasons).

Just put link on this forum post on bugtracker . Seriosly, I doubt that any of active squad crew would go trough this issue in such deep detail.

AFAIK, Far Future Technologies support CTT that is base for making UKS mod. Therefore should be compatible even if it is not listed in OP. However, if you feel that some parts from FFT are at wrong places trough tech nodes, as Cruesoe said, write your opinion on it. With so many mods published for KSP it is hard to check each one, but most of mods are compatible with either, or both, CTT and stock tech tree. So, you will be able to use any part trough career, just some parts might apear too early or too late in tech tree, depending on each player opinion.

There is description in changelog for latest release on github what is working and what not with KSP v1.11 in greater detail. Short answer, yes, it works with KSP 1.11, with in KSP and unity game engine limitations.

That is good to know. I no longer recall original author of that patch (it was posted somewhere on forums long time ago) and I didn't encountered such issue, so I didn't noticed.

Do you get stock arrow lift indicator on craft when you put culprit part on craft ? If you have those instead of just blue ball, then that is indication that such part does not have proper MM patches for it. Usually all of stock parts are covered by FAR config files, but it is possible that squad have changed some part or module names in latest release. I didn't yet downloaded last KSP release and played it yet, so, can't help you more about it. There is MM patch on previous page that can help you to identify problematic parts, if it is same case.

Integral parameter of PID controller: More info and methods how to tune it can be found on wikipedia and on various other web sites.

That kind of issue is best to bring on CKAN thread. I have to admit that I lost track what exact PW fork is supported by CKAN and what not. Best to call @HebaruSanor someone from CKAN staff to investigate this.

This piece from log just before CTD suggest that some mod that alters stock GUI in some way started to spamm log quickly and game crashed becaouse of it. [LOG 14:49:55.275] SurfAntenna added to ship - part count: 14 [LOG 14:49:59.968] Input field is focused, disabling keys It seems that spamm started after you have placed antenna and selected some edit box on GUI (place where you can write numbers and stuff trough keyboard). That is probably some leftover from debugging in some mod that is not removed prior release. Probably such mod was/have issues with editor and mod author put some additional writting in log to understand issue better. Unfortunately, it was not removed and caused CTD. Sorry, can't figure out which mod caused it from log. But, this piece from begining of your log is suspisious: [LOG 14:16:34.605] Load(Assembly): KerbalEngineer/KerbalEngineer [LOG 14:16:34.606] AssemblyLoader: Loading assembly at F:\KSP 1.10.1 modded\GameData\KerbalEngineer\KerbalEngineer.dll [LOG 14:16:34.609] Load(Assembly): KerbalEngineer/KerbalEngineer.Unity [LOG 14:16:34.609] AssemblyLoader: Loading assembly at F:\KSP 1.10.1 modded\GameData\KerbalEngineer\KerbalEngineer.Unity.dll ... <snip> ... [LOG 14:16:34.635] AssemblyLoader: Loading assemblies [ERR 14:16:34.759] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null [ERR 14:16:34.805] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null At first, KER plugins are recognised and loaded, but several log lines latter something from those dlls are not binded properly with something. Don't know if that message is harmless or not, you will have to ask for it in KER thread. Speaking of that, IIRC, there was few "unofficial" KER releases in recent past, I don't know if CKAN have picked some of those or it is sticked to some other repository. Anyhow, check a KER thread, solution for that issue might already be provided. I can't tell from log if KER is culprit for your issue or not, though. The rest of log does not reveal anything else that might be wrong. It may be that some of installed mods does not like to run along some other mod that is installed. While both of mods may work just fine alone it may be conflict when both of conflicting mods is installed.

One of reasons why you should not use mods on steam instance of KSP. You should rather keep steam install stock and make another copy/instance elsewhere on HDD for moded game. One reason is that some mods can overwrite stock files (any mod should avoid that, but it is possible), so steam may "think" that those files are corrupted. Second reason is that when KSP updates, it may take a while until mods are properly updated/supported. In both ways your saved games may become corrupted. You should create backup of your saved games before validating on steam. Then you should create a clean steam KSP install without any mods. Then copy that clean steam install elsewhere on HDD to create new instance of KSP. Install your mods over that new instance. It is better to install mods again as it is hard to say if tehre is already conflict somewhere between moded and stock files. After that copy saved games to new instance as well and do test run. Catch a log file from that test run and provide it here so it can be analysed to tell if there is still anything wrong with installs on your end.

You are welcome. Stock robotics and propelers are discussed earlier in this thread why it can't be supported by FAR. In short (and very rough) explanation, stock robotics and props use mesh transformation instead animations (if I recall terms correctly). Which means, there is no way to create code that will hook up on events when transformations start and stops. So FAR or any other mod that have need to intercept those events and do some custom calculations can't do that properly. On the other hand, Infernal robotics mod made long time before stock robotics is making animation start/stop calls, so whenever some robotic part stop moving and changing craft shape it "tell" FAR to recalculate lift/drag from voxel shape and wing shape.

Reason why you got stock PAW is that FAR didn't recognise part from mod you are using and removed stock data. Like in following example for stock part: @PART[AdvancedCanard]:FOR[FerramAerospaceResearch] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 !MODULE[ModuleControlSurface] { } MODULE { name = FARControllableSurface MAC = 0.93122 MidChordSweep = 37.044 maxdeflect = 20 b_2 = 1.7904 TaperRatio = 0.139074 transformName = ctrlSrf rootMidChordOffsetFromOrig = 0, 0.546675, 0 } } In that patch all of stock aerodynamic info is removed and replaced with FAR data. It didn't happened for part you are using. Except for proper removal of stock data, you also need to provide proper info for FAR. Info how to do that is on FAR github page. Following MM patch can help you to identify parts that miss FAR data: // Change Part title to make it visible in VAB/SPH if part is not compatible with FAR @PART[*]:HAS[@MODULE[ModuleLiftingSurface],!@MODULE[FARWingAerodynamicModel]]:NEEDS[FerramAerospaceResearch]:FINAL { @title ^= :$: *Non FAR*: } @PART[*]:HAS[@MODULE[ModuleControlSurface],!@MODULE[FARControllableSurface]]:NEEDS[FerramAerospaceResearch]:FINAL { @title ^= :$: *Non FAR*: } That MM patch will put "Non FAR" text in part title, so you would be able to identify culprit parts from VAB/SPH. EDIT: Forum does not let me to edit "code" part of post, so I will just put a link for suggested changes on MM patch from Drew Kerman:

It is very hard to guess what is going on without log, but, can you check out that you have properly installed Firespitter plugin and resource config file ? I can only guess that above function is failed to execute due to missing resource info. And KAX electricProp use some kind of unique resource "FSCoolant" that is "scooped" from air and there is no special fuel tanks for it. Engine itself contain that resource and is automaticaly replensihed in flight. But without proper firespitter plugin and resource confgig file that engine can't work in KSP. That is just a guess, ful log file can reveal if you have firespitter plugin installed properly or not.

Well, you have learned in a hard and unfortunate way why is always advised to make a backup. And why you should have separate copy of KSP for moded game from main steam install (if you use steam). Can't blame modders on this, they can't predict what can be broken in next KSP update. How much API is changed, or it depends on unity game engine changes (in some of KSP upgrades). You should always make a backup whenever you do some updete. Even if you only update some mods, they can have changes that may break your saved games. I can only suggest to start using S.A.V.E. mod, so you don't bother to do manual backup of saved games wit expence on some extra HDD space. Sorry for your loss of data, though.