kcs123

There is new bug in KSP introduced with 1.9.x. Discovered and discussed in Tweakscale thread. Quoting just relevant part: It is very likely that you are using some mod that alter craft resources and too add on top of that, you were using savegame from previous KSP releases that was edited outside of KSP to make it work at all. Quite a lot is possible to go wrong way, it is hard to even a guess what.

Files should be "MM_IR_rotationalScales.cfg, MM_IR_translationalScales.cfg and MM_IR_utilityScales.cfg". I helped a tiny bit to @ZodiusInfuser while it was created. My current install is a bit of mess between official release and custom/beta patches. Some of patches might nov even be released to public yet. It is being worked on them like 9-10 months ago, don't recall exac date. I think that those are already published, but can't tell for sure. Let me know in PM if you can't find those.

Check out in TS thread. There is new dependency plugin for latest TS. For users that don't want to use tweakscale at all, there is built in patch in IR that offer all parts in various sizes, so you don't need to use TS at all.

For IR parts, truss and similar parts were placed in Construction line of tech tree nodes (sorry don't know exact noce names from top of my head). So, those truss parts from SOC mod should be fine to put there too. Some may be put earler, some later on tech tree, but in general, that line of tech tree should suit better for those parts than SpaceExploration node. Fuselage, wings, landing gears seems to be OK along Arodynamics/Aviation/Landing lines. Maybe picture from OP as reminder can help:

kOS integration with IR next was created in period when IR next was in heavy development. So, yes, IR API have some changes and while basic kOS support was done at that time, it was experimental and AFAIK it is not finished yet. kOS could still search for old IR plugin instead of IR Next, while script support was probaqbly created. That is my best guess. I would like to see better kOS/IR next integration that would allow even better stuff than it is possible trough stock controler.

100% means that engine have enough air for operation. Lower than that, engine will start to loose thrust. IIRC, somwhere around 10%, engine will flame out, or shut off. Above 100% means that your craft have more than enough oxygen from air intakes for normal operation.

Jet engines need Liquid fuel and air with oxygen for combustion. "Air Req Met" tells how much air is provided trough air intakes for jet engines to operate properly. It depends on altitude and mach numbers. Some inlets are more efficient than others and some jet engines operate better in subsonic than supersonic and oposite. That info comes handy when you try to optimize your craft to use least amount of inlets and those that weight less than others for certain craft purposes.

Only thing that pop up on my mind is to use separate version numbers. For KSP 1.9.x and further, use higher version number for TS. That can have dependency on KSP reacall. For KSP 1.4.x up to 1.8.x use lower version numbers without dependency on KSP recall. TS code could still be same, even same compile, just need to be distributed separately with different version number. Rudolf made similar stunt with IR Next. That is to satisfy CKAN syntax and handling of various KSP and mod versions. For users who do manual installs, it might be oversighted need of new dependency. For those, "simple" warning in TS code if it run on KSP 1.9.x instance should do a trick. It will be hard to help those who don't read forum posts and warning messages on screen, no matter of font size and color.

@Lisias, you have forgot to follow your own thread And this is quite fast solution. Things to do, though is to change TS dependency on CKAN. Once it is tested and confirm to be stable, TweakScale 2.4.3.10 and later for KSP 1.9.x should have dependency on KSP Recall to work properly. CKAN staff should be notified to add both, KSP Recall and TS dependency in metadata files.

Grumpiness Factor is understandable, I mostly agree with everything said there. To add on this, I got impression that someone on higher position who "pulls strings" demand on coders to finish everything within unreasonable time frame, leaving a lot of new features half finished or with unsolved bugs. Also leaving a lot of unsolved/unreviewed bugs from several KSP versions ago and introducing new set of issues each time. Back to topic, on this issue. Best option should be to report bug to SQUAD and to solve issue on main KSP code. I don't have high hopes that they will do it or that they will do it in reasonable timeframe, but, yes this bug will impact a lot of mods and will make a lot of mod developers to just give up on further development. And moding scene and community is more than 70% of reasons why this game is still "alive". Second, less ideal solution would be to create separeate plugin, something like Modular Flight Simulator that assure MM, Deadly re-entry, FAR, RealChutes and some other mods can co-exists without steping on each other toes. Therefore, mods like FS, B9 partswitch, firespitter and similar could also be aware of new plugin as well as TS, to asure that everything work as intended. At the same time, such plugin must also assure that it does not broke again thing that SQUAD have "fixed" in KSP update. It is sad that community need to create fixes and workarounds that should be solved properly by SQUAD in the first place.

That part of log only tell that nullreference on object have happened, however it does not tell on what exact craft part or object it happened. I can only guess that it happened because after update some of mods you are using are become broken. That craft contain invalid/broken part that cause such exception, while other craft does not have them and work fine. To help you further, it would be necessary to provide full log, not just part of log and possibly MM cache files. Those might netter reveal what mod have failed to load properly. Savegame or craft file would not hurt either, but it is hard to expect that someone would install hundreds of mods just for debug purposes. When you suspect that some mod is culprit, it is best practice to reproduce bug with minimum of mods installed, to speed up support process. In my opinion, FAR have just revealed that someting else is broken, not that FAR alone cause strange things.

Nothing weird. It is something to be expected. You are using cheats over stock tech tree node names. So, cheating only unlocks known stock tech tree node names, it is not aware of custom CTT node names. CTT preserve stock tech tree nodes, so any mod with parts will be compatible with CTT even if there is not using any of new CTT tech tree nodes and even if such mod is not aware that CTT is installed. If you need everything unlocked, it is much more simple to just use sandbox game mode.

Everything is subject to change, I have yet to begin new career game in KSP 1.9, but I think that @Beetlecat suggestion reasonable good: veryHeavyRocketry seems to be good suggestion. You may want to use similar MM patch as in linked post, just use proper part name for Thumper booster. If you think that better place for Thumper booster should be sooner or later in tech tree, give a feedback with suggestion where it may be more apropriate place, so we can create different MM patch for that. We can only help each other while waiting for official UKS update and it will be easier for SpikAkron to create update once available free time for moding allows it.

Not sure what you mean by "normal" controls. I can only guess that you have missunderstood how controls works with FAR. Several pages back someone asked similar question:

Then you most probably want to change "Omni" variable values for ground station antennas. Those old SETI configs might still work, worth to try. There seems to be exact variable names in both, RT configs and SETI configs. Although, don't know if it will work in exact same way as it worked in old KSP versions and old RT version. Part of SETI configs: //---License (except for the names, ground station positions and the version file, which are AllRightsReserved): GPL version 2 (as RemoteTech itself): http://www.gnu.org/licenses/old-licenses/gpl-2.0.html @RemoteTechSettings:NEEDS[!GPP] { @EnableSignalDelay = False @RangeModelType = Standard @MultipleAntennaMultiplier = 0 @ControlAntennaWithoutConnection = True @UpgradeableMissionControlAntennas = False @DistanceToHideGroundStations = 3E+06 @RemoteStationColorDot = 1,0,0,1 !GroundStations,* {} GroundStations { STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = KSC Mission Control Latitude = -0.131331503391266 Longitude = -74.594841003418 Height = 100 Body = 1 MarkColor = 1,0,0,1 Antennas { ANTENNA { Omni = 9E+11 } } } } } Default RT settings got those: GroundStations { STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = #RT_MissionControl Latitude = -0.13133150339126601 Longitude = -74.594841003417997 Height = 75 Body = 1 MarkColor = 0.996078014,0,0,1 Antennas { ANTENNA { Omni = 75000000 Dish = 0 CosAngle = 1 UpgradeableOmni = 4E+06;3.0E+07;7.5E+07 UpgradeableDish = UpgradeableCosAngle = } } } } You may try to change only "Omni" variable value to be 9E+11 instead of 75000000 to see if it provide desired effect. Can't tell you from top of my head exact MM patch command, I need to check MM syntax to properly change nested values. So, it might be easier to just edit RT config file directly to get started with changes.

Do you really need those ? Additional ground station settings were useful long time ago, when stock game didn't got any. Disabling signal delay should be possible trough RT config/install, IIRC. Antenna range was change a lot since those SETI configs were made, so it would not work as intended like at time those configs were created. So, what exact current feature from RT you don't like and should be changed like it was in SETI configs ? Asking, because it might be easier to create new personal MM patch than to copy and change those obsolete SETI configs.

Most probably oversight, but you will have to wait for Rudolf for proper answer.

I have recalled that something may be changed somewhere, but I forgot to look in this thread just few posts above before answering. Thanks for reminder. I should probably check if I need new pair of glasses too . As lon as some parts is configured properly for either, stock tech tree node or CTT it will work properly with UKS, although, with possible minor gamebalance issues. Reason why it works is that CTT tech tree contains all of stock tech tree node names beside new ones for other moded parts. UKS contains both of those as well as few it's own nodes for gamebalance purposes and ability to avoid unlocking parts tha you might not need. For everyone else, instead of editing existing files and until official UKS update, you can write your own config file and put in there following: // Unkreballed start KSP 1.9x config changes for new stock engine names //rocketry7 @PART[SSME|liquidEngineMainsail_v2|Size2LFB]:NEEDS[CommunityTechTree]:BEFORE[zzzUnKerballedStart] { @TechRequired = rocketry7 } //heavierRocketry @PART[MassiveBooster|engineLargeSkipper_v2]:NEEDS[CommunityTechTree]:BEFORE[zzzUnKerballedStart] { @TechRequired = heavierRocketry } That way, if you need to re-install UKS for whatever reason, you don't need to edit again same config file and it would not do any harm when UKS is updated either.

It should be fine even without any additional patches. Report if you find out that some of new stock parts (drain valves) should be moved elsewhere on tech tree. I don't know if other stock (revamped) parts have changed names, that is only thing that might break UKS slightly that I can think of right now.

For KSP 1.4.x you probably want older version of IR: https://github.com/meirumeiru/InfernalRobotics/releases/tag/v3.0.0 Later IR versions use some of features included with KSP 1.7.x that could not work on KSP 1.4.x

Notepad++ or similar advanced editor. First search for keyword "warning". Usually, there is not so many in log files to make it difficult to search trough. On that line or one-two lines below is most probable chance to see another keyword to search for. Mostly the part name that raised up warning message, sometimes the name of plugin. When you find out part name that is culprit, use Notepad++ to search trough folders and within files for that next keyword. That should reveal exact config file where is part that cause error or warning message. And last piece of debugging puzzle is to reveal exact line in config file that is wrong and rising those error/warning messages. I would not recommend ModuleManager.ConfigCache file as starting point for searching for culprit parts. It is helpful later on when you get more familiar how MM works, though.

Don't browse forums late at night You have also missed this: Just a few post above, and since it is pre-release, it will not be available trough CKAN. So , you will need to install that manually.

Not yet tried, but someone has also reported elsewhere that real chutes does not work either. So, both, FAR and real chutes are affected with KSP 1.9 and need to be updated.

Well, I understand quite well where your frustration comes from, it is unavoidable and unfortunate part of sowtware development. Belive me or not, but I got quite a lot of stupid demands due to user mistakes on my regular job than trough mod development (on different game and differnt community though). So, with some of steam blown off, best of luck with hunting other remained bugs and new ones from KSP 1.9. Take your own pace and do that while having fun with that at same time, that's only advice I can give you to avoid being burn out and other frustrations.

Yes, just have to notify someone of CKAN staff that you want to opt out your mods from being listed on CKAN. But, you can also notify CKAN staff members when there is new dependency, such things are usualy resolved quickly. I doubt that opting out from CKAN would completely solve issues with install mistakes. In last few weeks I have witnessed several faulty manual installs. So, neither is completely foolproof. But with each new CKAN version things are improving and users became more aware how to use it. With rapid dynamic changes around KSP community (KSP updates, mod updates, hosting service changes etc.) it is not very likely that faulty installs will ever be completely ironed out. But, community is changing as well, so there is more people that are willing to help each other, to resolve things quickly. Despite some frustrations that happens from time to time.