some1
-
Posts
3454 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Everything posted by some1
-
But that's the whole point. The game has an offline mode that should let you play for 3 days without online connectivity. Yet with the recent server issues, all authorizations were revoked immediately. -
For some reason the current server issues cause the authorization system to treat it not like connection issue (when you still get 3 days to play offline), but an authorization issue (when the licenses are revoked immediately). I launched DCS twice today, the first time I got 3 days counter and could use the modules, but the second time I started the game, the authorization got revoked.
-
If DCS fails to authorize modules like with today's sever issues, it wipes out all settings from the "Special" tab in DCS Options. These settings are normally saved in "\Saved Games\DCS\Config\options.lua" in the ["plugins"] section. But DCS overwrites this file on every launch, and it does not bother to preserve options for modules that lost authorization. Before: options - Copy (4).lua After: options.lua
-
Openxr toolkit has a similar feature that works with any headset, you can adjust fov in real time and see how low you can get before you start seeing screen edges. Difference is, IIRC openxr increases pixel density for the visible part instead of simply shutting down pixels, so this setting does not improve fps, but image quality.
-
I was talking about the original link cable accessory that meta sells for 100 bucks. The one included with the headset is not a data cable, it only carries power. Great that you've found the culprit.
-
I don't think so, 1.6Gbps is plenty fast, given that the device itself can't decode signal at that speeds. You can try a different cable or pc port, even usb 2.0 should work although at reduced bandwidth. You don't need 20gbs cable, in fact the original cable from meta is still 5gbps.
-
PF was only a stopgap interceptror until better and more suitable aircraft were developed. Intended to find enemy bombers at night, and not much else. F and its derivatives were the workhorse variant of many armies around the world for many years. And we're getting SRD1 gun radar, that's enough for Dcs combat scenarios.
- 85 replies
-
- 11
-
-
-
Your GPU is loaded to 100%, in such scenario CPU can downclock without any loss of performance. It's idling between frames anyway, waiting for GPU to finish its work on the previous frame. CPU can change frequency several hundred times per second. Whatever you see on your OSD, it's just a rough approximation. CPU and GPU frametimes are the primary performance indicators in VR.
-
First of all, that 300 km/h you get in DCS is probably with the engines in takeoff range. You wouldn't normally fly like that for a longer time, though I think there's no penalty to do so in DCS. Also take note that the Kamov HUD and ABRIS show GS, which will be higher than IAS shown on AH-64 instruments, unless you're testing on the deck. Coaxial rotor system is said to be more efficient than conventional. The tail rotor robs you of 10-20% of engine power. On the other hand, the tall main rotor mast of the coax system causes more drag. But the shorter tail that doesn't need to carry tail rotor, with smaller stabilizers that don't need to counter asymmetric torque, all reduce drag. So it's a balancing act. Overall, Ka-50 probably has less drag. It has narrower fuselage, shorter tail, retractable gear and no dangling gun turret underneath. Ka-50 is heavier than AH-64 in typical configurations, but has more powerful engines to offset that a bit. Also I'm not sure how much of the nominal engine power is actually available to the pilot in both machines. IIRC AH-64D is normally limited by its gearbox, not the engines. The transmission won't take the full power of both engines at the same time, that extra power is reserved for engine-out situations. To sum up, the difference in top speeds between AH-64 and Ka-50 looks plausible. Now you may ask why UH-1 after the latest patch can do 150 kts, or why a fully loaded Mi-8 with external pylons is even faster in DCS, but I don't have answers to these questions.
-
Here is a simple mission where the AI is set to make a high performance sustained level turn, and you can try to stay on his wing or at least match his performance for a short period. You can also edit the mission and try different speeds or altitudes. Good luck. I checked several different aircraft and I haven't found a single one where it's possible. -MiG-21 AI sustains level turn at 7G. User controlled MiG-21 in the same conditions bleeds airspeed above 5G. -Mirage F1 AI will happily plow through the air at low speed, 26 degree AoA, until he runs out of fuel. Flaps not needed. -MiG-15, Fw-190, Mossie, AI can sustain something between 0,5-1G more than the human in the same aircraft. That's 20-40% difference for WWII aircraft, a huge gap that makes dogfighting AI in DCS a very poor experience. null zAIgload_Moss.miz zAIgload_Fw190.miz zAIgload_Mig15.miz zAIgload_Mig21.miz zAIgload_MirageF1.miz
-
I have this model, works very well once you get used to controlling it with the left thumb.
-
Engine power discrepancy between Russian helicopters
some1 replied to some1's topic in Bugs and Problems
Checked the engine numbers at Max Continuous mode again, this time in level flight at 50m altitude. Standard day, 20C, no wind. All helicopters set to 50% fuel, with IR supressors installed, no weapons and no gun ammo. Ka-50 engines achieve ~850C PTIT at 'H' setting, 262 km/h TAS in level flight. Mi-8 engines achieve ~890C PTIT at 'H' setting, 270 km/h TAS in level flight. Mi-24 engines achieve ~910C PTIT at 'H' setting, 285 km/h TAS in level flight. The limits on the Ka-50 EPR indicator seem to be very conservative compared to other two machines. It's quite interesting that Mi-8 is still the faster one even though it has all external appendages installed (armor, pylons, suppressors) and is 1 tonne heavier than Ka-50 in this test. speedKa50_262.trk speedMi24_285.trk speedMi8_270.trk
-
Yeah, but now that the GPS is fixed, the issue is also visible with GPS navigation mode.
-
The issue is still present in the latest open beta in all three navigation modes: VOR, TACAN and also for RNAV. Basically CDI always shows the aircraft off course by the amount of magnetic declination.
-
A headset is like a monitor with VSync ON. If you can't maintain the rated refresh rate of the display, you get stutters.
-
You need stable 90 fps for the stuttering to completely go away. What you see as stuttering is the headset displaying the same game frame for two refreshes in a row. Because it works at fixed 90 hz and the game is not providing 90 frames per second.
-
I don't play DCS with trackir, but it does skip a lot of frames in MSFS if the framerate is above 60. However, with DLSS3 Frame Generator it becomes smooth at any FPS up to 120, because then the actual game works below 60 FPS and the other half of the frames come from GPU itself. The change in Trackir smoothness is quite noticeable there when you turn on frame generation, but that requires one of the latest GPUs.
-
You don't need gsync in your mouse, but you need high enough mouse sampling rate. If you have a gaming mouse with adjustable sampling rate and try to use low sampling rate (like 125 Hz) on a 120 Hz screen, you'll notice that your mouse control is also slightly stuttering. Even moving windows on the desktop is not exactly as "smooth" as with 500Hz or 1000Hz polling rate. And it's the same with Trackir. 120 Hz sampling rate of the camera is actually not that much and with variable framerate above 60 FPS range you sometimes get two consecutive game frames without head position update. That's what causes perceived stutter. Of course some people may find it more noticeable than others. For keyboards and joysticks this issue is irrelevant, because they don't work in absolute coordinates like mice and Trackir do. But I've recorded a similar phenomenon in a different game once. Here you can see the game in slow motion at 2 FPS, but the camera does not update it's position every game frame, or at even intervals. When played at full speed, this creates a weird effect where the game itself is smooth, but the camera movement is not.
-
DCS FPS indicator does not detect CPU and GPU limits correctly in VR. It shows "CPU bound" message even if CPU frametimes reported by SteamVR and OpenXR are much lower than GPU frametimes. The game is in fact GPU bound here: And here we're simply at 90Hz refresh limit, still "CPU bound".
-
I find it very unlikely. DCS MT is not a heavily multithreaded application. We've only got rendering and main thread separated. Both CPUs show limited utilization on these videos and have some idle cores that could do more work. Also while 13rth gen Intel paired with fast memory (7000MHz+, tweaked timings) can trade blows with 7800X3D and often come on top, that would be a very unusual case if a 12th gen Intel with very slow memory is faster too (IIRC he said Intel had 4800MHz sticks). One very important thing that he is not showing on these videos are CPU and GPU frametimes as measured by VR software. All other tools and metrics are simply not designed to work with VR and may show garbage instead. The DCS "CPU bound" indicator is straight up broken in VR. The Nvidia overlay is also designed for 2D games, on my system it doesn't even show anything in FPS/frametime section when DCS is launched in VR. For example here you have a similar situation I've just snapped on my PC: GPU usage above 90%, but not 100% yet, DCS indicator screams "CPU BOUND", yet the VR software tells the truth. My GPU can't maintain frametime low enough for 90 FPS (orange spikes) which causes FPS drops. The CPU on the other hand sits at very low numbers in the green, there's so much headroom I could swap it for something slower and not see any difference, because here the GPU is the limiting factor. For a steady 90 FPS both CPU and GPU frametime should be below 11ms. GPU is at the limit, CPU is not. And that's what is probably happening on these videos. He's testing the game near the GPU limit. For some reason on the AMD system GPU usage is higher and that's what we can see on the video. Why is that, I don't know. But this means he hits the GPU limit more often, which causes FPS to drop. If your GPU is at the limit, then you are not testing CPUs any more. TLDR: Do not look at FPS when comparing hardware in VR, look at CPU/GPU frametimes. With FPS you simply don't know if the limiting factor is the CPU, GPU or the VR software itself.
-
And what? If all settings are the same, then why the GPU is loaded more at the same FPS? And if settings are different, then all comparisons are pointless.
-
I don't think he's testing at the same system settings, on the Ryzen 7800X3D side his GPU seems to have consistently higher utilization % than on the Intel side at the same FPS. Maybe HAGS on vs off? On the other hand his CPU utilization is higher on Intel even though Intel has more cores and it should show less % at the same load.
-
Solid investigation about the recent issues.
-
The choice of the chipset does not affect cpu performance, it only increases the number of peripherials you can connect and bumps pcie for some slots to gen. 5, which isn't useful nowadays anyway. It's actually the same chipset used on b650 and x670e, the later simply has two of them.
-
Not really. His reviews may be good, if you can understand the broken English. But when it comes to things like this, he's just another guy wildly speculating on the internet, without much to back it up. All his theories about why nvidia gpu connectors melted were proven wrong. The previous generation he stirred a drama about capacitors at the back causing crashes, that also turned out to be a nothing burger. Even now, some damage photos on the cpus does not quite match his theories.
