andyn
-
Posts
76 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by andyn
-
-
10 hours ago, Dup said:
Do you mean that SRS is reading the UFC display as we do ? The radio frequencies aren't part of the exports ?
Radio frequencies are exported. Other parameters - including guard status - aren't so SRS has to export the cockpit indicator state and interpret it to its best ability.
-
SRS has no way of accurately knowing which radio you're configuring. Whenever the frequency shown in the top left display matches any of your SRS radios, the right side option button values are read by the export script.
-
The rules above sound complex, but they can be summarized "always intercept the glide slope from above".
-
The F-5E is now unplayable in PvP multiplayer and PvE multiplayer on servers that use IC. This RWR mod has been widely considered a legitimate fix as the underlying issue has not been fixed for more than four years now.
-
12
-
-
-
We've had tons of fun in the DCS Finland community flying formation in the Midnight Hawks and FiAF Hawk 40th anniversary colors.
A small bug, but reporting it regardless: Emergency gear handle position is not reset to the up position between respawns and L/G cannot be raised until the black and yellow handle has been cycled. -
The raster effect might be realistic, but It makes the TGP almost impossible to read due to moiré, which does not happen in real life. That effect should not be implemented directly on the display texture until our desktop displays and HMDs have enough spatial resolution to represent it properly (and until the DCS engine can run at such high resolutions with an acceptable frame rate
).
A screenspace shader might produce an acceptable image quality in the meantime.
-
3
-
-
On 5/18/2021 at 4:50 PM, Rhinozherous said:
1 - Are the axis for the TDC fixed? Or do we still have to bind a button for left right up down - or can we use the axis?
The analog TDC axes were mostly fixed in early January, if I recall correctly. There was still another bug (that the devs were not willing to acknowledge) where you could not slew the DMT horizontally without adding vertical input, but it too seems to have been fixed with the latest action/no action slew update.
-
1
-
-
Do you have a WMR headset and reprojection on? Try disabling it.
-
DCS (somewhat unnecessarily) pushes hardware closer to its limits than most other games do and you're more likely to unearth issues with your hardware you didn't know exist, be it heat dissipation issues, power supply problems or something else.
DCS by itself does not break computers. If you start "optimizing" your Windows settings and mess up your OS because of that, you can't really blame the software vendor. If you start "optimizing" your CPU or GPU clock speeds, don't (unless you're talking about built-in features in various "OC"/"XT" series GPUs or Intel CPUs that are supposed to run up to 1½ times faster than their advertised base clock).
---
In any case "you can't break hardware with software" is one of the great computer fallacies. Who remembers the times when you could write a simple BASIC program in DOS that broke your monitor by switching between video modes as fast as possible? Who hasn't (at least temporarily) bricked their HOTAS with a botched firmware update? With vendors offering various "boost" features in their GPU drivers nowadays, overvolting and overheating your hardware is easier than it has ever been.
-
I remember seeing another thread about sea state vs wind speed in 2.5.6, and the general consensus of both aviators and sailors was that the waves on open seas were way too high for given wind speeds. Hence, the current implementation in 2.7 can be considered an upgrade until we get a separate sea state slider or the coastline proximity is taken into account in the weather model.
-
2
-
-
12 hours ago, andyn said:
11700KF, 6900XT and 64 GB of 3600 MHz DDR4, and the game is unplayable due to microstuttering caused by broken reprojection on the Reverb G2
Replying to myself: Today's (Wed 2020-04-21) Radeon update removed the reprojection-independent stutter for me. It also fixed a ton of other shenanigans in the compulsory Adrenalin crapware, so I highly suggest hitting that update button.
Note that DX11 mode still needs to be enabled in WMR for SteamVR settings.
12 hours ago, andyn said:I've spent five full evenings trying to find the correct settings to no avail.
But at least it's working now...
-
11700KF, 6900XT and 64 GB of 3600 MHz DDR4, and the game is unplayable due to microstuttering caused by broken reprojection on the Reverb G2 with the same graphics settings as on my previous rig (10600K and 2070S) on 2.5.6. With "unplayable" here I mean that my eyes literally hurt after a few minutes of playing and make me want to rip the HMD off my head.
I've spent five full evenings trying to find the correct settings to no avail.
-
2 minutes ago, sirrah said:
(really having a hard time with all these terminologies)
I'm not entirely sure about the configuration file. Change "Motion Smoothing" to "Disabled" in the SteamVR GUI (like in the lower screenshot). Then grab your VR controller. go to the cyan and black WMR Settings menu (via the goggles icon in the lower left corner in the SteamVR overlay) and make sure that reprojection has been changed to either "disabled" or "per-app".
Playing without motion smoothing will be a pain if you're used to reprojection being on.
-
On 4/12/2021 at 8:10 PM, fearlessfrog said:
I think I can recreate it without reinstalling Steam. Reinstalling Steam didn't fix it, it was more the settings going back to default. It seems like for me and my system, I can reliably recreate the issue by turning VR reprojection on. I've put the full steps to recreate here (I did try to post this here but had issues with images/text mixing and couldn't figure it out quickly):
Gotcha! I can trigger this issue reliably by slotting into about any heavy mission, including heavier single player missions. Disabling reprojection fixes this. Switching between legacy and normal reprojection mode has no effect.
-
1
-
-
Alright. Found the culprit. It's not C101EBSys.dll whose loading fails, but its dependency C101FM.dll. The GetLastError return value 53 just propagates through.
Removing network paths from the user's PATH env fixes the DLL loader. Normally PATH would be very last place to be crawled, but apparently the C-101 uses a custom DLL loader for easier development & debugging.
Ironically enough, the tools that triggered this issue are the very same ones I ended up using to debug it.
-
2
-
-
What bugs me is the error message "The network path was not found" which suggests that my E: drive was on a network share. It's an NTFS partition on a local NVMe drive and without any junction points or other trickery whatsoever. Permissions for the DCS installation directory have not been touched either.
-
Maybe I wasn't clear enough. I've already tried the following with Windows Defender:
- Excluding E:\DCS\ (the installation directory) and the Saved Games profile directory
- Excluding the whole dcs.exe process
- Disabling real-time protection altogether.
-
I'm unable to fly the C-101 at all. When starting a single player mission I get thrown to the map instead of the cockpit; in multiplayer the slots are light blue like other available aircraft but cannot be selected. According to logs the C101EBSys.dll EFM file is missing but it exists on the hard drive. I've tried the usual repair and logout/login troubleshooting steps. Windows 10 Defender does not detect the file as malware nor does it quarantine it, and other programs such as 7-Zip are able to read the contents. Other aircraft work just fine.
See the attached file from a quickstart mission. The relevant lines are as follows:
Quote2021-04-03 01:26:32.044 INFO EDCORE: Loaded E:/DCS/Mods/aircraft/C-101/bin/ABase.dll
2021-04-03 01:26:57.794 ERROR EDCORE: Failed to load E:/DCS/Mods/aircraft/C-101/bin/C101EBSys.dll: (53) The network path was not found. -
On 7/11/2018 at 12:08 PM, Pikey said:
Kegety's
15 years and you still can't spell the guy's name right. It's Kegetys or Kege for short, not Kegety.
-
I've used the 1000 lb rule:
- 1000 lbs for initial taxi and climb to cruise altitude. Less if you don't have to wait.
- 1000 lbs per 100 miles of cruise
- 1000 lbs per 10 minutes of playtime
With a steady left hand, these are conservative estimates with some built-in safety margin.
-
3
-
No, people should not be able to ruin other folks' public multiplayer sessions by trucking 4 HARMs or 12 Mavericks. Limit them to two and four, respectively.
However, I believe there is a third option that will keep most* players happy: Allow the Viper to carry and fire smart weapons on inner pylons, if they have explicitly been pre-loaded in the .miz itself. At the same time, prevent players from choosing those weapons in the in-game rearm dialog. It used to work for the Ka-50, so I don't see why it could not be used in this case. If the mission creator explicitly wants that loadout, they're free to do as they see fit.
*There is always that small but voiced minority who makes themselves heard even in the most trivial matters. The vast majority of people do not really care.
-
1
-
1
-
-
3 hours ago, Fri13 said:
That is about how I do get it. As the manual explains that if there is no code then ARBS/LST is not available and it is skipped to ARBS/TV mode.
That's what TAC-000 says and what I and you in your original post pointed out, indeed.
QuoteAnd that on WOW trigger it is specifically used word "zeroed" instead "reset to default" that would then make sense if there would always be a 1111 code in the system when starting aircraft, when landing and when taking-off and that 1111 code would be the "zeroed" meaning that if your system is in 1111 code then ARBS/LST wouldn't work. But it would mean that 1111 is not a valid laser code, and so on listed 1, 1-7, 1-8, 1-8 valid codes wouldn't include possibility for 1111.
Sorry, I don't quite follow you. The manual specifically used the word "zeroed" in the context of ARBS/DMT/LST. If a code has not been entered or it has been zeroed, LST is not available. 1111 is the default only for external hardpoints, i.e. TPOD and LMAVs, and the code is valid regardless whether it's in the missile seeker by default or if it has been entered. Furthermore, the codes are not bidirectionally linked. Setting the AC/system/ARBS/DMT/LST (or whatever you want to call it) code manually propagates it to the hardpoints, not in the other direction.
QuoteYes that is what I get from the manual. But it is challenging when one part of the manual say A is B and other part say A is X and if X exists then Y is not possible.
It can be a part of the old manual that just wasn't updated properly, but when one manual is still for Day-time, Night-Attack and Radar variant then it is fairly complex to start with.
The problem here is that if the systems would always default to 1111 from the start-up, powering individual systems or when landing, then why to even claim that proper code needs to be inputted to the system IF there is none - as there couldn't be scenario where there isn't one. And when 1111 is a proper/valid laser code, why to even explain that ARBS/LST is not available if no valid laser code is in the DMT system as there can't be a scenario where there wouldn't be one.
There is no problem here. Do read the pages 1-200, 1-392, 2-164. Check what part of the manual you are reading and what subsystems the information pertains to. Formulate the logic on paper if you're confused.
QuoteThe laser energy power is tied to the used laser code, the 1111 code is the most powerful laser energy you can have (and use most amount of battery from the designator) and so on 1788 is the least power required code and least successful for the targeting and spotting because highest PRF.
Oversimplifying, wrong (highest PRI, not PRF), and also not pertinent to this topic.
-
The magic number 1111 is mentioned in two places in TAC-000.2002:
- Page 2-164, which is about is about LMAV codes and the SMS, not ARBS/LST. Nothing about "zeroed" codes, mentions that 1111 is the "default" code.
- Page 1-392, which is about TPOD. Nothing about "zeroed" codes here either, 1111 is the "default" code upon pod power-up. Nothing about W-on-W logic.
The wording in the TPOD section suggests that neither TPOD nor LMAV can have their codes unset so they default to 1111. Meanwhile, the aircraft itself can have a "zeroed" code, and the scratchpad should be empty ("previous code, if any, will be displayed") in that case.
I'm suggesting that the following is the most likely logic:
- LMAV has its own code, which defaults to 1111 on startup and when transitioning to W-on-W.
- TPOD has its own code, which defaults to 1111 on pod power-up. SMEs can hopefully shed light on the W-on-W logic, but remembering the last code should be assumed otherwise.
- The aircraft/ARBS has its own code, which defaults to blank on startup and when transitioning to W-on-W. When a code is set, it is also copied to the LMAV and TPOD codes, respectively. If Sensor Select Aft is actuated while the code is blank/zeroed, the MPCD should go directly to TV, skipping LST.
[Official] SimShaker for Aviators
in PC Hardware and Related Software
Posted
An almost-happy new user here! The only gripe I have is this slider in Simshaker for Aviators: The deadzone center should be at 1.0 g, not 0. Currently the pad gives a positive g feedback even inside the 0 to 1 g range, when everything below 1 should be negative relative to the user.