Jump to content

DocNappers

Members
 View Profile  See their activity

  • Posts

    256

  • Joined

  • Last visited

 Content Type 

Everything posted by DocNappers

  1. DocNappers
    Huh, didn't even notice KSP had a launcher since I usually start it from the commandline. Pity they didn't fix any bugs relevant to me, such as this one. BDArmoryPlus and CameraTools don't seem to be affected by the changes.
  2. DocNappers
    If I can figure out what the cause of the audio bug is, then I'll gladly fix it, but I'm not even sure if it's related to CameraTools or only indirectly triggered by something that CameraTools does.
  3. DocNappers
    Yep, no worries. It's something that I was considering as a potential option for BDA+ due to the requests I received, but it's not high priority. Give me a ping if/when you have something ready to test and I'll see if I can get it to work. Thanks!
  4. DocNappers
    That's a shame since I run KSP natively on linux instead of via dxvk, which would make testing it difficult. If it can be made to work, then I'd make it an optional toggle in BDA+ anyway, so if it's not supported, then it can be disabled without any drawback. I think that should work, but I'd have to experiment a bit with the delegates to check that it works as expected.
  5. DocNappers
    Lol, fair enough! I was thinking that doing these would be much more computationally expensive. Yeah, they could be done that way. At the moment, the target selection logic only happens a couple of times per second anyway, so they could be done a few physics frames in advance without any issue. If I do get around to implementing this sort of thing in BDA+, then to avoid making EVE redux a hard dependency, I was thinking it could be done via reflection using delegates (in the same way that CameraTools does with BDA+ (ReflectionUtils.cs), which works fairly well), however that would require EVE redux to provide some functions for doing so. Since it'd be asynchronous, I think there'd need to be one for initiating the check and another to check if the results are ready and fetch them since I'm not sure if it's possible to use a coroutine that way.
  6. DocNappers
    @blackrack, the volumetric clouds are very impressive, well done! I've received some questions about the possibility of incorporating the reduction in visibility that the clouds cause to the line-of-sight checks (visual only, not radar or other instruments) in BDArmoryPlus. Do you know how computationally expensive it'd be to calculate a visibility reduction factor due to the clouds between two points? Is this something that could be calculated between, say, 8 planes (so 28 visibility-reduction calculations per physics frame) without a noticeable drop in framerate?
  7. DocNappers
    Isn't that basically just an air-to-surface missile at that point? Anyway, I think SI would be the one to talk to about that sort of thing.
  8. DocNappers
    No, I mean that the last commit on the KKS github repo was on 5 Aug 2020 and I know that KSP 1.11 introduced some changes that broke some stuff (BDA+ has special handling for these breakages to remain compatible with KSP 1.9.0). If it still works without throwing exceptions on the latest KSP, then that's fine, but the lack of active development means that any existing bugs aren't likely to get fixed. And as I said earlier, the amount of work required to integrate the two is quite significant (if at all possible), so since (as you pointed out) KSP2 isn't that far away, I don't see this as something I'll be looking into. BDA+ depends on PRE and ModuleManager, which are reasonable dependencies, but adding a dependency like KKS simply for this behaviour is unwarranted and would likely annoy most users of BDA+. I've had contact with SpannerMonkey and various others from that group, however, BDA+ is a framework for how part-types behave, not a part-pack mod. For that there exists mods like AirplanePlus, Moderately Plane Related, the as-yet unreleased BDArmory-Extended and numerous others.
  9. DocNappers
    I don't think so as the IRST doesn't have locking capabilities, but one of the other devs may know more. Please don't ping people unnecessarily as it'll just annoy them. We already get notifications on threads that we follow and reply to them when we have time and if we know the answer. Also, a lot of the time other users can answer many types of questions, particularly about reconfiguring parts (as Sidestrafe2462 did above), without putting the onus on the devs. I don't really know what you're asking for here and Sidestrafe2462 already gave you something of an answer. I assume this is a question of if it's possible. I see KKS hasn't updated since KSP 1.10.0 in Aug 2020, so I don't know what state it's in, but assuming it still works, combining BDA+'s health system and KKS's damage system would be non-trivial. The main difficulties I see with it off the top of my head are: Avoiding making it a dependency, which would require either: using reflection to communicate between the mods, which is fragile and likely to break if anything changes, or expanding on BDA+'s damage events with the required information to allow a third party mod to do the translation between BDA+ and KKS, which is also non-trivial as the kinetic impact information that KKS requires isn't contained in the current damage events. BDA+ has a variety of types of damage that affect the health of parts that don't translate properly into Krash events (e.g., explosive force applied to an entire side of a part instead of being a point impact). BDA+ already has battle damage that degrades the performance of parts. Having KKS also affect them would likely either make them break twice as fast or fluctuate between degraded conditions depending on how such conditions are applied. Performance. I'm not sure what effect KKS has on performance, but presumably the KKS's deformations to the colliders make many meshes non-convex, which are computationally more expensive. So, while the idea seems pretty cool, I think it'd be rather difficult to get it to work. Similarly, the amount of work required to get the line-of-sight checks for EVE clouds and the integration-without-making-EVE-a-dependency-of-BDA+ is really quite high and so unlikely to happen.
  10. DocNappers
    Looks like SuicidalInsanity has found and fixed the bug already, so it'll be in the next release.
  11. DocNappers
    Hi @Ilya_G! 1. Localization is most definitely welcome. I'm not sure what languages the other devs know that are supported by KSP, but the main language seems to be English (mostly US, but also some NZ in places). The German localization is pretty much up-to-date thanks to a guy in the RWP (Scott Manley's) discord server, but the other languages are either nonexistent or woefully out-of-date. 2. I'm not sure that'd be feasible/possible since, to my knowledge, the clouds provided by various mods don't use colliders (otherwise planes would crash into them), which would be needed in order to block the line-of-sight checks (which use raycasts and layer masks). In order to provide some level of being visually obscured by clouds in BDA+ without using colliders would require the mod providing the clouds (e.g., EVE) to be able to calculate the visibility information along the line between two locations (i.e., between planes) and provide this in a function or variables that BDA could access through reflection (delegates can be used to avoid the overhead that reflection usually has).
  12. DocNappers
    OK, yeah, I see the radar through the data link not showing the correct range. It looks like the range capability of the RADAR TRUCK isn't being passed to the CIWS TEST via the data link and the target is beyond the 1km range that's being shown. I'm not too familiar with that section of the code, so I'll try to get one of the other devs to look at it. The debugging info is showing the RADAR TRUCK targeting the SU 9 ARMED, but not having any valid weapons to attack it and the CIWS TEST is alternating between firing on the SU 9 and not firing due to the weapon not being available due to overheating or not being within the gimbal limits. Also, it got some hits. Yeah, debugging, especially damage debugging, can spam the logs a lot.
  13. DocNappers
    I think that's hard-coded to those 3 at the moment.
  14. DocNappers
    Use the little - and + to adjust the display range (the max depends on the radar). Note that the "Logarithmic RWR Display" option in the radar settings affects the radar window as well as the RWR window. Also, if the target is stealthy enough, beyond a certain range the radar won't detect them. That would require a lot more debugging to figure out why it's doing that (enable Debug->AI, Debug->Weapons and Debug->Missiles, then check the KSP.log file for lines with [BDArmory...]). It could be that the enemy aircraft is stealthy enough to be only barely detectable by the radar.
  15. DocNappers
    Check that the guns have line-of-sight (F2 in the SPH, guns won't fire if they'll hit the firing craft) and you have the right ammo or "Infinite Ammo" is enabled.
  16. DocNappers
    You're most likely using a FireSpitter engine. BDA+ can activate the engine, but FS has a check for the vessel being the active vessel in order to control it. Also, the VTOL/Heli AI is very limited compared to the pilot AI since it's based on the surface AI and hasn't really had too much work done on it.
  17. DocNappers
    It's not particularly high-spec other than the RAM since it's several years old now, but it has an i7-7700K, a 1080Ti and 64GB of DDR4 RAM with dynamically allocated swap. It's my work machine for neural network development.
  18. DocNappers
    A bit off-topic, but I was doing some neural network stuff on excessively large geotiff images the other day and it was using over 57GB of RAM and 89GB of swap... $ smem -k -t | (head -n1; tail -n3) PID User Command Swap USS PSS RSS 3116616 ***** /home/*****/repos/arctic-ic 89.1G 57.2G 57.2G 57.2G ------------------------------------------------------------------------------- 225 2 109.1G 59.6G 59.7G 62.0G
  19. DocNappers
    16GB should give you several hours of running tournaments before you run out of memory unless you're using an excessive amount of other mods or some other mod that's leaking memory. You may want to consider enabling the "Auto-Resume Tournaments" and "Auto-Quit Memory Threshold" options in the "Gameplay" section of the BDA+ settings so that KSP exits gracefully when it's using too much memory during tournaments and automatically resumes them the next time KSP starts. Also, having a swap file might help so that the OS doesn't just randomly kill processes when your RAM is full. KSPCF isn't able to fix the memory leaks (that I'm aware of), but it can detect some of them. Look for lines with [KSPCF:MemoryLeaks] in the KSP.log file.
  20. DocNappers
    The memory leakage is due to the base KSP game holding onto references to vessels and parts that no longer exist (the datastructures in managed memory still exist, but many of the underlying datastructures in non-managed memory have been freed) and isn't something that mods can fix (with the possible exception of KSPCF which uses Harmony to directly modify the base game, but they'd need to know a lot about the inner workings of the base game to be able to do that). All known memory leaks in BDA+ itself have been fixed (also in CameraTools). The rate that KSP leaks memory due to repeatedly spawning vessels (e.g., in a tournament with 6—8 100-part vessels being spawned every few minutes) is generally under 100MB per heat, so if you have around 32GB RAM, then it should run for 8+ hours without issues. If you only have 8GB RAM, then that could be a problem, but should only require restarting KSP, not the entire computer.
  21. DocNappers
    Breaking Ground DLC doesn't affect BDArmory. If the tab is broken, then there will be errors or exceptions in the KSP.log file (see the messages above), most likely due to duplicate or badly installed mods.
  22. DocNappers
    Usually sudden unexpected framerate drops (i.e., not when a bunch of stuff is exploding, in which case the fps drop is expected) are due to a bunch of exceptions being thrown. Look in the KSP.log file for entries starting with [EXC <timestamp>], e.g., [EXC 20:20:21.331] NullReferenceException: This is an example of an null reference exception. BDArmory.UI.BDArmorySetup.WindowSettings (System.Int32 windowID) (at /storage/github/BDArmory/BDArmory/UI/BDArmorySetup.cs:2497) UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI+WindowFunction func, System.Int32 id, System.Int32 instanceID, UnityEngine.GUISkin _skin, System.Int32 forceRect, System.Single width, System.Single height, UnityEngine.GUIStyle style) (at <e617217aa15744b7b9ef96dc4ee58c67>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) The stacktrace (the indented lines here) will tell you which function in which mod is the cause of the exceptions. (Mine has line numbers because I'm running a debug build of BDA+, the release version won't give line numbers.)
  23. DocNappers
    The easiest method for installing and maintaining mods is to use CKAN If you're installing mods manually, then each mod (other than ModuleManager) should be in its own folder below the KSP/GameData folder, e.g., KSP/GameData/BDArmory on Linux/Mac or KSP\GameData\BDArmory on Windows. ModuleManager goes directly in the KSP/GameData folder. Also, it's important that you only have one copy of each mod installed, otherwise there will be conflicts between the DLLs and KSP will either crash or give lots of exceptions. Note that some mods (mostly mod-packs) are packaged with other mods' DLLs which can cause issues. For debugging broken installs, look in the file KSP/KSP.log that KSP produces every time it is run. In particular, look in the "Mod DLLs found:" section for duplicate DLLs and any lines starting with [EXC <timestamp>].
  24. DocNappers
    ... and now imgur is having issues loading . I'll check again later. Edit: OK, imgur is working again... So, again, what's actually missing? Also, you appear to be using an older version of BDA+. The hydraulics on the Chaingun, Hydra Turret and Patriot Launcher models were fixed in v1.5.0.0.
  25. DocNappers
    No, Destruction Effects is a different mod. However, BDA+ has a number of similar FX for fires, smoke and fuel leaks that are enabled when Battle Damage is enabled (BDA Settings → Game Modes → Battle Damage enables the Battle Damage section of the settings where it can be customised).
×
×
  • Create New...