Papa_Joe

Congratz on the Alpha release. Been an adventure watching this develop! Cudos to you!

Been pretty consumed with BDAc updates and work, but I'm willing to work with folks on it. Whitecat is not gone, so he may be available for consultation. It was mainly the support I took over, and @Whitecat106 is certainly welcome in the mix

Hello everyone! It is that time again. Your feedback and our team have been busy. Here is a new release. Change log: v1.2.2.2 * Recompiled for KSP 1.4.5 * FIXES *Error spam in Log when a radar is destroyed. An orphaned index was not properly being updated. Reported in BDAc Forum post: https://forum.kerbalspaceprogram.com/index.php?/topic/155014-14x-bdarmory-continued-v1221-7102018-vessel-mover-camera-tools-bdmk22-destruction-effects-burn-together/&do=findComment&comment=3425233 Thanks to greydragon70 for his thoughtful evaluation of BDac and issue reporting. * Corrected an error where high speed missiles would sometimes not detonate in the correct location. * ENHANCEMENTS: * Increased maximum allowable missles per target to 18, up from 6. * Added EMP Module. Now Electromagnetic pulses exist in game that can disable electronics within the blast range. * Added 2 new EMP equipped missiles HellFire EMP, and AIM-120 EMP. Small pulse radius but demonstrates the feature. * Added 3 different sized EMP pulse FX, allows for additional sized pulse weapons. * Added Reloadable Missile Rail (ModuleMissileRearm. Now missile launchers can be reloadable! This module can be added to missile launcher designs to allow reloading. (code used with permission courtesy of @flywyx). Requires unity based modifications, normal rails will not function as reloadable unless additional transforms are added. * Added new standard resource High Explosive. Provides better matching of tntMass for balance. * Added an Ammo switcher feature (no more Firespitter required) * Added new Universal Ammo Box part that uses the new Ammo switcher feature. Old part remains for backawards compatability. Use the new part going forward. To remove the need for FireSpitter, replace existing Ammo Box parts with the new part on existing craft. * Improved sub categories for BDA parts. This helps with the clutter in the Editor under the BDA category. * Removed BDACategoryModule as a result of the BDA categories refactor. Existing craft may see a module not found warnings in the log. This will have no ill effects and can be safely ignored. * Improved smoke effects for smoke canister launchers * Added new Jet engine based on the J-404. Licensed from KTech. (Thanks @TheKurgan, @SpannerMonkey(SMCE) & @XOC2008!) * Added new BDAc Test Drone MKIII craft, utilizing the new engine. * Added engagement rules to all missiles NOTE: There has been a long standing issue with guns accuracy and the AI. Seem when the AI fIres, it can't hit the broad side of a barn (OK, it can if the barn jumps in front of it, but not intentionally.) As was reported and well characterized by @greydragon70 (Thanks) and many others (thanks as well!). we are taking a deep look at this issue. Based on our rather extensive testing, this problem was introduced some time around version 1.0 or 1.1. We are working on narrowing it down, but that is going back quite a ways. I just wanted everyone to know we are taking a hard look at this as we realize it is an unacceptable condition. More news will follow, but we wanted to get this latest change out so we could focus on this issue.

Go to https://www.github.com/papajoessoup/bdarmory/releases There you can find all releases for bdarmory Edit:. Ninja'd. Lol

I understand your dilemma. I think it is important to explain the roles of each type of weapon and how it affects armor and health. Forgive my wall of text, and you may already be fully aware of this, but it needs to be said for the benefit of those that follow this thread and use BDAc. Armor piercing rounds are designed to "cut through" armor and a part. They do this using a couple of methods. One is a hardened tip and projectile shape, to minimize friction and spread the armor material to allow entry into the interior of the vessel. The other is using a hot plasma jet to literally melt a hole in the armor to allow penetration. If the projectile penetrates the armor, the explosive force of the resulting blast is NOT transferred to the Armor part or the part armor is attached to (in the case of reactive armor for example). it is designed to destroy the interior contents of what has been armored to protect against damage. So the damage to an armored part upon penetration is minimal. IRL, there would be a hole, but the remaining armor would work just as effectively on the next shot as it did on the first, so the HP value does not decrease as much. If you have no internal contents to protect against, then why use armor, and why use AP to attack a "soft" target? So if you use armor, you are are trying to protect the interior of a vessel which be definition means you have something inside the vessel that needs protecting. Now most earlier designs of craft in KSP did not concern themselves with "internal parts". KSP is by design a simplified view of rocket and plane building. BDA has greatly expanded the design requirements of vessels to better simulate "real world" effects of damage. What this means is that the design of your vessels will now need to take into account internal features that you wish to protect. Making a tin can with nothing in it will not result in an epic battle. HE is a different beast. It uses an explosive force (shock wave) to cause damage. This is a brute force approach, and nothing is immune to its effects. With a sufficiently large HE blast, a Tank can be "flattened" Welds break, armor "spalls" (layers of the Armor's metal split and fly around), and the occupants of an armored vessel can be killed simply from the blast wave. However, with light weapons, HE has minimal effect on an armored vehicle. this is where the balance issues come in. If you have no penetration and a very small blast on the exterior of an armored vehicle, what do you do? There will be some small amount of damage done, and that will wear away the armor a little bit at a time. So the current model still allows for that. With high rate of fire weapons, the attempt at balance starts to break down. In fact the challenge for us had always been how to properly model small arms vs high caliber weapons and missiles using the same damage model and still get good results... Something needs to be done here, clearly. Now for the next part of this response. The BDAc damage model has evolved from the original heat based model to a more realistic penetration and damage model. This was a significant change, that altered the way the damage was measured, monitored and caused. In the old model, when a part got hot enough, it exploded. now that is gone. Heat can still cause an explosion, but usually it is due to any fires that result from fuel burning. Instead we now use Hit points, (or health points) to determine when a part is destroyed. This new model required a different way to calculate the "toughness" of a part. We spent a lot of time trying to balance this against the wide variety of weapons available to the community. We created an algorithm to calculate the hit points of any given part based on surface area and mass. However it is not perfect, and we also allowed for the community to create their own armor and hit point values in an effort to allow for better control and playability. Since its inception, we have seen the results, and have been watching the community's responses. We are now going through a refactor of the damage model using the lessons learned from play and from the community. It is our hope that this revision will result in a more playable battle, and better balance with the weapons you have at your disposal. That effort is nearing completion, but a lot of play testing and re-balancing will be needed to "get it right". Since we have weapon mod developers as part of the team, we get a lot of valuable feedback on balance, usability and playability during the test and evaluation phase of a feature's development. I hope this is helpful to folks in some way, and rest assured we are tirelessly working on making BDAc the best it can be, to the best of our abilities.

I think there may be a disconnect here. The current design of armor is to prevent penetration of an armor piercing round. HE is a shock wave effect. HP is the only defense against HE. Even heavy armor will not stop a part from receiving damage. It can slow it down, but not prevent it. This is baked into the code of BDAc. So I'm not sure how changing the Armor values will net the result you desire.. However, I don't see any problem in experimentation... You can accomplish what you desire using the MM config examples that @TheKurgan provided as an example and starting point. Also the Module Manager wiki explains how to create configs that will accomplish what you desire.

@SpannerMonkey(smce) Noted a recurring error in the logs related to the radar. I've located the issue and hopefully addressed the log spam. This fix will be forthcoming in the next release

It has always been possible to kill the KSP session without losing your game save data. That has not changed. If you go through the menu system to exit the game it will save the changes... so just force kill the app. Edit: In light of JPLRepo's response, killing the app is no longer necessary

I have performed a cursory check of the mod with KSP 1.4.5 It seems to be working, and does not throw any errors that I can see. Give it a whirl.... I cannot vouch for any other BDA associated mods however.

As @DoctorDavinci, the team spent quite a bit of time looking over this issue. I'm now looking at it as well, hoping my noobness to shaders might allow me some accidental insight into the cause. At the very least it will be educational for me.

@Hojoz, I appreciate your response. While a video could be helpful, so much is not shown that may be of value. For example, during the design of the craft, radar selection matters. If you test against one radar, and the engaging craft uses another, then the conclusions you have drawn from your tests in the editor are invalid, and could not be determined in a video of the engagement. The logs are generally useful. They tell us what mods are installed, and any errors that may be occurring. This is particularly useful when trying to determine why something is causing errors. In the case of unexpected behavior, where everything is working, but not "reacting" as expected is more difficult. Since likely no errors are being generated, then we must resort to other means to determine why. Behavioral problems are more related to conditions, so then the value of a test save and the craft files are more helpful. As far as the flak, as a general rule it is always best to be respectful when discussing your issues. I will be the first to admit that some of my team members can be "thinner skinned" than others. I do remind them of their attitudes and I will not defend their actions. But they are very proud of their work, and care a lot about the quality of BDAc and the associated mods that use BDAc as a basis. You can defuse the situation by making sure of your facts, and presenting them as a problem to be solved, as opposed to "your mod is broke". I will say no more about the issue and we can continue forward to determine if there is in fact a problem that needs to be solved. So, go back to your design, examine the RCS closely, and see if you are understanding how it functions. Since most of BDAc emulates the real life behavior of weapons and radars, some research online can be helpful to understanding the capabilities and limitations of the weapons and radars used in game. Hope that helps some. Happy gaming!

If I'm not mistaken (i will check) I think there are options for greater fidelity. Ah. I see that the options to turn on or off things like bullet hits, shell ejections, bullet hole decals exist, but not the density. those may have been hard coded. Also in flight flame fx have been disabled due to performance. We can add a setting to allow you to turn those on as well. I will look into that. If you really want to bring your machine to its knees, we can accommodate you .

Yes, from frame to frame it will be the actual cross section presented to the radar (LOS) at the moment of calculation. so if you are in a hard bank and present your belly, your chance of being detected goes up markedly. if you take care to present a minimal cross section, your chances of detection are reduced.

Lasers behave a bit differently, as the ballistic curve is flat and there is no reduction in velocity due to drag. the impact is treated like a ballistic impact with a mass equivelent and high velocity. So there will be penetration based on this. It dos not use heat, which would seem counterintuitive, but it is a game and for the sake of game play, some compromises are made. In the editor, the RCS calculations are made on the vessel design based on the parts assembled. if you change parts, it is re-rendered, but it only accounts for the profiles for full front, side, and bottom/top. SO any angles in between these transform positions are not calculated. You cannot rotate the vessel to see all possible angles. In combat, the calculations for detection use the same formulas but do not require the rendering process, so they can be performed in more "real time" to allow for instantaneous detection (frame to frame).

Instantaneous calculations is something we considered, but rendering the RCS images was too intensive for performance purposes. So a compromise was struck. Many changes were made to configs on most BDA parts and other BDAc parts packs as well. So the recommendation is to ensure your vessels won't break BDAc, and utilize the new damage model and ballistic characteristics. Many of the legacy config parameters are no longer relevant and new ones were introduced. We considered backwards compatibility, but in the end it is sometimes necessary to "break with the old" to allow progress going forward.

So, let me see if I can sift through the noise and the "chaff". You have a slow moving aircraft that is supposed to be low observable (RCS shows 2 km lock on full frontal). Is that correct? You have a radar lock occurring at 8 km, and the AIM-120 is engaging. Is the radar used on the engaging aircraft the same as the radar selected in the RCS analysis? Is the engagement occurring at exactly 0 degrees? You state flares have no effect and you are reluctant to use them. Okay, a radar guided missile will not be fooled by a flare. Chaff would be the better choice, and then only when the missile is fairly close and you are maneuvering to avoid said missile. Slow moving aircraft, may be more maneuverable, but lack the speed to fly far enough away from the missile to escape, even with perfect deployment of chaff. For a general rule of thumb, battles are a very dynamic beast. The aids we provide for craft development are just that. Aids. The RCS values are evaluated in a static environment, and aircraft are in actuality never perfectly presenting themselves in the way the static test would evaluate. So, most certainly your actual results will vary. In the end, no matter the aircraft design, it must be flown well to avoid the weapons. I don't know your experience level, but at least I know that you know how to obtain the logs. Based on your description, the logs will not aid us in determining what (if any) issue exists. Lock on range may or may not be correct (I would never rule out the possibility of a bug or error), but it would require a very controlled test to determine if the issue exists. I recommend you set up such a test to demonstrate your issue. Then provide a save game with the crafts involved, and proper steps to reproduce. Then we might be able to assist you with the lock on issue you may be having.

You are of course correct that the miniavc checked online when it was maintained by cybutek. however, since linuxgurugamer took over maintenance of KSP-AVC I believe he disabled that feature. So updating the local file should correct it. I just performed a test on my local install and it works as I described.

The cause is the .version file that is included with the mod. Since the last time it was updated was KSP 1.4.1, the version file reflects that version of KSP. KSP-AVC is the mod checking that file to determine if the mod is out of date. If the mod works in later versions (as they often do), then the mod author (linuxgurugamer in this case) will not bother to update the mod as there is no compelling reason to do so. Given that linuxgurugamer is supporting over 140 mods, I suspect that a working mod is very low on his priority list. I would just ignore the warning for now. If you really don't want to see it and you are brave, you can update the .version file that came with the mod From: "KSP_VERSION_MAX": { "MAJOR":1, "MINOR":4, "PATCH":1 } To: "KSP_VERSION_MAX": { "MAJOR":1, "MINOR":4, "PATCH":4 } If you do not see this entry in the file, just add it before the very last "}" in the file. This is not necessarily true. Since many mods include this file, you will likely find multiple copies in your KSP install. It can be quite tedious to try to locate them all if you have a lot of mods installed. Therefore the best solution is the one I described above

Yes. penetration is based on kinetic energy, angle of entry, and armor thickness. An angled plate presents a greater distance to travel, and is accounted for in the algorithms used. As much as is possible within the game framework we used real world penetration calculations to determine force, ricochet, and penetration. Modules are also considered when penetration occurs. Modules (such as fuel, batteries, etc) can be damaged and or ignite fires. In fact, this presents a problem. If you design a craft, with no internal parts and paper thin armor, an armor piercing shell will travel right through the vessel with very little damage caused. for many stock designed aircraft and ships, this means it does not seem to behave realistically, when in fact it is very realistic. So for best results with the new ballistics and damage model, you should design your craft to contain internal parts that can be subject to damage. If you look at SM Marine parts you will see examples of such designs. They are spectacular to watch when they are attacked. So, the takeaway from this is: craft design will greatly affect the results you get. the more effort you put into your designs, the better the battle will look and feel.

To add to this, ensure that the version of KSP matches the KSP version expected by Kopernicus. Finally the on load section of the log will shed some light o what might be happening. without seeing the mod code is it difficult to determine what might be happening, but looking at the logs will help.

Under normal circumstances it is not an issue. There are a few mods that are version locked (Kerbal Kostructs RSS/RO, and a few others), but the major changes occurred in KSP version 1.4. If you have backed up your save file, it is likely safe to install the new version (1.4.4) I would recommend backing up your old game version just in case you run into problems and want to revert to the earlier version.

I'm not completely sure what you mean by "hits the ground" if you are talking about the marks on the ground for kicking up dirt and leaving a gouge, then no. Decals can be placed on game objects like parts, but not on the planetary body. Technically there is a way to accomplish it like footprints, but the effort involved is not worth the result, and there is a performance hit associated with it, much like there is with decals. KSP has multiple texture resolutions, and the Planetary body resolutions changes as well. This means that small fluctuations in altitude of the ground occur, and must be accounted for at each resolution. The code gets messy fast. As for the 20mm vs 30mm decals, why? what is your concern with the 20mm decal?

Yes. in the OP is a link to the source. PapaJoesSoup is the git account. For your convenience: https://github.com/PapaJoesSoup/OrbitalDecay Note that it also uses Solar cycle simulator found here: https://github.com/PapaJoesSoup/SolarCycleSimulator Let me know what you might need and I can expose it if it is not already available, or create a specific method for what data you might need.

The BDAc team has reached out to @tetryds to inquire about assuming support for this mod. Given that portions of the code are based on BDA, and the fact that we are now maintaining a range of BDA based mods with permission, it makes sense that we should assume continuing support. As soon as we hear back from @tetryds (assuming he approves) we will be releasing a KSP 1.4.x compatible version.

Mike, I'm sorry I missed this post. SM has a vessel to vessel transfer feature. Trucks docked to your fueling station will appear as separate vessels, allowing you to fill all the tanks in the truck at one time.