Saab-FAN

As the title says, with the AMD StoreMI Software installed, I repeatedly get a crash of DCS during the loading process. Other games work without problems with the software installed. Regardless of where they were installed (on the cached Hard Drive, an SSD or a Hard Drive without a StoreMI Cache attached to it). DCS was NOT installed on the Cached Hard Drive and I tried it with the Saved Games-Directory on the Caches HDD, as well as on a SSD (without attached SSD-Cache). Btw. the DXDiag-Report was made after I uninstalled the StoreMI Software. The StoreMI-Version was 2.1.0.218 dcs.log StoreMI_Crash.txt DxDiag_SaabFAN.txt DumpStack.log

How about no change to the LD-10, but a few GOOD Chinese SAMs by Deka? Maybe combined with a challenge by Deka to ED: "Can you do something similar?" :D Btw. BlueFlag has a script active that disables radar once a Magnum is in the air. I don't think that it would be too hard to include that script in the standard-AI by ED.

The radar switches to Flood-Mode when it looses lock. In this mode it just floods an area in front of the plane and the missile follows the reflection of an object inside this flooded area. But it could also be that the lock was just temporarily lost and reacquired quickly enough for the missile to track the target and hit it (the fact that the lock-marker in the HUD was still there points to this possibility).

Before all of that, can we please have any type of Wing-Vapor on the F-5? :) AFTER all the systems of the Hornet are done.

I reached Mach 1.12 on the deck running from a Mirage at full burner on Persian Gulf after dumping everything I had, including the wingtip-missiles and the ones on the fuselage. At sea level that should equate to about 1370 km/h. Fuel was at about 3000 pounds when I passed the friendly sams at Fujairah, if I remember correctly. :)

I hope the Walleye can be added later. From what I read online, it was in service during Desert Storm and was deployed by F/A-18s. My guess why it's not implemented (yet, hopefully): The TV-Feed from the bomb to the radar-monitor in the cockpit. Now some observations on the AGM-45B Shrike: I've just fired several test-shots against a Fan-Song, Flat Face and SR-P19. When launched from about 8 miles in the direction of the SAMs (max deviation about 3° left or right) and at a 5° upwards angle from an altitude of about 7000 feet, the missiles track their targets pretty reliably. Their flight-profile is a bit strange, though: They first curve downwards but then pull up again once they find a radar-source. I had to poke the SAM-Site beforehand though, or the missiles wouldn't track at all, regardless of how they were fired. So they only seem to work against fully alert SAMs. I also noted that the missiles tend to follow the radar-beam of rotating radar-antennas, causing them to veer off to the left or right when approaching the antenna. Something the original Shrike was apparently notorious of (Wikipedia states that Vietnamese SAM-Crews just pointed their radars to the side to cause the missile to "follow the beam", not the source, and then turn their radars off - Result: The missile smashed somewhere in the jungle). So a good tactic seems to be to fire two shrikes 5 to 10 seconds apart in the same direction, to increase chances of hitting. Out of the 4 missiles I fired, 2 made direct hits, 1 made a near miss (close enough to destroy the Fan-Song), and one missed after doing a last minute course-correction to the right as the radar-antenna of the SR P-19 rotated to the right (from the viewpoint of the missile). All missiles had acquired targets and tracked them btw. I wasn't able to get any tone from the missiles and after carefully looking through the entire cockpit, I'm pretty sure that if there's some kind of RWR in the A-4E, it's purely audio-based, unless the Radar-Monitor is one of the first examples of an MFD :)

Looking forward to your credits in the latest patch-notes :D Nice work!

As there are already numerous requests in the two threads of the A-4E on how to employ weapons, I think it's a good idea to have a thread to collect information on this topic. So, anyone who has found out something, please post it here - For example how to do a dive-bombing attack, or how to employ the AGM-62 Walleye. Or how to enable the RWR / where it is at :) So far, I've flown the Skyhawk only a few minutes, using the Shrikes with rather limited success (they track, but tend to fly too low), so I can't add a lot of information, but as a start, I'll quote the post by Merker who has some good links in it about the radar, and basics like take off:

Has there been any word from the developer on this topic? They have managed to get a ground-mapping radar working in the Viggen, so I guess the biggest obstacle is out of the way. Doesn't have to be the BISON specifically, I'd be happy with any other modernized Mig-21 variant. The LanceR C for example. I read an article the other day that the MIG-21 LancerR C flown by Romania proved to be quite the challenge for a bunch of F-16s from Portugal during an exercise that was supposed to give romanian pilots a first look at their new office (Romania is in the process of replacing Mig-21 LanceR with F-16 Falcons).

Okay, was too lazy to look through the whole thread, but I ran into the same problem with a game I am developing and also was told the same thing by my teacher at the SAE: Use as few materials as possible to reduce Draw-Calls.^^ Every Drawcall causes overhead because the CPU has to tell the GPU what to do and if I remember correctly, DCS uses DirectX 9, which has not been optimized in that area. DirectX 10, 11 and especially the announced DirectX 12 will generate much less overhead for each drawcall sent to the GPU. Btw. as I said in my earlier post: The GPU is not maxed out yet. So it should be possible to save additional RAM and/or Drawcalls by calculating certain things in the shader. In my Game-Project we're using only the Red and Green-Channel for the Normal-Map and put the Specular-Map in the Blue-Channel. The Blue-Channel of the Normal-Map is then calculated by the shader-program that runs entirely on the GPU.

I have done some testing with a quite big mission I put together (over 100 units on the ground and in the air fighting), which pretty much maxes out the available computing power of ONE core (CPU-Usage never goes above 13%!). Frame-Rate in that mission is below 20. There seems to be an issue with the 3D-Model of the MIG-21. Idk if this is an issue caused by the relatively old render-engine of DCS that just can't handle all the polygons, or if there is a big bug inside the model. One suggestion: Check if you can reduce the amount of materials and thereby the amount of draw-calls for the model. The textures seem fine btw. The RAM-Usage of the GPU doesn't go above 2,5GB in the mission I created. Another thing I noticed (probably the main problem): Once I activated "Simplified Engine Management" in the options, I got a significant increase in FPS. Maybe there is a possibility to place the engine-calculations in a different thread that is computed on a different CPU-Core. (I also noted a short freeze of the entire game in other missions when I start the engine and also SIGNIFICANT slowdown when I put the plane into a stall.) In all, I think the biggest problem here is DCS itself, as it does only utilize 1/8th of the available computing-power in my PC. When I fly this mission in a A-10C, I get about 10FPS more, while CPU-Usage stays the same: 13% at maximum. Using the core-affinity option in the Task-Manager also doesn't really help. GPU-Usage (measured with GPU-Z running in background) also stays well below the 100%-Mark. My System: 8-Core AMD FX-8120@3,6Ghz, 16GB RAM, AMD HD7950 3GB, SoundBlaster X-Fi.

Maybe it would look something like this: http://www.stolidus-simulations.com/robotvacuumsimulator2013/ :megalol:

I think, you cannot go more optimized than this approach. Based of the code for the TGP/Mav-Views (the infrared-views seem to ignore any light-source, so you could probably tweak it for the use of just one light) for the render-target and with customized shader-code for the "Radar-Look", this method would do the job just fine. What you can do however, is to put a lower-resolution grayscale-texture into the game for the radar-screens. It would increase memory-usage, but reduce the bandwidth-requirements for this particular render-target, as only a compressed grayscale picture has to be sent from the GPU-RAM to the GPU, instead of an RGB-Texture. Also you can fit other information into the texture that way, which makes it look more radar-like. The best possible way to create this texture would of course be to use real SAR-Pictures of the area, created by satellites. :) The problem: To tackle this problem ED has to finish the engine first, or give specific informations about the features. Also the current code for the infrared views of the A-10C would help. Without this information, all we can do here is speculate about ways to do it. Does Coretex have access to the code of A-10C, to utilize stuff like the already implemented IR-Views? Edit: Or were you trying to aim at a realistic Simulation of an SAR? What I described here would just emulate (replicate the results) of a SAR. If used with the current ground-model and tesselation, this method would also take care of terrain-masking automatically.

DirectX 11.2 supports Megatextures, like the one used by id-software in RAGE (one GIANT Texture for the entire ingame-world). Maybe you can use that as the base (have the entire world-texture with tesselation-information edited to look like a Radar-Picture on the HDD and then stream the needed parts) and then just render individual units (Tanks, Vehicles, etc.) on it. The Engine has to support this feature too, of course. But ED is working on a new engine, so this method might work. Edit: In the Direct3D 11.2 Feature-List it is called "Tiled Resources" http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084%28v=vs.85%29.aspx#link

Ouch! That hurts! Should be a reminder to the old EVE-Rule: Don't fly anything you can't replace!^^

I think, an SAR could be implemented the same way, the TGP is and the Mavericks Sensors are implemented. They all provide an image of the ground through a separate render-target (thats how I would do it with the UDK) that is then used on the screens of the cockpit. I guess, the best way would be to go with the shader-code for the Infrared White-Hot view of the TGP.