FusRoPotato

Yeah, completely skipping over the altitude of a target on a single tap is... a little fast I'd say...

I haven't flown the 18 yet, but I'd take a guess that my instant death to ejection ratio in the 16 is probably floating around 100/1. In any FC3 aircraft, feels more like 1/4. I can usually eject after being struck, but not in the 16. I think a better approach would be to grab some server logs and do some comparisons. "The F-16 has a large glass canopy and the pilot is less protected than other aircraft." That's not a reasonable assumption to make. It's not even made of glass. Glass would be the worst choice of material possible in terms of weight, UV transmission, smallest xBand tangent losses, cost, and protective strength. I don't know of any example where glass was ever used as a canopy material for any fighter jet aircraft made after the discovery of polycarbonate. Based on lack of losses, there's not enough statistical evidence to provide nor reasonable structural assumption that the pilot is less protected compared to much anything other than craft with a hog style reinforced tub. In fact, there is an interesting article here about one of very few losses where the pilot was able to eject, and with an interesting bonus, the canopy was eventually recovered still in one piece. Featured Articles - Canopy of F-16 downed during Desert Storm returns home

The problem exists with the aircraft completely stripped. You can get a more exaggerated effect by flying slow, putting something on the right wing, or almost cancel it out by installing pylon 4. I presume the right side of the aircraft is simply heavier due to a mistake, or color me super surprised if there exists something in the flight model generating more lift on the left side.

I've been noticing the same starting from 3 patches ago. It's as if the right-hand side of the aircraft is abnormally heavy. 2 patches ago there was a note somewhere about fixing a weight issue, but seems an issue remains.

I've also noticed that some units, if respawned by MOOSE or similar, won't heat up even if they are moving around or firing.

I haven't run into this with the 16 yet, and it's my most flown aircraft in this sim, but I've had it happen often on FC3 aircraft, typically anywhere randomly between 0 and 100 kts. I suspect it may be some sort of runway geometry problem, possibly related to some kind of framerate or desync amplified by FC3 tire physics, because a similar thing with FC3 aircraft happens when rolling over a small corner of grass at ~2 kts rolling speed. However, it may also be related to weather turbulence settings because it appears more common there as well. I'm not sure if a tire itself is submerging under the runway, perhaps at a triangle, and then interacting with a simulated grass pothole/rock? I'd suggest anyone looking into this to take note of the speed, the specific runway, and the specific location of that runway if someone supplies a track or video. Socchi Addler on the main runway facing West was a common place for FC3 aircraft to blow tires at low speeds during short takeoffs. There've been times I've pancaked planes pretty hard or gone sideways with em due to really high cross winds, all while surviving just fine. Yet other times, buttery smooth touchdowns in perfect conditions just explode every tire on the plane shortly after touch down. Yet, I still haven't seen any such thing happen on the F16. The tire simulation on it feels indestructible. I think I've bent the gear more times than I've popped tires on it.

They are trying to account for sidelobe interference but, similar to lookdown logic, their approach to it is also misprepresenting how a radar functions and how much information it can return. When a radar paints an area, it does so with a main beam, but because of the radar's shape, there are additional beams that come out the side in a sort of water ripple pattern called sidelobes. Those can bounce off the ground and return noise, though typically only the bottom of the first sidelobe has enough vector strength to produce noise. Sidelobe interference can interfere with lookup detection while flying low, but this interference is very dependent on the time it takes for the first sidelobe to return compared to the range of the target. The other sidelobes almost never interfere because their returns will always be extremely weak, but sometimes the first one can be strong enough to mask a target far away at high elevation when the range of the target matches the range of the first sidelobe hitting the ground. This results in the sidelobe return squeeking past the filters and increasing the chance of masking. All other sidelobes are typically too weak or easily filtered out by time. What this typically results in blind spot that is dependent on a geometric calculation involving the targets range, targets altitude, and radar altitude. Of course, such estimation is simple and assumes flat terrain, but otherwise could be determined by the target's range, elevation, and a ray trace towards the ground from the bottom of the first sidelobe's forward vector. What might be left is a target you can't see at 20nm and 25kft up while flying at 1000ft, but you will be able to see it when it's at 25nm. It can be calculated geometrically if a source can be found of the AGP-68's first sidelobe radius angle, but even though it's probably not classified, such accuracy is in simulation is probably not a good thing. Just a generic representation of how sidelobe interference works would probably be more than good enough, but simply reducing range based on altitude misses the fact that radars flying low can still see far away targets up high. The interference is not always interfering, I wouldn't even say it usually interferes, but sidelobe interference is a real thing that can blind you.

Angle of surface and surface type might be too high-fidelity and complex to worry about because it concerns more of a finer detail than it does basic logical function. It matters only a little and you'd probably not enough difference for it to ruin the experience. What's far more important is whether or not the target is within the section of picture where the latter portion of the range bin dips below the surface. No matter what, if a target on the deck is approaching you, it should have some rare chance of showing through the noise just via doppler, then 100% chance of showing through when it rests within picture where the range bin is above ground. This of course happens more often the higher a target is, but there will not be any noise at all in some lookdown cases because it is filtered out by time. The range bin simply ignores anything that comes back too late. It may be impossible to lock them if they are far, slow, and low enough, but there should still be occasional hits with luck and it's what TWS prediction was created for. Not ever having anything show up at all makes a massive difference in combat tactics and this lookdown penalty just erases all possibility of that. The same can be said for lookup against side lobe interference. It's just overtuned and always interfering without any consideration for all the filtering techniques and randomness associated with how a radar paints a picture and determines if something is there.

I've been having the same problem, but only for CCRP. The only solution I've been able to come up with so far is to release with your centerline (not your VI) placed roughly 3 degrees below whatever you set the release angle at. That seems to drop them closest to the target. Otherwise, they always go over, regardless of speed, regardless of altitude, pressure, zero pitch rate, or whatever the rel angle is set to. It always lands about 50-100 feet behind. If you're going to use dumb bombs, just use CCIP until they fix it.

Sure, before high spectral purity exciters and 3-channel receivers... The APG-68 was known for its ability to detect low altitude targets while looking down despite its lack of power and size through several doppler filtering techniques, but it gets worse looking up compared to looking at the horizon?

Course alignment is very low and course alignment fails when the client is set to hot start ground. Still works fine in cold start mode. I suspect something buggy with the new radar gimbal limit indication in DGFT because the HMCS is low by about 30 degrees after pushing it. Not sure if it occurs after a fresh start, but will occur after pushing the radar gimbal limit and stick regardless of which slot is chosen afterwards. I approximate it's low by 30 degrees because normally the HMCS will hide when dropping the view into the HUD area from above. In hot start, it doesn't hide until dropping the center of view to around the dobber switch region. If you really need track files for this, I can provide them, but I suspect it's not necessary.

I was just about to make a mission to test this because I've been noticing the same thing. Felt more like below 4k, but basically acts like lookdown penalty inverted. All the dots vanish. Oddly enough, I can still auto lock hot targets within 5 nm in DGFT mode, but it won't draw them in A2A. Some older radars have a lot of difficulty when beaming the ground up close because the interference gets more intense, however I can't imagine there being any problems for bars looking above the horizon.

I got it all figured out actually!

Is there unclassified evidence to the contrary?

Yeah I've run into weird SMS issues before while switching between A2A and DGFT. Unfortunately, a track file can't replicate the problem. This probably means that, whatever the bug is, it goes deeper than everything recorded in a track. Some of the stuff I've seen is akin to: Switch to DGFT Switch to AIM120 Switch to A2A Lock target Switch back to DGFT At this point, the AIM9x tone is heard, but locking a target shows AIM120 ranging launch bars on the hud. It also shows AIM120 selected in the SMS, but fox3 that sucker off and watch an aim9x fly away dumb. I've seen this happen 4-5 times now but a track file shows everything as AIM9x and I think it's supposed to do that, but the SMS and HUD seem to miss out on that update in rare cases only in the moment it happens. In one instance, I caught it in the act and tried to switch weapon before firing. The AIM9x tone went away, but the hud and SMS page stayed on AIM120. I was then able to fox3. So long as you know that DGFT will always switch to fox 2's when entered, it can be easily worked around, but it is confusing at first when the HUD and SMS don't update. The only way to capture it is to always have video recording tied to a track file, but neither are going to help find a problem like that any better than a basic description. All it will do is validate I'm not crazy. I suspect something is blocking or corrupting the update because they are supposed to change when switching modes. It may be completely related to your SMS off experience.

Sounds right to me. When you apply thrust at a high AoA, there is a vertical component to that thrust vector normal to your flight path that reduces the amount of work your wings need to do to maintain that flight path. That flight path lift component belongs to the aircrafts normal lift, but the thrust line doesn't really have a vertical component perpendicular to lift, so I'd expect a sudden small loss of G's that the FLCS would attempt to correct by pitching up. This however should depend on the slope of your overall lift curve for your given AoA. In some cases, like a stalling speed where the slope drops and NP moves back, I'd expect the opposite. Since the lift curve slope will be negative in that condition, any reduction in AoA by an added thrust component vertical to the flight path will push the flight condition towards a point in the curve where the wing can produce more lift and sensed normal force. However, if the AoA limits are passed, it will no longer hunt for a G target, thought at those speeds, the aircraft should have stronger stability coefs. It seems like one of two areas the DCS F16's model does not operate quite as expected and I suspect it might be due to a fixed NP location prior to transonic speeds. Reason being that I can get stuck in a tailslide or inverted stall. If the NP doesn't move back when approaching a stall, you could end up with the effect of G increase due to added thrust being countered by an invented instability. The only other weirdness I've seen in the flight model is overcorrection, oscillation of yaw at supersonic speeds and low altitude.

The tracking algorithm and imaging of the AGM65-D is based on the ΔT of pixels presented by an object relative to its surroundings with its best sensitivity and resolution. It's not based on absolute T so contrast on the sensor itself so it wouldn't make any sense conceptually to play with "sensor contrast". The contrast adjustments your MFD only integrates those ΔT values to absolute T through contrast scaling for your eyes and brain to interpret. It will help you spot targets easier if optimally set but have no effect on the sensors tracking ability.

I don't think the F16's FLCS injected attitude mods to G control until Block 60, so yes, if you roll upsidedown or pitch straight up, it will apply up pitch until you reach 1G. This doesn't get inhibited until 24ish degrees AoA, which I haven't checked in DCS if that is applied or not.

What you will be able to see on radar depends on far more than just the power you plug into it. Increasing power or sensor surface area/count is just the general brute force method to getting better results. As the 16's radar evolved, it received very large performance enhancements just from filter processing alone. If a specific target is always detected at 35nm but not 36nm, regardless of radar and aircraft, I'd say that simulation is neglecting a few physical concepts and simplified estimations. A higher fidelity simulation, of which is still heavily reliant on basic simplifications, would account for small RCS variations based on airframe perturbation thru RNG, the shifting of backgrounds, sensor alignment, and the amount and frequency of power received from a painted object. Think of it this way, if someone takes a bunch of pictures of you, there's a chance some of them are going to resolve the tiny dot on your shirt while others won't. There wasn't supposed to be enough resolution in the camera to see that level of detail, but it will sometimes show anyways as a pixel larger than the dot itself. It's how we are able to build pictures of a black hole by stitching together many photos from different angles, or clearer pictures of the galaxy with exposure time. The whole point of reducing bars and azimuth is to get more pictures, not just for more updates, but for clarity as well. The concept of power is not exclusive to the wattage plugged into the unit, it is a summation of the energy you get back from targets you're looking for. That factor includes RCS, how often it is painted, and how well it can be filtered. What matters is how much energy over time that target sends back and whether or not your filters are strong and lucky enough to isolate it from the surrounding noise to recognize it for what it is. There's a higher chance of receiving faint returns at a greater distance in a shorter period of time if painted more frequently. The amount of power a target sends back doubles when halving the azimuth. It doubles again when halving the bars. That also means the power of the noise doubles as well, but noise does not always scale the same and the filters have an increased chance of recognizing something. Correct-as-is for a game maybe, but not real life. Reduced azimuth and bars should be enhancing range.

It's the same after rifling one off too, it slaves to bore instead of vis and vis has to be redone. This is not the case when using the TGP or markpoints, so the only current workaround is to use a markpoint instead of vis. Don't think it's supposed to be like that for obvious reasons. These systems are designed under the presumption that time is critical, but it's not specifically documented anywhere.

@Hardcard I'm just getting into the DCS ME and trying to learn about all this Moose LUA stuff, and I was wondering if I could ask for your advice on that script you posted. I put together an experimental mission in which I have a handful of groups that take off, fly around, land, get deleted, and respawn. I ran into a few problems that I think are logical timing issues but I'm a bit clueless as to what is happening behind the curtains with all these functions. If I let this sim run for an extended period of time where all these groups take off with very limited fuel, they seem to work well for the most part, but eventually one of two things will happen. Either a plane will end up sitting on the runway (likely not detected as landed), or the respawn script will respawn both planes and one or both will get removed again 1-5 seconds later. When this happens, it can happen 20-30 times in a row before it just stops happening and continues on without a problem. Do you suppose a better approach to that might be to just only look for planes that have been sitting at 0 speed for an extended period of time, regardless of landed condition? As someone who has little familiarity with lua, how could I approach this? I was thinking at line 14 of your code: if CleanupVelocity == 0 and CleanupAliveCheck == true then CleanupUnit:Destroy() MESSAGE:New(CleanupName.." parking detected!\n"..CleanupName.." removed from airbase!",10):ToAll() end maybe here instead of using OnEventLand and going straight for Destroy(), I could setup some kind of way of creating a time stamp for these met conditions of velocity and alive (so long as one doesn't already exist) and then later destroying it once a certain amount of time has passed? I'm just not sure how to efficiently dig into this. I was suspecting that these problems I've been seeing are result of more than one aircraft landing before coming to a stop, but seems fine if it's just 2 at a time. If I make shorten the fuel on one group so that it lands before the other, the delete on respawn shifts to that first group. It makes me think it's a list issue of some sort rather than one of synchronization. If you don't mind, any advice on this would be greatly appreciated.

I think stuffing an SD-10 on a J11A or an R77-1 on a Su-33 is a drop in the bucket compared to FC3 as a whole, AI coms, the coms menu, RCS, AI awareness, AI flight, radar penalties, and IR signatures... That fictional fitting might not be real lipstick, but it is lipstick. The rest of those issues are just problems only. The mistake here is framing it as a commitment to balanced gameplay. It could also be framed as committing to a realistic experience for the types of combat these modern modules might face. To get that experience, we must pit JF-17's against JF-17's, cuz we aren't allowed to pretend a J-11A is actually a J-11B. That's kinda the whole purpose of a simulator, to pretend experiencing something real lipstick with some trickery and hand-wavium where necessary.

The problem with this statement is that skewing the play field between coalitions by limiting one coalition to tech from decades earlier is not an accurate simulation. If they aren't concerned about the balance of content, they are going to limit their product's practical quality to a cockpit clicking experience. As many many others have said, it's otherwise a bit of seal clubbing experience. A temporary bending of blurred lines, like allowing a few fictional fittings (of which some might not be so fictional) until something more appropriate like a set of full fidelity modules comes around, would be a wise promotion of engagement. It's also an extremely easy fix, or unfix in some cases.

Half the time it launches S-25's in pairs for me, even if they are only on one wing. Otherwise, it launches all 4 at once. This is a problem regardless of whether or not it was intended. Sometimes, it will release 3 out of the 4 available, or release weapons outside of the selected category. I don't have a track for that specifically but someone else has posted tracks of that here in the past. Installation slow repairs have been done. I suspect none of this would be a problem if default was single as expected. I have no way of verifying what mode anything is in by default. https://drive.google.com/drive/folders/1Miy1eNSbDNSS6ZM7nJi_5IiXzuMcHKRB?usp=sharing Some track files. One shows everything being pickled off at once as if this "salvo mode" is... on or off? I didn't interact with it either way. Second track shows them dropping/ launching in pairs, which is as you describe, however it launches the rockets in pairs as well which is unlike your video. Usually those fire off all at once which is a huge waste. It's especially wasteful for bombs considering they have a blast radius 10 times smaller than the S-25's. As for the A-10A, This was 100% reproducible up until some point in time and I haven't been able to replicate it again since for a track file.

"D". It only changes HUD mode when I press the mode selection keys. Ok, I am new to DCS so I'll have to learn how tracks work, but I will check it out. I expect if something is wrong on my side, I won't see it swap correctly? I will also see if I can make a track myself, unless one is already made and stored somewhere. It happens after re-arm and refuel, apparently when I'm on a server, but not while in the Instant action CAS. Perhaps this is a server side bug of some sort, but sometimes on the server I can swap between 3 weapons out of 4 or 5 types. This CAS IA mission only has 3, two of which are different Mavrick variants. Tried my hand at mission editing for the first time and it seems I can switch between all weapons just fine with 7 unique weapons. Now I have to see if I can figure out how to rearm myself in single player to rule that out before assuming it's a server problem. edit, was able to land at a base in single player and rearm. It allowed me to swap all weapons after changing them all. I can only guess this is a multiplayer or server issue at this point.