Jump to content

TheDog

Members
 View Profile  See their activity

  • Posts

    165

  • Joined

 Content Type 

Everything posted by TheDog

  1. TheDog
    200m/s is too slow? Are you sure the plane is aerodynamically sane? Anyway, if you can wait for the next release (not soon though) we can increase the slider range...
  2. TheDog
    Almost fully correct, I have updated Wikia. Fire interval = scan interval for target selection. Every n seconds the situation is re-evaluated and a target picked. Burst length: if a gun is selected, how long does it fire on the Target. FireInterval - BurstLength = cool down time (no firing). If zero, old logic of half/half applies. And answering your #1: guard mode only knows to attack vessels as targets, it will never just fire on a GPS coordinate. Having one craft designate the GPS Target and another firing on it technically works, but guard mode is not aware it can do that (basically guard mode is a selfish "every man on his own" implementation...)
  3. TheDog
    Wow, that wiki has greatly evolved despite being flagged as defunct - someone put lots of work into describing targeting, radars and missiles. I added a small sentence about guard mode not utilizing multi-lock atm.
  4. TheDog
    Where is that mentioned in which wiki (I may have to correct it then)? Short answer: in theory yes, in practice no. Longer answer: yes, the AI will re-evaluate and switch targets every "scan interval seconds", as set with the guard mode slider. So it could fire, and then some seconds later switches to a different one. In practice though the re-evaluation will most likely result in the same target still being considered the highest priority one, so it will continue targeting it (even though a missile my already be underway). We will definitely improve guard mode behaviour in future versions, also to make it take advantage of multi-lock radar capabilities...
  5. TheDog
    You mean because of the editor category? Thats indeed already noted. Or is there anything else that doesnt work (so far we have seen nothing, but if you noted sth just let us know!)?
  6. TheDog
    Why don't u use the current version? Are u still on KSP 1.2? Anyway, a LOT has been developed in bda in the meantime, so honestly I have no clue whether the detonation thing worked properly in 0.2.1 or not...
  7. TheDog
    Which version do you have installed? Our latest version does not have a bahaturret.dll, the dlls have different names...
  8. TheDog
    mmh, that sounds logical. Too bad - I thought you had a magic easy trick to get rid of stock allocated garbage
  9. TheDog
    Just curious, and maybe you know why / did it on purpose: I was doing some debugging (developer mode, Unity profiler) and noticed that with pure stock there are constant memory allocations by FlighIntegrator.FixedUpdate (GC allocations in the unity profiler). Using ModularFlightIntegrator, I only see calls to TimedFI.FixedUpdate, and.... zero allocations/garbage. I mean, this is great, but I have no explanation, as from my understanding MFI calls into the stock FlightIntegrator (unless somehting like FAR registers its own overrides), is it? So, how did you manage to be better than stock regarding garbage generation - or I am misinterpreting my profiling output?
  10. TheDog
    Without any guarantee: this *may* perhaps be possible with Interstellar Fuel Switch. At least I think at one point @FreeThinker considered adding functionality to use IFS to switch an arbitrary module of a part. If it is possible to specify that you want IFS to switch the field "bulletType" of module "ModuleWeapon", then it can be done. You may want to consult the IFS thread and/or source code for details.
  11. TheDog
    It is not really one of our plans atm, afaik. If you have suggestions for that (technodes, part costs), or even better pull requests with config changes, or mm patches, we will happily consider integrating them.
  12. TheDog
    That's how it works, yes. The missile has an active radar for terminal guidance. It will search it's Target itself, no need to lock sth by the launching vessel. You can enable "debug labels" in the bda settings, then there is a ton of additional debug output written to the log, which might show if the missile could actually lock onto sth or not. Most efficient to defeat the terminal guidance would be to move away tangentially at 25+ m/s. Then it is unlikely the missiles radar seeker will see you. So if you have very fast craft it is no surprise the terminal guidance is not effective.
  13. TheDog
    *sigh* Without the use of physics range extender your radar range (and a lot more) is limited to like 300 metres...
  14. TheDog
    It is a bug that this field is shown, it has not effect (at the moment, at least...). All radars at the moment technically have the same range, which is limited to 40km. Not all radars have the same detection capabilities, though. Smaller craft might evade detection, and look-down from air to ground leads to ground clutter, which can also hinder detection.
  15. TheDog
    Afaik we already have a feature request for that, and I can assure you it is also high on my wish list. It might not come next version, but I want to tackle this in the near future, as I also love to see my aegis destroyers utilize their full potentials...
  16. TheDog
    Seems logical, there was never a check in guard mode whether a missile is facing towards a target. Assumption is, if it can be locked then a guided weapon can be fired to reach it. If we implement such a check it would prevent ships on guard mode utilizing missiles loaded in a VLS, and that would be a pitty. Tying such a "facing towards target" check to the condition of "isFlying" might make sense though...
  17. TheDog
    For helicopters try TCA (throttle controlled avionics) - it has functions like auto-hover etc. Works great for my choppers, though you need to build something that is not completely unstable in the first place, ofc.
  18. TheDog
    Bda requires the use of PhysicsRangeExtender, see links in OP or on all download pages.
  19. TheDog
    Probably would work if you give the part 2 radar partmodules, one with an inverted transform...
  20. TheDog
    By "not work" do you mean the rwr window is invisible? This can happen after fresh installs, cause being: In the settings.cfg there is a line for rwrwindowposition which specifies height and width = 0.0. Manually changing that to 300x300 pixels makes the window appear again.
  21. TheDog
    Please enable "debug labels" in the bda settings, and post a relevant log of the situation. Without a log my guesses would be: visual range too low (guard mode cannot see any target), or the guns are not set to engage air targets (right-click gun -> engagement settings).
  22. TheDog
    It is on our list of things we'd like to do, but since it involves quite some redesign of the guard-mode code, it won't come.e very soon. It comes down to this (long text ahead):
  23. TheDog
    You are using an old version, please download the current release from GitHub (v.0.2.1.1). Only that can work with KSP 1.3.
  24. TheDog
    No, that is not correct. The folder must be "bdarmory" only, not '-master'. What did you download, looks like you grabbed the source code zip ? Please re-download the latest release zip from GitHub. The range shown in the editor (in the part details) is currently meaningless. All radars currently have the same range - we might change that in the future, then you'll see values other than zero. Regardless all radars should be working in-game, if not please submit a scenario sfs and logs in a git issue, as requested by JR.
  25. TheDog
    Also, pls turn on "debug labels" in the bda options. It will increase the verboseness of the debug output.
×
×
  • Create New...