DocNappers

dist_dir.txt should contain some valid path that 7z can output the zipped file for distribution to. In Linux, the Distribution folder is used, which would be something like D:\github\BDArmory\BDArmory\Distribution in Windows (I think, you may need to experiment). After building it'll give something like BDArmory.1.6.0.2_2023-04-30T10:08:00+00:00.zip in that folder. Yes, the other .txt files should have the paths of those executables and the ksp_dir.txt file should have the KSP game path (you can have several, one per line). Pull requests https://github.com/BrettRyland/BDArmory/pulls for when/if you write something that you feel ought to be included in the official release.

Build instructions differ slightly if you're on Windows or Linux. In both cases, you'll need to create the _LocalDev folder in the parent directory of wherever you clone the BDA git repository, e.g., some folder |- _LocalDev |- KSPRefs |- ksp_dir.txt |- pdb2mdb_exe.txt |- 7za_dir.txt |- dist_dir.txt |- BDArmory |- BDArmory |- BDArmory.csproj If you don't need to package the build for distribution afterwards then you don't need the *.txt files, but you'll want to disable the post-build step to avoid getting errors about that. The pdb2mdb_exe.txt, 7za_dir.txt, dist_dir.txt files are only required for Windows to tell it where various programs are installed for the post-build step. The BDArmory.dll should be built in BDArmory/BDArmory/bin/Release (or Debug), which you can install by copying to your KSP/GameData/BDArmory/Plugins folder (while KSP isn't running otherwise it'll start throwing exceptions and likely crash), also anything you've changed in the BDArmory/BDArmory/Distribution/GameData/BDArmory folder. The KSPRefs folder should contain the DLLs in Kerbal Space Program/KSP_Data/Managed. On Linux, the easiest is to just make KSPRefs a symlink to this folder. On Windows, you may need to copy them. Don't adjust BDArmory.csproj with different paths to match your local setup, adjust your local setup to match the above, otherwise making PRs against other repositories becomes difficult. For building on Linux, you'll need to install dotnet-sdk-6.0 and mono-devel (package names may be slightly different on flavours other than Ubuntu) and set FrameWorkPathOverride=/usr/lib/mono/4.8-api/. You can then build BDA on Linux by running dotnet build --configuration Debug in the BDArmory/BDArmory folder. For building in release mode and skipping the post-build step, you'd use dotnet build --configuration Release /p:PostBuildEvent=. For building on Windows, .Net and other relevant libraries and settings should be already set up by Visual Studio, but you may need to enable/disable the post-build step somewhere in its settings. To get proper line numbers from errors and exceptions in the KSP.log in Debug mode, you'll want to follow the instructions at https://forum.kerbalspaceprogram.com/index.php?/topic/102909-ksp-plugin-debugging-and-profiling-for-visual-studio-and-monodevelop-on-all-os/ (there are some updates to the instructions in the most recent posts). I see Papa_Joe has written some scripts for automating setting up a build environment in WIndows https://github.com/PapaJoesSoup/KSPDevEnvironmentBuilder for this, but I haven't tried it.

It's still there in v1.6.0.2: It requires "precision engineering" tech, in case that's why you're not seeing it. I think this is working again. SI looked at some stuff related to missiles and fixed various things in the last few releases.

yes

If you're using the "Space Hacks" game mode, then there's settings for making space not behave like space (i.e., "Space Friction" and "Cornering Multiplier" which apply drag and other forces to craft in an arcade-like fashion as if they were in an atmosphere). The "Ignore Gravity" setting adds forces to craft to counter gravity as long as they have a WM and engines. While "Space Hacks" is enabled, the pilot AI will use RCS to manoeuvre, but it's not super effective (if you want to see it in action, FJRT ran a round with space battleships using it recently and I think they're planning to do another one with lighter craft soon). The "Repulsor" effect is a bit different from the other space hacks as it's more for hovercraft style vessels. It treats wheels as anti-gravity points that will try to keep craft at their default altitudes (kinda like Star Wars style skimmers). RWP has just run a round using this, but the official stream hasn't been run yet. The above options essentially mean that the craft are floating in space instead of orbiting at high speeds, so the pilot AI behaves as if it's in an atmosphere. If however, you want craft to shoot at each other while traveling at orbital speeds (i.e., >1km/s relative to the surface of the local body), then you'll need to enable "Vessel-Relative Bullet-Checks" so that the physics of bullet collisions works properly. This performs the collision detection of the bullets in each of the crafts' relative velocity frames to prevent bullets from jumping through craft, but incurs a noticeable performance cost. You'll also need to increase the range in PRE to something suitable so that KSP doesn't pack the craft beyond that range. However, the WM has a hard-coded max visual range of 200km (floating point rounding errors are quite large at this distance) and the pilot AI will still try to "fly" as if it were in an atmosphere instead of using orbital mechanics.

I haven't used NKDR, but I doubt it. NKDR shouldn't be interfering with BDA's models and configs unless they've got some broken MM patch affecting things. You could easily test this by temporarily removing the NKDR folder from your install (i.e., move it out of the GameData folder, then move it back once you're done testing).

The models for the nuclear explosions are in BDArmory/Models/explosion/nuke. To configure a missile to use them, take a look at BDArmory/Parts/AIR-2/part.cfg. To configure bullets or rockets to use nuclear payloads, set the nuclear option to true in the appropriate bullet or rocket definition in BDArmory/BulletDefs/BD_Bullets.cfg or BDArmory/BulletDefs/BD_Rockets.cfg (see the explanation of the fields in the default bullet or rocket config).

It should be fixed now in v1.5.9.4. Essentially, the Krakensbane frame velocity wasn't being taken into account when using manual targeting with the mouse (other targeting methods weren't affected) and in the visual predicted trajectory for bullets if debug lines and draw aimers are enabled.

It looks like the Krakensbane frame velocity isn't being compensated for properly in the aiming assist for some reason. I'll look into it. This seems to go back at least as far as v1.5.0.1. If you add in a second vessel in the area, the frame velocity should revert to 0 and then the aiming calculation works correctly. You can see the components of the aiming calculation by enabling both debug lines and debug weapons in the settings (the cyan + markers show the target and aiming positions, the green line shows the relative velocity component, the magenta line shows the relative acceleration component and the yellow line shows the bullet drop component due to gravity). Also enabling debug telemetry will show the krakensbane frame velocity in the upper left of the screen. The horizontal curving of the bullet paths is due to the change in perspective from the plane that's firing them. They're not actually curving sideways.

v1.27.0 of CameraTools is now available with the following improvements/fixes: Fix dogfight centroid mode. Add checks for the active vessel being a BDA missile and use dogfight chase mode if it is. Add roll option to stationary camera using right+middle mouse buttons, with the movement modifier key (keypad enter) switching between camera and world coordinate systems. Add support for using the MouseAimFlight mod in dogfight camera mode. Delay camera activation/deactivation when not in flight mode until back in flight mode.

Runway Project is managed in a section of Scott Manley's discord. FJRT has it's own discord. Son of Smith also has a discord. Each of these are suitable for sharing planes and configs. I'm sure there are several others too. Actual development of BDA+ and related mods occurs on the "Project Münway" discord (which can be found from the other discords), but that's more for coding, modelling and bug fixes than for sharing planes and configs.

Submit a bug report at https://github.com/BrettRyland/BDArmory/issues, which will let you upload the KSP.log file with it. This kind of bug needs the log file to be able to debug it.

It's a re-implementation of JR's VesselMover mod with a variety of improvements and fixes (which are listed in the changelog). You can replace the stand-alone VM with it or use it alongside if you want, though using both to move the same craft at the same time will likely do something weird.

Yeah, it's already fixed in dev. Thanks anyway though.

The auto-tuner stores the PID values with the lowest loss when it gets disabled, not the most recent. Additionally, the PID values are written to the KSP.log file whenever a new lower loss is found. Look for entries in the log with [BDArmory.BDModulePilotAI.PIDAutoTuning]: Updated best values: ...

Looks like it triggers an exception internally due to looking for a null dictionary key. Unfortunately, I don't know where that key is coming from, so there's not much I can do to fix it. Some missiles have radarLOAL (lock on after launch), but I'm not aware of any that can use a data link to get that lock from a separate radar. Others may know more though.

I don't have much experience with using them, but I think they should be working. Maybe @SuicidalInsanity or @josuenos can comment on how they're supposed to be used and if there's a bug with them?

I'm fairly sure that anti-rad terminal guidance should be able to home in on the ground radar once it's within range, however, I think some radars are smart enough to disable their radars when they detect an incoming anti-rad missile. Others with more experience using them can probably tell you more.

From the in-game description: A forward facing InfraRed Search and Track system housed in an aerodynamic pod. It can scan and detect thermal signatures within a 120 degree field of view. It is optimized for air-to-air use, and has difficulties detecting surface targets. Basically, it's an infrared detector that works as an alternative to radar for locking and tracking heat sources (e.g., other planes). https://en.wikipedia.org/wiki/Infrared_search_and_track

Yeah, Stationary Mode doesn't currently support rolling the camera, but I can look into an option for adding that. Note that the behaviour of the mouse control is different depending on whether the camera target is set or not.

I've added this in. It turned out not to be too difficult after all. One of the devs that does modelling would have to take a look at that (@SuicidalInsanity?) Have you checked out BDA-Extended https://github.com/BrettRyland/BDArmory-Extended/releases? It has a number of parts that you might find interesting and is maintained by devs either involved with or closely working with BDA+. BDA+ itself is intended as a framework for other mods to create part packs and only contains a few examples of each of the features that BDA+ provides, so it's not the correct place to add extra variations on weapons. There's not much we can do about other mods that don't update their configs, but I think at least some of them are still maintained. This is in the "Wing Commander" panel from the in-flight WM (BDA Weapon Manager -> Wing Command). It has an option for following. I think if the wingmen have guard mode enabled then they'll attack enemies that come nearby, but I'm not sure about this.

Self-sealing tanks and firebottles only apply to tanks with LiquidFuel or MonoPropellant (self-sealing only) resources when the part is loaded, so adding LF/monoprop to a tank, saving the craft and reloading it should add in the fire bottle and self-sealing options. Alternatively, adding LF/monoprop and then copying the part also adds the options to the new part. Fuel leaks and (non-surface) fires only apply to parts with LF/Ox/monoprop and batteries, so inerting and firebottles are irrelevant for tanks containing other fuels.

There's a hard-coded 100HP lower limit for everything other than missiles currently, though this could potentially be changed for MM-patched parts. I'm not sure if setting current HP will do anything or not.

The cruise prediction time is used in the cruise guidance for predicting the altitude and speed ahead of time (missiles with slower reactions need to look further ahead to avoid crashing). The optimum airspeed is the speed at which the missile gains full control authority, i.e., below this speed its ability to manoeuvre will be reduced. It's also used for DLZ (dynamic launch zone) calculations. This isn't as straight forward as the idea seems since there isn't currently a state tracking which of the GPS coords are selected, the current GPS coords are just copied to the WM when you click on one of them. However, I'll have a think about how this could be implemented.

You can modify their health in GameData/BDArmory/MMPatches/000000_HitpointModule.cfg to whatever you like.