dcs76

More interesting is: FYTTR ONE has FYTTR with DME 267/33 and FYTTR TWO has that navpoint with DME 270/33. Neither of those charts is correct (269/33). The question now is: Did the USAF pilots fly with the incorrect DMEs from FYTTR ONE?

I noticed that there are a lot of FLIPs/charts around for Nellis. There are excellent FLIPs made by vJABOG66 and the 476th VFG. None of them seem to be accurate for the year 2011 though. The FLIPs from the v476th are correct in terms of the radials/DMEs I verified, but the material is not as extensive as the FLIP from the vJABOG66 and there are pixelated charts which isn't good for printing in high resolution or having readible kneeboard pages based on. I mostly wonder about the naming of the procedures. For instance, from what I could find, the FYTTR TWO departure became active in the year 2014. Before that it was FYTTR ONE. I'm not sure though, what was before FYTTR ONE and when FYTTR ONE became active. However, 476th and jabog66 both have FYTTR THREE/FOUR in their FLIPs which became active some time after 2015. Does someone have the actual procedures/charts from 2011. I could only find those from 2014 and 2016. An AFI11-250 for NELLIS AFB from the year 2011 would be excellent.

I did some experiments with GBUs. The laser designator was illuminating a target from one side while another pilot dropped a GBU from the other side. The GBU should not have LOS on the laser spot. However, in any case the bomb hit the target perfectly. We used a stock building and we used a construction of containers from the 476th range targets mod. In all cases the laser spot should not have been visible by the GBUs Paveway sensor. We illuminated the ground right next to the object/building or the wall facing away from the GBUs. We also used LSS in one aircraft to find the spot and again despite not having LOS on the illuminated surface the aircraft was able to spot the laser. So it seems that LOS for laser is not working. Can anyone confirm this? Is this a bug or is it just not simulated?

Neither the Dropbox link nor the link to the 476th download mirror is available. Is this mod obsolete?

I created some kneeboard pages for the normal procedures of the DCS F-16 module. You can find it here: F-16 Normal Procedures You can also find the pages as image files ready to be copied to your DCS kneeboard folder here: f16-normalprocedures.zip

I also still have this issue. I deleted the fxo/metashader folders several times over without success. I'd rather keep the smoke densitity to 4 as I want to see chimney smoke.

Could some of the experts please explain to me how to interpret/employ the HUD symbology in HARS mode? I can see that the depressible pipper is still available. I can still switch between CCIP, CCRP, GUN, and NAV mode with the mode select button, but I'm not sure if this is correctly implemented in DCS. I noticed the depressible pipper having "eyebrows". What are they used for? I suppose they are for estimating distances due to their well defined mil distance to the pipper, but what is the mil difference between pipper and eachj eyebrow? How would I employ this knowledge? Is HARS even correctly employed in DCS? Is your virtual fighter group training your pilots in using HARS?

@GGTharos. Oh that's is very valuable input. Thanks! In order to look out for the cockpit reference points, it is necessary to have the same head position. Is there a procedure on how to align your position for the A10? Are there some objects I can align in order to get the correct position like in other aircraft? I fly in VR and need to change my position a bit more forward and up. Not sure if the is the correct position.

Ok, there might be different kinds of instruments/systems being damaged/malfunctioning. For instance if the IFFCC is out of service, you don't get a CCIP solution and have to do manual bombing. If the HUD is out of service, you can switch on the standby HUD and get that depressible pipper. If EAC/CDU is malfunctioning, you still get that pipper. If you do not have a pipper at all, bombing is just a gamble I agree. I assume that distances to targets can also be estimated by comparing them to the HUD symbology / pipper size or other reference objects (like those "antennas" sticking out left and right at head height from the seat). But please don't let us get side-tracked by the question whether and when we would actually use manual bombing. I just want to do the calculations.

I want to create bombing sleds on my own to understand the theory and math behind it. I understand that those sleds are usually created by each squadron in real life and maybe even created per mission. Also I want to figure out how good the ballistic model implemented in DCS is compared to real life. Before I go into a totally wrong direction, I want to provide my progress here and get some input from experts on that matter. I know that DCS is incorporating drag and wind in simulating the ballistics. I verified this by just calculating an expected bomb parabolic in vacuum with and compared this to actual bomb drops in DCS (with the help of TacView). The values were not close as expected. In order to check how close the DCS ballistics model is to real life I did a lot of (about 250 so far) bomb runs with MK-82 on the center station with the A-10C at different release altitudes, dive angles and speeds. Again I used TacView to get the values. (Side note: I noticed some deviations with TacView. When do a bomb run and record the metrics with TacView, then use DCS to watch the recorded track again and again capture the metrics during replay of that recording, TacView does show different values for the two different replays. The deviation is small, so I hope it can be neglected. I did this in standard atmosphere. bomb target was at sea level (I simply let the bomb hit the sea). Wind was zero everywhere. The current results can be found here: https://docs.google.com/spreadsheets/d/1No9rlRnPx9m74BlGR8MJ7XCg5r8mxsbOhcztxz2R_uM/edit?usp=sharing Bomb ballistics data for dive angles 45 and 60 is a bit tricky as it's quite hard to capture the exact airspeeds I need, but eventually I will have this data completed. For real life I did only find ballistic tables for the Mk82 starting at KTAS 400. The data provided there for time of fall and bomb range more or less seem to match what I measured in DCS/TacView. The bomb ranges are off by about 100 ft and the TOF data by about 0.1 s. My airspeeds, release altitudes and dive angles where not exact which might even explain the deviation. As I do not have ballistic tables for airspeeds below 400 KTAS my captured data is still quite valuable - I hope. With the measured data I then calculated the aim off distance and the aim off angle and depression from planned flight path. I hope the calculation is correct. Now I need add the angle of attack to the depression. In order to do that, I need to calculate the AOA at the bomb release point. I understand that the AOA is based on drag index, gross weight, altitude, airspeed and dive angle. I hope to find some charts or tables for the A-10 which would help me. Maybe there are some formulas which can be used. So this is what I need to research next. Furthermore I need to get the data for the altitude lost from bomb release until after executing the safe escape maneuver. This is of course dependent on the SEM itself. I intend to calculate/measure the data for CLM at first. Also I will need to measure/calculate/get the data for the aircraft to start a dive at a specific angle, airspeed and altitude in order to arrive at a particular release speed and altitude. I'm not sure if minimum time for fuzing is important in DCS. This needs to be clarified as well. I have some formula to calculate Initial pipper placement, so this should be covered. So much for the research. Again, any information you can provide would be highly appreciated. I also heard that real life A-10 pilots train manual bombing quite often as they do not want to RTB when they have issues with there instruments while there a troops on the ground who need their help. I understand the concept with the pipper depression, but cannot understand how the pilot would measure the distance to the target when TGP and CDU are damaged and thus cannot provide this information. The distance would be quite important for the roll in point and to correct errors during the dive. Also, how can you get the dive angle correct without a HUD? Do you use the ADI or VVI for that?

Just now I noticed the Mods and Apps section. If a moderator could move the thread there, that would be terrific.

DCSMissionTweaker With this tool, you can convert any single player mission into a multiplayer mission. The tool can be used with missions of copyprotected DLC campaigns as well. The copy protection is not circumvented with this tool. All clients/players are still required to have a purchased license of that DLC campaign. Download Either compile the source code (found here) with Visual Studio or download a precompiled executable here: https://drive.google.com/open?id=1pqKflZaAkdw_mAOhSlpCsKup3NyI4ld9 SHA1: 84081c37f52b371e1aa72c8bad817c699aac50d9 SHA256: 8051d4d1d67768a804bfe1444b1341eaf260e2cd100e35dd1e7de399b75e2873 The compiled executable is not signed. Windows will warn you when you try to execute it. You need to "accept the risk". Disclaimer As stated, this tool DOES NOT circumvent any DCS copy protection. If you tweak a mission of a copyprotected DLC campaign, all joining clients are still required to have the original DLC campaign installed. Otherwise they won't be able to join. As this tool does not circumvent the copyprotection, Eagle Dynamics is ok with it. I have permission from them to publish it. If you want to know, how it works, see below. Limitations Quite a few missions use SPACE BAR triggers in order to advance the mission progress. Due to this reason, one of the players/clients must also host the mission. This hosting player is able to hit the SPACE BAR. A few missions also use conditions/triggers based on specific cockpit dials or switches. Again, those conditions/triggers will only work for the hosting player. Usage dcsmissiontweak.exe <path_to_missionfile.miz> <numberofclients> This will change the units of the group the single player is part of to clients. Only the first <numberofclients> units will be converted to clients. The tool does not yet increase the number of existing units within the group. If the group has fewer units than the specified <numberofclients>, only the existing units of that group are converted to clients. Requirements This tool runs on Windows with Microsoft .Net Framework 4.5 or higher installed. Planned improvements 1. Changing airframe This will allow flying missions with other aircraft. This will only work if the mission does not rely on aircraft specific cockpit triggers/conditions of course. As long as the new airframe has about the same capabilities as the original airframe the clients shouldn't have too much issues. The first iteration of this feature will not add any loadout on the new airframe. The clients need to add the loadout themselves. Additional iterations of that feature will attempt to convert the loadout from the original airframe to the new one. 2. Increasing number of units If the number of clients is higher than the number of already existing units of the group, additional units (up to 4) will be added to the group. 3. Additional groups (with different airframe) It will be possible to just add additional groups to the mission. The tool will attempt to be as smart as possible to add those units/groups. Based on the starting configuration for the original units, the additional units will be configured and placed. a few options will be provided to give the user some choice. 4. GUI For the users who like a nice GUI, there will be one. How does it work? Essentially, miz-files are just zip archives. The file "mission" within the archive is a *lua* config file. This file contains all units. The tool simply parses this config file and updates those units. The method also works with copyprotected missions because only the triggers/conditions, scripts, behavior has been extracted into an encrypted file (extension .crypt) located side-by-side with the mission files. The miz file contains a reference to that file. This reference is not touched by the tool. The encryption mechanism does not include any checksums for the mission file itself or other content within the miz archive. This allows modifying it without breaking the copy protection. It also allows placing that miz file anywhere - even downloading from a DCS server). Upon loading that miz file, the referenced encrypted and protected file is being loaded as well. If that encrypted file cannot be located (e.g. client does not have a license of that DLC campaign or did not install it in his DCS version), that user is unable to join the mission. Contributions Feel free to contribute to this tool. Add issues (to the github repository mentioned above) if you find any bugs and or create pull requests for enhancements/fixes.

I think the wake turbulence simulation is not working as one would expect it. Wake turbulence creates vortices at the wingtips which descent downwards behind the aircraft until about 500 to 1000 ft below the aircraft within 30 seconds. As the tvortices turn clockwise on behind the left wingtip and counterclockwise behind the right wingtip, the turbuences create a downwash directly behind and below the aircraft and an upwash on the outside of the vortices. The result should be that an aicraft trailing on center line should experience the downwash only and should descent when not correcting for the effect. When flying behind and below the wingtips of the preceeding aircraft the trailing aircraft should roll towards the leading aircraft. It seems that causing a roll towards the leading aircrafts flight path, the trailing aircraft is pushed further out. McGowan, W.A., “Calculated Normal Load Factors on Light Airplanes Traversing the Trailing Vortices of Heavy Transport Airplanes”, NASA TND-829, March 1961 Also the wake turbulence effect is experienced too much when flying behind other smaller fighter jets. There should be slight effects only (buffetting, small roll effects). Instead the effect is as if the leading aircraft was not an A-10/F-18, but a 747.

Wow, today I received an answer to my support ticket from ED: From Andrey Filin

This thread of mine was just closed by a moderator without answering the questions and thus leaving me hanging. Also this moderator has chosen to block any PM despite him stating in the closing reply in my thread that I should use PMs for further inquiry. So if anyone can help me out and let me know where I can find a list of moderators who I would be able to PM? Thanks! Additionally I would like to know why my thread was actually closed as my question did not violate any forum rules. I did not post any links. That wasn't even the point of my original thread. I don't want this thread suddenly closed as well so I won't repeat the question.

I read a few times already that ED (and probably also the 3rd party module developers) only use publicly available sources for creating the aircraft modules and weapons systems in the simulation. I was wondering what those documents might be and where we as sim users could read those. As far as I can see, almost all flight manuals are classified or have export restrictions. So those should be off limits I guess. Another option is of course to use video footage found on youtube and elsewhere, but this shows only a very small aspect and is in no way enough to create a simulation thereof. Asking/interviewing (ex-)pilots is another option, but I'm not sure how much those pilots would be able to share. In regards to export restricted documents, it might be ok (I'm not a legal expert here) that someone reads those documents in the US and writes a completely new document based on that information which can be shared with the sim developers in another county. However, I'm pretty sure that this method would not be possible with - say -34 documents. As I said, I would only be interested in the publicly available documents. Wouldn't it be ok, to have links to those in the DCS forum for each module?

Before I buy the plugin I wanted to try the free version. I am having trouble setting it up though. Everything is installed as described. The plugin is active in VA and HOTAS mic switch activates it. However, I see exactly what is shown in the troubleshooting video - it says Easycomms ON depsite having set it to OFF in both DCS Stable and OB version. It does not recognize the A-10C when loading into an instant action. I can see that the VAICOM plugin is available in both DCS versions. The Other settings menu shows a VAICOM tab and provides version information. I also tried to delete the export.lua (thereby killing SRS and TacView plugins). Restarting VA recreated the export.lua file. The content of the file looked good as well. Still no success. I have most current versions of Stable and OB. I tried both versions. I also have lastest VA and downloaded VAICOM a couple hours ago. Also the radio activate/deactivate sound is not played on my VR headset but on my primary audio output device instead.

The good thing is with the APU being so loud now is that I won't ever miss to switch it off again. Also I am more inclined to watch the engine gauges when spooling up as I am supposed to anyway.

I created a support ticket and hope they get the message this way.

Before I could engage the convoy, I was shot down by SA-19. Reviewing mission in TacView showed that the whole place was still guarded by a lot of SA-19s. All SEAD aircraft (Tornados) have been destroyed by said SA-19. It seems something is wrong with those Tornados. They should have dealt with the SA-19s.

As long as the F-18 fills the same pockets as would have a purchase of the A-10, the receiving end would be fine with it.

Creating areas like killboxes in the TAD is already possible by creating waypoints for the corners and adding them to a flight plan. You just need to add one WP as first and last to get a nice closed shape.

I'd love to have better TAD symbology/functionality. I would even pay loads of money for a more modern A-10 with the HMIT. It could be a separate module for what I care. However, I suppose we won't have any of this within the next decade unless there is public material available which the developers could actually use.

@Snoopy The engine sounds are more realistic in the cockpit now? ok, that's great to hear. What confuses me though is that the APU is so much louder to them in comparison now.

No, the targets are not harder to kill. This is not the issue. The issue is that I killed all targets at the first 3 WPs and 9 out of 16 targets on the last WP. This is more than 50% kill ratio at WP 4 alone and should yield a Q- rating instead of an U.