Alioth81

Hilarious @ 8:42 I love those flying wing battles Thank you so much for running those and the tournament @SuicidalInsanity

I like the turn fighting but watching all those near mid air collisions like the one at 3:02 are a bit nerve wracking. I think the AL-18 probably was more often rammed successfully than actually shot down. Probably at least one AL-18 in every round died due to this. One a side note where is the like button? @SuicidalInsanity I think I found a way to fix the destuction effects "bug" where the whole plane goes up in flames. As I have no clue how to properly fix it with git hub etc. I posted my suggested fix here: I am not sure how often the mod is updated so you might consider using a local patched copy and check if it works for you and those nice videos :-)

@jrodriguez and @linuxgurugamer First thanks for your update! For the real BDAc experience this mod is really essential for me and I had to delete it because it did not work properly. When I tried the new version with BDAc I still got unwanted effects with autostruts however. Therefore I tried to modify the code. I am no programmer and do not know how to do it properly in code but also with github checkin etc. and I am sure my programming changes look crude to you but it works locally for me and I thought it could be of interest for others. Maybe you could integrate my suggestions or get inspiration for a proper fix that also solves the problem with BDAc installed? There were 3 problems (for me) in the latest version: 1. Autostruts enable/disable cause massive inferno with BDAc (also any restrutting due to an explosion of a part) --> As there is no indication in the partjoint if the joint is an autostrut (linuxgurugamer used the breakforce == 0 which does not work if the connection is dissolved by an exploding part) you basically have to check if the joint goes to a parent. However once the "Jointbreak" event occurs the connection is already dissolved. Therefore I added a function on the "onPartWillDie" during which the parent of the part going to die is still available and I put the info into a list. I then expanded the onJointbreak to check if the parts in the joint break are also in the list with dead parts and their parents. 2. If a middle part explodes there will be at least 2 joints that break. Once the "Host" of the joint break is destroyed and the target should get the flames (this is typically the main body) and once the target is destroyed and the host should get the flames (example would be the outer part of a wing that falls of when the middle part is destroyed). The second case could lead to an exception as it tries to attach flames to a part that is destroyed. --> I added a check to see if the target of the joint break is in the list of destroyed parts and if it is attach flames to the host. Added benefit you get now a lot of burning parts if the ship is shot apart 3. Many parts would not get flames attached because their names wer not included in the list or spelled with lower case. (e.g. "wing", "tail", cockpit", structural procedural, cone etc.) --> I changed the function so that upper case lower case should not matter anymore and added some items Below is my version of flamingjoints.cs (with some comments to show what and why I changed it, those can be deleted). Edit: I updated the code so that also in case the root part is destroyed flames are attached to the break away parts (only if the root part is a part that otherwise should have gotten flames attached).

Looks like a fight in slow motion Does any one know what determines if a plane is torn apart during a ramming? Is it the wing strength you can set in FAR? @SuicidalInsanity Did you change the 30mm tracers? i do not see any lasers

I thought about @OmegaForce who seems to have a working flying wing too. I believe it would be even better with 30mm guns (or at least the battle would be over sooner. I did not try the 23mm but all the other guns in my opinion need to many hits for a kill. However as the 30mm ballistics are so different you cannot pair it well with smaller guns which are good to force evasive maneuvers.

The AL-18 seems to have a weird tendency to always get hit first during the initial merge of the engagement and then tries to make a comeback from there. It also seems to loose all its ramming incidents. It is not even set to reckless ;-) It would be interesting to see at what speeds the engagements take place. If I get some time I want to to look if I can change the behavior of AI trying to turn via a looping which is probably one the worst things you can do in a dogfight. @Me1_base What mod do you use to have pro-grade/attitude markers projected into the scene? @SuicidalInsanity My favorite plane is your IA-34 VIII because it motivated me to build my own copy which was fun. I am in total agreement with @OmegaForce so I do not need to write a long text. In addition this building exercise motivated me to understand this adverse yaw effect which will benefit my future designs with elevons like Delta wings or highly swept wings. Can we have a battle of the flying wings in the end? At least 3 people seem to have one :-)

Here is my pure flying wing design. The AL-23-Boomerang a Ho-229 look a like. 20x30mm and according to the challenge rules but optimized for design. I took @SuicidalInsanity recommendations, some online research and a lot of trial and error (also from past failed tries) Although it is probably not competitive I am extremely proud of the design and it flies much better manually than any flying wing I designed so far If you manage to take off (either hit SAS or pull back the stick once over 40 m/s) it flies much better than I expected. It took some tuning but now the BD AI can handle it as well. My general advice for flying wings: Problem 1: Sideslip and yaw stability (less of a Problem once you get the basics) Basically once you get some yaw it has tendency to worsen or oscillates around your prograde vector CoM as far to the front as possible (this way you can get away with moderate sweep). Normally in regular designs I had CoM very close to the center of lift for best maneuverability but this did not work well (they are still fairly close however). Some Sweep is required however but less than expected especially once over a certain speed. Split ailerons for brakes rudders as far out and/or back as possible Cross sectional area should peak behind CoM Problem 2: Adverse yaw (much bigger problem especially when pitching and rolling simultaneously) 2.a Basically when you roll it yaws against the direction you roll (the wing that raises up in the roll creates more drag ->roll right [clockwise] it will yaw to left) Solved by giving the ailerons a bit negative incidence also solved by giving the outer wing (where the ailerons are) some wash out. Result is that the ailerons on the downward turning wing (which are deflecting upwards) have more relative deflection against the airflow and thus create more drag to compensate the higher drag on the upward moving wing (where the ailerons deflect downwards and create less drag relative to the airflow). 2.b. Very very bad adverse yaw when you roll and pitch at the same time. This will multiply the problem 2.a. by a lot (I think this is the banking turn @SuicidalInsanity mentioned). Roll right, pitch up --> yaw to left Solved by ensuring all roll components also have a pitch part mixed in (elevons) theory is same as in adverse yaw but the additional pitch component makes sure that the side that is rolling downwards (and deflects upwards) deflects even more upwards thanks to the pitch component and creates more drag to compensate the hard adverse yaw (on the other side the downward deflection of the ailerons for the roll is compensated by a upwards deflection due to pitch input to create less drag). you basically have to tune the mix of pitch and yaw in the elevons to get an ideal point where the drag difference in a "banking turn" is compensated (together it should add up to 100%) this took quiet some trial and error and is still not perfect but now manageable for the AI. In fact I believe this is one of the biggest problems why the AI could not handle flying wings as it likes to fully deflect pitch and roll together 3. Once you optimized the plane for those problems: Fine-tune the innermost elevons or elevators so that you get a level flight without to much pitch control Input. Typically you have to deflect them downwards to create a pitch down moment because the outer ailerons are probably deflected upwards because of wash out or incidence you set to compensate adverse yaw). edit added a short video of the Boomerang in action

@SuicidalInsanity I have some time this evening and even if it takes me past midnight I will rework my flying wing and then challenge yours (outside the competition) I thought a flying wing and BDAc AI within this setting will never work and gave up - you inspire me to pick up where I stopped... it already has the looks but it just doesn't like to fly. I will share it (however good or bad) it will be

As I attached wings to other wings and not the main body the inner wing part gets a lot of stress it seems. As the AL-21 has so much wing area I could not reinforce past a certain strength. If you make the wings stronger but also heavier it means more force on the inner wing part (and as the outermost wings are fully movable they had to had a certain strength) It was just pure experimental observation that the wings would fall apart as soon as it would fully pitch and try to roll at high speed.

I think at least 2 of the L-19 losses were structural failures. Regarding agility. It could turn harder but it bleeds too much energy. Thanks to the 3×30mm it has very weak engines so it cannot afford too crazy maneuvers. I would need two steer limiters. One for low and one for high speed Also structurally the long wings had problens at high G The strategy here was to have a stable plane with a lot of fire power and redundant systems. I am a bit worried that it wastes too much ammo. I tested also against very slow planes only. The other entry is a bit more agile

Some general thoughts about the challenge First of all I think this one is really great and I enjoyed spending quite some time to get it done and I will love to watch the videos. I also love the advanced settings of this BD Armory version (but I know @SuicidalInsanity had beautiful icons for team A and B in a version. Where are they?) Some engines have not ideal point values. If you consider the available guns that are most likely used there are some frequent combinations like 60 points (2x 30mm, 3x 20mm, 5x 12mm) leaving 40/60/90 points for engines or 90 points (3x 30mm, 6x 15mm) leaving 60 or 30 points. or 80 points (4x 20mm, 2x 40mm) leaving 20/40/70 points. This means engines like the the Nibelung and Geist with 36 points are difficult to use and combine - making it slightly weaker and 35 point would make them suddenly more attractive The same goes for Kobold and Gremlin which could be 30 and the Phantom at 45 (or some engines could cover combinations with 23mm and 13mm). Also spare points could be used to reduce weight (e.g. 25kg per point or whatever is balanced). I know it is probably not important but I felt an intrinsic urge to use up the point budget Additionally I think it would be great to add a new cockpit part with an MM patch that is significantly lighter with resources and reaction wheels patched out (e.g. 300kg). I would prefer to use a modified inline cockpit because I enjoy flying my planes in first person and it would make for some great videos. But the weight benefit of a constructed cockpit especially for light fighters is enormous. If someone manages to get the G-force limit in BD-Armory to work I would prefer to fly with GLOC as this would be beneficial for the faster less agile fighters. Currently you can create fighters that turn with huge G-numbers Now something very low priority: no autostruts, only rigid attachment - with autostruts the destruction effects mods has some weird flame effects @Noir regarding performance I use the mod memgraph - it has a shortcut "ALT +End" on that increases the memory heap and reduces stutter on my system quite a lot . If you use the adjustable landing gears try to use a file with this content to patch in your gamedata folder @PART[KF-ALG*]:Final { !MODULE[KSPWheelMotor] {} } it removes the motor aspects of the wheel which can lead to stutter Less parts are also good

Some background to my designs also some reasoning why they look this way. The light fighter AL-18-Swift was a quick design inspired by the He 162 as a low part count agile fighter with 2x 30mm Cheap procedural parts caused quite some problems during manufacturing The 2nd entry was a challenge - My flyingwing design which was supposed to look like the Ho-228 failed, mainly because the AI completely mishandled the yaw aspects. In general I think the AI uses yaw not ideally in fights and I would love to set the PID values individually but not sure it would help. The I tried a fast design that started like a Mirage III and ended looking like a Eurofighter - it was simply not fast enough compared to the agile AL-18 an tore itself apart after Mach 1. Often it would overshoot the agile AL-18 and get shot down immediately. Finally I settled for big tandem wing design: the heavy AL-21-Dragonfly inspired by the French WWII prototype aircraft Arsenal-Delanne 10 but with jets and 3x30mm guns. Very agile, trigger happy, surprisingly robust but underpowered. To get it stable I had to add a lot of tail fins - as like the flying wing it doesn't really have a tail. The part count was inflated because I could not really use the procedural parts and used many empty Mk0 tanks. It does not reach super high speeds but thanks to its low wing loading it does not loose to much speed either - even in high G turns

Does anyone know a workaround how procedural parts can be used despite the bug with the vanishing/moving nodes? e.g. does it only happen when certain parts are attached or certain shapes are selected?

I have problems with the procedural parts mods where attachment nodes suddenly go missing after a reload (meaning a stable plane is suddenly unstable). How do you deal with that it seems to be a known issue so maybe there are workarounds? I think the procedural nose cone is less susceptible to that but it also happens, but just not always. It would be sad to submit a plane just to see it disintegrate at the first high G turn.

I try to build something for this competition. But I have some problems with procedural wings or FAR linked here. It seems the main wings sometimes loose their Voxels. Did someone ever experience the same? If yes what did you do? Edit: It seems updating to FAR 15.10.1 does the job - the link in the rules points to 15.10.0 however. Additional question? Are Autostruts allowed or just rigid attachment?

@Gordon Fecyk No it is just a simple blue bubble with no arrow (it has a FAR module and the stock lifting surfaces are disabled/patched out.) I think I found out part of the problem. FAR seems to calculate the surface in the wrong direction - the surface area is the area of a circle related to the diameter of the "tubes" e.g. fueltanks, This can be easily shown also with stock parts. If you connect 2 fuel tanks behind each other the surface area will be that of one tank. However if you place them side by side you get the area of to circles and if you clip them into each other a fraction of it. Edit:interesting fact as soon as you add the first wing it seems that the values of "body parts" are disregarded.

Question for the FAR experts. I was under the assumption that FAR is based on shape (so it does take clipping thing into each other into account). I created an aircraft in FAR with procedural parts and wings (see image below) When I check the debug voxels it seems to recognize the shape and my general feeling is that it does do this also in flight. However when I check the calculation tab the numbers seem to be not correct. (e.g. adding structural parts like tubes does not change the wing area in square meters and also moving a wing into a structural part or cockpit (clipping) seems to have no effect. Changing the procedural wing size however does have an effect. My question: Is the displayed calculation wrong and the plane is actually affected in flight (my personal guess at least drag seems to depend on shape)? Or is FAR ignoring some parts and clipping of parts into each other for some behavior (e.g. lift of a part?)?

Thanks for the answer @Shadowmage I thought that their texture switching would probably interfere but I hoped for an easy way out @pap1723 You have some beautiful textures - I just tried quick and dirty if it is easily doable with a simple MM configuration and as I am not really a programmer it ends here for me. You currently use your side textures also for the end caps. if you add an excludeMesh = ends it will use the PP parts texture or you create also nice looking end caps. If you are fast at creating also the procedural wings could use some TU textures However I think you will face the same problems I had and the textures will not be persistent once you go to the flight scene. It would probably be best if the maintainers of the procedural parts/wings would integrate a MM configurable switch to disable their texture switching/handling system but i have no idea how easy that is.

Is it possible to influence the order in which textures are overwritten so that TU is last? I tried to make this work for the procedural parts mod for 1.5.1 In the same way TURD does it for Stock parts. Basically it works in the VAB and you can switch textures and use the repaint Ui Once you load the flight scene it reverts to the last selected procedural parts texture. If the texture config file of procedural parts is deleted. The switched and colored TU texture stays also in the flight scene as the orocedural parts mod thinks there is no texture available. So it overwrites the TU textures.

@aleksey444 and others who want to download it. Here is the link to the Reefshark https://kerbalx.com/Alioth81/AL-11-Reefshark let me know what you think. it is underpowered but accurate once it can point its guns at a target. What I do not understand is how the missiles work. Often they explode after a few hundered meters (target loss?). And sometimes they are just fired without target lock often resulting in targeting the wrong (an own plane) or just flying into the sky. @SuicidalInsanity Thanks for the explanation I will try it out

@SuicidalInsanity Thanks so much for this updated version :-) To celebrate it I created my first true YouTube video a showcase between your Fishtank and my Reefshark (they were meant to fight each other based on names alone). I had to replace the front landing gear of the Fishtank with the double wheel as it went off course with its single wheel during take off and allowed full steering with some offsets at high speed with the advanced parameters. The reefshark was supposed to be my original entry but it rammed itself into the ground all the time. (It still does but I can fine tune that now I believe and I will upload it to KerbalX when a bit polished). As I love your FAR tutorial. Can you also explain how to use the simulation tab? I get the other three but this is a mystery to me.

I had some time to look at the AI of BDAc and although I am not a programmer I tried to make it easier so that the AI does not pull the plane into black out or disintegration at high speeds. The idea was to leave everything as it was and just add a check to gradually reduce max control input above a certain speed. For this I added two more settings in the AI autopilot. "Corner Speed" (for lack of a better name) and "Steer Limit At Max Speed" Basically the behavior until "Corner Speed" is the same as before and it will fully pull the stick back However between "Corner Speed" and "Max speed" it will reduce control input in a linear fashion until it reaches the value defined at "Steer Limit At Max Speed" at the speed "Max speed" (beyond that the reduction will continue in the same linear fashion until 0.05 which is the true minimum) It is not a perfect solution but it works better for me than the limit G force slider. The default setting for "Steer Limit At Max Speed" is 1 therefore no plane will be affected except if someone truly changes something. Maybe someone like @SuicidalInsanity can integrate that into the beautiful custom version? (if others want to use it) Of course if people have better ideas and want to improve it feel free to do whatever you want I added the code I changed in BDmodulePilotAI.cs below

I am surprised that the Piglet is doing that good. I just checked my plane again and found its main gun (around which the whole plane is designed) to be significantly off axis... Kerbal engineering at its peek :-) So on my PC Piglet Bs are killing their predecessors. I have to say I am surprised how many 30mm hits a plane can take. I assumed that a single hit should be devastating so maybe Vulcans are the better choice. I am eagerly waiting for super sonic plane designs to see how it is done. I tried to design a fast plane before i submitted the piglet and although it made 400 m/s I just could not handle all the g-force issues that arise at that speed with my design. Many brave Kerbals either knocked themselves out due to G-force or were diving the plane into the ground because of lacking maneuverability. Is there a way to limit/alter control surface response based on speed? AoA% limits its performance at low speed quite a lot. How do you do it? As alternative how does the BDAc G-limit work? It does not seem to be active in a lot of situations (evasion and pull out below min alt at least).

What kind of issue are you referring to? Im using an older adjustable landing gear but with the latest ksp wheels mod. It seems ok but as i do not use motors on those plans i could add your patch. In my opinion the stutter must involve something with what BDAc uses or does just after "competition starts" . take off normally causes no or less stutter. I also use memgraph and as that decreases the problem it could be garbage collection. I am still on 1.5 By the way what do you mean by ripple fire?

Here is my try with the K-10 Piglet https://kerbalx.com/Alioth81/K-10-Piglet If someone could tell how to set the G-force limits in BDAc so that the pilot actually respects them that would be great. I had to add a lot of AoA% but and it seems to work but sometimes especially when diving towards ground Jeb pulls the stick too hard.