john4pap

I was trying to make that video today and spotted the problem. As you said, it was the T0-T1-TV switch being pressed at a very quick rate at spontaneous moments during the flight. It appears there's some kind of firmware/software problem with my throttle since these buttons are pressed without any user input. Many thanks TOViper!!!

I do have geforce experience too. I'll try it. Sent from my SM-J510FN using Tapatalk

Yes, I'll try to do that. What software do you use for recording? I've never done that before.

Thanks for getting into the trouble to read my long message TOViper :) That's a great guess and indeed it would explain a lot! However, I have assigned T0, T1 & TV as a three position switch on an 'axis to button' axis on on my throttle and it's pretty difficult to accidentally hit TV with that. Furthermore, I do remember that I had my radar in A1 mode in both cases, so I couldn't have taken visual fix. Still, I will keep this in mind when I try flying the mission again. Unless there's indeed some obvious mistake on my part, I suspect that there might be some bug triggered by the combination of the parameters I entered on the computer.

Hi! I have a problem with the Viggen's navigation system when I fly the third mission of the red flag campaign. I'll try to explain it the best that I can, although it plainly seems to go crazy at some random point. So, I tried flying the mission twice. The first time everything was going OK until the time I was approaching WP2 (perhaps some 60km away from it). The waypoint seemed to move further and further in the same direction. By the time I reached the real waypoint location (as shown in the f10 map), the waypoint in the Viggen's navigation was still quite far away to the north. While holding over the real waypoint location, at some points the waypoint was also turning so as to stay at my 12 o' clock. When I got the push order, I headed towards WP3 (Mount Irish) with the help of the f10 map, and got a visual fix of the waypoint. I supposed that this fixed whatever happened to the navigation system. However, while heading towards WP4, the system went crazy again with WP4 moving all over the place. The last two digits of the TERANAV (AKT POS) were stuck on 20 throughout this time. The second time I tried to make sure that I did everything right: REF LOLA - 9099 - LS TAKT - 9 - B5 AKT POS - B5 - TID - 162700 - B5 (time on target 16:27) AKT POS - B4 - TID - 086000 - B4 (Ingress speed 0.84) AKT POS - B5 - TAKT - 000050 - B5 (pop-up point 000 degrees, 5km) TAKT - 221 (motion measurement) (A while ago I heard there was a bug when inserting time on target and ingress speed (I think that xxJohnxx mentions it in one of his tutorial on YouTube). The workaround was to select the related WP in AKT POS. I only tried this the second time I flew the mission, just in case...) I turned the mode selector from BER to NAV once I entered the runway (I've heard that this is the right way to do it, but until now I was switching to NAV while still parked with no problems), I aligned as well as I could, and let the navigation system take its own reading between 100 and 200km/h during the take off run (in other words, I didn't press the reference button). I slowly climbed to 15000 feet (approx. 4570 on my backup altimeter that I adjusted for the given QNH pressure--the main altimeter was tuned to the target's QFE) and at some point the teranav display's last two digits started showing 20, 21, 22, 23, and 24 as I was holding over WP2. Everything's normal so far. When the push order was given, I headed towards WP3 and started descending. Flying over Mount Irish (WP3) fixed the deviation. The waypoint appeared to be in place (although the computer returned four or five km deviation by then) and as I passed over it the last two digits of the teranav display (AKT POS) showed 05 for the first time since I climbed to 15000 feet. Perfect! I continued flying low towards WP4 and at some point in the middle of the way, the navigation started going crazy again. While still some 30km away (I think) from WP4, the navigation system was updated, WP4 switched to U5, but the bearing to U5 was the same as that I was following for WP4. I selected WP4 again and found out that it had moved somewhere to the south. I then selected WP5 (the target WP) but it was constantly updated to different positions. I consulted the f10 map and when I reached the real position of WP4, I turned north to head towards the target. As I did so (from approx 260 to 0 degrees) the target waypoint was continuously updated to stay at my 12 o' clock. So, all WP4, WP5 and U5 weren't just in wrong positions, but were also constantly updated in a crazy fashion. The teranav second to last digit was on 2, sometimes on 5, and then it stayed on 1. I never had any problems with the Viggen's navigation system until flying this mission. However, I can't see how the problem could be related to something in the design of this mission either. Regardless the differences, the navigation system went crazy in both attempts. I'll keep on testing, however am I missing something obvious? By the way, I don't get any navigation system or other failure lights at any point during the mission.

I've just started the default mi8 campaign and had the same question about these strange fractions on the briefing map. Well, it appears that at least on the first mission of the campaign the distances are wrong for the first two legs. The briefing says the first leg is 12km while upon measuring it on the map it is 9.5nm/17.7km. Likewise, the second leg claimed to be 8km while it really is 6.2nm/11.6km. The rest of the legs are pretty much fine. I'm not sure whether I'm doing something wrong here, yet it seems that the person who made the briefing maps did not pay enough attention. Sent from my SM-J510FN using Tapatalk

I've selected stable 1.5.6 from the beta versions on steam and it works fine.

I'm in version 1.5 on steam and luckily I have saved an older version of dcs. I'll install it and opt out of any updates and see if it works. It appears that this is not a Huey specific problem and perhaps we'll have to wait for the next update for a fix. Many thanks for the answers. Sent from my SM-J510FN using Tapatalk

Hello, The error in the picture happens since last Friday. It is not random. It has happened once while touching down at the frigate in the UN campaign and then it consistently occurs while touching down at waypoint 3 in the same mission (I have tried it more than five times). I have also tried mission 3 of the Argo campaign. Same here. DCS crashed again having completed the mission and landing on the frigate (it's a landing related problem???). I had been flying the Huey for a few months and had never seen the error before. By the way, what changed on Friday - the day when the error first appeared - was that I purchased and downloaded Vigen DLC. Here's what I did: * Updated my nvidia drivers * Uninstalled & reinstalled DCS from file * Uninstalled Viggen (by unticking it on steam) * Uninstalled DCS and reinstalled it by downloading it WITHOUT Viggen. I am positive that hardware is not the problem. I have made no other changes in my laptop except for purchasing and downloading Viggen DLC. If there's anyone who could offer any help with this, it'd be very much appreciated. I also have attached the log file of the problem. I am not sure how to read it. All the best for the New Year to everyone, John https://forums.eagle.ru/attachment.php?attachmentid=175093&stc=1&d=1514446665 dcs.log-20171227-153951.zip

Just tried it again this afternoon. I flew an approach towards runway 9 as requested instead of going straight to the landing spot and permission was given this time. Many thanks to all! Sent from my SM-J510FN using Tapatalk

Many thanks for your answers, especially Ramsay for taking the time to compose such a detailed answer! At least I am now confident that I'm not doing something wrong. Frederf, if I understand correctly, you're saying that I have more chances to get a reply if I do things as the ATC expects me to do them. For this matter flying an approach like an airplane I guess. I'll try it. The ATC regardless how incompetent is surely part of the immersion.

Thanks Holton. I was flying around and above them for quite long while I was trying to figure it out. No luck. Eventually I crashed while looking at the avionics panel :D Sent from my SM-J510FN using Tapatalk

First off, the huey is the first and only clickable module that I own. My questions may be common with other modules that have clickable avionics. I cannot know that so I'm posting it here. Yesterday I was for the first time requested to use comms. Although the whole avionics stuff was familiar to me through flight simulator and I had already read the manual and watched some tutorials, this was the first time that I actually put it in use - specifically on the third mission of the UN Campaign ("reporters") where the captain asks you to get permission to land and let the reporters get off. After I found out the differences between UHF and VHF comms (and their corresponding channels, that is 2 and 3 respectively) and I discovered the alt+\ peculiarity on the Huey I was able to to contact the airport and get a reply for the "inbound" option on the radio dropdown menu. However, after a few moments the ATC contacts again and tells me to "contact tower" to request landing. Well, I hit the option to request landing but none replies at that point. Still, if I hit request azimuth from the same dropdown menu the ATC comes back with the vectors. It's only the request landing option that is ignored. Is it that I have to contact another frequency for the tower (there's no other frequency for the airport either on the briefing or on the F10 map)? Is it just a bug? Am I doing something else wrong. By the way, I have tried this with both VHF and UHF radios; same results. Anyone familiar with this? There's another thread in this forum about contacting tower on the same mission, yet my question is quite different.

oh yes, I now understand the logic of the f10 map and I think that I like it. Indeed, it some kind of intelligence instead of 'what you see from the cockpit' map, especially when set on the 'fog of war' option. It's indeed a pain spotting new targets, yet after some 80 hours on the frogfoot I feel that I'm getting better and better. In the aftermath it's all about tactics and patience. Thanks for the tips :thumbup:

I believe that a restriction in pilot view is good and indeed realistic, yet sitting on my chair I can look straight up (90 degrees) without moving my body. Also, arguably in a real cockpit you would be able to look much further than 90 degrees with your peripheral vision which naturally cannot be simulated on a pc monitor (unless you have a VR setup which I don't :cry:) Peripheral vision is not very detailed, yet you can - for instance - keep on tracking an enemy fighter during dogfights, although you may not be able to see it clearly. I am not sure on how the developers could simulate these restrictions, yet I feel they're quite awkward at moment - especially the camera jumping which totally disorientates me during dogfights.

Many thanks Voodooman! I tried your recipe and I confirm that I was able to look up 90 deg at the centre of my screen. It's certainly much better than it was in terms of looking up, yet I did find it a little awkward finding the right position for looking forward. When I find the time I will also synchronize the DCS's head up limits with FacetrackNoIR so as to get rid of this annoying camera-jump effect. I also recently bumped into some other DCS thread in which the same issue is discussed (for some reason I can't find it anymore) and where people report that the looking up behaviour is much better in DCS 2.0. So I'm just looking forward to the next official update :D

Yugon, thank you for your detailed and helpful reply. I think that I now understand how the f10 map works and what to expect from it. Your explanation on the view options also cleared things up for me. Mine was set to 'all' (perhaps by default). I now have set it to the 'fog of war' which makes more sense, and adds a bit of a challenge.

Thank you sthompson, No, from what I see it's not realistic. It's just looks messed up. The trucks that I referred to in my previous comment were 'hidden' on the f10 map yet they were clearly visible in the middle of a valley among other targets that were shown on the map. Yet, some other targets which were actually hidden behind trees and buildings were 'visible' on the map. It doesn't make sense. So, should I assume that there's no logic through which the targets are displayed on the map? If so, how do I know whether an area is clear other than getting hit?

Thank you for your reply Slazi, I haven't designed any missions. I'm just trying to play the default campaign. So, are you saying that the designer of this mission decided to 'hide' some trucks and some AAA? Is there any logic behind this decision or is it mere caprice? If it's the latter then this renders the f10 map untrustworthy.

Hello forum, I've been searching for an answer for a while before posting here, so please forgive me if my question is too dumb or has already been answered. I've recently started playing DCS and I'm still getting used to the Su-25T. I have the target labels removed and I'm trying to learn how to spot targets manually. The only help I can get during a mission with regards to target-spotting is through the in-game f10 map that displays air and ground units and through which I can understand whether an area is clear or not. My problem is that it is not all ground units that are displayed on the f10 map. For instance, in the first campaign mission of Su-25T, the player has to clear waypoint 5 before proceeding to 6. While trying to do that, I made several attacks on wp5 until no target was displayed on the f10 map. Then I decided to fly low over wp5 towards wp6 only to get hit by some AAA that was not displayed on the map (eventually I also noticed that several trucks were also not displayed on the map). Is there any logic behind this behaviour, or is it just a bug? If it is normal, how am I supposed to know whether an area is clear or not?

I have made a short video featuring the problem (sorry about the lag, I don't know what caused it). If anyone knows what causes this bizarre behaviour, please advise: https://www.youtube.com/watch?v=1WoCm_0AkJI&feature=youtu.be

Thank you for your reply Rudel (EDIT: & firmek). I have already adjusted the curves to the desired settings and the three led's are visible at all times. By 60 degrees I refer to the virtual head movement in DCS. In real life and with my current curve settings this is no more than 20 degrees of real head movement. The little head monitor on the left side of FaceTrackNoIR that previews the head movement seems ok and smooth when looking up. The problem only occurs when I look up in DCS.

There's not been any activity on this issue for a while now, yet I'm having the same problem. When I look up further than approximately 60 degrees the camera movement breaks and I end up looking back on the horizontal axis. I am using delan clip with FacetrackNoIr and I'm pretty sure that there's nothing wrong with any of them since they seem to register the movement just fine (as shown in Facetracknoir preview). I have tried various settings in the server.lua file (user\Saved Games\DCS\Config\View\Server.lua) but nothing seems to work. This is what I have ended up with: ViewSettings["Su-25TM"] = { Cockpit = { [1] = {-- player slot 1 CockpitLocalPoint = {4.000000,1.000000,0.000000}, CameraViewAngleLimits = {20.000000,140.000000}, CameraAngleRestriction = {false,180.000000,1.000000}, CameraAngleLimits = {280.000000,-200.000000,200.000000}, EyePoint = {0.000000,0.000000,0.000000}, limits_6DOF = {x = {-0.200000,0.200000},y ={-0.200000,0.200000},z = {-0.200000,0.200000},roll = 60.000000}, I'm currently flying the Su-25T and I'm using the steam version of the game (if that makes any difference). Has anyone been able to fix this? Any suggestions?