Jump to content

DocNappers

Members
 View Profile  See their activity

  • Posts

    256

  • Joined

  • Last visited

 Content Type 

Everything posted by DocNappers

  1. DocNappers
    You can ask, but I can't guarantee that I'll know the answer. First, however, make sure you're using the latest version of the mod. The missiles detonating a few seconds after switching vessels was due to floating origin shifts and was fixed in v1.5.1.0.
  2. DocNappers
    OK, version 1.24.0 is released. Improvements / Bugfixes: Initialise the "maxRelV" numeric field properly so that the field-width parameter is 6, not the min value. Cache the atmospheric audio sound clips to avoid GC allocations. Include the fix (from BDArmory) for Apple Silicon (M1 chip) not calculating sqrt properly when multiplied by a float. https://issuetracker.unity3d.com/issues/m1-incorrect-calculation-of-values-using-multiplication-with-mathf-dot-sqrt-when-an-unused-variable-is-declared Add an auto-landing option to the stationary camera. Without "Maintain Vel." enabled, the position of the camera is based on the vessel's current position. With "Maintain Vel." enabled, the position of the camera is based on the vessel's predicted terrain intercept if it follows a ballistic trajectory (no drag). The altitude of the camera above the terrain is defined by the "Up" component of the "Manual Flyby Position". An extra horizontal offset is defined by the "Fwd" (in the vessel's velocity direction when activated) and "Right" components.
  3. DocNappers
    So, something like this: That's with the "Maintain Vel." enabled where it's trying to predict where the landing will occur if the craft follows a ballistic trajectory. Without "Maintain Vel." it'll use the craft's current X,Y position. The altitude above the terrain of the camera is the "Up" component of the "Manual Flyby Position" and any extra offset is specified with the "Fwd" (aligned with the vessel's horizontal velocity when activated) and "Right" components. Also, don't mind my poor flying skills...
  4. DocNappers
    I just saw this now since the edit didn't trigger a notification... anyway, what's missing from the patriot missile launcher? (If you can't post a pic, maybe upload the pic somewhere else like imgur and just link to it?)
  5. DocNappers
    That sounds like something that would fit within the stationary camera mode as a "landing shot" toggle. I think it should be relatively easy to implement by clamping the stationary camera's position to Z metres above ground level. I can envision two modes for it: Without "Maintain Vel." enabled, which would work as you describe it where the camera's X,Y position is based on the craft's position + offsets when it's first enabled. With "Maintain Vel." enabled, which would predict where the craft is going to land (it may be a bit tricky to calculate this accurately, but shouldn't be too hard if assumptions are made about constant vertical deceleration and reasonably flat terrain at the landing spot) and use that as the camera's X,Y position + offsets when it's first enabled. This should allow for landers that aren't particularly vertical, though it'd become more imprecise the less vertical the landing is.
  6. DocNappers
    They're just part of the main KSP.log file and show up as lines starting with "[LOG 04:32:44.830] [CameraTools]: ...", but they're fairly sparse unless you set DEBUG = True file in the GameData/CameraTools/PluginData/settings.cfg (which will also display some debugging info on-screen). The warnings about texture resolution and compression aren't a problem. Btw, you do have the "Keypad Control" toggle enabled near the bottom of the CameraTools menu, don't you? (enableKeypad = True in the settings.cfg file.)
  7. DocNappers
    If you can bind the keys, then you should be able to use them to control the camera movement (note that they'll only affect the camera when CameraTools is active). Also, note that the defaults (written as [0], for example) are for the keypad, not the row above the qwerty row (just in case you're trying to use those). Maybe you have some other mod that's interfering with keyboard input? Check for lines starting with "[EXC" or "[ERR" in the KSP.log file (in the main KSP folder) for any issues that might be related to CameraTools (or other mods).
  8. DocNappers
    v1.23.0 of CameraTools is now released, available via SpaceDock or GitHub. Improvements / Bugfixes: Fix some memory leaks detected by KSPCF. Refactor integration with other mods into their own files (mostly). Some BDArmory-related settings may need resetting. Allow deploying to multiple KSP instances when compiling in Linux. Add speed free-move mode for keyboard input (default toggle 2). Toggling this resets the speed to zero. Disabled when in numeric input mode. Update numeric input fields when making changes with keyboard input. Add display field-width parameter to numeric input fields.
  9. DocNappers
    Yes, but I don't have much experience with it. @josuenos would be the one to ask about configuring it if the comments in the ecmj131.cfg aren't sufficient.
  10. DocNappers
    For relative bearing between two latitude/longitude coords, you need to use the Haversine formulation, see http://www.movable-type.co.uk/scripts/latlong.html. From what it sounds like you're doing, you want to use the latitude/longitude components of TargetSignatureData.geoPos and that of the current vessel (from FlightGlobals.currentMainBody.GetLatitudeAndLongitude(FlightGlobals.ActiveVessel.transform.position)) in the formula for the bearing on that site.
  11. DocNappers
    The latest version of BDA+ (v1.5.2.0) is now available from https://github.com/BrettRyland/BDArmory/releases/tag/v1.5.2.0. SpaceDock is currently having some issues, so it'll be uploaded there once those are resolved. Edit: SpaceDock is working again! https://spacedock.info/mod/2487/BDArmory Plus#changelog
  12. DocNappers
    Pretty much, though you'll need to increase the default range of PRE (the max visual range of the WM in BDArmory is 200km) and KSP can sometimes have some issues with vessels entering/leaving the PRE range.
  13. DocNappers
    It should be possible to add something like that. The easiest way I can think of doing so would be to have a toggle between keyboard input affecting position and affecting velocity, with an extra key that smoothly decelerates the velocity to zero.
  14. DocNappers
    The next release (coming soon) has a number of fixes for ballistic weapons in orbit. In the meantime, check these out: and
  15. DocNappers
    Hi. I guess that depends a bit on how SWE/Waterfall does the actual replacement of the plumes. BDArmory's missiles use a pair of models that get added to the missile when they're loaded in flight mode during OnStart (see MissileLauncher.cs#L2443 and where it's called from MissileLauncher.cs#L426) and removed again when the missile gets destroyed. It's done this way to avoid leaking KSPParticleEmitters since KSP is so bad at letting go of part references. E.g., the AIM-9 uses the following in its config: exhaustPrefabPath = BDArmory/Models/exhaust/smallExhaust boostExhaustPrefabPath = BDArmory/Models/exhaust/mediumExhaust If SWE/Waterfall can simply replace those models on the fly (e.g., with simple models containing an appropriate ModuleEngine via a MM patch or similar), then that might be enough to make it work.
  16. DocNappers
    I haven't tried, but I doubt it. Aerial combat can be quite frenetic and I suspect it wouldn't handle craft being torn apart by weapons too well due to network lag. Maybe others would know for sure though. Fair enough. In any case Drag0n and the others are aware of your request, so maybe they'll come up with something.
  17. DocNappers
    @Drag0nD3str0yer (who is helping with updating/improving AP+) was discussing it with some others on the "Project Münway" discord server for a bit last night (I can DM the discord link if you don't already have it - to avoid bots). The consensus was that BDA-Extended (BDA-E) would be the appropriate mod for such a part. I don't think BDA-E has a forum page currently, so the discord is probably the place to ask about it.
  18. DocNappers
    I think it's more the way the ordinance bay attaches to the other part since it only seems to have surface attachment on the underside instead of an attachment node (like the missile attachment nodes on the upper side). One of the other devs who's better at modelling is going to experiment with adding an attachment node to the underside to see if that fixes it without the need for a part in between.
  19. DocNappers
    Weird. The same happens with the hydraulic cylinder. However, if you attach them upside down (i.e., to an attachment node), then it works (but isn't very useful...).
  20. DocNappers
    That sounds more like something for the guys working on AP+ or BDA-Extended (still to be officially released) rather than base BDA+. I'll pass on the request to those guys.
  21. DocNappers
    The ghosting effect is due to some weird interaction with Scatterer. Reportedly, setting scatterer settings to "integrated" fixes that (I don't use Scatterer though, so that's second-hand info).
  22. DocNappers
    This is a known issue with the last couple of releases. It's due to Visual Studio messing with the capitalisation of various "sounds" folders on one of the dev's computers. It'll be fixed in the next release.
  23. DocNappers
    Lasers do have some randomness added to their shots (maxDeviation = 0.0125 in the config), but that's about 1/10 of that of the hidden vulcan, so they're more accurate out to longer ranges. And yes, missiles have very little HP, which may be more to do with the problem than lasers being super accurate, but I think that's so that point defence turrets only need to get a single hit on them to destroy them. @josuenosand @SuicidalInsanity know more about missiles and weapon systems than I do, so maybe they can chime in with their opinions?
  24. DocNappers
    Not really. Lasers are super accurate (due to their beam traveling at the speed of light and not having to account for the target's motion while the beam is traveling as opposed to standard projectiles). However, they also overheat more easily and drain a significant amount of electric charge. If you don't want them in your tournaments, simply don't let your participants use them or modify them with a MM patch.
  25. DocNappers
    Apparently, the FXLookAtConstraint modules weren't implemented properly on that turret and some others. This is now fixed in dev and will be in the next update.
×
×
  • Create New...