BahamutoD

Check the logs for errors. If it's running the same method but with a different outcome, it's likely an error pops up in the middle which stops it from reading the rest of the code in the method. There aren't any missile changes between 0.9.5 and 0.9.6. I did receive a PM from someone about one of your missiles though. I'll just forward it to you.

Update v0.9.6 = New = - TGP can be slaved to the selected GPS target - TGP can be slaved to radar locked target - TGP NV mode illuminates vessels = Changes = - Changed heat-seeker growl to slide pitch from searching to locked sound instead of two separate clips - IVA gun audio low-pass filter frequency is now configurable in settings.cfg - Removed redundant filter effects on lower depth TGP camera - Tracer size updates in OnWillRenderObject instead of looping through all pooled bullets for each camera - Stopped guard debug log entries unless DRAW_DEBUG_LABELS is enabled - Updated laser damage (Yski) - Guard will use long-range turrets for distant targets if no missiles available (Yski) = Fixes = - Fixed missing references in AIPilot causing loss of control when loading AI on standby - Fixed incorrect calculation with CheckMiss() that caused weapons to detonate prematurely - Fixed CheckMiss to only check no-target during post-thrust as a miss on AAM and not AGM or others - Fixed miss not being counted in certain situations - Fixed guard attempting to use an inactive TGP - Fixed anti-radiation missile behavior when fired without lock, or lost lock - Fixed TGP turret-slaving not working on non-active vessel - Fixed turret slaving breaking when both TGP and Radar are enabled - Fixed clicking on gui triggering a cannon reload - Fixed turret jitter when slaved - Fixed ABL reticle when slaved - Fixed ABL's rendered line and physical hit point when slaved - Max guard visual range value is read from config file (Yski) - Removed 8km limit for PooledBullet (Yski) - Max bullet range is read from config file (Yski)

Because it physically doesn't work in space. Since it's a long lasting effect (not like an instantaneous explosion), it has to be stationary in a certain frame of reference, but there aren't any frames of reference that make sense. If you're in orbit and its stationary to the planet, it will fly by you at orbital velocity. If you use the velocity of the target as the frame of reference, then if the target is flying towards you, the explosion will fly towards you. If you use the bomb as the frame of reference, then if you drop the bomb on a planet, the explosion will continue to move below the surface. Etc. Plus, it was entirely unrelated to everything else I've been working on.

Make sure to attach your log file as well.

Thanks - reproduced it. Will fix. I wasn't able to reproduce this. Everything should be working with radar or TGP: Are there any related log entries?

All turrets should work. Do they not?

Steer factor is the amount it steers depending on the magnitude of the error. So say a desired destination A is 10 degrees above the plane, and B is 30 degrees up. With a low steer factor, it might do a 50% pull to steer to A, and a 100% pull to reach B (then decrees to 50% by the time B is only 10 degrees up). With a high steer factor, it might do a 100% pull already to get to A. Pulling hard when its not that far off might mean overshooting because you're building up angular momentum. That's where damping comes in, as it applies steering to counteract angular momentum. So you want to tweak and balance both steer factor and damping until you get the results you want. It's kind of like a spring and damper system, where steer factor is the spring constant. The "pointing to" thing I mentioned was about pointing the camera around. AI escorts is something I have planned for later when I get to working on AI.

Nevermind. Despite spending most of yesterday trying to find a workaround, I figured one out in the last few mins. Sometimes typing out your issue makes it solve itself.

So I've been working on some of the TGP features: Unfortunately, the thing that makes vessels bright on NV mode also makes buildings bright. It makes targets really stand out against terrain though. Also notice the buttons for following a radar locked target, and to point to the selected GPS coords.

I'm still working on a few other things I said I'd do, but as soon as those are done and no major bugs pop up, I'll get on it. PM me with pics of your unity setup, and in-game, and output log, and config. I have a hunch that something would go wrong if the barrels are too far apart, and need to be able to handle that. The 'firing safety' (which also checks that the barrel is pointing in the direction you want it to) and turret aiming functions only reference one fireTransform, but perhaps it should calculate based on the average position and direction of all transforms. And nice work - link added. I take it everything is working out? It wouldn't work very well in it's current state. The way it works is it just attempt's to point it's velocity vector into a (constantly calculated) direction that would cause impact at it's current speed by pointing itself towards the direction it wants to turn. This would cause it to flip out in high upper atmosphere/space because if it attempts to turn, it would torque in that direction, but there's no aerodynamic stability and the v-vector wouldn't change despite the AoA so it would keep trying to turn. It also has no solution if it's physically impossible to reach a target at it's current speed, so it doesn't know what to do during launch or how to perform a g-turn. It also doesn't take the curvature of the planet into account. It might work in a terminal phase guidance situation though, if you fly the thing manually first. AGM mode would be fine for this too though. All of the missiles should still be surface attachable, so anything that worked before should work now. But I've always disallowed attaching things to the missile because they're not meant to fly with things hanging off of them. If it isn't taking off, engaging an enemy, or dodging a missile, it limits its inputs to 50%. If you're in combat and the autopilot is still not pulling 100%, it could be over-damped, so you could turn down the steer damper. 15 steer factor and 4-5 steer damper has always been okay for me though.

And the JDAM Forgot to close that - I 'merged' it manually way back when.

First guess is you're getting tons of exceptions in the log due to a missing animation. The howitzer has an animation defined, but the huddenVulcan model doesn't have an animation anymore. Try setting "hasFireAnimation = false". (It may have used to have an animation that was just empty, which is why it would work before 0.9) The formula for bullet damage is float heatDamage = (mass/hitPart.crashTolerance) * currentVelocity.magnitude * 50 * BDArmorySettings.DMG_MULTIPLIER; So crash tolerance is a factor. Explosion damage does heat damage float distanceFactor = Mathf.Clamp01((Mathf.Pow(maxDistance, 2) - sqrDist) / Mathf.Pow(maxDistance, 2)); float heatDamage = ExplosionHeatMultiplier * power * distanceFactor/part.crashTolerance; where sqrDist is the square of the distance from the face of a part to the origin of the explosion. (distanceFactor applies a linear quadratic falloff from 1 at closest point, to 0 at max distance) and applies a force, float force = power* distanceFactor * ExplosionImpulseMultiplier; Where ExplosionHeatMultiplier is 2800 and ExplosionImpulseMultiplier = 1 which are hardcoded at the moment and haven't gone through many balance tests. After things settle down with the bugfixing, I'll make a few quick tutorials on the different systems. My mistake. I'll look into it. (about AGM detonating prematurely when locked) Edit: Found it. Another dumb typo/mistake in the code. Turrets are now oriented with Z is forward Y is up and X is right (unity standard). But if your gun is a fixed gun, just remove the ModuleTurret module. It's no longer required to set up turrets for fixed guns.

I haven't touched the HEKV yet, so you may need to just add targetingType = radar to the part config (even if using legacy targeting).

Found the issue; it turns out I also used the same "activeRadarRange" value as the max range a semi-active missile can be away from its surrogate radar. Woops! I'll fix it. I haven't run into loss of control specifically, but I did fix some errors I found in a similar situation, so try 0.9.5 and see if it still happens. Forgot to update the title, but KerbalStuff always has the latest version. KSP only loads the terrain collider for the chunks close to the active vessel, so when trying to target something far away, the "laser" ranger or raycast has nothing to hit against (NO LR), so it raycasts an imaginary plane at the terrain altitude below the active vessel. Because of changes in terrain height and the curvature of the planet, this point usually isn't on the surface. You can! It's a feature for now. Generally, radar can't detect non-moving targets on the ground because they can't differentiate between the waves bouncing off the targets and those bouncing off the ground, though there are radar systems out there specifically to track ground targets. From a gameplay perspective though, I'd like to keep it this way to separate the use anti-air and anti-surface missiles. You can make a hollow model just fine, as long as the collider is convex. You can just have a separate mesh for the collider and remove any mesh filter or renderer components so you're only left with the mesh collider. For the stealth part - I haven't tested it since I don't have any parts that use it, but the implementation is like this: The "jammer" module has a value called rcsReductionFactor. This value is averaged among all rcs reduction parts on the craft (rcsAve), and the total mass of the stealthy parts are added up (rcsrTotalMass). Then I get a value by doing massFraction = rcsrTotalMass/vesselTotalMass. Then the final rcs multiplier is 1-(rcsrAve * massFraction). The idea is that the higher the rcsReductionFactor of the part the better, and the higher the ratio of stealth parts to non-stealth parts (by mass) the better (adding a stealth nose-cone to a 747 won't help much). If you want to just be able to use a single part to make a significant cut down in the RCS, you can give it a really high rcsReductionFactor. Oh, and just give it a resourceDrain = 0, and alwaysOn = true. Thanks, forgot about that. The guard mode's short visual range is intended - it's supposed to be what an operator can detect with naked eyes. Targets further out should require a radar or other sensors to detect and track. With legacy targeting, you still have the ability to turn guard range all the way up to phys range. Edit: Ohh you mean for when it chooses you switch to the turret (just checked the PR). I haven't run into this. Did anything come up in the output log? (Alt-F2 in-game, and KSP/KSP_data/output_log.txt) That tutorial is using the legacy targeting system, which you can enable in the options (Alt-. With the new systems, you need to use the proper targeting system, depending on the type of weapon. For the HARM, you need to turn on the RWR (in the modules tab of the weapon manager window).

Update v0.9.5 = New = - GPS Coordinate lists are now persistent - Enabled activating multiple jammers with diminishing returns for each additional jammer - Added more stack nodes to adjustable rail - Added configurable lock-on after launch ability for radar missiles (activation of this mode is not yet implemented though) - Above feature also allows radar missiles which have lost surrogate radar lock to continue to predicted impact point and automatically attempt active re-lock (currently used on AMRAAM) = Changes = - Added variations on jamming contact's detected bearing on jammed radar Demonstration GFY at different ranges - ECM functions have been separated into configurable traits (rcs reduction, range/bearing jamming, lock-breaking) - Made radar missile's active radar signal strength threshold configurable - Missiles will detonate some time after they have missed - Changed explosion damage implementation again (much better this time) - TGP, turrets/guns, and radar will disable if vessel is not controllable - Increased TWS Radar's sensitivity = Fixes = - Fixed persistence of TGP locked coordinates - Fixed jammers occasionally shutting down despite sufficient electric charge - Vessel's jamming status is updated if parts are broken off or destroyed - Weapon manager's module and weapon list is updated if parts are broken off or destroyed - Fixed (harmless) debug errors when launching rockets - Fixed rocket appearing in front of rocket launcher for one frame after launch - Fixed possible NRE spam from ModuleWeapon after vessel loading

Are you sure? It works for me. Things that could make it not work: -Guard mode -You're trying to fire by clicking on the TGP window. Firing is blocked if you're clicking on any BDArmory gui windows. There's no RPM support at the moment. I don't know what to say.. it's part of the design restrictions. Real aircraft that don't have room for a radar don't have a radar. If you're going to clip something into the vessel anyway, just clip one of the radomes in. It still works if you fire missiles without switching to a different weapon in between. It's always been the case that if you switch to a different weapon, the system 'forgets' to launch the symmetry counterpart of the previously launched missile because it's 'thinking' about the current weapon (something to be improved). Guard mode tends to switch to 'None' if it doesn't have a current target, which is why you may be seeing this in guard mode.

No, not really. If you have a target lock, it just calculates the timing with some random variance. It's intentional in the sense that career isn't supported at this time. Yeah, I guess I can separate the traits. At the moment the radars only detect airborne vessels. I'm experimenting with different implementations of explosions. I also don't like how this one turned out so it'll change in the future.

That's already implemented. Maybe that has something to do with why they aim way off if AI pilots aren't switching on radar to help with aiming, but in any case, the main reason is I haven't really worked on the AI pilot much yet. I'm gonna need more details than that. That last update was all about fixing and testing that turrets work with guards. It's just for making attaching missiles to rails with perfect alignment easier.

Update v0.9.4 = New = - Stack nodes for missiles/rockets/pods - Stack node for AdjustableRail - Adjustable rail will update the position of attached objects when height is adjusted (no more reattaching) Demonstration GFY = Fixes = - Fixed guard turrets not aiming/firing when 'visually' acquiring a target - Fixed missile not receiving target data from weapon manager if fired via right-click menu or action group - Fixed missiles being removed from guard's target database - Fixed guards not engaging missiles with new targeting system

I haven't modelled HOJ yet and the jammer functionality is still pretty lame/placeholder - I'll keep those tips in mind when working on it later. Thanks. Eventually it would be wise to either have solid fuel as a resource in the missiles that gets drained, or to just define an initial mass and final mass, which would be easier. Heh yeah I've seen that video.. AIM-9X's are insane! Yeah the AI will throttle down while flaring if it has energy to spare. Which mod? I have plans to do that later when I'm ready. Looking at Contract Configurator source, its a bit of a process to spawn vessels from craft files. Again the jammer functionality isn't completely finished, but as of now, you don't really see the effects unless the vessel is a certain distance away - it basically cuts down on it's cross section and causes the blip on the radar to be jittery. Found the issue.. dumb mistake. I'll upload a hotfix in a bit. I'll take a look. (But I think it's just because I haven't done threat assessment of GPS missiles yet) Edit: I found the issue. I have a coroutine that occasionally goes through the target database and removes null entries and entries that it thinks are no longer threats. Apparently missiles are always removed, but you just notice it on cruise missiles because they are in flight long enough to be removed by the coroutine. On top of that, with the new targeting system, the subroutine that checks whether a missile is hostile was still checking for legacy target vessel stuff. Fixed it. Here's a sped up gfy. (close call)

It's on the first page and download page.

I noticed that your license is "All rights reserved" but if you redistribute models from BDArmory, you have to respect share-alike license and use the same license. For now, with fixed guns, the AI pilot assumes it is pointing directly forward aligned with the reference transform (the navball). Since v0.9.0, guns controlled by guard no longer have the cheaty feature that made the guns shoot in the exact correct direction if it only off by a couple degrees, so AI planes using fixed guns aren't as deadly accurate as before.

Update v0.9.3 This is another round of new features that are still in their infancy - this is the beginning of guards/AI using the new systems. Please be patient and help out by reporting issues as you find them in a concise and thorough manner. Thanks! = New = - With new targeting, guard range is instead visual range (acquire targets without sensors), limited to 3.5km - Guard's visual scanning is a separate subroutine than the scan intervals defined by the slider (which is now just firing intervals) - Guards can still discover and acquire targets beyond that distance by using radar or other sensors - Guards can use Radar and TGP for turrets - Guard's can use GPS, Laser, and Anti-radiation missiles - Guards/AI now fire appropriate countermeasures and evade radar (via RWR) and heatseeking missiles (via visual detection) - Guards fire both chaff and flare when a missile launch of unknown type is detected - Guards will automatically enable radar or TGP if necessary = Changes = - Changed explosion damage to a new system of firing many rays in random directions using heat damage - more consistent on high-velocity impacts (may need balance tweaks) - Anti-radiation missiles now only lock onto SAM or Detection type radars - Bombs with any type of guidance now have the larger reticle (not just GPS) - Improved JDAM steering - Changed size of jammed radar ping - Slightly increased TWR Radar scan sensitivity - Increased missile detection for radars - Tweaks to certain missiles' steering and aero (tweaks will continue in the future) - Tweaked chaff effectiveness = Fixes = - Radar scan threshold now uses the proper configured value - Radar-detected vessels are no longer reported to both team's target database - Fixed debris showing up as enemy targets on radar - Fixed some inconsistent use of TargetInfo - Fixed rockets spawning in front of rocket pod instead of inside it Edit: Here's a GFY of an AI plane effectively defeating a heat-seeking missile

Maybe this is physically real, but is it necessary to add that complexity when the end result is the same? That's a pretty good idea. I'll eventually do that. Oh, forgot about that. In that case, I had two separate fireTransforms. I guess technically you could have a bunch of fireTransforms in the same spot to fire like a shotgun. http://i.imgur.com/ONKNHRa.png Works fine for me. Did you click 'slave turrets'? I'm still fixing bugs with the new stuff, so I won't even attempt to make it more complex by running multiple systems independently from a single vessel for now. Action groups would absolutely stay. I'm still trying to balance it. It's tricky. Since that's part of the stock game, it might have to be a hacky solution - I don't want to worry about it for now. There's some mods out there that let you switch to a vessel out of a list though. Were you using legacy targeting? As I mentioned before, the new systems haven't been completely integrated into the guard's routines yet. I'm working on that now. Absolutely. You don't need to credit for that. It should work fine as long as your cockpit is aligned as Y = forward, Z = down, X = right (which is how it needs to be for the navball to be correct anyway).

Oops, it turns out I left a temporary setting of 0.1 for the threshold of scanning, which means all radars have pretty much maximum scan range. It'll be fixed. Just ignore the weapon manager's right click menu.. I really should just remove it because all the features and more are more easily available in the toolbar. Whenever I see people having difficulty trying to right click the weapon manager part in videos, I wonder.. "why? Just use the toolbar!". Guards really shouldn't be jettisoning missiles instead of firing them. I guess you should try replacing them, but it's not something that should happen at all. Does anyone know what could be causing this?