Hippo

Is that right? I had understood that with R/BL the distances were both measured from the launch point or the turnpoint (if used). I reported a similar issue some days ago.

In the attached track at 02:03:50 I am trying to lock onto the blob, which I believe is the tu-22 parked on the apron, but the cross always appears to snap to a point just off it. Am I doing something wrong? Is it a bug? A real-life limitation? a2g_radar.trk

Fair comment, but bear in mind that I had no issues with the first coordinates message, which cleared exactly as expected and after which I could continue to fire guns/ missiles with the space bar. I've just flown the mission again and the same thing happened again: I was unable to use the space bar to clear the 2nd coordinates message or fire guns or missiles in the mission thereafter. You'll be happy to hear I was able to successfully complete the mission on this occasion, so I won't be back.

Thanks. if you mean: Note "a" and not "the" discounted price. I can't understand why they didn't just provide this information in the e-mail. And, apologies, I've just realised I posted in the wrong (sub)forum.

I just did a clean reinstall of my system and now find that the site for this sofware no longer appears to exist and that I am unable to register, and so unable to use it. Just wondering whether anyone else has had this issue, and hopefully knows of a solution. I had everything working just as I wanted with VAC and don't want to go through having to set up and learn another product. I get the following when I put in my details and try to register the software: although earlier I was getting

Hi. Thanks for the campaign which I'm now enjoying. I'm having a minor issue in the third mission, where I am unable to clear the second co-ordinates message by pressing SPACE. It does go away by itself eventually, but then later I find that when I try to launch a sidewinder at the Mig, it doesn't work. I have the space bar mapped (by default?) to the trigger, and it's what I use by mapping the key to my joystick trigger (with joystick software). (BTW the missile wouldn't fire even if I pressed the space bar so I doubt it's anything to do with the joystick mapping). I'm guessing something's gone wrong with the clear message functionality and it's "blocking" the SPACE bar from working. I got around it in mission by mapping another key. Apologies if it's me doing something wrong.

I have never experienced an issue with HSEL (and I use it a lot). I have had issues similar to the above if my joystick was not exactly dead centre, and had to turn on small deadzones to deal with it (I don't think it should be necessary to do this, and that instead the A/P shouldn't lock out on very minor joystick deflections off-centre).

Thanks for getting back to me. On further checking the issue is a bit more complicated than I thought, but I still believe there is an issue. In the mission below, the aim is to attack the enemy ship to the west, but neither your aircraft or the harpoons can go into the (purple) no-fly zones and the aircraft can't go north of the red line (or attack friendly ships)... ... so I want to launch the harpoon from WP1 so that it flies to WP2 turns to 260 (to attack the enemy ship to the west), then activates after 20 nm. Instead the harpoon just attacks the northernmost friendly ship (see track 01). However, it doesn't appear to be an HPTP issue per se, because if I remove the friendly ships to the north, then it works as expected (track 02). I'll add that I'm almost certain the harpoon did work as expected the last time I flew this mission around June 2022. EDIT: I think that what's happening is that the Harpoon is activating its search immediately at the turnpoint and have changed the post title to reflect this. Apologies for any confusion caused. harpoon_htpt_02.trk harpoon_htpt_01.trk

Bump... is this supposed to have been fixed? Because, afaict, the issue still appears to be there.

In one word: NO. I accept it's very subjective, but since the days of the CV1 when 90fps was easily achievable in DCS (a deferred rendering engine "upgrade" put an end to that), I remain of the opinion that running in reprojection is not "true VR". Reprojection was always supposed to be a stopgap measure for the exceptional occasions when a system could not cope with extreme loads, not the default. However, we must play the hand we are dealt... grumble... I now aim for 72fps on Quest 2 and can mostly manage it with low settings. 3080ti. </rant>

I'm very much in agreement with all of that. My aim is to run mostly at 72Hz on the Q2, with reprojection only kicking in under heavy loads, and I run lowish settings to achieve this. Running the same missions and settings I use for testing in the old and new rigs the GPU util, and the points at which reprojection kicks in are pretty much identical. TBH, I was hoping for at least a small improvement. I left the data on my SSDs untouched and wasn't expecting the system to boot, but to my surprise it did, so my comparison was even using the old installation of Windows 10. I am now in the process of installing everything from scratch as I would normally do with a new system.

I have just got myself a 13900kf and z690 mobo to replace my getting-a-bit-long-in-the-tooth 8700k which I'm using with a 3080 ti. I'm using the same 32GB of DDR4 3200 (plan to upgrade later) and the same NVMe SSDs (I just changed the mobo, cpu and cooler). It's early days, but comparing benchmarks, in practical terms in DCS in VR Quest 2, it has made NOT A BLIND BIT OF DIFFERENCE!!! I'm now wondering whether I should've just gone for that (exorbitantly priced) 4090 instead. If anyone thinks my results should be better, then I'm all ears.

Thanks for the response. I wasn't aware of the MT/ VR issue and I have indeed been using the MT version. I will now be away from my VR rig for about a week but will check on my return.

Once again, apologies if this is not a bug. Please move to appropriate forum if not. In the attached track I am putting the a/c into the landing configuration. If I engage the HDG A/P only, and use the trim (pitch) switch there are very large fluctuations in pitch of the fpm, which I don't see with the A/P turned off where I can use the hat repeatedly to very finely adjust AoA. To my understanding we should not see an effect like this when using a roll-only A/P mode. Relatedly, from my reading of the NATOPS, wrt ACLS it should be possible to engage ACL with CPL HDG on leaving the hold ("commencing") and keep it activated through the change into the landing configuration at around 10 DME. I see the same effect in this case which can make trying to do this very, very difficult. ap_hdg_trim_changes.trk

Just played and much enjoyed this campaign (SC with Nevada) again. Many thanks for putting it out there for free. In the above mission there was one thing I found rather frustrating. I am using VR, and I found that the targets only became visible far too late to really be able to properly line up. Even using VR zoom, the targets would just suddenly pop up. I got around it by using labels, which isn't ideal. I was hoping to get your opinion as to whether this is an issue others have reported, if there might be a setting that can help with it, and whether it just happens to be an issue with this particular type of target. Tanks, e.g., I can see as dots from much greater distances. I thought that increasing visible range might do it, but it didn't appear to make any difference. Having the voice actors makes a huge difference, btw. Great job all round. P.S. IIRC, the a/c starts cold and dark, and I think the briefing suggests that it starts with the a/c ready to taxi.

Bumping this as I have never seen (and don't now see) any difference when changing it: no matter how I set it I can't see any part of my image that is not anti-aliased. I haven't tried restarting the game between changes when testing as it doesn't tell me in the options that this is necessary. Is there anyone out there that is using it, sees that it definitely works, and sees a perfomance benefit from it? Some time ago I used to use Kegetys's mod which offered this feature, which very evidently did work, and gave me a noticeable perfomance improvement. EDIT: I've just run the same mission twice, with mask at 0.1 and 1.0, and not only can I see no difference, measuring performance shows no difference either. AFAICT, for me this setting does absolutely nothing.

Sorry to keep banging on about this, and you might want to move this post out of bugs and into the general forum, but the workings of this mode just appear irrational to me. Perhaps I'm missing something and someone can explain the thinking behind it. I have attached a second track. If you go to 06:06, I have designated the target near WP1. You will probably want to watch it speeded up. Why the following work as they do is inexplicable to me: The LAR appears on the HSI depending only on your heading and not on your position relative to the target. So the only point of this mode seems to be that the LAR is not shown if your aircraft's heading does not match (+ or - some angle) the selected heading irrespective of the aircraft's postiion. I can see no realistic practical advantage to using it instead of SL. gbu-24_clar_pp_01.trk

Thanks for responding. I don't have any such information. I probably should have posted in the main forum and not in bugs; it's just that this mode doesn't seem to offer very much to distinguish it from SL Maybe I'm misunderstanding something, but why use PP when you can just fly the bearing you want to the target and then use SL; all it seems to offer is to save the pilot from doing a subtraction (of bearings) in their head. It seems rather implausible that such a mode would be implemented when it offers so little additonal value to SL.

Sorry if this is not a bug, but if it isn't then I'm struggling to see the point of using CLAR PP over CLAR SL. The manual on p. 332 states This suggests to me that in PP CLAR the LAR should appear with larger steering errors. In the attached track I am planning to attack the target at WP1 on a heading of 270, by flying to a point near to WP2 and starting the attack from there. Shouldn't I see the LAR on the HSI well before I am lined up? Otherwise, what is the point? At 6:03 (first screenshot) I have designated the target. Shouldn't I be seeing the LAR at this point? BTW the arrow showing the offset ?steering error? 67 is not explained in the manual. Only at around 6:05 (second screenshot) does the LAR appear. Hopefully I'm explaining myself adequately, and apologies again if it's me misunderstanding. gbu-24_clar_pp.trk

Thanks again for your patience. Reducing the "video brightness", afaik, can't be done at the pixel level on a monitor, so it has to be simulated, to my understanding, by varying RGBA (and line thickness?). I think that the transparency value should probably be higher throughout the range. Also, I notice that the HUD brightness is by default (when a/c starts in flight) at its highest setting, is this reasonable/ representative of real life? Anyway, lowering the brightness solves my problem, but it would be nice to still see the target when the HUD is at a higher brightness setting. Left image HUD brightness at 9 o'clock (pretty much minimum). Right image HUD at max (full cw).

Thank you. Sorry for wasting everyone's time and for my disturbing lack of faith; if it's any consolation, I'm feeling rather stoopid now for not having tried that. When I turn the brightness down I can clearly(ahem) see it is indeed transparent. I will turn down the brightness in future when required. EDIT: Sorry to be a pain, but having thought about it a bit more, I still feel it's not quite right. The transparency goes down and the shade of green gets "brighter" as the HUD brightness is increased, so that it is virtually opaque at the default brightness setting. Would having the transparency not go down so much while the shade of green gets "brighter" be a possibility? I do realise that this suggestion might, technically, be nonsense.

I'm using VR. Sorry if I've got this wrong but I've been wondering about it for ages. I'm not sure this always happens but it seems to me that the symbology on the hud is opaque and it shouldn't be. E.g. when I place the ASL over a target at distance (i.e. a dot) to try and line up my approach, I can't see the target "through" the ASL which means I lose sight of the target.

Great post, thank you.

Thanks. Is the structure/ available variables/ etc of mission files documented anywhere, or have people, such as those who have developed mission generators, just had to work it all out for themselves?