Jump to content

DocNappers

Members
 View Profile  See their activity

  • Posts

    256

  • Joined

  • Last visited

 Content Type 

Everything posted by DocNappers

  1. DocNappers
    There was an issue with attaching exhaust prefabs in v1.6.10.0, which should be fixed in v1.6.10.1 (in case that was the problem), though it seems there's still some issues there that we're looking at. I'm not sure about the muzzle flash effects, but examining the KSP.log file would be the first step. BDA+ usually gives errors or warnings if there's something missing. I don't think that's possible, no. There was some talk at one point about making custom turrets, but I don't think it ever got beyond just talking about it due to how complicated it very quickly becomes trying to handle the weird designs people invariably make. Check the KSP.log file or in-game messages for errors or exceptions. Enabling "Debug Spawning" in BDA's debug settings will add more details to the log, which may help. If it's completely failing to spawn, then there's most likely an issue with the craft file (missing parts or the file is otherwise corrupted). I'm not sure what could cause a spawned craft to end up sticking into the ground, but likely the log would give some indication as to why.
  2. DocNappers
    Josue (one of the BDA+ devs), has just released an extended version of NKDR that's compatible with BDA+ thanks to KingNoob1337's efforts: https://spacedock.info/mod/3551/North Kerbin Dynamics Renewed-Extended (NKDR-E)
  3. DocNappers
    v1.32.0 of CameraTools is now released. It has the following improvements / bugfixes: Improvements to death camera angles and transitions for dogfight mode. Add a button to switch from pathing mode to stationary mode while maintaining the current view. Adjust location of random mode options. Add a button for resetting the camera roll (in stationary and pathing modes). Optimisations to use vessel.CoM instead of vessel.transform.position where applicable. Apply maxRelV to the stationary camera when using random mode. Remove the low-altitude stationary mode override for random mode. Prevent the camera from going below terrain and water (when vessel is only partially submerged) in dogfight mode. Separate the auto-zoom toggle between dogfight and stationary modes. Adjust default settings for a dynamic dogfight mode. Add a slider for setting the minimum interval to check for a new secondary dogfight target if the secondary target is a missile. Don't restart the dogfight camera when switching secondary targets for smoother transitions. Krakensbane optimisations (from BDArmory). Finish adding English (en-us) localisation and tooltips.
  4. DocNappers
    I don't think any jitter is intentional. It's likely an interaction between the mouse movement (when adjusting the camera) on rendered frames and the plane's movement on physics frames. I can add it to the list of things to look into. I don't see that much jitter when using the camera, even at 4x zoom from 10km altitude. One thing that can help is to enable "Lock Target" when the camera is close to the right position to stabilise it and then continue to adjust the camera to fine-tune the point before sending the GPS coords.
  5. DocNappers
    They're working fine. The problem is with your install. Check the KSP.log for details of why it's not working. It should be Launch mass - BoosterMass - BoostFuelMass, i.e., BoosterMass is the dry mass of the boosters if they decouple, however, it doesn't seem to be working correctly at the moment and the mass isn't reducing by BoosterMass when it decouples. I'll fix that for the next release and add a mass readout to the debug telemetry. For now, if you have KER installed, you can switch to the missile and monitor the missile's mass during flight. This is almost always due to badly installed mods or missing dependencies. You need to examine the KSP.log file to determine exactly what is installed incorrectly/missing. You'd be better off asking @SuicidalInsanity about that. He has a much better understanding of the radar locking and target acquisition side of things. However, gun turrets will continue to estimate the position of targets that have been detected in the last 30s (for air targets, can be longer for ground targets) based on their last known position, so that might be what you're seeing.
  6. DocNappers
    v1.31.0 of CameraTools is now released. It has the following improvements / bugfixes: Fix NREs from atmospheric audiosources when not in atmosphere. Don't reset the original camera parent's position when reverting (fixes weird camera angle). Override the camera restore distance with custom distance (from BDA) when reverting due to auto-enabling for BDA. Add support for a new BDA helper property for inhibiting camera tools. Add support for new BDA helpers for tracking missiles' targets in dogfight mode. Minor tweaks to MouseAimFlight helpers. Some internal restructuring of utils. Begin adding localisation support (not yet complete). Begin adding tooltips (not yet complete). More localisation/tooltips and the feature mentioned in the previous post should be coming in the next update.
  7. DocNappers
    That sounds like a good part request for BDArmory-Extended.
  8. DocNappers
    Switching from the pathing camera to the stationary camera without any of the flyby or target options selected ought to start the stationary camera in the same position and orientation that it's currently in, but it looks to be shifting the camera down a bit for some reason. I'll look into why it's doing that and add an explicit option to transfer the current view from the pathing camera to the stationary camera. In the meantime, moving the camera up ([7] on the keypad by default) should allow you to bring it close to the position it was in when you switched.
  9. DocNappers
    Yes, but if you later remove it, then trying to load any craft you've made while it was installed will warn about missing modules (which isn't actually a problem) or missing parts (which makes those craft unloadable).
  10. DocNappers
    BDA+ can fire missiles via holding the main fire button (WEAP_FIRE_KEY, which is the left mouse button by default) if the trigger is armed (firing guns doesn't require arming the trigger), or you can assign a separate button to firing missiles (WEAP_FIRE_MISSILE_KEY) to arm and fire them with a single click. You can also assign a key to toggling the trigger armed state (WEAP_TOGGLE_ARMED_KEY). There is a toggle in the pilot AI to disable extending for A2A. It should be being stored in the craft file (canExtend = False) when you save your craft in the SPH/VAB, not getting reset. No. That's a major undertaking that I don't have time for. I haven't really looked into how BDAc handles the multiplayer support, but there'd be a lot of data that'd need to be synced between clients for proper multiplayer support.
  11. DocNappers
    No, I'm fairly sure that it doesn't.
  12. DocNappers
    v1.30.1 of CameraTools is now available, which fixes a bug in the pathing camera if timestamps are set to the same value by shifting one of them by 0.001s (fixes PR8).
  13. DocNappers
    v1.30.0 of CameraTools is now available. It has the following fixes/improvements: Fix stock aero FX not being applied and provide a toggle to disable them. Adjustments to fix some issues when BDArmory should be inhibiting CameraTools and more detailed debugging messages. Add check for new BDA OrbitalAI.
  14. DocNappers
    v1.29.2 of CameraTools is now available. It fixes a memory leak introduced in v1.29.0 where an AudioSource wasn't getting destroyed correctly.
  15. DocNappers
    How far they see. You can see the checks for adding a radar contact here https://github.com/BrettRyland/BDArmory/blob/master/BDArmory/Radar/VesselRadarData.cs#L1690. The -20m comes from a check for being considered "underwater" since some boats sit with their "altitude" some distance below the waterline. I'm not sure if there are any checks to disable a normal radar that is below water, so it could be that a sub with a standard surface-to-air radar might be able to detect planes (which should probably be fixed if it's the case).
  16. DocNappers
    You can enable Debug AI and check the KSP.log for messages about why it started/stopped extending. Look for messages starting with "[BDArmory.BDModulePilotAI]:". If the plane is stuck in extending for a long time, there's also a Debug Extending button below the other debugging options if Debug AI is enabled that will log the current reason and details for why it's extending. Often, if a jet fighter is extending for a long distance, it's due to the DLZ range of misssiles that are not very manoueverable being very high (since they need the extra range to turn around). Maybe with two boresight radars facing sideways each with FoV set to 120°? Sonar only works when it's in water (or whatever liquid) and can only detect other vessels that are likewise in water. Air-to-ground radars can't detect splashed targets below -20m.
  17. DocNappers
    This should now be fixed in the latest release (v1.6.7.0).
  18. DocNappers
    That kind of error is usually due to a broken install. If reinstalling BDArmoryPlus doesn't fix it, then there's probably some other mod (e.g., BDAc) or extra DLL that's interfering with it, which you should be able to see in the first part of the KSP.log where it loads in the DLLs.
  19. DocNappers
    Countermeasures don't flow like fuel/ammo and, as such, don't use refill boxes (which come from some other mod) (see https://github.com/BrettRyland/BDArmory/issues/482). Instead, put multiple CM launchers on your craft with different priorities. The AI will use the highest priority CMs (of the appropriate type) first before proceeding to those of lower priority.
  20. DocNappers
    The Stingray torpedo in BDA and the Swordfish and Tigershark torpedoes in BDA-E should be working. There's been a bit of work in dev lately for the recent boats round in Scott Manley's discord server, so there's probably functionality that has been improved since the latest release.
  21. DocNappers
    Wouldn't such a timer be measured in days or longer? I'm pretty sure submarines can be self-contained for fairly long periods. SI has done most of the work on adding submarine behaviour to the surface AI, so he would know best. However, looking at the code, I think "Combat Altitude" is essentially what you're describing as the cruise depth, which looks to be basically equivalent to the "Default Altitude" in the pilot AI. That is, if it's not doing anything else then it should aim for that altitutude/depth. If it's engaging a target then it'll try to surface (or be near the surface) to fire weapons/missiles at flying/surface targets or match depths with other subs/boats. The code is still fairly beta though, so some values are hard-coded and some logic isn't finished.
  22. DocNappers
    It just adds logic to the surface AI for more appropriate underwater behaviour (what it can engage, what depth it should aim for to engage, etc.). Looking briefly at the moist mod, I think linking the ballast control to the pitch axis group and then adjusting MaxSlopeAngle to compensate might be enough.
  23. DocNappers
    I don't think there are any parts with this configured as such, but we used it in the last runway project round (S5R10) where the BDModuleNuke module was added to the root part of every vessel at competition start (it was in space, so the thermal effects weren't anywhere near as bad as they are in atmosphere). It set the following, but otherwise used the defaults for the module. nuke = (BDModuleNuke)pilot.vessel.rootPart.AddModule("BDModuleNuke"); nuke.engineCore = true; nuke.meltDownDuration = 15; nuke.thermalRadius = 200; Default values are thermalRadius = 750, yield = 0.05, fluence = 0.05, isEMP = False, engineCore = False, meltDownDuration = 2.5, plus the paths that you can see in the AIR-2 Genie part.cfg. If engineCore is True, then it will detonate after the melt-down period during competitions under various conditions. Looking at those conditions in the code, if it's on the root part, then it'll detonate during competitions if the craft has no functioning engines (due to flameout or whatever); if it's on an engine then it'll detonate during competitions if that engine gets detached, turned off or not at 100% thrust despite not having taken damage (so battle damage doesn't trigger it); otherwise, if it's not on the root part and not on an engine, then it should only detonate when it gets destroyed. So, you should be able to just add the BDModuleNuke module to whichever non-engine, non-root part you want with engineCore = True and it should detonate when it gets destroyed. The duration of the explosion FX for the nuke scales with the sqrt of the thermal radius, but I think the actual speed of FX is baked into the asset. @SuicidalInsanity could probably tell you, since he was the one that made it. With turrets and missiles, sure. There are settings for that in the weapon manager: "Max Turret Tgts", "Max Missile Tgts" and "Missiles/Target".
  24. DocNappers
    Nuclear warheads don't detonate unless they're primed to do so, which for missiles, happens when they're fired. The only other use of the BDModuleNuke module currently implemented is as a nuclear core of an engine (engineCore = True in the config), in which case they should detonate when the part gets destroyed or 0.5s after getting detached from the part of the craft with the WM. However, during competitions if the part is actually an engine and it runs out of resources or is thurst limited (this was originally for a Runway Project round) then it will also detonate. It isn't intended to be used in other ways, so YMMV. For firing a ballistic missile/artillery over such long ranges without using some sort of terminal guidance (GPS or otherwise using the new lofting logic), I think having line of sight in order to aim would be the main issue. Also, beyond 200km, floating point errors are going to be a significant problem, even with PRE enabled for such long ranges. I'm fairly sure that BDArmory never had contracts as part of the mod. Those were provided by other mods. If you're referring to the issues with the hydraulic cylinders in the chaingun, hydra turret and patriot launcher models that got fixed in v1.5.0.0, then I believe that those were issues with the models themselves (IIRC). So, that'd be something that the KSP devs would have to fix in their model (or some modder could probably make a nice replacement part).
  25. DocNappers
    OK, v1.29.0 of CameraTools is now available with the following improvements/fixes: Add a configurable movement threshold to activating free-look mode (default: 0.1). If the camera parent gets stolen, automatically steal it back if it's the original camera parent (due to spawning a kerbal, BDA MML, etc.). Allow customising the maximum value of the zoom, auto zoom, dogfight distance and dogfight offsets in the settings.cfg. Optimisations to how part audio effects are managed. Rework the sonic boom calculations, allowing them to reset and removing the booming when switching vessels/restarting camera modes. Edit: ... and an immediate bugfix release (v1.29.1) due to the wind-tear audio being too loud.
×
×
  • Create New...