statrekmike

Sorry to resurrect this but has there been any movement towards fixing this. Now that we are about to get the Tomcat and its targeting pod, being able to spot and identify placed static objects (used as mission objectives) is going to be quite important. Not being able to spot any static object out past 8 nautical miles is a pretty serious issue to say the least. I don't mean to pester or anything but this is a huge deal and perhaps not a fix that would require a ton of man-hours.

I went ahead and turned wind off on one of my scenarios and did not notice any roll issue. This seems to be very much connected to how the aircraft responds to wind.

Has anyone tried it without wind? Does the roll still persist even then?

In real world BFM training, there are a lot of restrictions put in place that give the F-5 something of a fighting chance against more powerful, more modern, and much faster fighter aircraft. If you were to put even the most skilled aggressor pilot in their DACT focused F-5 in a real-life fight against a dedicated 4th or 5th gen fighter, that F-5 would get killed pretty quick if it tried to pick a fight. In DCS's public servers, this are a bit different because we are seldom dealing with real combat pilots and instead hobbyists who may or may not put a lot of time into learning tactics, procedures, and good pilot skills. This can create a environment where planes like the F-5 can actually thrive. If you were to construct a multiplayer environment that closely models real world doctrine in terms of air defense, AWACS support, realistic tactics, and highly skilled pilots, the F-5 would have a very, very tough time doing much of anything.

People are putting a lot of attention on trolling as a issue and while I have ZERO doubt that it will be a issue, I don't know if it is the larger issue at play when talking about human RIO's on public servers. As elitist as this might sound, I think that when we are talking about a module like the F-14, player competency is going to be a very, very large factor. The player in the pilot's seat is going to be dependent on the player in the RIO's seat in almost every way so having a RIO who never really put a lot of time into learning the radar, the navigation systems, or even how to properly keep a eye out for enemy aircraft is going to be crippling at best and incredibly frustrating at the worst. For some players, this is not going to be a big issue. Some are going to have buddies that they can fly with and reliably count on. This is a nice ideal situation but it is not one that is always feasible at any given time. Those who have a buddy that they trust may want to play on servers when their buddy is not available and in that case, it may be better for them to use Jester rather than hoping and praying that the random RIO they let in the cockpit has actually learned how to do what they NEED to know how to do.

This seems rather extreme considering that we have no idea how Jester will play out in servers as of right now. For all you know, Jester could be slightly worse in all cases when compared to a competent player who has bothered to do some amount of practice in the RIO position. That last part is important. Since there is no set standard for player skill on any given server, anyone who chooses to pilot a F-14 would have to (assuming a option exists to lock Jester out of a server) hope and pray that they get a RIO who has bothered to read the manual, learn how to use the radar systems, understand navigation system interaction, and can keep their head on a swivel the entire time they are doing all that other stuff. I don't know about you but I would rather have Jester than take a gamble on who ends up in the back seat. There is also potential player-count issues on certain servers and at certain times. If you can't get enough players to occupy a flight of F-14's, things are going to get kinda tricky.

Thanks so much!

I am putting together a sort of "training/practice environment" where I can spawn enemy aircraft groups in via the F10 menu. This in itself is not difficult but I wanted to try something a little different. To give you a hypothetical. The F10 menu might have a entry for "fighters" and when you hit that, it then selects one out of five different possible groups to spawn randomly. Is there a way to do this without getting into scripting and just using flags/triggers in the editor? If not, I have no real knowledge of how to do such a thing via scripts so if that is the only option, I would really need to know where I should start on that. I suppose the big issue here is that I can figure out how to get the F10 menu options to select randomly from a set of possible groups but I can't really figure out how to remove the group that spawned from the pool of possible groups when the player hits that button in the F10 menu again.

Are you doing navigation fixes to keep your system aligned? If not, I HIGHLY suggest referring to that section in the manual so you can learn how that works and what the procedures are. Another thing to keep in mind. If you fly low enough, your radar altimeter will work alongside your aircraft's computer to help keep your system properly aligned. If you fly higher than your radar altimeter can read, you will have to do visual fixes. This is part of the deal when flying the Viggen. It is part of what makes it interesting and challenging.

That is what many of us have already been doing for almost a year now. I have had the Harrier collecting virtual dust in my simulated hanger for quite a long time while I wait for it to get the functionality it needs to be used in realistic missions. I am not advocating that RAZBAM put a ton of time into talking directly to the community but at this point, a good, detailed post about where the Harrier is, where it is going to be, and what we should reasonably expect is not really all that extreme a request. Sure, I have other modules I can fly but I did buy the Harrier with the intent to use it in realistic missions. It has been a year and I still can't really do that. I know this stuff is super demanding and I know that some in the community can take things too far but let's not forget that we did pay for a module and many of us have been waiting patiently for quite some time.

I hate to join in on negativity but at considering where the Harrier is at right now and how long it has been since its initial early access release, I don't think it is unreasonable to say that this module is in pretty rough shape to say the least. At this point, it lacks a lot of functionality and even has some pretty serious issues with core systems that directly relate to its intended mission. Out of all the DCS modules that I own, this one is probably the "hanger queen" because I have been waiting just about a year to build a realistic mission for it but as of right now, I can't because the functionality simply is not there. I know you folks are swamped with work and I appreciate that this kind of thing takes a lot of resources and time. That being said, perhaps it might be a good idea (at least from the perspective of a customer) to issue a sort of long-form "statement" about the Harrier. Have the developers really talk about where it is right now and what it will really look like when it is done. If there is a problem with getting the required information or if there are parts that simply won't be implemented, we are at a point where it would be good to know so we can adjust our expectations accordingly. Again, I understand that things are hectic and that you don't have a ton of folks to throw at any one module but the Harrier is in very rough shape and some direct communication about that might help us know what to expect and how to approach the wait going forward.

Is there any news about this? Is this something that the team is working on currently? I know that it is probably annoying to keep hearing about this issue but it is a big one. It makes it pretty much impossible to fly strike missions that involve the targeting pod and any static objects. This kind of thing can really grind otherwise normal missions to a halt until it is fixed. Please, just let us know where we stand on this. It is a pretty huge deal.

Do you mean that this may be a fix in Wednesday's patch or that it might be in a later patch down the line?

I can't help but feel that flying a Hornet straight towards a armed warship with the intent to shoot a few Mavericks at it is kinda a flawed idea from the start. It is the kind of thing that you are certainly free to attempt and that is one of the advantages of doing such things in a sim versus reality but if you are hoping for a result that does not include getting shot down by surface to air missiles, I think you may need to start looking at this scenario from a real-world doctrine point of view. To be blunt, if you want to sink a warship, there is more to it than just strapping some mavericks to a plane. You are going to want to consider the larger picture. You are going to want to think about supporting assets (friendly naval forces), using the correct weapon for the job (probably a Harpoon), and even multiple flights/wing-mates that can also launch their weapons at the same time. At this point, it is probably best to leave Mavericks to smaller, less heavily armed ships and leave the warships to platforms that are actually configured to fight them properly.

Military aircraft tend to look worse for wear. Even if they are perfectly maintained, they still will not look all that new simply because it would be a waste of manpower and time to make sure that the paint is always touched up and the cockpit is in showroom condition. If one were to go to a Air force base and look at the active duty aircraft, they would find a lot of fairly "worn in" cockpits. Likewise, if you were to look at aircraft during a cruise on a carrier, you would quickly find that even a well maintained example is going to look rather weathered to say the least. To put it another way. The aircraft textures you saw in the stream ARE what you would find from a "well maintained" aircraft. That is just what these things look like when you actually use them.

In order to fully rule out a hardware issue, you may want to consider plugging the throttle into a powered (very important that it is powered) USB hub. As it stands, the X55 and X56 throttle both draw more power than a typical USB (especially a USB 2.0) can deliver. This causes random "ghost inputs" that can manifest even without the user touching the throttle. When I first got my X56 (functionally identical to the X55 in this specific regard), I found that I was getting odd random inputs. At first, I suspected a faulty throttle but when I plugged it into a powered USB hub, the issues went away entirely. Heck, at one point, Saitek themselves even advised users to go with the powered USB route as it seems to consistently solve the problem.

Is there any chance that we could get official word about the status of this issue from someone at ED? I mean, this is a pretty big issue and entirely prevents realistic mission types in certain aircraft. For example, it is impossible to do realistic on-station CAS stuff in the Harrier or even realistic CAP's in the Mirage. This bug has been around for a good amount of time and while I appreciate that the Hornet has probably placed a lot of demands on ED's attention but this is a kind of bug has a big impact and hurts the experience across a variety of modules. Is there any word on this? Is this fix in the works or is it further down the list at this point?

How high do you typically fly? If you stick to lower altitudes, it takes longer for the freeze to happen but if you fly at around 25,000 feet or higher, the freeze happens much quicker.

Good to hear that the ED team will be working on this. Hopefully it gets fixed soon. Heck, I would even go as far as to say that this is hotfix material due to its severity.

Just finished doing a test where I fly without external tanks at 25,000 feet. I had no freeze at all during the flight. From the looks of things, the external tanks are indeed causing the freeze and how long it takes to freeze depends on altitude. Sadly, this means that until it is fixed, I can't really fly realistic missions since external tanks are absolutely essential for many of its tasks. This is something that I hope can get fixed quickly as it can be called a game-breaking bug without hyperbole.

Did some further testing just now. I was able to have a very long flight in a Hornet that air-started at 10,000 feet. I was able to intercept a enemy aircraft (ruling out any combat related causes) and shoot them down. After that, I continued for a good while at treetop level without any issue. I was even able to maintain exactly 20,000 feet for more than fifteen minutes without any sign of a freeze. So it seems that when I do a air-start (with the same aircraft loadout, enemy forces, etc) at 25,000 feet, I freeze after nine minutes or so pretty reliably. If I stay at around 20,000 feet or lower, I don't have a issue at all. In order to narrow this down and hopefully gather some useful and consistent data, I went ahead and created a mission with three Hornet air starts, two Hornet ground starts, and a Mirage air start (as a control). It might be useful for all of us to try out the various Hornet air starts and try to fly at the starting altitude as long as possible to see if we experience freezes. The mission is attached to this post and while it may be tedious to do this kind of testing, it is the best way we can narrow this down without adding in a bunch of random and potentially distracting variables. crash test.miz

So I have been spending the better part of the day troubleshooting this (in hopes that I can get some information that can actually help solve this issue) and I can't. The DCS.log file is not really producing any meaningful results (that I can see), and there are no tracks produced or crash log to find. What I have noticed is that it seems to happen reliably when I set up a mission in the Caucuses where I am in a F/A-18 (set to client) that air starts at 25,000 feet. I put a Tu-22 (that I can spawn in using the F-10 menu) about 100 nautical miles away and we both head straight for each other. The mission starts fine and performance is very good. I do experience very occasional micro-freezes every now and again but that does not seem to be a issue. Once I get inside 40 nautical miles, (generally takes about nine minutes or so), the game will lock up entirely. It does not crash or quit on its own. It just freezes with audio in the background (probably looping over and over). At that point, I have to use the task manager to force the game to quite via "end task" but since it was a freeze and not a crash, I don't think DCS can generate a meaningful report. It seems to be kinda random. Sometimes I can get more than ten minutes (like last night when I flew the waypoint training mission). In the scenario I just described, it happens 100% of the time. Also, I have tried both the Persian Gulf map and the Caucasus and it freezes in both maps. I have also routinely deleted the metashaders and FXO folder. My graphics driver is up to date, windows is up to date. I have no idea what else to do at this point.

Same exact issue after today's patch.

Nope, I thought it was fixed last night but I just tried a basic scenario this morning (a player flown F/A-18 and a AI Tu-22 flying towards each other) and after about ten or so minutes in the air, it just froze dead. Again, this does not happen in other modules so there is something going on specifically with the Hornet here. It does not crash but it hard freezes and I need to end the task to quit the game.

Not using a anti-virus beyond the basic Windows 10 setup. Oddly enough, I went ahead and deleted just the "metashaders2" folder just now and was able to do a couple of long flights without incident. I will go ahead and do some more testing tomorrow but if things go as they are, it seems to be fixed.