Jump to content

DocNappers

Members
 View Profile  See their activity

  • Posts

    258

  • Joined

  • Last visited

 Content Type 

Everything posted by DocNappers

  1. DocNappers
    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.
  2. DocNappers
    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).
  3. DocNappers
    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).
  4. DocNappers
    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.
  5. DocNappers
    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.
  6. DocNappers
    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.
  7. DocNappers
    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.
  8. DocNappers
    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.
  9. DocNappers
    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.
  10. DocNappers
    Yeah, it's already fixed in dev. Thanks anyway though.
  11. DocNappers
    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: ...
  12. DocNappers
    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.
  13. DocNappers
    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?
  14. DocNappers
    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.
  15. DocNappers
    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
  16. DocNappers
    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.
  17. DocNappers
    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.
  18. DocNappers
    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.
  19. DocNappers
    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.
  20. DocNappers
    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.
  21. DocNappers
    You can modify their health in GameData/BDArmory/MMPatches/000000_HitpointModule.cfg to whatever you like.
  22. DocNappers
    v1.26.0 of CameraTools is now available with some minor fixes/improvements: Prevent the camera from going below the surface in dogfight mode when the vessel is landed or near the surface when splashed. Disable roll and offset in dogfight mode when the vessel is an EVA kerbal. Ignore ksp_dir.txt lines starting with # for post-build events in Linux (not sure how Windows should do this). Fix bug in field name for input boxes.
  23. DocNappers
    Sure, I'll add one in.
  24. DocNappers
    This is now fixed in dev and will be in the next release.
  25. DocNappers
    Yes, v1.5.7.0 contains the changes from v1.5.6.2. We're busy making silly designs for the current RWP round, but will look into this bug shortly.
×
×
  • Create New...