kcs123

Yep, whole gameplay mechanic in KSP is not suited well for usage of weapons. BD Armory authors have to put a lot of effort to make that mod at least somewhat playable. Maybe if SQUAD was have weapons in mind in stock game, it could be possible to make it better, but I doubt that it would happen.

Personaly, I found that BD Armory is nuisance when you play space exploration career game. For example, physics range extender have conflicts with some other mod that I use and it cause unwanted slowdowns and kraken invitation. And also, true, you have no need to use any kind of weapon at all in KSP. If you exclude (un)wanted explosions from own craft failures and piloting mistakes, violence of any kind does not realy fit within spirit of KSP. I use BD ARmory, from time to time, though, on separate install. Mostly just for aestetic reasons to put weapons on aircrafts. I didn't found much fun to watch AI fights, I rather want to get involved in more active way to play game. Sure, you can do some dogfights against AI, there is even some contract pack for BD Armory, but I just didn't found it to be fun for me to play with it. It is not that I'm against violence in computer games, I played a lot of such games (heck, even moded one) where glore, violence, ubusive language, alchohol, drugs and other adult stuff is core of gameplay. I just found it that it does not fit in game like KSP is.

I'm new when comes to MM syntax, but above does not look legit to me. I suppose that firts "!AUDIO{}" command try to earse whole AUDIO module and after that, to add new one. Does MM can handle such thing properly ?

For anyone who play with Unkerbaled Start tech tree mod, I have created MM patches for IR Next parts and my own personal usage. Figured out that others may also benefit from it:

IR Next is just released. While IR Next comes with Ctt support, seems to be off the place for UKS. So, I re-positioned those along robotic line of tech tree branches:

InnerLock mod is not installed completely. Plugin and essential files are installed in "InnerLock" folder. However, that mod also have parts that should be installed in "MagicSmokeIndustries" folder: https://github.com/whale2/InnerLock/tree/master/GameData/MagicSmokeIndustries/Parts/Rework_Utility/Probe/Misc/IR_LockConnector CKAN only install files within InnerLock folder. While part itself is also modeled by Zodiusinfuser it is not within packed parts of Infernal Robotic Next mod. It can work by it's own without IR plugin. Maybe just a bad choice to place it inside MagicSmokeIndustries folder, but since IR next is also released, might be possible to add additional check for part if it can be installed when IR mod is also present or not. Don't know what to suggest to properly resolve issue. EDIT: Also, CKAN bot might have issues to catch properly new version of KJR Next:

You are welcome, but I'm not sure how CKAN will handle such version number. IIRC it sorts version number as string, so 4.0.9 is greater version number than 4.0.10 due to string sort. I might be wrong with this, have to check with CKAN staff to confirm, but might be better to set version number as 4.1.0 instead. It was released 18 hours ago, CKAN bot should be able to catch it by now. Afterall, latest release have received some serious overhaul in code.

When some parts have missing missing BulkheadProfiles info in part config files it can create issues with part filter in SPH/VAB. I have used this MM patch, to fix issue and detect parts with missing info: // Gambiarra para sobreviver ao bug do VAB/SPH no CategoryFilter. // https://forum.kerbalspaceprogram.com/index.php?/topic/181078-vab-category-fail/#comment-3517556 @PART[*]:HAS[~bulkheadProfiles[]] { bulkheadProfiles = srf, missingBulkheadProfiles } This fix issue with missing info and at the same time allow easier search trough MM cache to find culprit parts with keyword "missingBulkheadProfiles". On my KSP install, I have found few parts from USI/MKS mod and several others from Kerbal Foundries mod. I think that all parts from Kerbal Foundries miss info about bulkheadProfiles.

Some of parts have missing bulkheadProfiles info in config files. When that info is missing, it can create havoc with SPH/VAB part filters. I have detected them with this MM patch: // Gambiarra para sobreviver ao bug do VAB/SPH no CategoryFilter. // https://forum.kerbalspaceprogram.com/index.php?/topic/181078-vab-category-fail/#comment-3517556 @PART[*]:HAS[~bulkheadProfiles[]] { bulkheadProfiles = srf, missingBulkheadProfiles } This patch fix filtering issue and at the same time add keyword "missingBulkheadProfiles", so you can easy search trough MM cache and find parts with missing info. When comes to USI parts, those are with name "USI_Nuke_*", but could not hurt to use same patch for yourself, in case that I missed some, or don't have them installed in my Gamedata folder.

@theonegalen, have created MM patches for it, for his own personal use. Don't know if it is available somewhere to download or not.

One of first hing to try, as soon as I grab some time for it.

IR mod use different module names than previous version of IR and it is different from stock names in DLC. So, it should work with new DLC just fine. Only possible issue might be that you could not use DLC parts with same control GUI as IR mod and vice versa. Possible support might only happen when DLC is released and more info about new API and usages for DLC parts are provided. Should one work better than other it will be hard to tell until we all have a chance to try both and deceide.

I can only tell on that topic how much I can recall from the past and ongoing issues that some other mods have. KAX, unlike APP mod, does not contain wings and controled aerodynamic surfaces. So, as long it stay that way, to create only new cockpits, fuselages and similar parts, you are mostly covered in that regard. Wings and similar aerodynamic parts need additional info in MM module for FAR. More about it can be found on FAR github page, how to calculate wing surface area with help of blender and put proper values in MM patch, so everything could work properly. There is good "hack" to discover unsuported parts trough additional MM patch: That would not fix unsuported part, but it will let user know if he have some unsuported part installed. Another possible issue (I think it is solved for KAX long time ago) is collider from transformed "blured" propelers. In games it is necessary to fake a lot of things. One of those is spining propeler. Once engine start and propleler spin up, actual stationary mesh is replaced with another spinning, "blured" mesh part that is actualy static mesh that only gives ilusion of spining propeler. So, why that collider matter at all ? Well, reason is that FAR use colliders to detect boundaries of fuselages and such trough voxelization process. I think it is solved for KAX engines some time ago, by adding additional MM patch or something similar for those. Anyhow, issue is similar as invisible collider used by Near Future Tehnologies gravitational engines. It is described how it can be solved in this post: How it is represented in game, if it is not supported properly ? Well, if it is not "told" to FAR to exclude some collider from voxelization process, it will be calculated as any other fuselage part and it would cause more drag forces than it should be from spining propeler. It would not be calculated as another magical "wing" with drag and lift coefficients due to lack of info for wing surfaces, but it would act as any other body (fuselages and such) of similar shape and size to calculate drag and lift trough voxelization process. That being sain, I have only encountered issue with some APP parts (that were not wings) and FAR when drag and lift was not properly calculated on craft (some NaNs were involved). That was several KSP, FAR and APP versions ago, I haven't checked them lately to see if those still cause issue or not. So, when comes to propeler engine support for FAR, it comes to properly recognize colliders that should not be voxelized and create proper MM patch for it, that should not be too difficult, even I might be able to do it if I know proper module names. Well, I could find proper use of "demilitarized" cockpits (meaning no guns and such) and even for "bomb bay" if it is created in such way that could be used as cargo bay too, for transporting various things. Incoming DLC as well as IR Next mod offer much more possible uses from it.

Found some more parts that does not seem to fit properly in tech tree. SIGINT parts from DMagic Orbital science apear too soon in tech tree, much sooner than most powerful stock RA-100 Antenna. While those parts serve as science part, their secondary role is over powered Relay in comparison to stock parts. Put one such part in geostationary orbit and your comm network is early covered for whole KSP universe. So, I moved those for my peronal purpose much higher in tech tree. Also note that there is 3 similar SIGINT parts: "dmSIGINT.Small", "dmSIGINT" and "dmSIGINT.End". Seems like "dmSIGINT.Small" was not covered at all in config files, so it apeared too soon in "miniaturization" tech tree node. To balance out changes I have also moved part "dmScope" (least powerful in terms of Science collection) to "miniaturization" node, it was just one tier less than before, but also that part should be available sooner than GORESAT (infrared scope). @PART[dmSIGINT.Small]:NEEDS[CommunityTechTree,DMagicOrbitalScience]:BEFORE[zzzUnKerballedStart] { @TechRequired = experimentalScience //@TechRequired = miniaturization // apear too soon } @PART[dmSIGINT.End]:NEEDS[CommunityTechTree,DMagicOrbitalScience]:BEFORE[zzzUnKerballedStart] { @TechRequired = longTermScienceTech //@TechRequired = advScienceTech // previous tech node } @PART[dmSIGINT]:NEEDS[CommunityTechTree,DMagicOrbitalScience]:BEFORE[zzzUnKerballedStart] { @TechRequired = longTermScienceTech //@TechRequired = advScienceTech // previous } @PART[dmscope]:NEEDS[CommunityTechTree,DMagicOrbitalScience]:BEFORE[zzzUnKerballedStart] { @TechRequired = miniaturization // tier 5 //@TechRequired = advExploration // previous tier 6 }

By all means, if both of you have time and willpower for new parts, go for it. I do use BD ARmory, from time to time when I'm more in the mood to create aircrafts. And not only modern jets, but also WWI and WWII style aircrafts. Use to like Firespitter parts, but after several kraken attack, I have put those parts on hold. K.R.X. mod is good too, but also slightly behind from latest KSP. Airplane Plus have some good looking parts for aestetics, but also unsuported for FAR, so have to use them on separate install without FAR or again risk to put unsuported part on craft and invite kraken. Somehow, I always looked at KAX as civilian line of aircrafts, for aircraft transporters or small scout planes as well as experimental electrical crafts. So, it might be better idea to create separate part pack, like KAX Extension, or KAX Armory pack or something similar. Such new part pack may fit well with some other BD Armory weapon packs that are no longer in development. Such new mod could even get more attention as separate mod than if it is included with KAX.

Only thing that maybe "fit" to KAX mod is WWII and post WWII era of parts. But all of them have no good use without BD Armory mod. Don't get me wrong, your ideas are good for users that use BD ARmory mod, but for others that don't use BD Aarmory any of those enumerated parts does not exactly fit within style of other KAX parts. Your idea of part list might be more useful as part of BD Armory itself, rather than separate mod. IIRC, there was also some additional mod for BD Armory with extra parts, WWII era weapons and such, can't recall if there was cockpits and similar parts. Sorry, can't recall name of mod and if it is still in development or not. Just my opinion on this, since I'm not the one who maintain KAX, last call is from maintainer, his own free time and opinion is it worth to do it or not.

Well, that is at least some progress, have yet to try experiment with those once become available. I hope that is possible to avoid stock landing gear "autostrut feature", it is only concern for now .

Maybe it is too early to hope, but can those work when being attached to other craft part instead of ground ? Or it will be kraken invitation ?

My 0.02 cents on this: MM would be better idea to handle copying files than separate plugin. Possible issue with another plugin is timing, to execute copy command and wait for all files to be copied before MM start to search for other MM commands trough Gamedata folder tree MM would need to search trough all config files to see if any of them contain command to copy files before executing the rest of patches. That would be slow down loading game to some degree, depending how many files need to be processed twice. MM should restrict available folders for source and destination, otherwise someone could exploit it to copy some malicious files from elsewhere to KSP game folder Even better idea might be for less educated people to use CKAN and extend CKAN with new feature to copy files from deprecated folder to gamedata folder instead using batch file or doingh that with MM. People who don't use CKAN for whatever reason, already know how to copy files and read instructions what need to copy where, so it is less likely that simple batch file would be marked as virus from some stupid AV software. I have to deal with people that don't know how to create backup on their USB sticks every day and they either, don't want to learn it or they are to lazy to learn it. It can be strenuous at times to explain it again and again.

This page in kOS document might be good starting point. Try to enable SHOWSTEERINGSTATS first, to see what you will get in terminal. I wasn't investigated much of steering manager suffixes, what is readable only what thing can be set and what not. But, I remembered pieces of those info when steering manager received coding overhaul several versions of kOS and KSP ago. I can't help you much more on this topic, but I hope it will be good for start.

Can you try same with 4.0.0. version ? I have one craft that worked well with 4.0.0. but after some coding overhaul that fix discovered issues with 4.0.0. later versions have introduced some new bugs that was not happend to everyone. It would be of great help if you can send craft file that work properly with KJRn 4.0.0. but have issues with 4.0.9. If possible, only with stock parts. And be patient, next version is being worked on, hopefully it will solve issue you have, but describing problem with better details, creating videos, screenshots etc. might help to get fix sooner rather than later.

Hahaha, good one .

Sorry, "struggle" might not be the best term, please note that english is not my native language, so don't take everything written literaly. When I said first time that steering manager have "struggle" to steer rocket, I was not mean that it have lack of authority. I was thinking about unproper set of Kp, Ki and Kd of internal steering manager PID controlers. I apollogize that I didn't elaborate it better first time. Basicaly, what @Flibble said: But, things are slightly more complicated. I'm writting following from top of my head, I have found some info about it in kOS documentation, some info on this formu, some from other web pages, etc. Can't really recall all exact details. But, IIRC, steering manager use not one, but pair of two PID controlers for each axis: yaw, pitch and roll. Furthermore, it use some self-adjusting algorithm, to set apropriate Kp, Ki and Kd for PID controler. Over time, based on passed results it re-adjust itself. I'm not sure when steering manager re-calculate Kp, Ki and Kd during flight, but I know that it does. Now, at the begining of flight, influence of aerodynamic forces are neglectable, compared to gravity and other forces. And when aerodynamic forces started to build up, lift and drag coefficients are almost linear. Steering manager was set Kp, Ki and Kd for PID based on data from first seconds on flight. Suddenly when Cl and Cd become more curvatore, previous set of Kp, Ki, and Kd was no longer apropriate for whole craft steering system. It was not reacting quick enough when Cl and Cd rapidly bumps up and down and become more linear again. Now, I was talking about non linear Cl and Cd as most common issue of unexpected change in steering PID loop craft system. It may also be influenced by to steep momentum when you set different pitch angle or heading or any other outside force that was not exist previously when steering manager calculated Kp, Ki and Kd values. IIRC, @hvacengi have worked on steering manager for kOS, he might tell more accurate details how it works. Try to put mach velocity on the graph you posted above. Also grab screenshot of FAR velocity sweep graph from 0 to 2 mach and for AoA 0 and 5. For each craft Cl and Cd is diffrent and become non linear sooner or later. So, aproximation of 0.8 up to 1.2 mach for transonic flight may not fit to all crafts. On your second video, pitching and heading is more stable, but you have heavy roll oscilation on transonic flight. You need to compare flight records (mach and AoA) with FAR graphs from VAB/SPH for velocity sweep to see when you can expect unstable transonic flight regime. Based on represented data, it is nothing wrong with steering manager in terms of some software bugs involved. It attempts to do it's job best as it can, but it is not always perfect and you can't expect perfect ascent path as you desire. Considering how much variables are involved, kOS steering manager does it's job pretty well. As much as I can recall from kOS documentation, it is possible to set different Kp, Ki, and Kd to steering manager if default settings does not give desired results. Also, other option is to not use build in steering manager, but to create your own with your own PID object and raw controls. I tried this long time ago and realized that built in steering manager doing it's job much better than I was able to accomplish with separate PID controlers and raw control inputs.

Didn't think about using that, to be honest I'm new with MM syntax and it is only 3 levels of SAS. I see few issues in your aproach. SAS0 actualy don't exist, there is missing variable for those probes in part config file. That would also add kOS CPU on craft with 0 disk space that is almost useless, can't put even boot file on it. It would only create more confusion as you would need additional CPU on that craft. I don't desire CPU on that probe level at all. Second issue, it is not linear function. Highest level is set to 300,000 while second is 20,000. I have choose "3" and "2" multiplications to easier check out MM patch within game, not necesasry have to stay like that. So, if anyone want to tweak it further, I think that it would be easier and more understandable for noobs to just change exact number to desired level. Thanks to let me know about possible other solutions, might be more useful in one of my other personal MM patches that I started to create for myself.

@theonegalen, is it possible to remove "FINAL" from this KAX config ? //Hide Propelators, which asre useless without tiny SXT wings @PART[KAXVintagePropelator|KAXVintagePropelatorExtra|KAXVintagePropelatorS|KAXVintagePropelatorSS]:NEEDS[!SXT]:FINAL { @TechRequired = unresearchable @category = none @TechHidden = true } I don't use SXT mod, but don't find those engines useless without it. And because of "FINAL" command, I need to comment out this piece of code each time when UKS mod updates. I can't create my own MM patches that could overrride that MM comand. It wont work. More apropriate thing would be to use BEFORE or AFTER UKS or something like that. I understand that there is some people who want just to hide those parts, though.