backspace340
-
Posts
1243 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by backspace340
-
-
16 hours ago, dporter22 said:
I wonder if it has something to do with multiplayer then, because in single player I can place/remove the chocks just fine regardless of the Mic switch position, canopy position, or whether engines are running or not.
You probably have easy communications / radios switched on, which will take effect in SP but gets over-ridden by the MP settings (most servers have it disabled).
-
1
-
-
I wonder if this isn't an INS issue but a desync issue - there's a bug report for LMC desync (where pilot and cpg have different views of where the TADs is pointing after the CPG uses LMC) - if the target coords takes the pilot's view of where the TADs is looking (instead of the CPG's), that might explain why the target points or hellfires are hundreds of metres off target.
-
Still seeing this in the latest open beta - at night on the Syria map, buildings in the cities had different levels of lighting in different eyes (I. E. Shut left eye, building is lit from the right and a particular level of brightness, shut right eye and it's a different lighting direction and brightness on the same building). With both eyes open it's a weird glimmer on all the buildings due to the mismatch. I've never used the shared parser setting.
-
I use the paddles on the back of my TWCS for the rudder pedals, which works well for me. I've heard of people using a mini-stick to do the same.
-
1
-
-
16 hours ago, aaronwhite said:
I think they're obviously going to fix it, as it's not finished, and George randomly crashing isn't something that they would want in a final product.
I do wonder if fuel state is an issue as well. I generally fly offline, and I'm usually around 50-65% fuel load, with Rockets/Hellfires. The other night I was online for the first time with the Apache, took off with 100% fuel just in case, but a pretty light load of 4 Hellfires, with 2 on each wing. I got into a hover behind some trees without too much trouble myself, and then switched into the front seat to try and find some targets, and had George move forward a bit, and then once I got close to some trees, had him lower a bit to keep from being too exposed. He seemed to enter into VRS or settling with power, whichever it would be, and bounced us hard off the ground. It broke off the tail (though my tail rotor did stay floating in the air, apparently working) and I was able to continue flying without an issue. Trying to move around again with George flying lead to 2 more bounces, before I decided to head back to base and repair, though I was still able to fly without issue.Anyhow, not meant as a complaint, just wanted to add a little more of my personal experience, as George offline never did seem to have much of an issue for me, but I also fly with less fuel, though I do usually have a heavier weapons loadout.
The weight definitely has an impact and makes it more likely, but I don't think it was the cause in my cases - I'd kept the weight below 17k lbs (something like 70% fuel, 8 hellfires, 300 rounds, no aux tank) so hovering wasn't a problem for me. Anecdotally, he seems worse over hilly terrain, I don't seem to have as much problem over flat ground - the main cases that got me killed yesterday were stalking through the valleys of low hills trying to stay under the 100ft engagement altitude to get a shot at some SAMs. Once I spotted them, I jumped in the front seat from a stable hover at 60ft, and George immediately rose to 150ft (so was about to get us shot at), commanding him back down to 60ft caused him to VRS and we died.
-
Yep, he killed me three times today... Doesn't look like this topic has a label, is it wip/reported or is this not going to be fixed?
-
LMC seems to be worse this patch for me - seems like before if you engaged it, it'd immediately null out the aircraft's movements (without having to touch the TEDAC slew) and basically stabilise the image, but now it's not doing that. It doesn't seem to do much of anything until you start putting inputs into it.
-
1
-
-
1 hour ago, Amarok_73 said:
Nah, even if I am not touching the collective, trying just to position myself to get into hover, the heli is way too twitchy.
In general, if I am coming into the hover, as long as controls indicators (those available with Ctrl+Enter) stays within gray area, the heli should be stable and with the AT/AL enabled, the flight computer should dump all inputs and hold the parameters of flight according to the speed that heli has at the moment, the Force Trim Up button/hat was released. And this is not happening since the End of the Year Patch I've mentioned before.I think we all would appreciate if someone from ED would clearly state what is the ultimate behavour model they're trying to achieve, otherwise all this thread is just a guessing game leading us to nowhere.
As an example of this empty efforts in guessing whether it is as it should be can be the @Apache 64's post from May 4, when he stated that after last patch the the heli is more predictable with shifter CoG and the @BIGNEWY's answer, that the patch have not brought any changes to the Apache's FM and there were no any information about changes in Release Info.
After the last patch I feel opposite, like EDs sits and observe, like we're circling around the subject, with conflicting opinions, because in Release Information there was communicated changes in FM, while in fact there were nothing of any substance provided.
Observing how we all loosing in the assumptions, and guessing, I think we would benefit from the honest dialogue with the tester(s) working with Apache's FM, otherwise, with every patch where the changes in FM are announced, in many of us the frustration increases with feelings that the things goes wrong way and in the end, we will be left with the product that offers no fun for many of Apache Lovers, especially the ones, that have in mind how the Kamov behaves, and appreciating the way the FMC works in that module.
And yes - I _know_ that the FM between these two have to differ, but still I don't believe the real Apache require from pilots so much attention and focus to tame the heli as the ED's implementation do in current version. This feeling is even amplified with the statements like from Casmo, who in one of his movies confirms, that the DCS' Apache is too sensitive.One thing that seemed a bit confusing from your video - it looked like you engaged Atittude Hold straight after takeoff when you weren't actually hovering and then left it engaged for the whole video. But once you went over 5 knots it would have gone to normal attitude hold (not position hold/hover hold) and so I wouldn't expect it to hold a hover after that. I think perhaps worth trying getting into a stable hover first (without lateral movement) with FTR held and then releasing the FTR and activating attitude hold (and alt hold if you want), that should hold the hover. And if you go over 5 knots and then want to hover again, I'm assuming you need to cancel attitude hold, bring it to a hover and re-activate it.
-
Seeing a big difference in the behaviour when the force trim release is held, feels much more stable in this latest patch compared to the previous one. Since release holding the FTR would make the helo start to roll and feel very top-heavy, but that's now entirely gone - it actually feels natural (like the KA-50) to hold the FTR while changing attitude/orientation and then let go to hold the course once steady. So much easier to fly than it was before!
-
2
-
-
18 hours ago, YoYo said:
No trial of Normandy 2.0 yet.
But it sounds like ED are expecting it to work - bignewy said so when he asked for the dcs.log and it's even in the faq that it should be trialable:
-
On 5/4/2023 at 8:08 PM, BIGNEWY said:
The trial version should show full detail for Normandy 2.0 areas, we are looking into the issue.
if you are on the trial and not seeing detailed areas outside of the old Normandy area please attach your dcs log
thank you
I just activated the trial for Normandy 2 and in the module manager pre-download it referred to it as Normandy 1944 (rather than Normandy 2). Have flown on it and confirmed it has a blurry big ben, dcs log file here: dcs.log.old
-
I saw Wags has updated the roadmap to say they're planning to give us the AGM-114L Radar Hellfire next month (but no indicative timeline for the FCR) - so I was just wondering if anyone knows how we'll be able to use the radar hellfires without the FCR? i.e. what methods will we be able to use to designate a target / area and what are the likely limitations?
-
3
-
-
8 minutes ago, zerO_crash said:
I expect so, still, changing the overall settings yields very little fps-difference. I can add 2x MSAA at fhe cost of 1-2 fps for example. That’s why I attribute the issue to the one thing I cannot avoid using - OpenXR. Furthermore, I’ve been using purely SteamVR before, and never had a problem.
I’ll have to wait for an update, but quite a few people with HP Reverb G2 are getting the same results as me. For me, MT runs equally bad as ST. I’ve been wondering why ST of all things runs bad as well, but I imagine it has to do with the implementation of MT (we are talking about VR all the time, 2D is working splendid).
Let’s not the derail the thread. I presume that the reason why OpenXR targets a much greater resolution at 1oo% setting, is the same as SteamVR - the first generations of VR headsets had so bad resolutions, that in order to have any decent image fidelity, it was common to upscale. As to why a HP-employee would claim that it’s recommended with upscaled resolution, that’s beyond me. HP Reverb G2 is quality-wise on the level of Varjo Aero, when looking at the sweetspot. It is absolutely fantastic, even at default resolution.
You can fix this pretty easily - just set the Pixel Density in the in-game VR settings menu to 0.6 or so, that'll get you back down to where you were on SteamVR. I've got a G2 & 1080ti and had to do the same thing when switching to OpenXR - my Steam VR resolution was set closer to the actual G2 resolution, but OpenXR is running way more pixels than that by default. I dropped the pixel density, didn't see any drop in visual fidelity (because it was rendering more pixels than I could even see, wasting performance) and my frames recovered.
-
13 minutes ago, Furiz said:
So LANTRIN doesn't have TV mode?
what about resolution, image quality etc? Any videos?
There's a video of what the same pod looks like in the F-15E here - seems a lot worse than the Litening, can't really see what something is even 6nm away:
Obviously ED might implement it a little differently, but that's probably a good idea of what to expect.
-
1
-
-
Just to confirm, is this still an issue? I've been battling with the collective SAS a bit recently and discovered switching it off helped massively, but couldn't find much recent about it so assumed I was on my own! Is this still awaiting a fix?
-
2 hours ago, T-Pap said:
I use standalone.
Reducing pixel density would be completely pointless considering multithreading is to enhance performance .
MT does not affect visually , it is not a graphical enhancement. Its point is to allow the same settings you already have to peform at a higher fps and therefor allow settings to go higher without loss of fps from your original fps , not the opposite , needing to reduce pixel densityThe MT exe is forcing everyone onto OpenXR, even if you were previously using SteamVR (which works with standalone) or on Oculus's OpenVR equivalent. Switching to OpenXR from OpenVR (SteamVR) changed the default settings for what resolution to send to the headset for me - to get the exact same visuals on OpenXR that I was getting in OpenVR, I had to drop the PD to 0.6. I switched to OpenXR on the previous patch, but on a side by side comparison with OpenVR I had 60fps and OpenXR I had 30fps, until I reduced the pixel density to equalise the resolution between the two. So it's possible what you're seeing is entirely unrelated to the MT change, but caused by the forced switch to OpenXR (it might not be, but I had a performance issue from the switch to OpenXR that I've solved as I've explained).
-
1 hour ago, Padonis said:
The problem is that a couple of times I encountered a situation where the target was in an empty field, was marked, in range, there was a sound, and the bullet did not fire. Petrovic said nothing. I did a few airstrikes on the target and nothing. Only the exchange for a new helicopter works. The problem is not just me.
Had the same happen to me - clear line of sight (I was at about 1000ft AGL, target in an empty field, about 2-3km away), in range, had missiles, got the message 'up a bit' (no idea why, line of sight was clear) and no matter what I did he wouldn't fire. In the previous patch I never had issues like this.
-
Try reducing pixel density - I noticed that I could reduce the PD to 0.6 in DCS VR settings on OpenXR and suffer no loss of visual fidelity. I think OpenXR was pushing a lot more pixels than I had before in SteamVR (when I had PD for both at 1.0), and if the same is true on Oculus that could explain the drop in performance.
-
Completely missed that video - it does seem odd that the two trailers from Razbam seem to have been incredibly careful to only include the weapons that they're talking about us having at EA launch, but then the ED videos (2023 and beyond and that trailer) have basically got all the weapons in. Razbam are being really, really clear on their discord not to expect JDAMs or AGM-130s/GBU-15s at launch.
-
On 2/21/2023 at 3:05 AM, Zboboinator said:
if we assume that what is shown in the trailer will be available at launch then we will have GBU-31 and 38 (0:18)
if you look closely you can only see the ATFLIR pod
Which trailer has the GBU-31 or GBU-38? The pre-order trailer just has dumb bombs and LBGs for A2G (doesn't even seem to be a GBU-24 here):
9 hours ago, hotrod525 said:Hopefully AGM130 make it at release, we saw the bomb and the pod several time in trailers... hopefully in two weeks'
The AGM-130 was in the '2023 and beyond' video, but not seen in either the pre-order teaser video or the pre-order start trailer - seems a very low chance it's going to be in for the EA launch (think Notso on discord has said basically no chance).
-
Having the same thing happen fairly often whenever I die on a MP server - it seems to be the auto-transition to following another aircraft that does it. I can hear/see it struggling to show the random aircraft it picks and then SteamVR encounters an issue.
-
I think this might be a bit wider than just the F-16 - I've noticed this happening a lot in the Huey/Hind as well in this latest patch while hot rearming on MP servers (but saying 'Stop, what are you doing?'), I think something has changed to make the ground crew incredibly sensitive to movement (or something else, latency?). It's taking 3-4 attempts sometimes to get rearmed.
-
7 hours ago, JSpidey said:
Are you also making sure the HDU's LOS reticle is centered inside the BRU?
He's in VR, so this isn't really possible. If the HDU is set to both eyes, focusing on the rings gives you double-vision on the LOS reticle, put either one inside the BRU and it'll misalign. Try and get the middle point of the two inside the BRU, and it's still almost impossible to get a good alignment. I've never tried one-eye setup, but I imagine that'll also give you issues (do you close the left eye and align with just the right image?).
I've not heard of anyone finding a reliable way to boresight in VR.
-
I've seen the Russian ATGM's do this as well (AT-5, AT-10, AT-11).
Keep getting stuck on GC Hold during alignment?
in F-15E
Posted
It only seems to ask for coordinates if you get something wrong the first time round, e.g. if you see 'GC HOLD' the first time and alignment doesn't progress, then switch INS off and back to GC align, it'll then ask for coordinates (even though the PP coordinates it wants are the same ones that are already input in the UFC).