john4pap

Lots of people are using ff and I believe that ff is the future of joysticks. I never had many problems with the Huey that others report, but it's nearly impossible to fly the spitfire with ff. It is not that much of a bug, rather an oversight. However, if ED wants to support their ww2 modules (where ff shines in my opinion) they will have to take a look at it. I understand that it is not a priority, however it can't be that difficult to have curves compatible with ff. Sent from my SM-J510FN using Tapatalk

Alright. Thanks again! Sent from my SM-J510FN using Tapatalk

Many thanks for your answer! That's really helpful :thumbup: On the speculation part... I'm not sure that I understand... are you saying that in the real Viggen, the pilot would possibly be getting more information than we do after trigger unsafe (altitude and steering cues perhaps)? But then he would have to aim again in order to hit the target?

Thanks for the clarification! I have read the manual on level bombing multiple times so I have already understood most of what you're describing. So, are you saying that the manual is inaccurate in saying that level bombing should be performed at 200m, and that 200m is rather the minimum altitude at which level bombing may be performed? If so, I can understand why we are given the choice of different safety altitudes. Now I'm wondering: what is the max altitude at which one can perform level release? Also, is there any reason the manual instructs to maintain 0.8 to 0.9 mach during level bombing?

Certainly. I'm saying that once you equip with low drag bombs and the safety height is left to default in the mission editor, you cannot aim to release in level bombing since the targeting cues disappear under the HUD. Correct? Now, if level bombing is supposed to be performed at "around 200m" (and supposing that this is accurate information), why should there be any option for different safety heights? The logical thing is that once a type of weapon is loaded, the aircraft should be automatically set up to be able to employ that weapon effectively. We’re supposed to be piloting the Viggen not performing the tasks of the ground crew, isn’t it? :)

Not per se, however it is inhibiting any satisfactory release if the targeting cues disappear under the HUD due to an incorrectly set safety height, isn't it?

From the manual (p.298): "Level bombing can be done in a slight climb or dive if necessary. Release altitudes is around 200 metres." From this statement only it appears to me that what you call "safety height" should be automatically set in relation to your armament. Under what plausible situation would a Viggen be configured to NOT be able to employ a weapon (here, level release with low drag bomb) just because the intended release height (200m here) is outside the limits of the "safety height"? Is this serious? If there is a reason for that, please do update the manual. RC2 was released in the meantime but there's nothing specific on safety height in it.

He speaks for many of us. Common sense implies that if you want to do something better with a module, you first put some work in it, then you distribute it for beta, and then moving yo stable. At the moment, the mirage has been broken for many months because the supposed "stable" is broken. Are you saying that the community should be happy with this? Do you actually enjoy flying the mirage anymore? It may be paramount to get the module closer to real life, but this doesn't mean I should get to see every single bug on the way there.

Indeed, that was stated clearly in the last open beta changelog.

I'm sorry but my message isn't a bug report nor is it listed under "bug reports". As mentioned above, I have lost interest in even tracing new and old bugs. If you are indeed interested to know about the bugs introduced in the mirage since late-2019 you won't have any difficulty finding long lists in the same forum.

Back in November (I think) this was a perfectly playable aircraft with the only bug I can recall being the INS update (ah, and the bomb recticle was off too). Somewhere around that time the devs decided to update it and make it more realistic (what could be more welcome than that!). Yet, this introduced a ton of bugs and a different approach to its functions, and after struggling to re-learn the "new" aircraft's systems I realised that my main difficulty grasping it was the ton of bugs introduced in it. I did relearn it, yet since then it remains grounded due to its new bugs. Now, I'm not a real fun of beta versions; I have a life and I'm no kid who wants to check the new features first. But since the last stable release is back in December, and having seen the recent changelogs mentioning bug fixes for the Mirage, I decided to check if the mirage is anywhere near being playable again. No, it's not. And in fact, I don't know and I don't have the time to check whether they fixed any of the old ones. I found new ones though: adjusting seat height isn't working any more, and the green box that appears on a target after locking it isn't always there anymore... Ah, and yet new approach to controls for locking targets and weapons employment; second time since November. I don't have the time to dive into this mess again, especially upon seeing that bugs are still there. So I'm back to stable with the m2000 grounded for an indefinite period of time. What I'm saying is that I do appreciate the devs work but never signed up to any beta-testing (ok, I did download the beta but only to see whether the broken stable is fixed). I would be more than happy having the old and less realistic but virtually unbugged mirage while being in anticipation for a new and bug-free update. I don't understand why the devs forced us with this. How about they give us the old mirage back until they finish it? Am I the only one here who has just been wishing for this simple solution?

I don't know if it's always been like this but bombs have always been problematic on the viggen. I would have very much preferred if the devs could address such problems instead of directing their resources to visuals such as pilot body and that fancy fan.

I felt you had something cooking for Christmas for us Viggen die hards. Many thanks, keep it up, and I hope to see the plane complete soon!

I found a couple of YouTube tutorials before posting this but they do it all wrong anyway--partially or completely disregarding the instructions in the manual. I hope this gets fixed soon anyway

Has anyone figured out how to get decent results with toss bombing? I've been trying it for a couple of days now. I understand that it isn't an accurate way of bombing yet the first bomb consistently falls a few hundred metres after the target. I have tried 0.9M at 4.8km, 0.9M at 5km, 0.8M at 5km, 0.8M at 6km. I have also tried different altimeters between 20 to 70 metres, and pulling up with 3 and 2.5G instead of the instructed 4G. All I'm getting is a relatively consistent result with the first bomb falling some hundred metres after the target. Ah, and the QFE is correct. The only way I managed to get some better results is by making a radar fix way before the target. This makes me think that the computer is making calculations taking account where the target waypoint is, and that's why my bad results are consistent with different speeds and ranges. However, if I understand correctly, the target waypoint shouldn't play any role on toss bombing other than helping the pilot estimate his course and distance to the target. It shouldn't have anything to do with the execution of toss bombing, right?

It has FFB support, yet it can spontaneously 'die'. I have a MSFF2 and it only happens with the Viggen and the Spitfire on DCS. Perhaps it'd be something to look into.

How about fixing the bug? It makes fuel tank jettison harder than it already is. Sent from my SM-J510FN using Tapatalk

I still have my good old MS sidewinder FF2

I was searching the forum for force feedback being too light when flying the spitfire. It always feels like I am flying with force feedback turned off in terms of stiffness, regardless of the speed and with some forces kicking in when making abrupt movements on the stick. Is this your experience? Sent from my SM-J510FN using Tapatalk

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