Jump to content

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


BahamutoD

Recommended Posts

I had something similar when I crashed a hovercraft into the water. Two white squares appeared. So I think the bug is caused by KerbalFoundries.

not KerbalFoundries, never got that bug and have been using it for a while

Link to comment
Share on other sites

not KerbalFoundries, never got that bug and have been using it for a while

It actually is related to KF since those white boxes are the water slider colliders (helps us make the repulsors work over water since water doesn't have the same collision as the rest of the planetary PQS crud). The odd thing is that it shows up on a non-KF part and is positioned above the ground. Normally it would always sit below the surface of the planet and only be collided with when the altitude hits below sea level. we're working on trying to get that worked out. As of the most recent version of the mod, the collider should only be active if a KF part is present on the craft, and it should be invisible (theoretically). Work in progress.

Link to comment
Share on other sites

It actually is related to KF since those white boxes are the water slider colliders (helps us make the repulsors work over water since water doesn't have the same collision as the rest of the planetary PQS crud). The odd thing is that it shows up on a non-KF part and is positioned above the ground. Normally it would always sit below the surface of the planet and only be collided with when the altitude hits below sea level. we're working on trying to get that worked out. As of the most recent version of the mod, the collider should only be active if a KF part is present on the craft, and it should be invisible (theoretically). Work in progress.

oh... I stand corrected then

I must be fairly lucky then...

Link to comment
Share on other sites

Hi, I'm currently making a 30mm fixed gun, everything checks out, but since I just copied the cfg from the hidden vulcan, the accuracy is all over the place.

What line of cfg determines turret (or in this case, fixed gun) accuracy?

And what does maxDeviation do and is there in depth explanation on how it works.

According to the code, maxDeviation is "max inaccuracy deviation in degrees". So, maxDeviation controls accuracy and is the maximum angle in degrees between the barrel and the bullet.

I think there may be an error in the vulcan cfg file, though. In the cfg file, it's given as "maxDeviation = 0.1f", but I think the "f" at the end is causing the game to not read it correctly. Removing the "f" at the end (so it reads "maxDeviation = 0.1") causes the gun to be much more accurate.

Maybe it is reading "0.1f" as a string when it expects a float or something and is defaulting to maxDeviation = 1. I'm still using 0.9.6, though.

Interestingly, a gun with an accuracy of 0.1 degrees means that all bullets fired will land within a ~3.5 metre diameter circle at a distance of 1,000 metres.

It actually is related to KF since those white boxes are the water slider colliders (helps us make the repulsors work over water since water doesn't have the same collision as the rest of the planetary PQS crud). The odd thing is that it shows up on a non-KF part and is positioned above the ground. Normally it would always sit below the surface of the planet and only be collided with when the altitude hits below sea level. we're working on trying to get that worked out. As of the most recent version of the mod, the collider should only be active if a KF part is present on the craft, and it should be invisible (theoretically). Work in progress.

Totally unrelated, but I am suddenly reminded of the scene in Back to the Future 2 where Marty tries to use the hoverboard over water.

Link to comment
Share on other sites

Hey BD, been playing around with this and it's pretty cool. Dunno what the source is, but something added between 0.9.7 and 0.8.3 hit the overhead real hard; dogfights that wouldn't require slowing down time in 0.8.3 now have the MET solidly yellow. I should note that I'm doing this with a pair of planes with only guns on them and no missiles or radar, so I'm not sure where things could be slowing down. I know you added that radar UI; I'd say it might make sense to check that and any UI stuff, since all that stuff tends to be really expensive in terms of overhead.

Thanks for the work though, still definitely cool.

Link to comment
Share on other sites

I have a Problem. i cant use cannons und guns anymore becaue the ammo boxes are sort of bugged, the ammo does not show in the "fuel tab". im sure i installed everything right, is this a known problem? did i do something wrong?

Link to comment
Share on other sites

According to the code, maxDeviation is "max inaccuracy deviation in degrees". So, maxDeviation controls accuracy and is the maximum angle in degrees between the barrel and the bullet.

I think there may be an error in the vulcan cfg file, though. In the cfg file, it's given as "maxDeviation = 0.1f", but I think the "f" at the end is causing the game to not read it correctly. Removing the "f" at the end (so it reads "maxDeviation = 0.1") causes the gun to be much more accurate.

Maybe it is reading "0.1f" as a string when it expects a float or something and is defaulting to maxDeviation = 1. I'm still using 0.9.6, though.

Interestingly, a gun with an accuracy of 0.1 degrees means that all bullets fired will land within a ~3.5 metre diameter circle at a distance of 1,000 metres.

Wow! No wonder.. It's just a typo due to being used to putting an F after every float in C#.

It looks like I had that 'f' in there on most of the gun configs. I'll definitely through them and fix them soon.

Hey BD, been playing around with this and it's pretty cool. Dunno what the source is, but something added between 0.9.7 and 0.8.3 hit the overhead real hard; dogfights that wouldn't require slowing down time in 0.8.3 now have the MET solidly yellow. I should note that I'm doing this with a pair of planes with only guns on them and no missiles or radar, so I'm not sure where things could be slowing down. I know you added that radar UI; I'd say it might make sense to check that and any UI stuff, since all that stuff tends to be really expensive in terms of overhead.

Thanks for the work though, still definitely cool.

Thanks ferram. My first guess while reading that was "It's definitely the radar cross section method" but you said you weren't using any radars, so now I'm half hopeful that it wasn't the radar slowing everything down after all, and its something I can fix.


PS - I made a quick 'tutorial' video for using radar:

Edited by BahamutoD
Link to comment
Share on other sites

I would suspect the radar is slowing things down a bit for people using them (you're rendering an image from a camera and then getting data from that, right? That's gonna be slow to render it on the GPU and then bring all that data over to the CPU for what you wanna do) as well, but I suspect new UI things might be slowing things down (Unity 4 UI is horribly slow, ask Sarbian about MJ) and depending on how often they have to run.

Another thing to check is to look at anything that checks null for a Unity object; strangely, casting PartModules to (object) is faster than a check without that, because the standard null check involves checking to see if that underlying UnityEngine.Object and its stuff on the native side exists. This is slow; if you've got no risk that an already-existing one could be destroyed for some reason (checking a PartModule on a different Part, for example), casting to object can speed that up a bit.

Another thing to do is a sweep of all your math functions. If you've got trig functions, find a way to replace them with vector math if you can; trig functions are slow. Little things like that. Also, make sure that you know what your math is doing. As an example: this line seems innocent, but it's a lot slower than it needs to be; calculating the angle involves normalizing the vectors, then calculating their dot product and then passing that into a Mathf.Acos and then convert it from radians to degrees, and the inverse trig functions are much more expensive to calculate; it could be replaced with "Vector3.Dot(targetDirection, forwardDirection) < 0" which is equivalent but will get rid of the inv trig function, two sqrts, two divs, and a multiplication. You don't wanna die a death of a thousand unnecessary cuts.

Anyway, optimization talk aside, if I get a chance I'll see if I can contribute some code to make the AI aware of low power-to-weight ratio vehicles and how to fly with them, as well as spin detection and recovery. It's currently very fond of stalling and crashing WWII warbirds. :P

Link to comment
Share on other sites

Maybe it is reading "0.1f" as a string when it expects a float or something and is defaulting to maxDeviation = 1. I'm still using 0.9.6, though.

..How have I not noticed that? I've tweaked those deviation numbers several times, knowing full well you don't add the f to floats in config files, only to casually wonder why turning 0.01f to 0.0000001f didn't seem to change anything. I ended up adding a ridiculous number of guns for my space battles just so I could spam enough bullets in the general direction of the enemy that at least some of them would hit :blush:

Edited by Yski
Link to comment
Share on other sites

Interestingly, a gun with an accuracy of 0.1 degrees means that all bullets fired will land within a ~3.5 metre diameter circle at a distance of 1,000 metres.

A weapon's precision is normally measured in milliradians - old school shooters still use MOA, but all the popular scopes use mil dots so MOA is oh-so-slowly fading from use . The interesting result is that at 1000m, 1 mrad will create a dispersion circle of 1m. Ever since Baha added maxDispersion to the guns, I've had mine tweaked with real world figures (ugh, the maths) and the results have made battles a little more interesting, especially between dissimilar guns. I'm tempted to make a small land warfare systems mod just for that reason.

Link to comment
Share on other sites

I know it will sound stupid but...

how do I use the space missiles? I tried to use the radar, the TGP and the GPS but nothing worked :(

edit:

how do I use the data link?

I can't send data, does the link work with all the radars or only a few of them?

Link to comment
Share on other sites

I know it will sound stupid but...

how do I use the space missiles? I tried to use the radar, the TGP and the GPS but nothing worked :(

edit:

how do I use the data link?

I can't send data, does the link work with all the radars or only a few of them?

It might be like the Modular Missile Guidance and use the legacy targeting? I don't know, I haven't really taken to the stars with any weapons since radar and company were added.

Link to comment
Share on other sites

how do I use the space missiles? I tried to use the radar, the TGP and the GPS but nothing worked :(

The HEKV hasn't been touched with the recent updates, and has no method of targeting. You can theoretically make them work though: open the config file with a text editor and paste this below the line that says

homingType = RCS




targetingType = radar
activeRadarRange = 10000
maxOffBoresight = 50
lockedSensorFOV = 5

radarLOAL = true

and you should get something that will work with the current targeting system. How effective it will be is another thing entirely.

Link to comment
Share on other sites

Would it be possible to see shell casing collision? Just a colliderbox, no convex hull or something. Maybe even with settings how long they gonna stay on the ground? That would be really cool.

By the way, I LOVE the new radartrack function for the TGP

Edited by Themorris
Link to comment
Share on other sites

and you should get something that will work with the current targeting system.

Actually, I'm fairly sure the AI will never use HEKV missiles even with the config file additions, it's an RCS missile and the weapon selection algorithm doesn't include them, or didn't when I last checked. My temporary fix was to add HEKVs to SwitchToAirMissile(), but it never made it to the official version. Missiles use radar by default, so you could probably fire them manually without changing the config file, but the AI won't use them unless you recompile the dll with the fixes.

I'd love to just point you at a fixed dll, but I'm having some issues logging into my desktop at the moment. Ubuntu somehow broke and left me with an infinite login loop, and I've always had an issue where I can't actually see anything when using the terminal only mode to fix things, so I'm typing in commands blindly and hoping it works. If you feel like compiling the fix yourself, you'll find the code on my fork. If not, you can either wait for Baha's official fix or me to either fix my Ubuntu or decide to do it on my laptop instead.

Edited by Yski
Link to comment
Share on other sites

Actually, I'm fairly sure the AI will never use HEKV missiles even with the config file additions... Missiles use radar by default, so you could probably fire them manually without changing the config file, but the AI won't use them unless you recompile the dll with the fixes.

I was unaware of that, which is why I threw in some caveats as to the solution I proposed. As for the AI, that's something I imagine is way, way off... but I wouldn't mind seeing a configurable AI based around ROE criteria.

If you feel like compiling the fix yourself, you'll find the code on my fork.

I sorta laughed at that because I had just finished watching Hannibal and software development wasn't the first thing that popped into my mind... anyhow, I am just a humble creative-type who happened to stumble onto BDA and thought my knowledge of sensor and weapons systems could be put to use. Compiling stuff is beyond me at the moment, as right now the closest I'm getting to programming is trying to figure out how to get an attachment node to move with an animated part without requiring IR (highly unlikely :mad:) and how to rig the cargo bay aero occlusion thing so I can make this:

YnswqWr.gif

so that people can, without paying an aerodynamic penalty, nor having to disable the clearance check to get the missiles to work, make planes like this:

PuoKlAt.jpg

Yeah, I know, "good luck with that" lol. I may overreached with those bays... I probably should have stuck to just making radars, missiles and guns.

Link to comment
Share on other sites

i was unaware of that, which is why i threw in some caveats as to the solution i proposed. As for the ai, that's something i imagine is way, way off... But i wouldn't mind seeing a configurable ai based around roe criteria.

I sorta laughed at that because i had just finished watching hannibal and software development wasn't the first thing that popped into my mind... Anyhow, i am just a humble creative-type who happened to stumble onto bda and thought my knowledge of sensor and weapons systems could be put to use. Compiling stuff is beyond me at the moment, as right now the closest i'm getting to programming is trying to figure out how to get an attachment node to move with an animated part without requiring ir (highly unlikely :mad:) and how to rig the cargo bay aero occlusion thing so i can make this:

http://i.imgur.com/ynswqwr.gif

so that people can, without paying an aerodynamic penalty, nor having to disable the clearance check to get the missiles to work, make planes like this:

http://i.imgur.com/puoklat.jpg

yeah, i know, "good luck with that" lol. I may overreached with those bays... I probably should have stuck to just making radars, missiles and guns.

oh my god yes

- - - Updated - - -

On another note, the Mk82 bomb, and Mk82 Snakeye, seem to be incompatible with FAR....they always cause my craft to have it's lift calculated for only the root part.

Link to comment
Share on other sites

With GPS now implemented, the tools are coming into place for AI auto-landing.

The AI would need:

- a GPS coordinate for ideal landing spot,

- heading so it approaches from the right direction (aligned with runway),

- a tweakable glide slope, and

- tweakable ideal landing speed (so it can cut throttle and/or deploy brakes to achieve desired approach speed).

A button to lock current position and heading for the first two would be handy also.

Other useful options:

- desired timer from last enemy contact until landing begins.

- cruise speed for circling behaviour when no enemy in contact (saves fuel)

I've previously suggested ways to allow AI to fly VTOLs by swapping pitch and throttle response to control altitude and speed.

Planes gain altitude by pitching up, VTOLs by increasing thrust or collective. Planes gain speed by increasing thrust, VTOLs by pitching down.

VTOL mode would enable yaw steering control.

Tweakable roll and pitch limiters would be useful for both helicopters and non-aerobatic planes.

Landing AI for VTOLs would then be trivial - just reduce landing speed to a small number.

Having VTOL / HTOL behaviour toggle on an action group bound to gear allows AI to switch between the two; vertical takeoff with horizontal flight (a jump jet) or horizontal take off and VTOL type flight (e.g. some kind of jet assisted helicopter)

This way, we have to design our VTOLs around BDA instead of BDA having to cater to us.

Edited by colmo
Link to comment
Share on other sites

With GPS now implemented, the tools are coming into place for AI auto-landing.

This is veering off topic a bit, but. There are some useful mods to control autolanding of planes like Mechjeb. Also there are mods to control relative position as well as vertical height for VTOL's like Horizontal Landing Aid and Vertical Velocity Control. I use a combination of those three for all my videos involving landings.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...