Leaderboard

So just to check since it was so close. The 110Nm Shot in the real world test terminated at 157 seconds of flight, assuming the target maintained a constant mach 1.5. If so, the AIM-54A in that shot travelled at an average speed of Mach 2.9 (1660 knots) to consumate the intercept at 72.5 Nautical miles of travelled distance. In my Shot against a slightly lower altitude target, the missile traveled a ground distance of 74 Nautical miles in 152 seconds. An average speed of Mach 3.05 (1750 Knots). So even now while this is definitely within any reasonable margin of error, the AIM-54A Mk-47 is just barely overperforming the real world. There is of course enough room for error in either my performance in flying and employing, or in details that are unknown from the real world test shot for this to be used as any more than a curiousity and a datapoint. Overall that it is THAT CLOSE is quite cool. Just to put some percentages to it, thats a time error of 3% shorter, a distance travelled error of 2% further, and a speed error of 4% faster. I'm going to dig up the old pre-patch motor values If I can find them and redo the shots and see how far off they were. Ok, Redid the shot above with the Pre-Patch Phoenixes just for comparison. The Old Mk-47A completed the shot in 138 seconds, travelled 77 Nautical Miles in that time, and flew at an average mach of ~3.35 percentage errors from the real shot are 13% shorter on time, 6% further on distance, and 15.5% faster on speed. The Old Mk-60 completed the shot in 121 Seconds, Travelled 80 Nautical Miles, and flew at an average mach of ~3.97 percentage errors from the real shot are 23% shorter on time, 10% further on distance, and 37% faster on speed. 110NmPhoenix-A PREPATCH shot.zip.acmi 110NmPhoenix-A CURRENT PATCH shot.acmi

Just one thing I wanted to note on this, in the outsiders view for the 110 mile shot, it states the phoenix topped out at 103,500 feet and travelled a distance of 72.5 nautical miles to impact the target. Note how closely the current AIM-54A Mk47 matches that. Tops out at 103,943 feet (103,500 for the real world) and travelled a ground distance of 74 Nautical miles to impact the target. That's.... quite close.

DCS: Sinai Development Report The total size of the DCS: Sinai map is 1500 x 1000 km, of which, 700x700 km will be in high-detail. The map includes the entire Sinai Peninsula, eastern Egypt and the Nile Delta, southern Israel including Gaza, western Jordan, and western Saudi Arabia. This area features a wide variety of landscapes like mountains, rivers, desert, agricultural areas, sea and bays that provide a variety of mission and campaign settings. The map is being designed to represent the 2000s and up to the present. It is planned to recreate about 40 airfields, both military and civilian: Wadi al Jandali, Abu Suwayr, Faid Air Base, Nevatim Air Base, Ramon Airbase, and many more. The map also contains many military bases and strategic seaports that allow for interesting strike missions. A large number of military facilities and bases will help realize various historical scenarios based on the Arab-Israeli wars, as well as fictional missions and campaigns. Major cities include Cairo (including Cairo International Airport), Ismailia, Alexandria, Suez, Port Said, and others. About 100 unique objects and architectural monuments will be included. All objects and assets are divided into territories to present greater unique, regional characteristics. The coastline of the Suez Canal, the Gulf of Suez, and the Gulf of Aqaba will be created in detail. The project will consist of three phases, and each phase will include airfields, unique objects, and unique scenes. The first phase will include the entire territory with major cities and 14 air bases in Israel and Egypt. The second phase will add 11 more airfields. The third phase and final phase will add 12-14 more Egyptian military airfields. The OnReTech team is making every effort to ensure that customers will receive the first two phases in early access, which will help to fully reflect the theater of operations of the Arab-Israeli conflicts.

Summary: DCS World is creating invalid ballistics objects which are not cleaned up. These ballistics objects persist until mission restart and have a significant impact on the performance of Multiplayer servers, measured in "Server FPS" or the number of simulation frames per second that the server is processing. Background: Ballistics objects are spawned whenever a rapid fire weapon starts firing. They may also be spawned when cluster munitions are dispensed but I have been unable to confirm that. Ballistics Objects tend to have an impact on Server FPS which depends on the power of the server, the number of objects and, apparently, the number of connected clients. This is because the server has to spend time calculating the trajectories and other properties (Collisions etc.) of these ballistic objects. Here is an example of Ballistics Objects being spawned when rapid-fire weapons fire. You can see that the number of Ballistics objects in the mission spike when a shooting event starts and the resulting impact on server FPS. You can also see that the number drops back to 0 as the ballistics objects expire. (Note: The below graphs come from a liberation mission running with only AI running on a home-server) Bug: There are times, however, when Ballistics objects increase without an associated shooting event (Or any other event that I can find). You can also see that after this jump the objects are not cleaned up and the number of ballistics objects in-mission steadily accumulates. If we look at these objects we can see that they are invalid and they are always identical aside from the main ID. Their type is all 0, their coordinates are all 0 and the lat/lon is always at map origin, the country is 99 which is not in the country enum. Clearly these are not something that should exist. "33584385": { "Pitch": 0, "Type": { "level3": 0, "level1": 0, "level4": 0, "level2": 0 }, "Country": 99, "Coalition": "Enemies", "Flags": { "Jamming": false, "IRJamming": false, "Born": false, "Static": false, "Invisible": false, "Human": false, "AI_ON": true, "RadarActive": false }, "Name": "", "Position": { "y": 0, "x": 0, "z": 0 }, "Heading": 6.2831854820251, "LatLongAlt": { "Long": 34.265515188456, "Lat": 45.129497060329, "Alt": 0 }, "CoalitionID": 0, "Bank": 0 } I have also noticed that these invalid objects tend to (but not always) spawn 76 objects at a time as evidenced below (Note: This graph is from a Hoggit Georgia At War session). The trackfile for this Liberation mission can be found in the attached `liberation-mission.trk` which is tiny because, I assume, there is only AI. Impact: The accumulation of these Ballistics Objects has a deleterious impact on the Hoggit multiplayer servers (And potentially others, but Hoggit is what I was analysing) due to the fact that the server still has to assign time to process them even though they are doing nothing. Here is a graph of a typical mission on Hoggit Georgia At War. You can see that the server FPS steadily decreases as the number of Ballistics objects increases. I could find no other metrics that shows such a correlation. You can also see that the number of players also has an impact on the server FPS in that the FPS recovers very slightly as player count drops at the end. I am not sure if the number of players amplifies the impact of the ballistics objects but my assumption is yes because on a server with very few players the impact is not as great. (Note: The below graphs come from the Hoggit "Georgia At War" server) As well as a corresponding increase in CPU usage: You can see here that the number of invalid Ballistics objects is in the thousands. However I have also observed that this depends on which of the two missions that make up "Georgia At War" is running (P1 or P2). In one mission the Invalid ballistics objects consistently numbers in the hundreds and one in the thousands. However even just a few hundred ballistics objects has a massive impact as well. I have observed this behaviour across about 20 different mission sessions. Track files for some GAW sessions with this ballistic object accumulation can be found here: https://drive.google.com/drive/folders/1-_Ae-h6dl5s2k9v1FWwfkME0OBOflbWt (Size warning. 300-400MB) Request: Eagle Dynamics to find the root cause for these invalid ballistics objects being spawned and fix it. liberation-mission.trk

You're absolutely right. And, frankly, I want this project to succeed more than anyone else. It upsets me knowing that life takes the upper hand of my time, availability and commitment. That said, I won't let that stop me from achieving what I want. The MiG-25RBT will happen: a community mod by the people, for the people. This is the one thing, despite years of poorly backed up promises in the modding community, that I will absolutely commit myself to making happen. Vapour Labs has currently made what we consider "vaporware" here, and I want to turn that into software. In the next few weeks, there will be a GitHub organisation and set of repositories set up for the project. There's still plenty of work remaining to be done on the MiG, and just to be transparent, almost everything besides the 3D models have been lost due to struggles during COVID-19. But I'm absolutely willing and committed to continuing, even it means I have to start almost from scratch again. I really wasn't a knowledgeable nor good modder years ago, and there's plenty of things I still regret, but I want to make this project not only a redemption to the community but a gift that sets a higher standard. The DCS: MiG-25RBT Mod will happen because the community here is freaking awesome, and I can't lose grip of something that people also want besides myself. Positions will be opening up soon due to the result of COVID-19 eliminating most of my original team backing up the project.

Bogey Dope with more info on the C-130J

And here is what that looks like in DCS. I fired a 54C-Mk60 and Mk47, and then repeated with a 54A-Mk60 and Mk47 so you can see that all missile variants meet the performance. Fired in PD-STT. Only difference from the real test is the AI wont fly at 50,000 feet. Highest I could get the Backfire was 43600 feet. All missiles impacted with ~50 seconds of battery life to spare. 110NmPhoenix shot.zip.acmi 110NmPhoenix-A shot.acmi

Your missiles battery died 200 seconds in. You launched it at .8 mach, against targets that are going .6 mach. This is what the actual 110 mile shot profile looked like, from the Outsiders View of the Awg-9 weapons system. F-14 at Mach 1.5, Target at Mach 1.5

"Missile?" "Yeah, RIO?" "I want you to hit that target 30 miles outside Rmax." "It'll be hard, but I'll give you my maximum effort! Wait... you said thirty- three zero?" "And if you can't get to it, I want you to not even try." "But... look at the range- why are you shooting me? FCS, back me up, son!" *pushes button* "WAIT, BRO?!" *WHOOSH*

Not yet, sorry. I'm working on the remaining seasons. Once they are ready, I'll update the first post with the link. As for the previous version, I won't be uploading it till the end of the week (need some space on my google drive for testing new releases). Please be patient - you won't regret it. AUTUMN:

Please show me once where we said something someone reported does not exist, when it really existed? We may say we do not see it or cannot reproduce it, but never did we not believe a factual report. But, if for example someone says "can't lower the flaps above 250 kts, they are bugged" and we say "that is not a bug, you broke them by overspeeding", and it then gets called toxic, it is creating toxicity in itself, if you'll pardon me pointing that out. No one is trying to shut you down, but you want us to change things we just have no access to. The F-14 is us, the missile guidance not. That's a nuance which is not outrageous to ask to understand. And it is not toxic if we do so. Which is what Fringe was trying to point out, again, trying to help you gain perspective. And while ED may be a meme to you, they are not to us, and to the contrary very forthcoming and helpful, but you will have to forgive us that certain things take a certain time. You say you want these things talked about, but when we talk about it, you say it comes from a - fair enough, as you say, seemingly - toxic attitude. If a discussion means only agreeing with what you say, then it is quite frankly not an invitation to a discussion. Not sure if I come across wrongly here? But I hope you do notice that I am trying to have a reasonable conversation with you. There is a whole lot of claims and accusations, which I am sorry, I do not see all just as substantiated as you put it, and that is something you will have to accept just as much as I have to accept your being displeased with us. We can talk more about loft, if you want, which btw I already acknowledged twice now, and many times before in general. We are aware that it is irrational in certain regimes. But we also mentioned and explained several times in the previous thread that it is the best compromise given with how loft is currently handled in DCS, and why in most circumstances it is not only not wrong, but correct as is. I also acknowledged it is being worked on. In essence thus it is not being worked on fast enough in your opinion, which is fair, but reality dictates the speed, not willingness. We want loft to improve, but we, ourselves, cannot do that. We have no control over that part. And again, imo to ask to kindly understand that is neither outlandish, nor toxic. "Should" is a word used often in air to air, because it depends on so many factors. Anyone who says always "is" instead, I would take with a grain of salt. And again, when the testers do tell you "does", because they did so many tests, which Fringe told you literally in his reply, you fail to see that, you instead choose to see it as a "firestorm of ppl trying to tell you that you are wrong" and to reply "thank you for proving my various points about *testers*" ... I am not even going into the "what information we are missing" thing, because I fail to see how you could possibly know that. We're open for criticism, we are exchanging with the community likely more than many devs out there, and we always meet you guys on eye level. Calling us toxic, or our testers toxic, for trying to provide clarity, is not fair, especially if you just literally asked for that, then don't like the answer and come in barging with accusations in such a manner. I get it, you find it frustrating, and fixes for some issues are not delivered fast enough for you. That is fair. We will try to do better, I mean that. But please try to refrain from accusing our testers to have a toxic attitude towards you, they are not. You are instead being toxic towards them, you really are, so please understand if that is where I draw a line. You can express your being displeased with us, no biggy, but please do not involve those who are willing to give their free time to improve the game I would guess you care about, and on top of that are willing to help ppl on the forums to understand and learn the Tomcat better. Thank you for respecting that.

Admiral Kas update! She's almost complete. I need to add the Navigation lights and the surface-to-land missile. Shouldn't be much longer. It's moving slowly but i'm getting her completed. Thanks for your patience!!

Time to revisit the accuracy of AA/AAA. Here's some links to stats and info: https://www.quora.com/How-effective-were-anti-aircraft-guns-during-the-Second-World-War https://www.lonesentry.com/articles/ttt07/german-aaa.html The first study includes data from the US Navy and as an example shows that for say the 20mm AA, that it would normally take over 5000 rounds to kill an aircraft. The second talks about the use of larger AAA, like the FLAK38/41 including: The Germans had stats that it took roughly 16,000 rounds on average to bring down a single bomber. The FLAK guns had a minimum 20 second period for the fusing, and were typically employed against targets at over 20,000' To predict where to fire a large AA - "This method requires that the aircraft be flying reasonably straight and level for about 90 seconds before reaching the predicted point" To sanity check how the above stands up in DCS. I setup 3 airfields, one with a single 20mm AA. The other two with FLAK unit and the spotting kit, then flew a P51 straight and level over each. At 2000' the P51 was shot down on the 4th burst of fire by the 20mm At 5000' the P51 was happily engaged by the large FLAK At 10000' the P51 was happily engaged by the large FLAK The track file is here: https://drive.google.com/file/d/1IVThE92KoJQTkER03k7lcTQd6sIXFtO6/view?usp=sharing If the above links are anything like accurate that would imply: - The big FLAK shouldn't have been shooting at the P51 at 5000' and 10000' - Accuracy of the shooting against a target at 2000' is simply too good

Yes!!! Enviado desde mi SM-G981B mediante Tapatalk

The community does not have access to any APIs that can garbage collect these objects as far as I am aware. I fully agree that it will probably take time since debugging can be a pain and hope ED do not rush the investigation and potentially come out with a non-fix or break something in a rush to resolve the issue. However I hope that "It might be something in the mission" will not be a position that ED take as a reasoning for doing nothing since the DCS World Platform should not allow invalid objects to be created via its APIs in the first place. It should instead return an error if it is incorrectly called rather than silently create invalid objects. * If the problem lies within DCS world and can be fixed then great! * If the problem lies in the scripting involved in the missions then the DCS World API that is allowing these invalid objects be created should have validation added and return an error instead. Not just in this case, but in general.

В том то и дело, что добавить команду на Российский Авианосец - не требует никаких особых сложностей. Достаточно чтобы они там просто стояли и переминались с ноги на ногу. Анимация есть. 3D модели тоже есть. Но не делают. Раньше там хотя бы Камаз Пожарный стоял. Теперь просто как неживой. Очень уныло смотрится.

К счастью, это малозначительный и ненужный модуль. При этом в DCS широко представлены современные самолёты стран Запада: F-14, F-15, F-16, F/A-18C, всякие Миражи да Харриеры. Какие-то Еврофайтеры в планах, Страйк Игл в работе. Ещё Геркулес теперь. А что у красных? С-ный И-16.

Dear all, As part of this patch, we are very happy to conclude a major overhaul of the AIM-54 Phoenix! This effort is intended to bring you significant improvements in realism based on new analysis and insights into the AIM-54, further enhancing realism and more accurately depicting air-to-air combat of this era. Regrettably, our journey with the Phoenix is somewhat long, owing to the difficulty of simulating even older ordnance. In the end, our goal has, and always will continue to be, to achieve a greater level of realism across all facets of our simulation, even at the cost of some inconsistency over time, investment and time. We are not afraid to take a step back, further analyze and improve upon our work to bring all of us, and you, one step closer to the ultimate simulation of the F-14 and its trademark Phoenix. Over the course of this overhaul we gained many new insights and new knowledge, through new documentation and SMEs, that has increased our understanding of the AIM-54 missile, ultimately helping us to improve the simulation of this iconic weapon. It is a continued journey of discovery and learning, and we appreciate you all being a huge part of it and helping us to expand our knowledge and insights through your outstanding and unwavering feedback. Thank you! With this update, we believe that we’ve reached a point, where both -A and -C variants are depicted as close to real life as is possible with the current API/schema. Any further updates to guidance and features will have to come as part of a renewed effort to fill any remaining gaps that may remain. On a general performance note, we’ve very thoroughly tested these changes, and have recreated all known test shots from 1972 and 1973 (with the -A) as part of our verification process. Every missile has strengths and weaknesses, and particularly with older missiles, one has to play to its strengths to not only make it work, but make it work consistently. In that sense- we will be very much looking forward to your feedback and results. We truly hope you enjoy the changes, both as F-14 drivers and otherwise, further detailed below: Motors Upon further in-depth investigation and consultations with SMEs, both the MK-60 and MK-47 motors were found to have somewhat incorrect performance. Of particular note is that with newly found data we’ve concluded that the MK-60 motor performance was too high, and this motor now more closely aligns with the other motors. Thusly, we’ve adjusted motor performance to levels which now more closely reflect real life performance as follows: MK-47 Mod 0: Reduced Impulse: burn time is the same but thrust is reduced. MK-60: Reduced impulse significantly: thrust is the same, but burn time is reduced to 20.6 seconds. MK-47 Mod 1 (originally the C motor): Impulse has been reduced to be the same as the MK-47 Mod 0, however this motor produces a reduced level of smoke. The MK-60 motor has been made available for the AIM-54C. Guidance As many of you have noticed, we’ve been working on guidance for the AIM-54 for the past several months- continuously improving tracking and terminal performance. In this update, we’ve continued this general guidance work, and all missiles have seen their proportional gain increased, yielding better terminal performance. Primarily as part of this overhaul however, we’ve made significant changes to both the -A and -C specific guidance models, which now gives a greater depth of simulation of both missiles, as well as differentiating appropriately. Specifically: AIM-54A The -A model of the AIM-54 is rather old, and unfortunately not very smart. This will now be more accurately reflected in the missile’s behaviour and how it guides on targets. Reflecting the lack of internal guidance, the AIM-54A will now only track when the target is actively illuminated by the radar. This means the missile will only guide periodically in Track While Scan (TWS) mode. The guidance updates can be observed when viewing the missile in external view. Single Target Track (STT) will still illuminate the target constantly and as such the missile will guide the entire time. We’ve also reduced the chaff resistance of the -A to a level that we believe is more appropriate. Overall, the AIM-54A guidance will more accurately reflect being a product of its time and being limited in processing power. Note the periodic guidance updates of the AIM-54A AIM-54C In stark contrast, the -C is a smart cookie and we’ve now been able to implement some additional features to reflect this. Importantly, the missile will now go active on its own. This is important as previously the -C had to receive a command from the aircraft, limiting its capability somewhat in situations where the shooting aircraft had to turn away. We’ve also reduced the chaff susceptibility of the AIM-54C, and added a MK-60 equipped -C variant due to motor interchangeability. One remaining small limitation is that in STT, the missile will erroneously go active on your target (it should remain semi-active all the way to target). This is unfortunately a limitation of the API at this time. We endeavour to model this behaviour properly in the future. Overall, we hope that you will enjoy this update and are greatly looking forward to your input and feedback. We believe we’re now one step closer to the ultimate F-14 simulation, and we’ll be continuing our efforts to get ever closer as we continue our journey out of EA. The full changelog of the update is as follows: DCS: F-14 Tomcat by Heatblur Simulations AIM-54 Overhaul, Part 2: Increased PN gain for all variants. AIM-54A will now only update guidance when the target is illuminated (you will see the missle periodically update). Corrected motor impulse (reduced MK47 a bit and the MK60 significantly). Reduced MK-60 burn time from 30 to 20 seconds. Both motors have the same total impulse now. The MK60 has a slight advantage during motor burn time, while the MK47 has an advantage in burn time. With increasing altitude the difference becomes smaller. MK47 Mod 1 has now the same thrust/impulse and burn time as the Mod 0, but with reduced smoke (was previously weaker than the Mod 0). AIM-54C should go active by default (even when losing lock from STT). Increased AIM-54C chaff resistance. Reduced AIM-54A chaff resistance. Added option for AIM-54C with MK-60 motor. Adjusted AIM-54 missile empty mass. Adjusted MK-60 motor propellant mass. Set the JESTER option for automatic PDSTT -> PSTT to disabled by default. Fixed several issues with damaged avionics and flight systems (including jammed flaps for example) not allowing a repair to be triggered. Potential fix for CTD with F-14 AI (was not applied correctly in the last patch). Fixed emergency sweep logic: Fixed commanded wing sweep position being saved over to a new aircraft spawn. Fixed emergency wing sweep handle moving to spider detent on new aircraft spawn. Fixed wing sweep indicator commanded position bit mismatching with the actual indicated position. Fixed emergency sweep handle able to be moved between 68° and 75°, after being stowed at 75°. Now it has to be lifted to move it again after it has been stowed. Fixed wing sweep indicator raising EMER / OVER flags when wings get swept past 67 degrees. Fixed turn indicator needle deflection rate. Fixed mach buffet not dying off beyond M 1.3. Fixed an issue with the AWG-9 track logic to avoid tracks being thrown by aircraft launching air to air missiles. Fixed LANDING CHK light remaining illuminated after touchdown. Fixed Manual Throttle not unlocking after disengaging the Autothrottle. Fixed all mission versions of “Watching the Devil Dog” not being able to be completed successfully. Fixed VF-31 AE-200 and AE-205 1991 by Mach3DS - thank you. Fixed VF-14 AB-100 and AB-103 1796 by VFlip - thank you. Added Top Gun 114 by LanceCriminal86 - replaces previous Top Gun livery. Thank you. Updated Rogue Nation by YaeSakura - thank you. Thank you! Sincerely, HB

Для любопытсва сделал автопилот замера максимальных скоростей самолёта в зависимости от высоты. Там всё просто, скрипт разногоняет самолёт по горизонтали, ждёт когда скорость перестанет расти, пишет данные в лог и аккуратно поднимает самолёт с заданым шагом и т.д.. Обратная сторона простоты - на больших высотах у некоторых самолётов сильно меняются коэфициенты эффективности плоскостей. Нужна будет правка коэфициентов, для норманльно горизонтального полёта. Пока публикую то, что есть. Вроде как всё довольно наглядно. При какойто заинтересованности, продолжу работу. Speed.xlsx

Adding manpower (or money) doesn't always speed things up. It can also slow them down if done poorly, and will have no effect in the best case scenario (read: the new dev is told to stand in the corner and refill coffee mugs) if the tasks are already maximally parallelized. This might already be the case with the core overhaul, particularly since it's not uncommon for some otherwise parallelizable tasks to be held up by a need for a certain milestone to be passed by another task. For example, new ATC and Dynamic Campaign might both require under the hood changes to AI logic to enable them to hook into the AI's decision making process, which can only be implemented as part of a larger task that simply isn't there yet. Generally, if you can improve a project's ETA by simply adding another person halfway through, that means it was critically undermanned when it started. A project properly staffed and budgeted from the start will not benefit from either extra people or extra money, and in fact can even be slowed down by that.

How can all those 3rd party content free resources from ED? edit: ED states over and over that more than half of the team is working on core improvements. So all I hope from all the announcements is that ED earns to grow even more, which is the best way to speed things up imho.

null

Gents, Appreciate the passion and discussion and thank you for the great feedback. A couple of notes and we won't really comment more in-depth on two topics: re the nozzle exit area: We are aware of this not being "correctly" set and this was (at least for now) intentional per the steps we took during development. We're revisiting this topic, but as of yet it's unclear whether this will change. Without delving into specifics, it's not as easy as setting it to the correct real nozzle exit area without more due diligence. Re guidance- we hope to make further improvements in this area, however it requires the help of our partners and moving the missile to the new schema. We'll be driving this topic forwards as quickly as possible. Guidance can have significant effects on kinematics, and over the years both guidance and our subsequent kinematics have changed. Right now, we've chosen to make a missile that is as close as possible aerodynamically - even if guidance isn't perfect yet. This to leave ourselves with the correct foundation for any improvements that should come from guidance, not aerodynamics, possibly at the cost of lessened performance for a time. Thanks again for all the wonderful discussion and feedback!

Neither was Grinelli Simulations, nor Airplane Simulation Company, nor Aviron until recent announcements Edit: Or indeed the company making the Sinai map, or the one making Australia map, or even Orbx themselves despite being otherwise pretty famous in sim industry.

The C130J is instabuy from me, if for no other reason than to experience how a large, heavy 4-engined aircraft can perform in DCS World. Doing logistics in multiplayer in the Huey and the Mi8 was my go to for a long time, so this will definitely be an upgrade. As for the other projects, I really, really hope that we get an F-111 from a third party developer, but that's probably just a pipe dream at this point.

To OP's point, it would be nice if the User Files had a filter for "fictional" liveries. The Wind Riders Aggressors schemes have recently been spamming the User Files (for all modules) and have been making it hard to find other new liveries. When users upload their liveries they can simply tick a checkbox for "fictional" and it gets categorized appropriately. Users searching/browsing for liveries can simply tick a checkbox for "include fictional liveries."

To fix it, it is good practice to supply feedback and test results. That's why I do bother to help the team narrow it down. The effect of switching shots between target and waterline hasn't been reported AFAIK and I am very aware that it is WIP. That's why we have the Openbeta, to catch these things and provide input, data and feedback to help getting it fixed.

No one has ever discredited what you said, to the contrary I both acknowledged it and tried to explain it, as well as re-assuring you that we are very much interested in fixing remaining issues. But you'll still have to allow me to disagree, where I disagree, please. Loft being improved is a consequence of guidance improvements, but we have no control over lofting of missiles in DCS, so it is not a changelog item for us. Not sure where you see this inconsistency between what is written, done and happening. We are completely open about everything we do, and everything that has changed. And one also needs to be precise: the over-lofting is a bug happening from mostly over-pitching, which is a bug that is not aim-54 native. The missile going very high as quick as possible, is benefitial to its terminal velocity. Just because it looks like going straight up from the pilot's POV, it doesn't mean it is always wrong. Do we think the lofting is perfect? No. Personally some very pointy lofts at closer ranges seem suspicious to me. But medium to long range the loft does not appear wrong to me at all, neither to our SMEs. But it is also not something we can fix. It is not an aim-54 issue. The aim-54 only illustrates it better, due to its longer range. Same as stuff like flying around the mountain (thank you for the video, btw). We can only make an overhaul of the things we have access to. We cannot overhaul ED's missile guidance. This is not meant to shift blame, but please understand that it is equally not constructive for us to say "yeah it is on us", if in fact it isn't. And as I mentioned, we are working with ED to resolve these issues. If you feel like me trying to be helpful, is descrediting folks, my apologies, but I hope it is clear this is not the intent. However, you will also have to forgive us, that we kind of have to refute misconceptions, wrong impressions or false statements. There is no harm in doing them, but it's not very wise to just let them stand, so naturally there needs to be some back and forth. Also, please forgive me, but I really do not understand where we a) broke the missile (it changed, it didnt break), where testers are denying the change (who also try to be helpful in understanding the new missile better), and why a patch should not reflect community feedback, which is the entire point about it, as long as the feedback ofc is based on facts, and not on opinions or feelings. As for our testers, who spend an enormous amount of their free time trying to improve DCS, and who are actual members of the community and in large parts members who have been active for nigh two decades, with a lot of community work and experience under their belt, including SMEs: it would be nice if what they do would get appreciated. We most certainly have no intention to rotate any of them. And trust me, our testers are far from being blind followers. They give us the same scrutiny as you do. We would not want it any other way.

Let's put you in the role of tester: provide a Tacview of a level shot Phoenix, ie, non-manually lofted, of any type, that performs a loop or over the shoulder response. Herein, again, lies the problem- its not the testers saying "git gud"; there is nobody on this side of the table who doesn't want people to have their Phoenix launches connect. The SMEs confirm the profile. The materials confirm the profile. The devs express this, and the testers reinforce with hundreds of shots during the lead in to release. Update drops. Community outliers choose to not accept the guidance provided, perform their own routines, and come back and claim everything is broken. We literally witness Tacviews where the claim is made there's no attempted loft, have the images shown here, and oh, look- there's a manual loft you can literally see in the missile smoke trail. Actions that need to be discredited are going to be discredited in practice. That's not being a fanboy, and not defending a developer blindly. That's expecting people to actually use the weapon as intended, rather than making it up as they go along then coming back complaining that it's broken. Sorry, but no. When some of us have manually shot 100, 200 or more Phoenix rounds against varying target types in all ranges and looks, plus group MP test sessions, and none of them become moonshots based on simply honoring the shot profile, they're rare. HB works through the flight dynamics and increases the guidance capability while expressing the limitations under which the weapon must be fired, the player base needs to then own their part of the equation and use it like it's being explained, and own up when they aren't. Everybody loves Victory's comments. He says center it up. Everybody jumped for joy over Puck's 75 minute 10 Percent True interview. He discussed the limited azimuth shot envelope and 20-30 mile hold. But nobody wants to honor those limitations, wants their big angles and manual loft and shoot a missile thats two and a half times as large as an AMRAAM and get 120 mid range performance out of it, then come back and complain when it doesn't work. Sorry- you can't have it both ways. You can't call for realism, then complain it doesn't work when shot in an unrealistic fashion.

После слов Chizh о политической обстановке, я уже очень сомневаюсь в появлении новых красных модулей от ED.

Есть ощущение что чем больше внешников будет появляться , тем меньше шансов на целостность мира DCS. (Надеюсь я ошибаюсь)

Airpower 22 Austria Heatblur, I fell in Love with the Phantom and can't wait any longer

Working now in J and Juli real aircraft implementation!!!! Enviado desde mi SM-G981B mediante Tapatalk

RAZBAM M2000C improvements.

Yeah its a real thing and actually what causes the "snake" behavior of the earlier missiles. The optical system is an inverted cassegrain system so the dead center of it has a small dead spot between the secondary and the focus where the "reticle" is (not pictured). That's why there is a null. When the missile guides is basically steering the target lets say left/right through this null which is why it snakes back and forth as you can see in some actual videos. ED doesn't model that but you can see it clearly in the vids. And at any rate thats an ED issue not a Aerges issue, and honestly not a major one, though it does reduce the Aero range slightly for the missile which may be accounted for anyway. Next steps are to fix the Aim9J/P behavior as those should not autolock as they do now (look at the F5E for correct behavior). They would use the (uncage button on the throttle to do it) Also fixing the 550 behavior (which does autolock) but the uncage switch in that case returns it to boresight. And of course fixing the 550 seeker to be rear aspect (PbS seeker), and the 530IR (InSb) to be limited all aspect.

Like KlarSnow says, it should be much harder than what it used to be in DCS before we changed it but it should still be possible. We'll continue to have a look at this and tweak it.

This

OMG can we please stop with the wind riders agressor bull<profanity> skins...or can you guys move them to some fantasy server or separate category....this is supposed to be simulation not dungeons and dragons elite fantasy grand master token-holder decorating contest for cryin' out loud.

Where is Eightball?

They'd have to start somewhere.

It's quite possible the MiG-17 will be officially announced somewhere in this cycle. It's not been officially featured yet, so it can be that. Or, we might see something completely new.

Can you please post some pics of summer with low level ceiling? As If about to rain.

Hi there, Posting this since I thought this would be of interest for some of you the next time you head into a dogfight. I did some fiddling around and charted the STR of the Mirage F1 at various speeds. Hopefully this can come in useful when you dogfight. In essence, manoeuvring with just the automatic slats seems to give the best performance, whereas flying slower with the combat flap/lever extended affects STR severely. Additionally, manoeuvring above 440IAS causes the slats to retract, affecting the STR a bit. In essence, you can expect comparable performance from 300 - 430IAS, though the lower end of the range tends to force the aircraft at higher AOA meaning it's harder to bring the nose around if you need to. I'm finding sticking at 400IAS seems to work quite well. Hopefully this helps a bit, but if someone else has some feedback would be very welcome. Otherwise, I have been posting more of my findings on this unofficial DCS Mirage F1 Discord if you want to check it out: https://discord.gg/U79aAxrqRT Cheers, Peter

ED can you please make a slider for the F-16, F-18 and for the AH-64D where we can change the thickness of these lines in the game options? Standard setting are way to thick...

In the link are many pics of vintage Canadian H versions that served for many decades, and also the brand new J's we recently bought: https://www.silverhawkauthor.com/post/canadian-warplanes-5-lockheed-cc-130-hercules You can see the old vintage color photos, they were quite a sight!

For those who want to visualize the difference between the nozzle_exit_areas I've calculated (0.04525 m^2 vs 1e-6 aka 0.000001 m^2), here are some graphs. The performance difference down low is expected to be pretty marginal but once up high, its absolutely stunning to see the difference. Excuse the colors on the graphs since this was pretty rough and quick and I just reused the previous graph's colors. Click here for link to charts so you can hover over the values to compare with the motor performance from prior to the September 2nd patch 500m 6km 12km Conclusion: The AIM-54, both in the Mk47 and Mk60 configurations, have an additional peak Mach speed of ~0.6 Mach at 12km with the nozzle_exit_area of 0.04525 m^2. EDIT: Here are some bar graphs for Peak and Average speed for the missiles at 12km. Peak Average Here's the differences between the Weapons.lua (stock and new nozzle) that I used in order to perform these tests: https://www.diffchecker.com/v3DOf6fU

SRS supports that, as well as line of sight and distance (but it's up to the server owner) Sent from my HD1903 using Tapatalk