Leaderboard

Preliminary changelog for next patch: * Fixed: Z Fighting in the exhaust tube * Fixed: the MB-339 has no lods * Fixed: Blind hood animation is not synchronized between internal and external model * Fixed: AI jettisons canopy when parking * Fixed: luggage and recon pod are diplayed as Rockets on the weapon panel * Fixed: canopy does not demist when open * Fixed: COMM1 radio initialisation * Fixed: Anomalous Morse signal heard in cockpit * Fixed: 3D model has no lods * Added: Three position flaps keybinding * Added: Joystick trigger with two detents keybindings * Added: Gunsight Repeater * Added: Guncamera * Added: New Net Animations * Improved AI Damage Model * Updated Flight manual Inviato dal mio ASUS_I005D utilizzando Tapatalk

AviaStorm Tornado

Reopened. Thread cleaned. Folks please if you have given your feedback please take a break, the back and forth between some is getting out of hand. When posting remember the rules at the top of the page, in particular 1.1 no profanity, 1.2 treat people with respect and 1.10 Product feedback and constructive criticism is encouraged when provided in a mature and courteous manner. However, feedback that is abusive, insulting or condescending is not welcome. Additionally, to bring up a particular issue repeatedly after it has already been acknowledged will be considered "trolling" - in such cases a warning will be issued to the author and the post will be removed. thank you

Dudes, how about both stopping at this. We all know it's not good enough and that this is just first iteration. Let's wait for the next version ED releases.

I don't think I have ever read anything so blatantly arrogant and demeaning on this forum before...

The point of which is to foster thought over possibly unforeseen negative consequences. You're not doing that. You're just ignoring everyone else.

Can you be more condescending? Is that even possible? What kind of person posts things like this?

Absolutely. Even if one can afford a drive, the idea that getting a new one is some kind of be all "solution" is ridiculous. No reasonable person is going to want to throw away money to solve something that could be resolved for free. Looking beyond money, having the option to free up space with a few clicks is far easier than going out and getting a new drive and then installing it, if you even can install it which may or may not be difficult given hardware and your current situation.

Maybe so, maybe not, what's certain is, others' life priorities fit pretty well into "none of your business" category. And again, many of us are concerned with the storage footprint of liveries regardless of availability or affordability of it.

Irrelevant, I might have spent my existing budget on other bits of the computer, or on another peripheral, or on modules, or, indeed, blackjack and hookers. What matters is, it is an item of not insignificant size for many budgets where the available moolah is indeed limited, for this or that reason. And thus, it competes with other such things for such budgets. Once again, "storage is cheap" meme needs to take a step back, a pretty long one at that. It isn't so for some of us, and even if it is, that is not the only reason people want liveries to stop causing a runaway disk occupation. Having to sacrifice this or that important software just so I can do every large sim update got old quite some time ago.

My older brother saved this item when my father passed, many years ago. He served in Normandy, arriving on the Beach five days after the beaches were liberated. He was a radio man. This is his Dress Jacket. It shows his rank, ribbons, and awards, as well as the unit he was assigned to. A special piece of history, preserved for all to see! It is in Perfect condition! A family treasure! And now shared for you all to examine and enjoy! If you have any of your own, Please post pics in this thread. I would enjoy them immensely! Thank you! Staff Sargent! Back in the day --------------------------------------------------- His awards

G'day guys! We know that you've been itching to find out more, so this report will be purely focused on the development state of the A-7E Corsair II for DCS World. The SLUF has an all new, much improved 3D model and today we're happy to be sharing the first pictures of the new model in-sim! First, I must apologize for the lengthy gap between development updates. We understand that many of you are keen for more regular update reports, and I will strive to do my best going forward to try and keep the development news flowing through more regularly. Without further ado, let's dive into what we've been up to in 2023! ARTWORK 2023 has been a wild ride for our beloved Corsair; with some difficult decisions being made throughout the year. In our previous report, we unveiled our overhauled and remade 3D model in all of its beauty. The model was exquisitely detailed, and we were very proud of it (and still are) - especially considering the model was built from only photos and blueprints. In 2023, we recruited a new artist, Oleg, who is a veteran of the industry & aircraft modelling, having worked previously with some of the very best teams in Flight Simulation. Not only an incredible 3D artist, Oleg has extensive experience with photogrammetry; the fascinating process of extracting a 3D model from a real-world object via a detailed photography process. This presented us with a unique opportunity to do something we've never done before - scan an entire aircraft as the basis of our model. After being presented with this opportunity, we made the very difficult decision to remake the 3D model AGAIN. Now I know what you're thinking, and don't worry - this decision hasn't had any effect on our release projections; there is still plenty of more programming work to be done in tandem. Of course, this decision was very painful for us, having to set aside thousands of hours of work is not a decision to be made lightly. Ultimately though, we believe that this was the best decision going forward for the team, for the module and for the consumer. Our previous model was excellent, however any model built from blueprints & photos is prone to inaccuracies, as minor as they may be. This is just the nature of dealing with wild blueprint inaccuracies, incomplete photo reference and managing strange photo perspectives and alignment. Photogrammetry eliminates these errors and inaccuracies, providing a true-to-life 3D reference of the model and textures. The external model has progressed at an incredible pace thanks to the photogrammetry, and soon work will begin on the cockpit remodel. Now that the new model has been in development for some time, we are absolutely confident that we made the right decision, and we think that these screenshots might just convince you too Note that the textures here are using the scan reprojection from an A-7P, and don't necessarily represent the final textures or level of wear & tear. PORTUGAL TRIP Earlier this year, Oleg & all of his gear packed up and made the journey to the Museu do Ar (Air Museum) in Portugal. The museum is home to 2 beautiful A-7P aircraft - one in Ovar, and one in Alverca (plus an additional cockpit display in Sintra). We were lucky enough to be granted full access to both aircraft; not only the exterior and cockpits, but also to internals such as the radar & avionics bays, landing gear compartments and intake! With perfect weather shining down on our scanning days, we were able to capture near perfect scans of both airframes - giving us not only 1, but 2 complete reference models. This took several days of laborious photography, crawling inside tiny compartments, setting up lighting rigs and capturing tens of thousands of photos from every angle imaginable. As you can see, the end result has been well worth the effort. We are immensely proud of the new artwork and the progress it's been making; Oleg is doing fantastic work and we truly believe it will be up there with some of the best in DCS World. Of course, we didn't stop there - you don't get an opportunity like this every day! We also used the opportunity to capture video footage inside the cockpit, providing detailed reference of switch, dial and lever motions to provide accurate reference for animation. The final step, using a professional microphone rig, was to capture all of the unique cockpit sounds that we possibly could. Although it would be very easy to use generic switch & lever sounds, we think using genuine sounds from the real cockpit just adds that extra level of immersion & authenticity. FLIGHT MODEL Moving into Phase 4 In the last few months, work has been mainly focused on further developing and refining the flight model, with the aim of getting it ready for testing and into phase 4 of development. It's been quite a lengthy process, requiring a redevelopment of the equations driving the flight model, in order to be able to better integrate the CFD data we have been capturing. We also came across a new source of wind-tunnel data this year, providing more direct data to be used in our tables as well as providing very useful validation data for our CFD model. Without getting too technical, we have significantly expanded upon our stability & control derivative modelling, replacing previously linear derivatives with complete non-linear data tables, often with 3 or 4 dependencies and inputs. Again, this goes above & beyond the derivatives provided from wind-tunnel testing and provides a more in-depth and accurate simulation of aircraft dynamics, particularly at & beyond the edge of performance envelope. This year also saw the expansion and development of the TF-41 engine simulation, with much the same process being applied here. Various data reports & engine simulation software were used to create a comprehensive picture of engine performance, with work ongoing to further develop simulations of various engine subsystems & quirks. The TF-41 is a relatively slow engine to respond, adding an even greater challenge to carrier landings and Air Refuelling operations. Finally, 2023 has seen the completion of the Automatic Flight Control System (AFCS), which includes a complete Control Augmentation System (CAS) as well as multiple autopilot operating modes. We've previously discussed the AFCS in detail and the importance it has on all areas of flight - we're now happy to report that it is finished and awaiting testing! Optimization & Efficiency An EFM in DCS World is typically simulated every 0.005 seconds - meaning that the flight model is updated & recalculated 200 times every second. This is necessary to allow for the accurate computation of aerodynamic models and also for accurate reading of pilot inputs, providing an appropriate level of sensitivity and resolution. Given that an aerodynamic model consists of huge amounts of data (often thousands of data points split into as many as 100+ tables) and heavy calculations, any inefficiencies in the EFM model can lead to a degradation in performance at all times in flight. For this reason, we have been spending time optimizing and improving runtime efficiency in our flight model to try and ensure we have the best possible performance. The focus here was to redevelop our Look-up Table (LUT) model from the ground up, using the latest available research to help direct our efforts. Without getting too far into the nitty gritty details, we have been able to significantly improve the processing time of a simulation loop by increasing the speed & efficiency of our look-up tables. Typically in a LUT, data is stored in tables, which usually have up to 20-30 rows and often the same amount of columns. The computer will take an input, such as AoA, and loop through the table until it finds the nearest matching values. From there we can do mathematical interpolation to determine the correct value that matches our input. This is repeated for each table (can be 100+ tables), and the whole process repeated 200 times per second. While this is an acceptable process in most cases, there is certainly room for improvement. One such approach is to store the previous result, and then use that as a starting to place for the next search loop through the data table. This helps, but still requires a full search loop whenever a large change in input occurs. Our new LUT model however does not require any searching or loops; instead, we have developed a clever method that involves manipulating our data sets so as to maintain a linear relationship between inputs & corresponding data tables, so that the table index (or where to look in the table) can be simply computed from the table input value. We have of course expanded the model to include n-dimension tables, so that it is ready to handle any fresh CFD data we can throw at it! It was important for us to get this right, not only for the performance reasons above but also because the LUT model is a cornerstone of the EFM, and can be reused in any future modules. CFD WORK You'd be forgiven that we would be finished with CFD work on the A7 by now, but not quite! Previously, our CFD model was built in NASA's OpenVSP software, meant to only be a crude representation of the A7 with a very simple, performance based mesh. This has given us acceptable results over the last year, most of which has been implemented into the Flight Model already. However, having captured the scans on a real A7, the opportunity to collect fresh & more accurate CFD data was suddenly available. So this year, using the scan as a base, we have been busy also rebuilding our CFD mesh; this time using a much more detailed and accurate mesh. Given that CFD is entirely mesh dependant, an upgrade to mesh fidelity consequently provides an increased data resolution and accuracy. This was particularly beneficial for capturing peripheral data that is not present in the literature, such as landing gear forces, speedbrake forces and so on. Our previous mesh was very simplistic, and thus only captured a general idea of the forces. Now however, we are building our CFD mesh from Oleg's incredible scanning and modelling work, providing 1:1 accuracy with the mesh and consequently the data collected. It has been a difficult & intensive process, as anyone that has worked in CFD can undoubtedly attest to. Fortunately, we have been working closely with Research in Flight once again to further refine our new model and ensure validity of our collected data. It is a large undertaking and fairly heavy workload, however we are grateful to have the opportunity to work with the experts to really develop our CFD knowledge & skills; not only is it a huge benefit to the A7, but it also opens the door for us to be able to model any future aircraft with full EFM fidelity. Here you can see just a very, very small sample of some of data collected from a test run of the landing gear model. MECHANICAL SYSTEMS The Corsair has a beautiful duality as an aircraft; it was a technological pioneer of the time, featuring the first fully-fledged Heads-Up Display unit that we are so familiar with in modern aircraft. Yet, it was also very much an 'analogue' jet of the past, lacking the huge array of sensors and digital control systems that modern fighters are equipped with. The Corsair is a very much a hybrid of the two; a transition between two eras in military aviation. With this in mind, we've been spending some more time this year really expanding upon our simulations of the aircrafts mechanical systems such as gear & ground operations, carrier ops & systems, hydraulic & fuel systems. While these aren't as flashy as the weapons & avionics systems, these elements make up a considerable portion of the airframe, procedures and overall simulation experience, and its important that we get them right. As a simple example, the speedbrake is hydraulically operated, but not immune to the intense forces of high-speed flight. It will be buffeted and pushed back, partially retracted by a strong enough airflow. It is prone to drooping & partially opening should PC2 hydraulic pressure fail. It cannot be operated with gear extended, unless using a manual PC2 hand pump when on the ground. We have done our very best to capture all of these quirks & details, really developing the unique character of the Corsair II airframe. As we are modelling a later-era Corsair, the airframe includes Automatic Manoeuvring Flaps (AMF), an advanced flap control system designed to increase turn performance and manoeuvrability in lower speed conditions. The system operates by partially extending the trailing & leading edge flaps when angle of attack exceeds 14.75 units at an airspeed below 0.7 mach, retracting again below 10.5 units AoA or above 0.7 mach. The AMF system has been completed & integrated fully in 2023! CARRIER & GROUND OPS We are happy to report that the Corsair is now operational off the carrier deck, having made her maiden launch & trap several weeks back. Landing a Corsair on the ship is immensely difficult, and success will not come easily. We have to commend the incredible skill & courage of real-world Corsair pilots; to be able to regularly achieve such a feat is nothing short of extraordinary. We have completed work on the launch bar system and its various safety measures & dependencies, as well as the arresting hook system, nosewheel steering, braking systems, landing gear systems and much more. To give you an example of the work that's been happening, lets discuss the Nose Gear Steering system as an example. The Nose Gear Steering (NGS) system is the power steering of the Corsair; it is electrically controlled & hydraulically actuated via a hydraulic cylinder mounted on the nose gear shock strut. When the system is deenergized, it provides an automatic nose gear shimmy damping function - essentially damping nose-wheel wobble and providing a smoother taxi. Engaging the system via the Nose Gear Steering button on the grip allows the pilot to steer via the rudders up to 60° off-centre. Hydraulic power is provided via the PC2 system and requires the utilities isolation valve to be OPEN - it will not function if the valve is closed. Automatic recentring of the nose gear occurs during gear retraction, or when the right gear weight on wheel sensor determines there is no weight on the gear. When this happens, a servo valve repositions to block PC2 hydraulic pressure. A spring-loaded damper shutoff valve then moves into position, connecting the left & right sides of the nose gear steering system to a damping orifice, restoring the automatic shimmy damping functionality. We are quite pleased that we've been able to capture & simulate this functionality; it will be important to follow procedures correctly when flying the Corsair. As you can see, the technology used is slightly older than what you might be used to, and has some more limitations than modern aircraft. There is alot to remember, even with something simple such as the Nose Gear Steering. You'll need to make sure your utilities valve is open, flap settings are correct, hydraulic pressure is okay and even then you'll always need to be on your toes to ensure you don't exceed that 60° limitation or you may be in for a rapid departure off the deck! In a similar vein, we have completed work on the braking system - featuring simulation of antiskid behaviour, PC2 pressure dependency and an additional emergency wheel brake system. Landing Gear operation also requires correct management of the utilities isolation valve, and features a similarly detailed emergency release system. I won't go into as much detail on these systems, but each has been carefully crafted to match the detailed operation procedures and information available in the NATOPS & pilot manuals (as well as with pilot input of course!). There have been a few challenges along the way, such as overcoming DCSs rigid body physics in-order to create a realistic simulation of hydraulic compression, something that is seen during a carrier landing when the arresting hook is compressed. Most likely you might never notice these types of details when you fly the Corsair, and thats good however extensive work has gone into their development in order to provide a natural, realistic experience. Most of these core systems are in various stages of completion now, with work on-going on the suspension model & fuel systems. SENSORS & AVIONICS Much time has been spent this year on improving the realism of the flow of information that occurs through the A7's suite of computers and sensors. Every display, every computer, every calculation throughout the avionics suite relies on data that is collected via specific sensors in the aircraft. These sensors pass data through to the AN/ASN-91(V) Tactical Computer, the central brain & processor of the avionics suite. The computer can then run calculations as needed, and feed data to various displays and systems. As you might imagine, any disruptions in this chain of information can have severe consequences on the quality and availability of data available to the pilot. Fortunately, the NATOPS manual goes into great detail regarding this flow of information & we are also lucky to have access to a paper that extensively details the inner workings of the software used in the avionics suite. You can see an example below, just one page of many demonstrating the flow of information through the aircraft. To this end, we have been working on detailing our aircraft sensors - the first part of the information chain. We have created an accurate simulation of the Corsairs unique Angle of Attack system, which used non-standard AoA 'units' instead of degrees and is a key data element for a number of display & guidance systems. Work is ongoing to correctly model damage to any sensors, and the consequential disruptions this has on the avionics suite. We are quite pleased with the progress we've made on this front through 2023, having completed the Air Data Computer, begun work on the IMS and have completed integrating most of our systems correctly within the chain of information. Work has now also begun in earnest on the Tactical Computer, one of the most sophisticated parts of the aircraft (and consequently most complex to develop). The Corsair does not have any modern MFD's; consequently any inputs the pilot needs to make, settings that need to be changed, data that needs to be read - it all happens via the Tactical Computer and its numerical inputs. The functionality of the Tactical Computer is enormous and beyond the scope of this report; however I have included some of the input codes below to give you a taste of how the computer is operated, and the extensive amount of information that can be accessed and edited as required. Whilst much of the basic functionality of the Tactical Computer has already been done, we expect we will be continually working on advanced features right up until release. WHEN WILL IT BE FINISHED?? Two weeks Just kidding, unfortunately we still don't have a solid estimate on when we will be finished with development. Officially, we are expecting to move into Phase 4 of development sometime early next year, with the aim to begin testing at some point during the year. We are only a small team, without the resources to really expedite development over a couple of years. What we do have in spades is passion for the aircraft, and a willingness to craft if to the absolute highest standards, as long as that may take. We do want to extend a sincere thank you to everyone reading this, everybody that stops into our discord to chat about the A7 and everybody leaving comments on our social media and blog posts. Truly, you guys have been so patient and supportive of our work, it fills us with pride to be a part of such an excellent community of aviation enthusiasts. Thank you! Thank you for reading & for your continued support. Cheers, Dan, Alex, Raimond, Oleg & Iakov. FlyingIron Simulations

In walk-around mode will I be able to lick the battery electrodes to make sure they are good?

in 2021 I have a shared part of my mods. Since then I have created others which to this day have not been shared. Pour information, le porte-char Ceasar mesure 18,14 m de long et 3,45 m de large sur l'image publiée. Un bon point de départ pour faire évoluer votre c-ram ld-3000

This is fixed internally, please back up your control settings as it could be possible that you will lose assignments when this change comes through. I have not tested it yet but wanted to let you all know. Thanks.

It is for me. I live in a thirld world country. Thanks for the life lesson though.

Just so everyone's on the same page, above quote is not something I've said, but something said to me by SharpeXB that I replied I think buceador above quoted the post wrong

I agree, this area should include all countries of the former Yugoslavia.

Just so you're aware of what you look like.

Welp, that's 2 shots, let's see how long you keep this up.

It's not perfect but is much better than before. Keep the good work ED. Cheers

Even though it looks very basic. It actually shows decent ammount of info for AA and AG delivery. Like range and roll inputs.

I would love to see the test modeled as well. I currently omit the "useless" steps, but would rather prefer it would work as per NATOPS, if only for the fact that it might break INS alignmend which was prematurly started by the RIO, knowing nothing is going to happen to it. It should be part of the "game" that makes me believe I'm a hot Fighter Jockey. I strive more for immersion than anything else, so BITs / Systemtest should be a part of it, at least giving one the choice of doing the full startup / checks procedure with experience the expected results.

It's not a potential issue. We already know what happens if a skin is missing. It is already not a cheat. The modifications you worry about are a matter for IC to handle, and it can already handle optional downloads just fine.

No, it's actually one of the most irrelevant one. Please explain how either: Including only a small set of liveries in the base game, with additional downloadable livery packs Including only low res liveries in the base game, with additional HD livery packs Would allow more cheating than possible today, or would prevent improving an hypothetical existing livery cheating problem by classical means such as adding liveries to IC. In the case of the first point, yes a player without the additional livery packs would see a default livery for players using the additional ones, not a "ultra high visibility cheated livery". In the case of the second point, it's even less relevant. Edit : For the record, I'm using three DCS installations for various reasons such as module development on my desktop (gaming & main dev hardware) and two on my laptop (which is a PITA to upgrade for storage space) with only the required module installed on each.

Yep, I'm aware. With 2.9 ED chose to add additional warning messages (the same as they've done in earlier releases). In this case it's a warning message, so it's not critical and won't impact the functionality of my assets. But because I don't like warning or errors messages in the log, every time I update an asset I fix this. But there is no point in updating all the assets at once since it won't make any difference at all for the users.

I think it's a bad idea to modify the game files directly. Exports are better, but I would not recommend using the Export.lua, but rather Scripts/Hooks subfolder. This is at least how I did it in my own mod. It works great since users do not need to edit the export.lua (which they generally tend to screw up), but rather just drop the lua file in the folder: https://github.com/okopanja/SharkPlanner/blob/main/Hooks/SharkPlanner.lua

The problem is that the "lua_state" is not associated with particular files. The "lua_state" is used and shared by all cockpit scripts during loading and execution. In this "lua_state", any script has the ability to change any other variables and functions. Where the script originated doesn't matter to lua_state. If there is ONE file, just one file that not protect by IC . You can run any code throughout this procedure and access all functions and tables as long as those scripts are in the same state. include overriding tables and functions, manipulating strings that originated from other files and hijacking the loading process. bypassing the IC completely. For example. A loadout.lua file inside of users/missioneditor folder, which is not protected by IC, and supposedly should only contain a loadout table. because this file and unit_db use the same lua_state. We modify this file and add our custom code. while loading it into the ME. All of the units, weapons, and sensors in the _G table(globe table), are accessible via this file. Imagine a user modifies the missile's speed to Mach 20 and range to 100 nm. ED must make the unit database readonly in order to prevent cheating. So they have to separate the "ControlsIndicator.lua" to a different "lua_state", which also requires them to modify the C++ part. Introduce extra work, and It's up to them to decide. But it is very unlikely they will make changes for those indicators.

the QR code and manual code are compatible with every program. It's using the standard TOTP algorithm (RFC 6238). Compatible with any 2FA program that supports RFC 6238, which means almost every 2FA program does. Google also use RFC 6238 by default, but you can choose not to use it.

Careful North! Careful! [emoji1] Sent from my SM-A536B using Tapatalk

Well, there isn’t an aircraft designed that’ll take that sort of damage and shrug it off. You’re talking about high caliber systems. The goal is to avoid getting shot, because you’re likely not going to survive the encounter….which makes practicing autorotations moot.

Everything is good in this regard! You just need to study the screenshots well!

It is, that it may not be for you, or even the majority, is nice for y'all, and is also besides the point.

Everything makes sense save for the zeroing. CZ in VIS mode should zero out the slews made in this mode. As written here, to zero out the HUD symbology in a VIS mode, you have to go to a PRE mode then hit CZ. This makes no sense and I think that's what everyone's confused over. You don't go to a VIS mode to zero out something you did in a PRE mode, especially since PRE mode ignores slews made in VIS like it should. Hitting CZ in VIS should zero the slews you made in VIS, going to another mode should be unnecessary, and the write-up in the updated logic pinned thread backs this up. The pinned thread says that to zero a slew made in a mode, you have to go to that mode and zero it. But here you're saying we need to go to a DIFFERENT mode and zero it. Here's the relevant writing: Cursor slews are now possible in several different modes that are independently accumulated. As an example, the VIP cursor may be slewed and zeroed independently of the Navigation cursor. If Cursor Zero is pressed and "CZ" remains displayed on the MFD, it is because another cursor still has cursor slews applied. This may be seen when the DTOS/VIS cursor is zeroed back to the FPM, but the main Navigation cursor may still be slewed away from the original steerpoint location. To zero the Navigation cursor, CCRP or CCIP should be entered and then CZ pressed. This is providing an example where the nav cursor has been slewed elsewhere, not to expect the VIS mode CZ to reset that. This makes sense. However, the VIS mode according to you (and this write-up), does not actually move the STPT, it sets the current STPT to the slewed location IN VIS mode. We know this because if we go to PRE mode, the slew is gone like we expect. These two statements cannot both be true. Also, this thread suggests this behavior is a bug: TL: DR; hitting CZ in VIS mode should zero out all slews made in VIS mode without having to jump to another mode to zero out what was done in VIS.

I too enjoy a good recce mission. It would be nice to have RF-4B/C Recce Phantoms. The USMC B for carrier operations with post SURE upgrade with updated navigation, sensors, ALQ-126B DECM and slotted stabs. A USAF C, preferably a late 70's-80's RF-4C, with ARN-101/DMAS, G-139 LOROP pod, UXD-1 Laser recce pod, AVQ-26 PAVE Tack (39 A/C), ALQ-119/131 DECM pods and, towards the very end of their service lives, some machines carried AIM-9L/M. I doubt it will happen though. Early B from 60-early 70s. Two post SURE upgrade RF-4B's Note the PAVE Tack on the belly of this Alconbury bird. Bergstrom AFB 67th TRW I'd go for a RA-5C or Recce Voodoo as well.

Why should it be acknowledged that the system needs to be thrown out when the screen shots demonstrate that it's working? The screenshot I presented didn't actually show anything I had said it didn't. Rather, in your hunt to prove that it was there, you ended up pointing to something completely different, which was the first clue, and then you provided another one when you finally started giving the information that was needed to constructively participate in the discussion. You are not playing on a good monitor — it is very likely that that it is distorting the image for you (including the screenshots) and showing you stuff that just isn't there. This is why you pointed out non-existing dots as “proof” of your position. But the proof wasn't there. At no point did you manage to show something that I had said didn't exist. It's really that simple. Who? It certainly can't be me since you know my name and have no need to refer to me as “the other guy”… so your reference here is quite unclear. And if you are saying that it was me, then I'm afraid that no, that's most likely you misinterpreting rendering artifacts as something they're not and you need to be very clear what it is you think you're seeing and where. The farthest out anyone — including, and especially you — has been able to accurately point to an aircraft in the pictures I've provided is out to 50km. At that point, they are by very definition of the word, not clear. And they are, as I have repeatedly mentioned, still too visible… but even so, it's a massively improvement over how it used to be. It is working. It is moving in the right direction. There is no reason to rip it out at this point when we haven't even seen the results of any tweaks. If you want to present an argument why these at-the-very-edge-of-visibility dots are rendered incorrectly or shouldn't even exist, present that argument. This constant sniping and misrepresentation is utterly useless and unhelpful for everyone involved. So here's a simple one to start with: why should the planes shown in my images not show up at the distances they do? If 50km is too much, what would you suggest was a more sensible upper limit for being able to after very close examination, spot the presence of a large fighter aircraft?

+1 Since we got the new cloud system almost 3 year ago there's basically been no updates at all?

An option to turn it off is now working internally, and I hope it comes out in the next update. Making a system that can work as perfectly as possible on every possible combination of equipment is daunting, but we are working to do our best. Thanks.

With respect to visual engagements, because of the weapons that the F-4E carried during the bulk of its service, you’re going to have to learn to maneuver to your opponents rear quarter. It’s going to be fun to watch, but the skills required will make you a better ACM driver. No more put the lift vector on, feet on the instrument panel, pull as hard as you can with both hands and pretend that you are ace of the base in your sporty F18. I can’t wait.

A-7E Corsair II development updates https://flyingironsimulations.com/blogs/news/dcs-a-7e-development-update

Since 2.9 has anyone else been getting lots of intermittent big lag spikes ? I know for sure it is MP lag, because the guys I was flying with all got the lag at exactly the same time as me

It doesn't. Space doesn't stop mattering just because it's a certain size. If your disc is full and you need 2 GB, then the ability to remove 2 GB is useful. If you need 4 GB, it's still useful because it means it saved you from seeking 2 GB elsewhere to remove. You're really overlooking some basic situations here. Uninstall options exist for a reason, and it's partially because managing space is a lot more sensible than buying new drives all the time. A bit of a weird statement. Whatever the universe is, it only makes sense to ask for something beneficial instead of sitting around lamenting that you don't have it.

A reminder to all in this thread, please keep away from political discussion. thank you

I have no issues with all three assets.

I have plenty of storage. Why should I fill it up with stuff I don't need? Oh really Sharpe, is it? I take it you think the module manager is curtailing and complicating the development of the game, effectively asking ED and other developers to stop making modules, maps and campaigns? Oh so you're actually in favour of this, then? And are just arguing against it, for, reasons?

Would be really nice to have a MiG-29 to be able to have a high performance full fidelity Red-For aircraft.

Getting same issues on dedicated servers...

Even as someone on the side of wanting more liveries, I don't mind having to click a download button if it's all in an easy to use system like the module manager. My preference would be what @Northstar98 suggested though. Either way, a manager for liveries benefits pretty much everyone.

I found this very interesting video, many information about stick, lift center, gravity center, relaxed stability and so on

Yes, 15 on a multiplayer server last night trying to run a mission. Had wingmen freezing and re appearing. Apaches that were 2 human crew desyncing into earth or just losing control as pilot out of sync with cpg. Real struggle, caucuses map too.