[1.3.1] BDArmory Continued - FOR MODDERS - Public BETA of v1.0.0 (Update: Preview 2)

[SpannerMonkey(smce)]

1 hour ago, Canberra_Gaming said:

it's easily exploitable and quite frankly BS.)

Hey this is KSP.  Every system is exploitable , and you missed the point the idea was to see if it was possible and perhaps improve and add some interest to something that hasn't changed much in years. The intention is not to prove hey we can beat a 300 million dollar weapons system simulation with a crappy 64 bit install and a massive lump of code and hundreds of hours work, but to get the best we could with the tools available and tools created to do the job.

Thank you for your appreciation

[Canberra_Gaming]

26 minutes ago, SpannerMonkey(smce) said:

Hey this is KSP.  Every system is exploitable , and you missed the point the idea was to see if it was possible and perhaps improve and add some interest to something that hasn't changed much in years. The intention is not to prove hey we can beat a 300 million dollar weapons system simulation with a crappy 64 bit install and a massive lump of code and hundreds of hours work, but to get the best we could with the tools available and tools created to do the job.

Thank you for your appreciation

We're not trying to rip on you guys at all, like I said before. We do appreciate where this is going and trying to help you by finding exploits such as this as well as bugs. I threw out my ideas that I believe would make the system better and more realistic, now whether you want to do it/ can it be done in game isn't up to me.

[Abraxis]

Would it not be simpler to just utilize a hybrid between the current model, and BD's previous mechanic of calculating the total area of the sky your craft blocked? That way, it will place emphasis on aircraft design--in order to make something undetectable, you would need to limit its frontal area, which, in combination with the previous model, would give skillfully-designed aircraft an advantage over drones specifically made to exploit the setback of the regular, angle-based model.

[gag09]

What you guys are using drones? the exploit works on stuff much larger.

[ScriptKitt3h]

To the mod developers, I don't think that what ya'll have been doing is 'BS', but I do feel that it needs some major tuning. Like others have said, the current (yes, it is a beta, but that's why there's responses about how it could/needs to be improved) RCS system just is plain inadequate and inaccurate.

While yes, the solution you guys have used to calculate RCS in-game is clever, the mere fact that something that arguably shouldn't work (like what gag posted earlier, etc.) works excessively well shows that the system needs refinement and tweaks. I'm personally not a developer for KSP mods, but I'd suspect that not relying 100% on purely what the shader reflects off of (or setting parameters for the types/strengths of return based off angle of deflection, etc.) would be a way to help make it less exploitable and more in-line with reality.

Also, I don't believe what the posters earlier intended to say was that the work of the mod devs was 'BS' or in any way wrong, just that the current system has flaws that need to be worked on.
Everybody wants the same thing here (I'd assume?), which is a functional, effective RCS system implementation in BDAc going forward. The current public beta's system is not up to par quite yet in that sense.

[DuoDex]

A few posts have been pruned from this thread. Please keep in mind that

• Maintaining a civil demeanor towards all members of this forum is required.
• Mod authors do this for free.
• A thread for a weapons mod is not a free-for-all discussion on a participant's intelligence (or lack thereof).

Thank you, and now please return to your polite and reasoned conversation on the new release of the BDArmory mod.

[DuoDex]

There is a bit of a rant going on, and I might have worded my initial post poorly. When I posted, I was trying to get everyone to calm down a bit (I did remove posts from "both sides", if you will), but it looks like people are latching on to the idea that their criticisms were removed because they were criticisms.

Posts from users are being removed because they are being disrespectful and uncivil, not because I am trying to censor their criticisms. If you check the thread, you should see a fair few posts that criticized the new system that I haven't had to remove - they were polite and respectful.

Posts from devs have also been removed, because they responded impolitely to those same criticisms.

 

Let's just all calm down a little.

P.S. I accidentally hid a few posts that were unrelated to the problem. Sorry.

[TheDog]

Thanks for testing these extreme cases.

Indeed, it is not too great that these 45° only planes can fly and have such good stealth.

Franklin, though, to me it is more awkward that they can FLY in this configuration...

Regarding over-excessive usage of stealth: that is exactly why our radars have an assured detection range, as mentioned earlier, and we encourage all 3rd party mods to define the same.

Lastly, about using actual real-time angles and returns instead of static rcs value: yes, that would be great, but unfortunately it's computationally too expensive. It would slow your frame rates to a crawl. So this system was devised in this way to be performance friendly, though not fully realistic as a trade-off...

[Canberra_Gaming]

16 minutes ago, TheDog said:

Thanks for testing these extreme cases.

Indeed, it is not too great that these 45° only planes can fly and have such good stealth.

Franklin, though, to me it is more awkward that they can FLY in this configuration...

Regarding over-excessive usage of stealth: that is exactly why our radars have an assured detection range, as mentioned earlier, and we encourage all 3rd party mods to define the same.

Lastly, about using actual real-time angles and returns instead of static rcs value: yes, that would be great, but unfortunately it's computationally too expensive. It would slow your frame rates to a crawl. So this system was devised in this way to be performance friendly, though not fully realistic as a trade-off...

Thank you, I didn't mean to come off as disrespectful earlier, I was getting kinda irked when we didn't get any response about the idea different radar system or what you could or couldn't do. This answered all of my questions. Thank you.

[TheDog]

Well, I am grateful you found this 45 deg exploit, cause this is going into a direction we definitely don't want - and would make bda tournaments difficult as everyone would abuse this... So, we are investigating what can be done about it!

[Canberra_Gaming]

From my understanding of stealth, radar cannot reflect off of smoothly built, rough surfaces (Coating) and angles. I'm sure this is your department more than mine, you've done more research than me I'd bet.

Is there any way to use that RCS from three different pictures in radar without slowing the game to a crawl? Instead of averaging the total perhaps?

Edited October 12, 2017 by Canberra_Gaming

[Acea]

Not really related but I'd ask a question, is there any plan of advanced ECM methods, like fake target signals and decoys for radar confusion?

[TheDog]

2 hours ago, Acea said:

Not really related but I'd ask a question, is there any plan of advanced ECM methods, like fake target signals and decoys for radar confusion?

Not at the moment, no, but it would be useful also for our sonar/torpedoes...

[TMasterson5]

Hey gents, in light of the coming changes contained in this thread I thought it would be cool to have one sheet that lists all(or at least as many as possible) of the 100's of BD Armory and associated mods parts. I think this would make it far easier for people at a glance to see what they're getting and especially with what this update will contain, which parts would work best for certain scenarios. This is by no means perfect or a final draft, but its a start. While only radars are tracked right now, I would eventually like to expand it to other categories as well like guns, missiles, etc...

 

If you would like to be a part of it(I hope you all do) just put all the associated data from your mods into a text document, or a spreadsheet, or something, and then shoot it over to me and I will get you added. Obviously this wont go live until the update outside of this thread but ideally I want as many mods in this as possible before that so we can start a trend and have it available from day 1 of the new version.

 

Lastly, I'm also looking for feedback on what you all think of the idea as a whole and specifically ways to improve the current sheet as I know it is nowhere near perfect by any means. Thanks in advance for you guys help and feedback and stay awesome! 

BD Armory Part Comparison

[TheDog]

10 hours ago, TMasterson5 said:

All data

I did have the need for that already, so I have provisioned a small "extraction feature": if you run the public beta build and turn on "debug labels" in the bda options, then enter sph, it will dump all currently installed guns, missiles and radars into CSV files, to be found under gamedata/bdarmory/plugins/data

Maybe they are helpful for your task.

Since I have a heavily modded install, I used them to compare configs of items...

[njmksr]

@TheDog Does the current version factor in planform alignment?

Also, thanks for the beta, and great work... I love it a lot so far.

[Guest]

my custom cfg radar wont lock! whats wrong?

Spoiler

PART
{
    name = bdRadome1
    module = Part
    author = BahamutoD
    rescaleFactor = 1
    node_stack_bottom01 = 0.0, -0.9382, 0.0, 0.0, -1.0, 0.0, 1
    //node_attach = 0, 0, -0.313, 0.0, 0.0, 1.0
    TechRequired = precisionEngineering
    entryCost = 6200
    cost = 320
    category = none
    subcategory = 0
    title = AN/APG-63V2 Radome
    manufacturer = Bahamuto Dynamics
    description = A forward facing, aerodynamically housed radar. It can scan and lock targets within a 120 degree field of view. It is optimized for air-to-air combat, and has difficulties locking surface targets.
    attachRules = 1,0,1,1,0
    stackSymmetry = 2
    mass = 0.375
    dragModelType = default
    maximum_drag = 0.1
    minimum_drag = 0.1
    angularDrag = .25
    crashTolerance = 40
    maxTemp = 2000
    fuelCrossFeed = True
    bulkheadProfiles = size1
    thermalMassModifier = 6.0
    emissiveConstant = 0.95
    MODEL
    {
        model = BDArmory/Parts/radome125/radome1
    }

MODULE
{
      name = ModuleRadar

          // -- Section: General Configuration --
          radarName = AN/APG-63V2 Radome        // if left empty part.title is used, but advised to set this to a nice printable text
          rwrThreatType = 1                // IMPORTANT, please set correctly:
                                  // 0 = SAM site radar
                                  // 1 = Fighter radar (airborne)
                                  // 2 = AWACS radar (airborne)
                                  // 3, 4 = ACTIVE MISSILE (DO NOT USE UNLESS YOU KNOW WHAT YOU'RE DOING!
                                  // 5 = Detection radar (ground/ship based)
                                  // 6 = SONAR (ship/submarine based)
          rotationTransformName = scanRotation
            //turretID = 0                    // if needed
          resourceDrain = 0.825                // change to higher values for more capable radars, e.g AESA

          // -- Section: Capabilities --
          omnidirectional = false                // false: boresight scan radar
          directionalFieldOfView = 120            // for omni and boresight
          //boresightFOV = 10                // for boresight only
          //scanRotationSpeed = 240                // degress per second
          //lockRotationSpeed = 120                // only relevant if canLock
          lockRotationAngle = 4
          showDirectionWhileScan = true            // can show target direction on radar screen. False: radar echos displayed as block only (no direction)
          multiLockFOV = 40                // only relevant if canLock
          //lockAttemptFOV = 2                // only relevant if canLock
          maxLocks = 3                    //how many targets can be locked/tracked simultaneously. only relevant if canLock

          canScan = true                    // scanning/detecting targets (volume search)
          canLock = true                    // locking/tracking targets (fire control)
          canTrackWhileScan = true            // continue scanning while tracking a locked target
          canRecieveRadarData = false            // can work as passive data receiver (NOTE THE SPELLING! [SIC])

          minSignalThreshold = 80                // DEPRECATED, NO LONGER USED! use detection float curve!
          minLockedSignalThreshold = 100            // DEPRECATED, NO LONGER USED! use locktrack float curve!

        radarGroundClutterFactor = 0.1            // how much is the radar efficiency reduced to by ground clutter/look-down?
                                // 0.0 = reduced to 0% (=IMPOSSIBLE to detect ground targets)
                                // 1.0 = fully efficient (no difference between air & ground targets)
                                // default if unset: 0.25
                                // Ground targets, especially ships, already have a massively larger RCS than fighters, hence
                                // any ground clutter factor >0.25 is to be considered very good, making an efficient surface/horizon search radar.
                                // values >1.0 are possible, meaning the radar is MORE efficient during look down than vs air targets.

          radarDetectionCurve
          {
            // floatcurve to define at what range (km) which minimum cross section (m^2) can be detected.
            // this defines both min/max range of the radar, and sensitivity/efficiency
            // it is recommended to define an "assured detection range", at which all craft are detected regardless
            //     of their rcs. This is achieved by using a minrcs value of zero, thus detecting everything.
            //        key = distance    rcs
                      key = 0.0    0
                      key = 5    0    //between 0 and 5 km the min cross section is 0, thus assured detection of everything
                      key = 10    1   //
                      key = 20 2.5    //
                      key = 35 4.5    //maxrange of 35km
                      key = 55    7   //

                      key = 80    10.5   //
                      key = 110    14.5   //
                      key = 145    19.5   //
                      key = 185    25   //
                      key = 230    30   //
                      key = 280       37.5   //        }

          radarLockTrackCurve
          {
              // same as detectionCurve, just for locking/tracking purpose
              // ATTENTION: DO NOT USE an "assured locking range" here, as this would render lock-breaking
              //   ECM-jammers & chaff completely ineffective!!
              //      key = distance    rcs
                      key = 0.0    0
                      key = 5    0.5    //between 0 and 5 km the min cross section is 0, thus assured detection of everything
                      key = 10             2.5   //
                      key = 20             3.5    //
                      key = 35                  6    //maxrange of 35km
                      key = 55    9.5   //

                      key = 80    14   //
                      key = 110    19.5   //
                      key = 145    26   //
                      key = 185    33   //
                      key = 230    41   //
                      key = 280       50   //        }
}

}

 

1

 

[TMasterson5]

Minimum signal and minimum locked signal thresholds shouldn't be there. They are depreciated and serve no function. Also if you delete all the other none needed text and reference stuff it would make it a lot easier to narrow down the issue. That just looks like a wall of text. 

[TheDog]

9 hours ago, dundun92 said:

my custom cfg radar wont lock! whats wrong?

  Hide contents

 

1

 

 

mmhh, config looks fine. How does it look like in editor, in the part right-click information (while the part is still in the catalogue)?

Are the locking capabilities and ranges detected?

EDIT: no, config is not fine: after the floatcurves (radarDetectionCurve and radarLockTrackCurve) the closing bracket "}" is on a line with a comment "//", thus it wont be parsed, and the config is not properly formed. Put the "}" on a new line after the last range-rcs block...

13 hours ago, njmksr said:

@TheDog Does the current version factor in planform alignment?

 

No, not really. The low rcs value on your craft comes from the bda cockpit's rcs reduction factor, apparently you have increased it a lot, my example MM patch put it at 0.65, you seem to have 0.15 set (or used multiple additional YCSM modules from DCK)...

Edited October 15, 2017 by TheDog

[Guest]

7 hours ago, TheDog said:

 

mmhh, config looks fine. How does it look like in editor, in the part right-click information (while the part is still in the catalogue)?

Are the locking capabilities and ranges detected?

EDIT: no, config is not fine: after the floatcurves (radarDetectionCurve and radarLockTrackCurve) the closing bracket "}" is on a line with a comment "//", thus it wont be parsed, and the config is not properly formed. Put the "}" on a new line after the last range-rcs block...

No, not really. The low rcs value on your craft comes from the bda cockpit's rcs reduction factor, apparently you have increased it a lot, my example MM patch put it at 0.65, you seem to have 0.15 set (or used multiple additional YCSM modules from DCK)...

It tracks fine in the editor and on the radar screen, it simply wont lock on either.

[SpannerMonkey(smce)]

1 hour ago, dundun92 said:

It tracks fine in the editor and on the radar screen, it simply wont lock on either.

 

9 hours ago, TheDog said:

EDIT: no, config is not fine: after the floatcurves (radarDetectionCurve and radarLockTrackCurve) the closing bracket "}" is on a line with a comment "//", thus it wont be parsed, and the config is not properly formed. Put the "}" on a new line after the last range-rcs block..

 

[Guest]

On 10/15/2017 at 3:32 AM, TheDog said:

 

mmhh, config looks fine. How does it look like in editor, in the part right-click information (while the part is still in the catalogue)?

Are the locking capabilities and ranges detected?

EDIT: no, config is not fine: after the floatcurves (radarDetectionCurve and radarLockTrackCurve) the closing bracket "}" is on a line with a comment "//", thus it wont be parsed, and the config is not properly formed. Put the "}" on a new line after the last range-rcs block...

No, not really. The low rcs value on your craft comes from the bda cockpit's rcs reduction factor, apparently you have increased it a lot, my example MM patch put it at 0.65, you seem to have 0.15 set (or used multiple additional YCSM modules from DCK)...

 

On 10/15/2017 at 12:37 PM, SpannerMonkey(smce) said:

 

 

The radars work! Thanks!

[TheDog]

Update: Preview Build 2

(NEW) Preview Build 2: https://github.com/PapaJoesSoup/BDArmory/releases/tag/v1.0.0-preview2

Changelog:
- attempt to fix "stealth exploit" with additional 45° renderings. Can still be defeated, of course, but should be less sensitive to "easy" 45° angles vs all renderings, as it will compute the RCS based on the max return between "flat" zeor degree angle, and the 45° angle. Hence when reducing the flat return, at some point you will have more return from the 45° angle, which then counts (visible in rcs analysis preview).

[Guest]

I have an issue. My custom radar has 200km range in the cfg, and PRE is set to 200km, but radar display is still at 100km.

[TheDog]

22 minutes ago, dundun92 said:

I have an issue. My custom radar has 200km range in the cfg, and PRE is set to 200km, but radar display is still at 100km.

Yes, it is limited to 100km (hard coded limit).

It currently needs a recompile (like rbda) to extend this.

 

Edited October 22, 2017 by TheDog