[1.1] BDArmory v0.11.0.1 (+compatibility, fixes) - Apr 23

[War Eagle 1]

Oh and Bahamuto your mail box is full

- - - Updated - - -

Is there a way to make the menus and what not smaller so they don't take up the whole screen?

[BahamutoD]

That's because you're doing it backwards. The TTR/FCR radar locks up multiple targets as a designator (this is called multi-targeting and radars can lock up from 1 to 37 targets, depending on the model). The datalinked launch system selects one of the locked up targets to fire at - the system does not tell the radar which target to lock. So all you have to do is set it so a unit with a datalink gets a choice of targets to launch at, but doesn't actually get to tell the radar set which target to lock. UI-wise, the player would select the radar and click on which targets they want the radar to lock up, and then switch to the launching unit to choose between targets. You could probably have a tally for the targeting radar which indicates how many lock-ons are left; this would allow players to have multiple radars locking up multiple targets, and datalinked units would switch between radar sets for their target selection. This would allow for homeland-style radar chains and scenarios where a player has to punch through the chain to get at a target within.

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.

[Acea]

OMG that Mod is AWESOME. I love it and all it additions! Maybe I'll make my own... So remember the old "Gondola" cannon from Retro future? The parts are outdated and I would like to see a tutorial... Maybe I can recover the model =)

Or a tutorial for making missiles would be awesome too... XD

An addition called P.E.W. by LORDPrometheus, has provided a tutorial about making missiles in its development thread.

[harpwner]

Would it be possible to make a missile launching turret? something like... the ASROC launcher that I want to add to my expansion?

[goldenpeach]

Is there a way to make the cruise missile lock on a ground target(like, by being GPS guided)?

Because they don't work very well on airplanes(which would,more or less, be the only flying target you could lock with the radar).

Also, can radars lock on a ground target like buildings?

[BahamutoD]

Would it be possible to make a missile launching turret? something like... the ASROC launcher that I want to add to my expansion?

Currently, no.

Is there a way to make the cruise missile lock on a ground target(like, by being GPS guided)?

Because they don't work very well on airplanes(which would,more or less, be the only flying target you could lock with the radar).

Also, can radars lock on a ground target like buildings?

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

[Scoundrel]

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?

[Quabbo]

An addition called P.E.W. by LORDPrometheus, has provided a tutorial about making missiles in its development thread.

Yea I know... I am watching it at the moment while trying to make a missile. But it is not that

precise

[Fabio]

That's odd, drone parts should work fine too. Maybe it was out of electricity?

No, they always have enough electricity (RTGs) and I can use them and shoot without any problem.

And a feature request: Turrets are useless against planes flying in a circle (because they only calculate where it will be based on the current speed).

They would be more accurate if you use a curved flight path (based on the average of the last 0.3 seconds).

I think the mathematics would be easy enough if you use the approximation technique.

Edited September 4, 2015 by Fabio

[Coga19000]

Actually, I have an idea concerning radar: In not sure if it works this way in RL operations, but would it be possible to combine readings from the RWR and a radar (most likely an AWACS) to calculate the position of a ground radar in the radar screen? (I would also suggest triangulation for further challenge and realism?, but getting three AEWs out of the hangar to radar-lock a single SAM at close range is reaaaaly not worth it.)

Also, the firing button doesn't seem to work for Bombs and missiles for some reason. It works perfectly fine for guns though.

[Fabio]

Also, the firing button doesn't seem to work for Bombs and missiles for some reason. It works perfectly fine for guns though.

Press the button longer and watch the tutorial videos.

https://www.youtube.com/user/bahamutod/videos

[Coga19000]

Press the button longer and watch the tutorial videos.

https://www.youtube.com/user/bahamutod/videos

I have already seen the tutorials. But press it longer... Hasn't thought of that.

[Fabio]

I have already seen the tutorials. But press it longer... Hasn't thought of that.

He said it in one of his videos but I think it was older.

[Combatsmithen]

The "large detection radar" is an Early Warning Radar (EWR) and its job is to detect aircraft at long ranges. The "TWS locking radar" is a combination of Target Tracking Radar (TTR) and Fire Control Radar (FCR) and it is supposed to get data transferred to it in what is called an EWR Passdown - that is to say, the EWR tells the TTR where to point, and whether to got active or stay quiet. In KSP's limited battlespace, the AI should keep the TTR off if there is an EWR present on its side. The much more powerful EWR continually scans the area, and the AI should only allow the TTR to go active when the EWR detects something within the search range of the TTR; the TTR then looks for the target, activates its FCR to lock up the target, and fires its missile/guns at it. If the EWR is taken out, or there isn't one present, or the system doesn't have a datalink (I can't remember what Baha called his datalink part... radar receiver?) only then should the AI should use the TTR as a search radar.

On another topic:

The current b-scope has the icons fade out after an azimuth sweep; because I was messing with stealth parts I assumed it was because the target was fading out of track due to RCS reduction. Turns out it does this for all targets. On a digital scope the icons don't fade out between sweeps - the fading out people associate with radar was because prior to LCD digital displays, they used old phosphorus tubes on the PPI screens, whose dwell time was long enough to make a pip stay on the screen so people could identify its position and bearing - making it popular in movies for displaying radar sets because the audience could interpret what they saw much more easily. On a real B-scope, the icon stays in its position until the next sweep - and will start blinking if the contact is lost at its last location for 3-5 sweeps depending on the radar model. Hopefully Baha will consider fixing this for the next update.

Wait..... There are stealth parts and i didnt know about it and havent seen them in the parts list!?!?!?!?!?!?!?!?

[Coga19000]

Wait..... There are stealth parts and i didnt know about it and havent seen them in the parts list!?!?!?!?!?!?!?!?

I don't think so. Currently, an aircrafts RCS is calculated by taking a low res photo of the target and count the pixels ; if they are below a certain limit, the radar doesn't notice you. Stealth designs are generally bulky,and therefore should take more pixel space ; ergo, a stealth design is a of now impossible. Unless only the pixels at the edges are calculated, in which case a smooth flying wing design could possibly have a miniscule chance of evading detection- but by far not a useful enough chance to be practical, as such designs still have a pretty big surface area, and I have noticed the pixel threshold to be unforgiving at times.

[Scoundrel]

Wait..... There are stealth parts and i didnt know about it and havent seen them in the parts list!?!?!?!?!?!?!?!?

I'm making stealth parts for my BDA addon RvB that uses the radar code Baha did to make them low observable. If you search through the forums you'll see pics of my weapons bays which are the current stealth parts, though I'll be making more. I'll be doing a release soon once I finish some missiles and other parts, and have fixed some texture issues with my DDS exporter.

[Shumihazai]

Hey Baha thanks for the latest update, I've been enjoying the dogfights with the new AI. Is there any possibility for a satellite GPS targeting? I found this mod

http://forum.kerbalspaceprogram.com/threads/24646

I believe it gives GPS coordinates using at least 4 satellites. Any chance of having the same feature for BD Armory? I guess satellite targeting will be FUN plus it will make the use of the HE-KV-1 for anti-satellite warfare.

Thanks!

[phas]

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.

This is what i would do:

The radar detects the targets in his range and build a list-like object (maybe a binary search tree ordered on distance or even a quad tree).

The guard will inspect this list-like object and his own weapons and settings to search for a suitable target. When found it will ask the radar for a lock on the target.

The radar will track the target as locked and give back the guard some Lock object filled with informations on tracking status and stuff.

The guard and missiles or whatever will use this Lock object to fire at the target/guide missiles/whatever.

The radar will maintained a list of Lock objects and update them with current locking status. e.g. if lock it's lost it'll update the status and the guard/missile will act accordingly

Considering the current tracking capability of modern radars and the limitations of pratical ksp/bdarmory i wouldn't worry on limiting the maximum number of trackable targets. Even if you have a lot of targettable objects, it's unlikely you have that many guards, so the system would not be OP. On the other hand in the future you may implement multiple target engagement in the guards and then set a different maximum number of trackable targets in different models of radars and that will add a lot of variety to the radar system.

[Scoundrel]

Actually, I have an idea concerning radar: In not sure if it works this way in RL operations, but would it be possible to combine readings from the RWR and a radar (most likely an AWACS) to calculate the position of a ground radar in the radar screen?

Heh. Interesting idea. It sort of works that work that way in real life but not really. Normally, post-1970s radars have several ground attack modes that interface with the RWR to provide radar ranging for A2G ordnance for attacking SAM sites and EWR installations and the like. If Baha ever decides to do A2G radar modes, then it would make sense to add such a feature.

[War Eagle 1]

Is there any way to make the radar window small in size. When I open all the tabs my screen gets filled up

[Dunbaratu]

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)

Speaking as a kOS developer here (the one who made the partmodule interface code under discussion).

The kOS generic PartModule interface described at that page had the following goal:

- Give people's scripts the exact same controls to manipulate that the manual pilot has via the game's GUI, BUT NO MORE. If a variable or function doesn't have a user interface on the rightclick panel or from an action group, and we allowed people to start fiddling with it, then we are going to be giving those other mod developers a LOT of headache as people start reporting "bugs in your mod" that are their own darn fault because altered variable values the mod never expected to be changed by a player in flight.

So we took "the mod decided to allow a player to have a user interface to manipulate the thing" as our 'permission' to allow a script to fiddle with the thing in the same way a player could have manually. Anything that doesn't seem to fit that profile, we don't allow, just to keep from angering all the other mod authors.

If your mod allows player interaction through its own customized way, then kOS doesn't know how to look for it by default, since every mod will do it their own different way, and there's literally several hundred different mods. No way we can support all that.

However, because some mods might want to allow kOS to do more than the default interface allows, we do have a means to allow some modders to add code to our mod (or have us add it for them) to give people that extra way to access things they gave us permission to access.

Here's an example page showing some of the other mods we have extra support for, outside the partmodules system:

http://ksp-kos.github.io/KOS_DOC/addons.html

Remotetech, alarm clock, action groups extended, and infernal robotics have some additional addon support here. You can look at how they were done to see a model for how it could be done with BdArmoury too.

[JewelShisen]

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.

Thank you! I know that for a while I was using it to control the game's camera movement so I am sure there is a way to do it.

[MunGazer]

Speaking as a kOS developer here (the one who made the partmodule interface code under discussion).

The kOS generic PartModule interface described at that page had the following goal:

- Give people's scripts the exact same controls to manipulate that the manual pilot has via the game's GUI, BUT NO MORE. If a variable or function doesn't have a user interface on the rightclick panel or from an action group, and we allowed people to start fiddling with it, then we are going to be giving those other mod developers a LOT of headache as people start reporting "bugs in your mod" that are their own darn fault because altered variable values the mod never expected to be changed by a player in flight.

So we took "the mod decided to allow a player to have a user interface to manipulate the thing" as our 'permission' to allow a script to fiddle with the thing in the same way a player could have manually. Anything that doesn't seem to fit that profile, we don't allow, just to keep from angering all the other mod authors.

If your mod allows player interaction through its own customized way, then kOS doesn't know how to look for it by default, since every mod will do it their own different way, and there's literally several hundred different mods. No way we can support all that.

However, because some mods might want to allow kOS to do more than the default interface allows, we do have a means to allow some modders to add code to our mod (or have us add it for them) to give people that extra way to access things they gave us permission to access.

Here's an example page showing some of the other mods we have extra support for, outside the partmodules system:

http://ksp-kos.github.io/KOS_DOC/addons.html

Remotetech, alarm clock, action groups extended, and infernal robotics have some additional addon support here. You can look at how they were done to see a model for how it could be done with BdArmoury too.

Good information, thanks. I totally respect that decision to keep people from getting in over their heads with kOS, and it probably does save the mod developers a ton of headaches. People will inevitably be snooping around doing all sorts of wacky things. kOS is just a really great concept however; it would be really cool if someday all the mods out there could be kOS friendly. I'd imagine there is definitely truth in what you're saying about not being able to cater to several hundred mods. Generally it would seem that they should come to kOS rather than vice versa. And I would hope not, but don't know, if maintaining kOS compatibility during the development of any mod would impose limitations to what those mods could do; my hope is that it would, instead, expand possibilities even if only through compatibility with other mods that are kOS friendly. I also understand that a re-write would possibly be in order for guys like baha to make it kOS compatible, and would sympathize if such an action would be deemed too much trouble to execute if the aforementioned issues weren't already enough to avoid it. I'm sure they have lives and I get to enjoy their work for free so I'll never complain. I just love so many of these mods and when I slap that little kOS CPU on to manipulate my stock parts, I can't help but wish I could program insane amounts of code for all the cool toys I have crammed onto my craft.

Edited September 5, 2015 by MunGazer

[TronX33]

How does the radar receiver work? I have it on one ship, and I have another ship with radar and locking capabilities, yet the receiver says no data.

[Coga19000]

How does the radar receiver work? I have it on one ship, and I have another ship with radar and locking capabilities, yet the receiver says no data.

You have to link the Radar Receiver to a radar unit. I think it's done by right clicking.