virgo47

In the meantime, I discovered a problem with another object on the Kola map - and the reason why I mention it is that it seems to depend also on the plane type, which is really strange. I tried the Dover castle with some other planes and it was quite difficult to reliably replicate the results. The suspicion is that it may be CPU bound because of intense collision detection, but it's just a hunch.

I wasn't around when Caucasus 2.0 dropped, but from what I've heard it was originally more detailed but not performant enough, and some buildings were removed - those are all the blurry patches on the map surface that look like low-res satellite image. Perhaps they could at least add some of those buildings back? It would make the map look better. Even in some training mission, "a water tower on your left" (or something similar) is mentioned, and there in nothing there. Those patches look really ugly.

Today I wanted to push myself a bit with a high-performance plane I'm not that familiar with. Sure, there is 5 m/s wind from 270, but still, I'm quite satisfied with my first landing without running over the runway (barely):

I haven't checked MSAA, however, it'd be funny, because I have a feeling that DLSS now ghosts much more. And the radar scan line in F/A-18C is not anti-aliased, it looks more like unaliased+ghosted (but this may be the effect of May 21 upgrade that mentions DLSS, I haven't played F/A-18C for a while). But it's not just this in particular, F2/F3 views also show more ghosting. It's difficult for a common user to track and compare these changes in this kind of technologies - and it may even be impossible if it somehow differs from GPU to GPU.

Ah, Steam, that's it. It's not available in DCS Shop (and I tested logged-out of the shop as well), that confused me.

I was one of those lucky ones who considered one or another module here and there and always postponed, only to be rewarded with the pack of 3. That's true. At the same time, the other modules were offered for a very good discount individually. They probably didn't feel the need to add three more duo-packs. So yeah, the laggards kinda won, but there were options. BTW: Why mention it now? I can't find the pack in the shop anymore.

I found the fix! I normally use MOUSE_BTN3 (middle mouse button) for clickable cockpit toggle (single press), but for whatever reason, it was double assigned also for Camera transpose mode (press and hold). This is the original binding, I'm not sure how it got applied, but after I removed it, the clickable cockpit toggle started to work with a single press as expected. Of course, you still need the Quaggle or something similar for it because it's not provided for the mouse by default (which is a trivial fix for the devs, but often ignored, not just by Mag3). For whatever reason, zoom axis with mouse wheel started to work after this fix as well, I have no idea why. But I'm a happy animal again. Still, Mag3 guys, consider adding at least some useful bindings options for the mouse - without actual bindings, just that the cells in Controls work and are not disabled. Thanks.

Great news! Will there be a separate lock and unlock binding for the latch? Was that the original intention?

Yeah, I don't really mind... and still, I Might Be Wrong (such a great song BTW), but there was nothing clearly describing this in the changlog, so I rather ask. I adapted already to the new version. Thanks for weighing in.

"has begun"

I don't know why I started my tests on Pagan in this map. It really is extremely short, and I didn't understand why some sources mentioned a longer runway, but the one from game more or less matches today's satellite image. So a volcano is to be blamed! Great OP. I'll welcome a few more meters/feet for this strip, it's really on the edge for any warbird.

Ah, good to know about the previous report. I was confused a bit, so I didn't even know what is and what is not the problem. I can't be sure 100%, but I have very systematic binding configs, I track them with Git and also make colourful spreadsheet for them. I didn't see any binding for that lock/unlock in my controls. I'm definitely sure I have to deal with the lever lock in some planes, but again, I'm not sure which they were (probably MiG-15 out the top of my head). But I didn't use this binding before. It works fine after I bound it, so if it's intended to work like this, it's OK. Of course, separate lock/unlock bindings would be nice as well. Maybe it would be nice to have hard-core Gear Up binding where one has to explicitly control the lock and one which would do it automatically. But I'm fine with the hard-core option only as well. (EDIT: I guess this is not necessary, when there is Landing Gear Lever, toggle, which does more or less the same.) I may be wrong (often I am), but I suspect it wasn't needed a few updates ago when I last flew Yak-52. I see a different landing gear bug reported from March, so maybe something was changed around it after all.

I'm not an everyday flyer with Yak-52, but today (after the yesterday's patch), I tried Yak-52 again and couldn't retract my gear. The reason is, that the gear lever is locked. I know I have some bindings for this in other modules, but I don't seem to have any for this one (checked all my configs for it), because it likely worked auto-unlocking until now... I guess? (Unsure.) Then I started to investigate the bindings for the latch and found this (search for latch): Was there a change related to this? Probably in 2.9.15.9408? That's the latest Release notes with anything about Yak-52: DCS: Yak-52 by Eagle Dynamics Fixed. Wrong brakes behavior via axes Fixed. Bindings for Landing Gear EXTEND and RETRACT not working Fixed. Binding for the Emergency Gear Valve backwards Fixed. Rudder by notch input did not move the rudder, causing a crash instead. Fixed. Elevator Trim Keybindings not working Fixed. Incorrect behavior of AI after takeoff and during landing. But nothing quite fits the description. It seems like the Landing Gear fixes broke something. If it was mentioned as realisme improvement, then it's not described properly. How should it work?

I haven't flown CE2 for some time (but I have not long ago), so I can't be sure about the version when this broke... but there is nothing about Christen Eagle in the release notes since the fuel/radio display patch (much welcome!). But now the mouse bindings don't do the right thing. I'm using Quaggles Command Injector with the following settings: {down = 3256, cockpit_device_id = 0, value_down = 0, name = _('Pilot torch light on-off'), category = {_('Lights'), _('Custom')}}, {down = iCommandViewAngleDefault, name = _('Zoom normal'), category = {_('View'), _('Custom')}}, {pressed = iCommandViewCenter, name = _('View Center'), category = {_('View'), _('Custom')}}, {down = iCommandCockpitClickModeOnOff, name = _('Clickable Mouse Cockpit Mode - ON/OFF'), category = {_('General'), _('Custom')}}, ...because your module does not allow binding these things to the mouse for no apparent reason. In the middle of writing this report, I suspected that maybe Quaggle got broken by the latest DCS upgrade (happens occasionally), but I have similar overrides for AJS37 and it works there. So something seems to be broken with the commands themselves in CE2: Zoom axis (mouse wheel) doesn't work (that one is not even handled by Quaggle) Single click to clickable cockpit doesn't work (the fallback default double click does) Zoom normal and View Center seems to work fine though.

I also suspect something like collision detection, and that would make sense to be different for a different plane. But on my part, it's just a guess.

OK, mission finished! Observations: With flares armed, it starts flaring when the missile is incoming. It's 1 flare a second or so, so it may be a good idea to add a few more manually. The automatic flare dispension does not stop afterwards, so the player may want to switch countermeasures to SAFE if they want to keep some flares for the next missile. You'll likely need to dodge one missile if you fly towards the cottage or even none at all if you fly over the ridge. Though, it's more fun to pop up, bait the missile and dodge it right. After the landing with the Alpha team, I let the newly arrived helos doing their stuff for a few seconds before joining them. I haven't encountered another missile after that. It's a fun mission after all, and it's also one of the shorter ones. Packed with action and tricky all the way to the final landing zone. (Just don't go through the orange smoke, obviously.) Case closed, one more to go!

OK, this time I was prepared... kinda. I slowed down the time when the missile launch was reported. Alas... I even set the flares counter beforehand (1). But looking at the panel now, the next time I'll also arm the flares (2).

Ah, I didn't know about those flares. I eventually managed to dodge some missiles, mostly when I was on the top of the ridge, and I dove down on the other side. But when I wanted to dive into the critical valley, I "bought" all the missiles so far. But I can't claim I took swift enough evasive action. This mission is not that long until that point, so it's not so bad. I'll try again and check the flares count before and after the successful dodge, and I'll report back here. Thanks for the info!

What is the best strategy to deal with the manpads (besides disabling them in the F10 menu, of course)? They easily cover the whole area, at least in theory, although they don't seem to shoot as far as the circles would indicate. But if I just go north of the river towards the hut, I've got a hit both flying low in the valley or close to the hut. One does not have much time for evasive manoeuvres, so it's mostly game over in one hit.

I've found this thread just because out of the blue DCS suddenly reported "red" integrity check: I have no idea why would anything touch that file, I've never had Apache, never tried it (yet), so it's strange. I have two modules in the installation directory, but those are very small and this file is not involved. I removed the mod, clenadup and repaired (no change was done by that) and then the check was green again. It all looked like a glitch. In other words... DCS can randomly show a wrong check for reasons that are not obvious at all.

Here is a modest attempt to "rank" maps based on their performance, be it FPS, VRAM usage, etc. It was inspired by my recent purchase of a modest 5060 Ti 16GB, which allowed me to push some details up. And then, I wanted some reasonable experience also on "slower" maps, so there are some tips about that as well. Not all maps are there, but I guess it covers the spectrum quite good. Where would you rank those missing ones (AF, IQ, Sinai, SA)?

Please ED, can you simply fix the descriptions for fast/slow bindings in Local object camera? All of them are inverted. I've returned to this cam after a while and first redone my bindings only to find that all fast/slow is the other way around. EDIT: Forget it, it's worse... whatever I set here, LCtrl is always slow and LShift is always fast. That's what confused me. I wanted the mods exactly the other way, it acted reversed and I thought "ah, labels are swapped, typical". But in fact, these fast/slow bindings seem to be ignored and modifier works somehow differently. How should this work? EDIT 2: I made a few experiments: I assigned non-mod binding (e.g. key H) to Camera height up slow. The result is that it acts just like Camera height up (default speed) - but LCtrl/LShift modifiers don't affect this key. So the LCtrl/LShift don't work as some default modifiers. I removed Camera height up slow/fast bindings, now I can't move camera up slow or fast, only the default speed. That sounds expected. I set Camera height up slow/fast with different modifiers, RShift/RCtrl+E. All plain E (yes, I'm a ESDF guy) and E with either modifier only moved the camera with default speed (?!). Using any other mod for E didn't do anything - at least that was expected. So there is something special about using LCtrl/LShift for those bindings. Doing so, it seems you "enable" the slow/fast movement in the first place - but otherwise it's completely ignored what modifier is where. E.g. with this (fast/slow are reversed for up vs down): The camera works fine without a mod, with LCtrl it's always slow and with LShift it's always fast. This system is broken beyond user's expectations and very confusing.

Ah, I decided to check the mission file, and while there are no trigger zones visible, I suspect I was totally off. I guess I needed to land where this infantry unit starts its journey: The line in the picture shows the edge of my screenshot from above. The visible part is above, so I haven't even consider this place. I turned left way too soon and way too much.

I'm struggling with the Night Flight mission (10th mission in the list, file WORLDS APART Mission 9.miz, title "Mission 7 / Nigth Flight"). Everything goes well until I have to drop the passenger at the Berlin Command. But I have no idea where is the LZ for the drop. This is the marker that was on the map earlier during the mission - I thought that's the place: But after approaching "Berlin", the marker disappears, and the map looks like this: null Later, I get into this message history: And the situation looks like this: I tried various spots around some high-rises, mostly around the one on the right in the picture - but no luck. After running low on fuel, I gave up, landed at Batumi repair parking spot and that concluded the mission successfully. But I'm not quite satisfied, obviously. What am I missing? Thanks for the hint!

Just a bump, in case you missed my previous post.