BillNyeTheIE

It doesn't look like there's anything wrong in the log, there's a few bullet config related null exceptions but those are normal and it's just the code taking care of missing fields in cfgs. Is it just loading slower or is it actually getting stuck? Could you give more details about what exactly the loading problem is? Also the mentions of "KSP_x64_Data" in your log are a bit strange, could you verify that you installed CKAN correctly and directed it to the correct folder? Where is BDA+ being installed? Is it placed in the "Kerbal Space Program/GameData" folder? Do you have only one copy of BDArmory.dll in your game folder?

Can't access the file, are you sure you've shared it?

Can you post a log file? Also, does a manual install of the latest version work? Simply unzipping and drag-and-dropping/cut-and-pasting the "BDArmory" folder included into your "Kerbal Space Program/GameData" folder should be enough (in case you're not familiar with this process). Were you using a previous version of BDArmory before? Off the top of my head, a common reason for the game to hang on load is improper formatting within certain files (GameData/BulletDefs/BD_Bullets.cfg for example, the "def" bullet define has to be correctly formatted). If you've modified mod files in some way or are grandfathering in these files from an older install, a clean install of the mod could help you, if you haven't I'll have to look at the logs to be able to tell what's wrong, without them I can't help you.

What type of guidance are you using? "radarTimeout" is working exactly as intended. The BD AIM-120 is SARH/ARH, when you fire it it is initially guiding via SARH, at this stage when the lock is broken the missile self-destructs as it no longer has guidance data unless "radarLOAL" is true (which is the case for the BD AIM-120), in that case the ARH seeker will turn on and try to find a target. "radarTimeout" is intended for this ARH stage. If there is no target, or the target breaks lock somehow at this stage the missile will search for "radarTimeout" and then self-destruct. You'll know when the missile has successfully acquired using its ARH seeker (if you kept the lock) when an "ACTIVE" indicator flashes on the radar screen, at this point you can safely break the lock. Terminal ARH guidance works just fine without a lock, please describe what issue you're having, because I can dumbfire terminal ARH missiles, both with missiles that are SARH/ARH and with missiles with different initial guidance types, and have them lock on to targets. Are you within ARH range of the target? Is the missile able to engage the target type? (I.E. is Engage Air/Missile/Surface/SLW true?) Missiles also have IFF on them, are you trying to target a friendly? Have you made sure you and your target are on different teams? If you're still having issues, provide a video and log with debug options turned on and a more detailed description of what's happening. "lockedSensorFOVbias" works exactly as stated in the "sidewinder.cfg" file where a more detailed description of it is written, it's working as intended. If you have any confusions about what it's supposed to do feel free to ask but I can't help you if all you tell me is "it don't work". It's a KSP floatcurve as stated, the last 2 digits are the slope of the curve on the left and right of the point, if you want more information about it read documentation about KSP floatcurves. The BDA-E AIM-54 is currently broken, that's a known issue, it's been fixed and just waiting for a release. You can fix it in your install by replacing your .cfg file with this https://github.com/BrettRyland/BDArmory-Extended/blob/main/BDArmoryExtended/Parts/Missiles/ERRAAM/part.cfg .

Sorry, I've recently been busy but I've been meaning to update the wiki. The variable names should be relatively self explanatory, the gLimit is a direct gLimit, based on g0 or Earth/Kerbin gravity. It's not a 100% accurate gLimit due to various approximations, it also only considers normal acceleration of the missile. I would also recommend looking at MissileGuidance.cs to get a better understanding of it, I don't know if I can offer more of an explanation aside from the pseudocode. There exists a gMargin as well, which is basically an acceptable acceleration miss margin, where the missile pulls less gs in order to stay within the "non-separated flow" regime, basically where our drag curve rises rapidly. Do also note the guidance algorithms are not designed to take the missile load factor limit into account, so they may not necessarily perform harder early maneuvers to reduce terminal loads, you have to tune them yourself (for the ones that can be tuned). For realism, I'd recommend you use both maxAoA and gLimit, maxAoA for low speed maneuvering limits, or general aerodynamic limits for controllability, determined by the design's aerodynamics. gLimit is a structural limitation and you can just set it to be the specific overload you have in mind. maxTorque is a tuning factor and more or a control surface related issue, IDK if these numbers are easily found online. steerMult is more important, it's basically the P in the missile's PID controller. Set it such that your missile is appropriately pulling the gs you want it to in the regime it's designed to operate in. Technically this probably should be dynamic based on airspeed but that isn't a feature in BDA+.

Principia makes big changes to how the physics works, chances are that when you pick up the craft the vessel manager is having to fight Principia because both of them are trying to change where the vehicle is. Generally having multiple mods which change the physics of how craft move active at the same time can cause issues due to all of them trying to do something to the craft simultaneously IDK the actual compatibility of the vessel mover with PersistentThrust or wind mods (I suspect the latter may be more of an issue than the former) but if you do encounter this type of issue they're the first suspects if nothing shoes up on the log. They're all working properly, just that the combined result isn't what you want.

I mean the actual deviation in position designated by the laser, we're looking at the visual issue. It's not an issue with 1.6.x in general but rather 1.6.9.0 as far as I'm aware.

They are meant to be usable by the player, there's just a bug right now that's preventing that. In the next update you should be able to fire them at a radar, IRST or a GPS target. If you want to use the Phoenix for now you can just swap "targetingType = inertial" to "targetingType = radar" for now. The jitter issue is being looked at, right now the deviations seem to be on the order of ~0.1 m at 20 km so it should still be usable for targeting but you do need to be flying steadily. Regarding inertial guidance, like SI said there's a bug in the code that he fixed, they'll work in the next update. Like I said to Rakete you should be able to just swap the Phoenix from "targetingType = inertial" to "targetingType = radar" and the Swordfish from "targetingType = inertial" to "targetingType = heat" and they'll work for now, then swap them back to inertial after the next update goes live. The guidance laws for both the Phoenix and the Swordfish work just fine, it's just that they aren't being sent the targeting information they need.

I haven't played around with inertial guidance yet but I designed the guidance law for that missile and that sounds like an uncommon bug I've encountered with it, could you post the KSP.log file the next time you encounter this issue? Best I can tell is when the stars align in the wrong way, it (or something else) throws a weird bug in Unity which causes the guidance to fail. Have you tried launching the missile after reloading the game at any point? Is it consistently doing that?

Not sure what you mean, are you using the latest BDArmory release? If you mean Modular Missiles, they're behind the regular missiles in terms of features because they're slightly different in terms of code and need code specifically written for them. I explained it in this post

For the first question, I'll refer you to this series which I've posted previously: Long story short though, yes and no, "pronavGain" being set higher results in a more predictive missile, ensuring it's on an intercept course as fast as it can. This is advantageous in that for a predictable target, the energy cost to the missile is reduced, however, for an unpredictable maneuvering target this can be worse as the missile makes very early large adjustments which bleeds off velocity, resulting in an inability to achieve catch. There are no analogous integral and derivative terms for pronav, however there is "aeroSteerDamping" which is a derivative term for the missile, I.E. P = steerMult, D = aeroSteerDamping. In my experience I don't usually need to use it however, good selection of steerMult and maxTorque is typically sufficient. For the second question, as per the documentation on the wiki, there is the "terminalHomingType" field which allows you to select the type of guidance you want as terminal behavior. This defaults to pronav when not specified as aam wasn't achieving very good PK with aamloft. We also do have "hybrid" homing types, which also make use of "terminalHomingType" and allows you to have a boost/cruise phase guidance law and a terminal guidance law. For the third question, it's in the part right click menu, if the missile has "homingType = aamloft" the sliders should show up, with Advanced Tweakables on like you have it you should be able see all of the trajectory parameters. Yeah, apologies for that but currently modular missiles don't have support for some of the new features yet.

1) It's just used by the AI, EXCEPT for RCS missiles 2) It's a speed used in guidance calculations, it should be set to around the cruise speed of the missile, doesn't really have to be that exact. 3) steerMult affects how hard a missile steers, it's analogous to the P in a PID controller. 4) You could, but it'd be kind of difficult to do, you'd need a combination of steerMult, maxAoA and maxTorque to get anything that approaches a max G overload. 5) Missiles start with a 0 torque limit immediately after launch and ramp up to maxTorque at a rate of torqueRampUp torque/s. 6) Yes, just set uncagedLock = false, the missile is limited to 0.35 * maxOffBoresight while on the rail, once off the rail it can use the full maxOffBoresight. There is no current way to specify the on-rail maxOffBoresight independently. 7) uncagedLock = true increases that 0.35 * maxOffBoresight to 0.75 * maxOffBoresight and allows for cueing the missile on targets that are outside of the seeker's FOV prior to launch. 8) Not as of yet, I do plan on eventually working on radar notching being a thing and beaming making chaff more effective but it's not currently a feature of the mod. 9) Apart from loading the game up and firing them? Not really, it's why I allow for in-game adjustments of loft guidance parameters since that can take a while to tune. BDA weapons are generally made with stock aerodynamics and stock engagement ranges in mind, they're also made with gameplay rather than realism as the focus. The main thing that makes the missiles in particular unrealistic is the lack of fuel burn (which is a feature of the mod now) and the ridiculously powerful motors. Also, all the missiles use "aam" guidance rather than "pronav" which leads to it being a lot easier to defeat them, swaping them over to "pronav" and fixing the tuning on them (they'll generally need lower maxTorques and steerMults) will go a long way to improving their "realism".

1. Yes, but I'm not sure I can answer the question properly if you don't give me more of an explanation or an example of what you mean by "does not track". If you mean it doesn't lock when before you launch it, by default if uncagedLock = false, so if you're launching against an air target and the launch vehicle is in the air the max launch angle is 0.35 * maxOffBoresight. If it's true, or the vehicle or the target are landed/splashed then it's 0.75 * maxOffBoresight. If you're still not getting lock, are you close enough? Is the target facing you or flying away from you? If you've got lock and it's not tracking the target after launch, does the target have flares etc.? Flares are fairly effective right now against IR missiles, and the AI uses them pretty effectively. 2. Yes. 3. AAM is lead guidance, I.E. the missile calculates a lead based off of the current position of the target and its velocity and tries to point in that direction. It generally can hit targets, especially with the stock BDA missile configuration files and it's fairly insensitive to tuning, but it's also prone to undershooting and isn't that good against targets that are flying more perpendicular to the missile. ProNav and AugProNav, or proportional navigation and augmented proportional navigation are two commonly used guidance laws for missiles. They're pretty good, however they are much more sensitive to good tuning, I.E. having too high maxTorque, steerMult and/or pronavGain values can result in the missile doing a "twitching" motion as it over-corrects, then tries to correct for the over-correction etc. The explanation for how they work can get quite lengthy, I'd recommend this playlist on YouTube for a more thorough explanation: