BahamutoD

Yep, unfinished though. BTW I forgot to mention that solar panels, radiators, and other fragile parts won't break anymore when placing vessels.

Update v1.1 - Added change log - Added slow and ludicrous speed modes (press tab to toggle) - Added other rotational axes - Changed input bindings to use your settings for attitude and translation control to support non-QWERTY keyboards - Changed controls to follow cardinal directions when in map mode - Fixed surface relative rotation - Fixed and improved vessel size calculations - Vessel size calculations update when vessel is rotated - Smoother pick-up action - Faster yet more gentle put-down action Here's some updated instructions: Press Alt-P to pick up and place vessel. It must be landed or splashed down in order to pick it up. Use pitch/yaw (WASD by default) to move around. Use roll (Q/E by default) to roll, and translation buttons (IJKL by default) to rotate pitch and yaw. Press Tab to toggle speed modes. Press Alt-P again to put down. For long distances, it works well to use "Ludicrous speed" in map mode!

I'm working on some improvements including different speed modes.

Hey guys, just stopping by to let you know I'm still alive. More importantly, I quickly wrote a little tool to help you guys set up battles. Check out Vessel Mover. As mentioned before, I'll be paying more attention and working on BDA after KSP 1.1 comes out, unless I need to fix something for 1.0.5. Thanks for your patience!

VesselMover v1.5 Pick up, move, rotate, and place landed vessels quickly and easily. Download from GitHub Installation: Extract the folder called "VesselMover" to KSP's GameData folder. Usage: Use the toolbar menu buttons to pick up or place a vessel. It must be landed or splashed down in order to pick it up. Use pitch/yaw (WASD by default) to move around. Use roll (Q/E by default) to roll, and translation buttons (IJKL by default) to rotate pitch and yaw. Use translate fwd/back (H or N by default) to auto rotate planes and rockets respectively to level/upright. Press Tab to toggle speed modes. For long distances, it works well to use "Ludicrous speed" in map mode! Click spawn vessel to open the craft browser. Select a craft, then select a place to spawn it. It will spawn in vessel-move mode so you can reposition it or rotate it before placing it down. Video Demonstration: License: MIT Source: https://github.com/BahamutoD/VesselMover

allmhuran, unfortunately, it was never the case that guns had action groups or right-click menu buttons for firing. KSPActions and KSPEvents (action groups and buttons) are one-shot events, so for a gun, it would either have to be firing one bullet at a time, or toggling start firing/stop firing. It's why I had to use a separate keybinding for guns in the first place. When KSP 1.1 comes out and I come back to working on BDA, I'll see if I can add this as an option.

Currently, no. Cruise missiles are GPS guided. And no, radars in BDA can't lock buildings or any ground targets.

No, you don't need any other plugin than what's included. You just need to make sure you have the latest version, which is the one that's included. Other mods of mine may still have older versions because I haven't updated them.

You're saying that a TTR/FCR unit should just be locking a bunch of targets by itself, then the guard that's linked to it should choose one of those targets to launch at? This would require a lot of rewrite though. In a situation where there are a few enemy air targets and a single SAM unit datalinked to a radar unit, this is the current order of operations (ignoring missile threats): The guard first looks for a target that no other team mate has engaged by going through the list of all detected targets (either by radar or visual), since the only other team mate is just a radar unit, it will pick the closest one. Then it will go through it's list of weapons to find one that matches the range of the target, lets say it picks the AIM-120. Then it checks what kind of missile it is - radar. Then it checks it's radar if it's already locking the target - if not, it will try to lock the target. Since the radar is just a datalink receiver, it transfers this command to the linked radar. If I do it the other way, the radar unit would need to be locking targets by itself regardless of whether it has weapons or not (how should it decide what to lock?), then the SAM guard would have to pick a weapon first (decide to use a radar missile, arbitrarily?) then pick a target from the already locked radar targets.

That's odd, drone parts should work fine too. Maybe it was out of electricity? Seems like a good idea. There's a few other things I need to handle with the datalink receiver, like what to do if two different units want to track different targets using the same tracking radar. Right now, whoever tries to lock a target last overrides the command of the radar. This could be an issue if the previous user was using to guide a missile. The reason I bring this up is, if there's a whole bunch of datalink receivers auto-linking to the same tracking radar, they'll just be fighting over it the whole time and interfering with each other. Ah, if that's the only access kOS has to partmodules, then it won't work at the moment. The way the GPS system works right now, is the designated target and the list of targets are objects that contain a Vector3d (lat,long,alt) and a string (name). This means it's not a KSPField. If only kOS had a way to fire a method with parameters or something, like GETMODULE("Foo"):FUNCTION("SetGPSTarget",name,lat,long,alt)

I only have limited knowledge of kOS, so I don't know if/how it can access fields from part modules. I'll look into it though. If its simple enough, I'd also like people to be able to write their own autopilot AIs that can use the sensors and weapons.

It could be your decouple settings for the missiles on that truck. If it's set with an ignition delay, the clearance detection could be tripping since it knows the missile will collide with the bottom or the other side of the launcher. I don't yet know how to access KSP's input binding stuff, so I'll look into it. Yup, its on the todo list. The main purpose is for AI/Guards to detect enemies - just to know they exist and where they are.

The hat switch actually counts as 8 buttons usually so it should work, but right now only one direction seems to be getting recognized for me (hat down). This could be a problem with the default Unity input system, and I won't be able to work around it without some external input plugin.. we'll see. I'm unable to reproduce these issues. Please provide some more details, or try again with "debug labels" enabled in the settings, and send me your log. Otherwise I have no idea what might be going wrong and can't help you. Currently no. While the turret module is now separate and can be used with other things, the support for it needs to be implemented in the rocket launcher module. It will be simple, but I haven't got around to it. That shouldn't be the case. I'll need more details to figure out what could be going wrong. If that's the case, you should check with the contract configurator guy (I assume that's what you're using).

Here's the tutorial for Air-to-Ground missiles.

^That's odd. I use BDArmory and IR together fine. I'll look into it though.

It's happened to me before, but I assumed it was part of the finnicky nature of undoing. When it happened, I pushed alt-f12, then clicked show input lock stack, then cleared the lock stack, and things went back to normal.

Fudge. I thought I removed it. (It's not meant to be there) Hotfix v0.9.9.1 - Removed "WingCommander test" (did not intend to include it. Unfinished.)

Update v0.9.9 = New = - Browning .50cal AN/M2 Fixed Gun - Added auto proximity gun target tracking feature (currently used on fixed vulcan and browning) - FLIR Ball Targeting Camera - Dynamic launch zones for missiles - DLZ display for Radar and TGP - Guard will choose an appropriate anti-air missile depending on target distance and missile's DLZ - AI Pilot will go evasive if it detects someone firing guns at it = Changes = - AI is better at trying to stay behind target - Guard only force-enables RWR if missiles are detected (note: guard needs RWR to detect incoming radar missiles) - Guard FOV will narrow on engaged target - Improved and re-implemented Pilot AI launch authorization so they won't take missile shots that will obviously miss - Added targeting info to missiles' description where it was missing = Fixes = - Re-enabled guard tweakables in editor - Fixed LoadedVessels being reset when using hyperedit to place vessel - Fixed shells being ejected in front of gun when moving - Fixed radar window resetting when another vessel loads - Fixed parts disappearing from BDA category after a database reload - Removed BDA parts from utility category - Removed 'aam' homing type from HEKV-1 (still untested) Notes: - I didn't include the wingman commander yet; it's not finished yet and will need alot of GUI, so I'll wait for KSP1.1 for that too. - Modders: check the new launch range values for missiles. This will help players and AI choose a weapon/time a shot based on how far a target is. - The "auto proxy gun target tracking" automatically brings up the target leading indicators when you're near a target for the guns that use it - no need for radar lock. - When a guard engages a target, it will have a sort of tunnel vision on the target - one effect is that it will be more likely to detect incoming gunfire and missiles from that target, but less likely to notice a different target firing at it.

I doubt it - I pretty much just chopped off the head from the existing TGP; probably what you did.

Don't bother, I made a FLIR ball for the next update.

Just gotta wait till I fix it. Check your BDArmory installation and/or reinstall it.

At the moment, you don't even need the data receiver for AIs. Once a radar picks up an enemy, it automatically gets added to the AI's target database.

I plan to eventually setup the settings so all the configurable values automatically populate the settings window, similar to the key binding page. (Just recently figured out Reflection)

I don't think that's what he was talking about. He meant the max guard view distance. Right now, for seeing targets further than 3.5km they need to use radar, but they will engage if they detect a distant enemy on radar. The pilot extend range you edited in the pull request was the distance a pilot will fly away from a target in order to get a better starting point to run an air to ground attack.

Here's another clip with ww2 type crafts: http://gfycat.com/PertinentSnarlingDamselfly A common kill is when an AI decides to fly straight for a bit (if it keeps turning and turning for >15 seconds and hasn't made progress) and an enemy gets on its tail - easy kill. I've since wrote some behavior to detect that it's being shot at and to take evasive actions at that point. You'll see it in the next update.