Jump to content

DocNappers

Members
 View Profile  See their activity

  • Posts

    256

  • Joined

  • Last visited

 Content Type 

Everything posted by DocNappers

  1. DocNappers
    With the "Auto Zoom" disabled, the zoom already goes up to 1000x (technically from 1 to 1096.6=e⁸/e¹), but yes, I can make the limit customisable. I presume for the free camera distance, you're referring to the distance in dogfight mode since the other modes don't have any limits. Yes, I can make those limits customisable too.
  2. DocNappers
    They should have already been firing within the DLZ range, but there was a bug preventing this. It's now fixed in dev, so it'll be in the next release.
  3. DocNappers
    That's quite a game breaking bug! I'll look into it.
  4. DocNappers
    How are you spawning the craft (via BDA+'s VM, the vessel spawner window, via the original VM mod, something else?) and under what conditions (is a competition running, is vessel-switching active, etc.)? Providing a KSP.log file would help in figuring out what is happening. Generally, if the craft being spawned has an EVA kerbal, then KSP automatically switches to it; this can't be avoided at the moment (something internal to KSP is doing it, not BDA). This shouldn't make a craft lose control or get eaten by the Kraken though and neither should any of the other methods for spawning craft in BDA+. The auto-enable vessel-switching is for automatically enabling the vessel-switching when competitions start (i.e., it enables the A on the vessel switcher window). I'm not able to reproduce this on BDA+ v1.6.3.0. A Jernas turret on a surface vessel with AMRAAMs (Aim-120) will happily fire them at a circling plane in my tests. Can you provide more details on how you're triggering this and a full KSP.log file that can be analysed (you can submit a bug report at https://github.com/BrettRyland/BDArmory/issues)? Edit: I'm seeing these errors showing up in a different situation and am looking into it.
  5. DocNappers
    This isn't directly a bug in Camera Tools, but it is aggravated by it. Basically, the Sound Manager in KSP only has a limited number of virtual channels and the stationary mode in Camera Tools adds a bunch of audio sources to various vessel types when the "audio effects" option is enabled. If too many audio sources get added to KSP's Sound Manager, then it just breaks for a while (I'm not entirely sure what it's doing internally or what the precise trigger that makes it break is, but it usually recovers after a while once the number of active audio sources decreases again). Camera Tools tries to detect when KSP fails to play its audio sources and stops trying to play those audio sources for a bit to try to help KSP recover, but it's a bit of a black box.
  6. DocNappers
    Feature requests and issues can be reported on the github repository here (where they hopefully won't get lost). General questions are probably best asked here where others with knowledge can also provide answers or others with the same question can get those answers. If there's something that you'd rather not be public though, then you can DM me and I'll try to answer.
  7. DocNappers
    Yep, something seems to have gone wrong with it... I'll look into it. That seems like something suitable for BDArmory-Extended. You can make a request there and hope one of the devs that do modelling makes it.
  8. DocNappers
    The pitch and yaw speeds are in the turret configs, so you can just apply a MM patch to adjust them or copy the part config and make your own variants. Similarly, the fire rates and accuracy (maxDeviation) are in there and can also be adjusted.
  9. DocNappers
    Version 1.28.0 is now released. Improvements / Bugfixes Adjust random mode selection for low altitude to be more amenable to BDA pod-racing. Add a visual toggle for free-move mode (speed vs position). Add an optional keybind for resetting the roll in stationary camera mode. Initially unbound, remove the entry from the settings.cfg to unbind it once bound. Fix camera position in Stationary and Dogfight modes when returning from Map mode. Add a free-look mode to Dogfight mode (hold right mouse button, compatible with MouseAimFlight integration).
  10. DocNappers
    No idea. One of the others might know though. Those two depend on BDA Continued, not BDA Plus, however, their respective forum threads indicate that it's possible to use them to some extent by installing them manually NKD thread, Kerbal Field thread.
  11. DocNappers
    Sorry, I didn't see your post until now. I must have missed the notification somehow. Speed mode (vs position mode) for keyboard input was added in v1.23.0 (with the default keybind of [2] for toggling it) for smoother movements. I can add a visual toggle to the settings so it's easier to see which mode it's in. I presume this is what you meant by SAS. This still works, but by the sounds of it, you have one of the "Auto Flyby Position", "Auto Landing Position" or "Manual Flyby Position" toggles enabled, which overrides the initial camera position. Sure, can do.
  12. DocNappers
    The issue is with the GameData/BDArmory/Parts/EJ200/caesar_hone_60_TS.cfg file, which is intended to make the mass of that engine scale more consistently with other engines. Removing the file should fix the issue for now. This should get fixed in the next release.
  13. DocNappers
    Fair enough. We've had complaints before about craft not respecting the G or AoA limits, but that's mostly for instantaneous stuff, which we haven't been able to fix. The G and AoA limiters do affect how the AI adjusts pitch, it's just that that bit of code is really old and poorly documented, so we're not really sure what the logic behind it is and no-one has come up with anything better. That seems odd. Possibly the dynamic pressure at those speeds when using FAR is varying a lot? The G-load and AoA are also available if you enable the on-screen debug telemetry, which would indicate this. Alternating between engaging and avoiding terrain is to be expected if the terrain threat distance is varying a lot and there's something to engage, but the terrain threat distance shouldn't be varying that much.
  14. DocNappers
    That would indicate that you're either not running the latest version, or that some other strange bug is occuring. There's no difference code-wise between the "subsystem damage" toggle and the "structural damage" toggle. Tuning the terrain avoidance settings should avoid this. Based on it being high-speed, I suspect you need to increase the "Control surface deployment time", which is probably better labelled as something like "Time the plane continues in roughly a straight line before actually turning tightly" (it's more of a heuristic than a precisely computable factor). The AI has checks for avoiding doing downwards loops when it's so close to terrain that doing so would trigger terrain avoidance and makes those turns more horizontal than vertical. The turn radius, terrain threat distance and low-alt loop altitude (when relevant) show up in the on-screen debug telemetry in the lower left of the screen. If the target is too steeply below, then extending a little way away from it could be helpful, though extending also has its downsides if you're dogfighting. The turning radius is something that's based on recent measurements of the dynamic pressure and speed, not the G-limiter. Also, the max G and max AoA limiters don't work that well, particularly w.r.t. preventing short-term high Gs or AoA, but improving them has proven to be somewhat difficult. I'll check with SI. He knows more about that sort of thing.
  15. DocNappers
    It's listed as "Structural Damage" in the settings When enabled, the breaking force, breaking torque and G-tolerance are scaled by the fraction of HP remaining for the part.
  16. DocNappers
    That's telling you that it's selected the "Test Plane - AA" as the target (so it's within visual range, has a radar lock or some other way of tracking it), but couldn't find any valid weapons to use against it. For missiles this is often due to failing a DLZ (dynamic launch zone) test due to being too close (there'll be messages about this in the log if this is the case), but can also be due to configuring your missiles wrongly (e.g., disabling being able to engage air targets) or other reasons (e.g., not firing radar missiles when an anti-rad missile is incoming).
  17. DocNappers
    It sounds like your installation of BDArmory is messed up (e.g., folders installed to the wrong place, duplicate folders, etc.). You should reinstall BDArmory. I recommend using CKAN to manage your mods.
  18. DocNappers
    There can be many reasons for it stopping (such as no line-of-sight on the target or a relay for remote firing, or a lack of power and the AI/WM getting disabled, etc.), but without examining the KSP.log file with debugging (AI, weapons, missiles, etc.) enabled, I can't tell you what the problem is. I'd suggest you enable debugging (Graphics/UI Settings -> Enable Debugging -> various toggles), then examine the log yourself. Much of the logged debugging is self-explanatory, though some of it can be very verbose.
  19. DocNappers
    When/if KSP2 becomes reasonable to use, the KSP2 devs release official mod support and the BDA devs have the time and resources to do so.
  20. 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.
  21. DocNappers
    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.
  22. DocNappers
    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.
  23. DocNappers
    yes
  24. 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.
  25. 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).
×
×
  • Create New...