Slight quality of life improvments

Expanded range of sliders to a rediculous amount for late war jets and added an over-drift warning.

Minor angle of attack now occurs 1/5th of the set AoA on the slider and AoA slider indicates actual stalling angle again.

Also sorry no file saving this patch because system32.io.updown.updownupdown.lists.arraylists is too bullshit for me to work with and it turns out C# doesn't work with multi-datatype lists so I'll have to string it first and im too lazy for that. Sorry.

update 11/4/2020: Sorry I forgot to upload the fix for the april fools easter egg. It's done now (version 1.4b)

OverSpeed warning added. More assets.

I was supposed to release this version before christmas but I had forgotten to with the release of the MiG-21 SMT/MF to WT, which has a 10x higher chance to break up in overspeed compared to the F-13 for some reason, which meant going even 1 kph above your redline was very dangerous. For this, overspeed was a much requested warning to be added. Overspeed warning uses the WhoopWhoop sound from the WhoopWhoop-PullUp! warning because the other sounds aren't as attention getting and or are too long to be suitable for the app.

Some assets that have been added (unused): Fuel 500/800/1500 (It turns out WT's jets barely have enough fuel for these warnings to mean anything for the purpose of low fuel warnings), Minimum Speed, Maximum Speed, Whoop-Whoop/pullup (Portion of it was used for the overspeed warning).

WT-Betty Version 1.3 - Sink rate warning, unit conversions.

At the moment sink rate is tied to the gear check because it activates when your gear isn't up while you're at a speed where you get the landing gear reminder. There are no russian betty voices in english for a don't sink warning so I used the one from a B737 cockpit warning system video. I did a basic noise clean up (-32 dB with VLC) and deepened the bass a bit so it doesn't sound so plastic-y, made sure the volume is approximately level with the others.

This build also includes contributions from SonStrong, which basically just cleans up the code, standardises the code CamelCase format for a certain section, more safety checks and includes a basic unit conversion function.

Other new resources (unused): Don't Sink, Whoop Whoop Pull Up (unprocessed, it is still in .ogg format). Feel free to fork the project if you wish to use these resources.

And yes, I have confirmed, WT-Betty does not trigger a false positive with EasyAntiCheat. It makes sense, because WT-Betty only reads protocol 8111.

I haven't yet started the rewrite of the software in a different language because I'm still not entirely sure where to start, but I can tell you when I do, I'll make sure to use a language that other operating systems can use, because the unfortunate thing with C# is that it is only designed to work with Windows with MS Visual Studio. Which to my surprise is actually quite a nice IDE, I used to think it was absolute cancer with its resource requirement and strange UI. It would be nice if Atom got some of those advanced features.

From the looks of it, diVineProportion thinks Python is the best choice. However I have my doubts, because python will only work if the end user installs python interpreter on their computer, even if you made a standalone binary. At least that's my experience with the language. If anyone has any recommendations in particular, feel free to suggest away. Oh and by the way, diVineProportion is working on a Tacview interpreter through protocol 8111 for War Thunder. However there are a lot of issues in the way such as 8111 not providing sufficient data for other vehicles other than the player and thus the requirement for multiple users to record with the tacview interpreter and merge later for it to work, no height maps without an extractor, 8111 json output refresh rate and so on. However, he has shown me some well, let's just say, interesting things. They could possibly be merged with wt-betty if I did code it in python too I think.

WT-Betty Version 1.2 - ZdrytchX's Fork edition

New Features over SoulMaril/Europa's original release:

• Ground (Sea Level) Proximity Warnings: This is sufficient for most Air RB mission maps because they are mostly flat and the ground is generally less than 100 metres up. There's no forward visibility radars yet or any of that stuff although helicopters do get true height above ground readings. I'll look into that in the future. The current equation is basically: 2 seconds to sea level in vertical speed + (airspeed in kph / 100) ^ 0.7. For gaming purposes 3 seconds should be plenty for most part but if you're lets say in a mig-19 flying at nearly mach 1 in a dive you have about 6 seconds to pull out.

• Bingo, Fuel: Activates when your fuel reserves drops to 10% remaining. Because it's currently triggered within like a 0.3% range, the duration of the warning differs from aircraft to aircraft with the quickest being on the Ki-200 where it only sounds once or twice while on a PB2Y with its 8 hour endurance or something it'll sound like 10 times. If you have a major fuel leak it may not sound due to the low refresh rate of the war thunder JSON protocol output but at that point you should already be concerned about returning to base.

Modifications to the original application features:

• Sounds: Sounds aren't as blaringly stupidly loud. I did reduce their volume using audacity so by default you don't have to reduce their volume.

• Angle of Attack / Stall sounds: The original application had a rather boring flat tone but he had provided additional unused sound samples with the source code that seem better. AoA now has two layers of sounds, one that beeps quickly and one that is supposed to be a constant tone but actually sounds like it beeps slower because every "tick" the application updates its information it momentarily stops the sound. Not a big deal though. The fast beeps sound occurs up to 2 degrees below the set AoA warning and the major one stops about 10 degrees after so should you ever get into a super flat spin the application won't blare in your ear that お前は死んでいる. I also extended the AoA setting limit from 18 to 22 degrees to support the newer squishy supers.

• Landing Gear Warnings: Defaults are set to higher speeds to better suit jet speeds but they should still be low enough that your gear breaks off before you hear them in a bf109 or spitfire. Also the conditions whether it sounds or not no longer depends on flap positions (previously it would only sound if your flaps were deployed. Now it is dependant on your throttle being below 20% and your IAS has to be above 40 kph so you don't get the the warning as easily if you're throttle down in a slow Immelman.)

• G-Overload Warning: Like AoA warnings this is now multi-layer. The first regular warning sounds at whatever the cursor is set to. I recommend leaving the cursor around 6-7 Gs because that's when you start to black out if you hold it out too long. Even an aced crew with G suit upgrades will still G-LOC sustained at 8 Gs, so keep that in mind. The upper warning sounds 3 Gs above your set threshold, divided by whatever your set threshold divided by three is. In other words if you have 6 Gs set, the critical G-overload sound would start at 8 Gs and if you have the lower limit set to 9, it will sound at 10 Gs if you get my point. This is really helpful in some aircraft especially in the recent years such as the MiG-19, where it will break its wings with about 11 Gs and a bit of side slip, while you generally only start to black out at 5.1-6.7 Gs although generally you will only notice by 7-8+ Gs with the G-suit depending on your crew status.

• Added checkboxes for the respective new features: If there are any bugs please let me know. I kinda rushed this and was like /whatever/

TODO

Here's my current TODO list.

1. Ignore dummy-plane status and mute all sounds
2. Write config to JSON or something PER AIRCRAFT so you don't have to tweak the values going between a Po-2 and a MiG-19 every time you alternate between them.
3. Auto-load the config if it exists on aircraft change
4. Add support for helicopters
5. Remove that strange lag between each "tick" of the program
6. Somehow find a mathematical way to find out if the player is actually dead or alive. Unfortunately the JSON protocol doesn't really provide that information, so yeah, good luck me.
7. Rewrite the code in Lua or Python or something, at least make it multiple-OS friendly. I don't really have experience starting entire OOP projects from scratch though especially with one that consists of UI, but I certainly don't want to be using TkInter of Python3 because that thing is just weird and nobody uses it in the real world. Preferably I'd like not to use python too but who knows, maybe someone can recommend me an easy to learn language and utilities for this.