andyn
-
Posts
66 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by andyn
-
-
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.
-
Your first GBU-12 hits exactly the point your TPOD is pointing at, which happens to be the field behind the targets. The second one is tossed to the side in a 2.6 G pull and I believe the bomb has little to no chance to guide with those launch parameters.
-
Happens on Warthog Deltasim mod and analog sticks on VKB MCG pro so calling this a hardware issue on users' end is just dishonest.
-
On 1/21/2021 at 6:41 PM, Wisky said:
i did buy the Harrier as my first module during the black friday sale.
since then it has been improved a lot and i liked flying it more and more with every update.
Black Friday? After that there has been one patch with Harrier fixes, so saying "with every update" here is a bit intellectually dishonest.
On 1/21/2021 at 6:41 PM, Wisky said:there seems to be a problem with the TDC slew, but that seems to be only happening for T16000 throttle users, so seems to be a hardware issue.
Nope, not a hardware issue. Happens on the Warthog with the Deltasim slew and on the analog hats on the VKB MCG Pro, so at this point blaming users with quality gear for bugs is just being a dick.
On 1/21/2021 at 6:41 PM, Wisky said:some people say the sidearms dont work, and while they wont point towards the target anymore, if you got tone you can shoot.
The Sidearm crosshair has been buggy as long as I've owned the module, around 2 years. While it's just a minor inconvenience it constantly reminds us that Razbam is incapable or unwilling to fix issues that get reported again and again.
On 1/21/2021 at 6:41 PM, Wisky said:i dont use the DMT because thats gonna be gone with the AV-8B plus anyway.
Hud repeater? never used.
CCIP drop line off target? never had that happen to me.
Gun Pipper is slightly low, but its no problem if you hold it just slightly higher.
slight bugs like some lights not working for an update or two? i dont really give a crap.
On 1/21/2021 at 6:41 PM, Wisky said:i have more than 650 hours racked up flying the harrier since november, so i would say if its working for me, it should normally for everyone.
The video game addiction hotline number is +1-888-966-8152.
On 1/21/2021 at 6:41 PM, Wisky said:so if your asking my recommendation? thats a big fat: ‚yes‘
but i am a fanboy, so at the end its you who will decide
So am I - It's just that it's impossible to enjoy a product that constantly tries to gaslight you.
-
3
-
-
8 hours ago, VirusAM said:
But if you move the mouse while also moving the head the mouse cursor will follow the mouse movement.
I just tried this tonight to answer here..
Also without this option PointCtrl couldn’t work because as already said above, pointctrl it is just a mouse for your PC and for DCS.
Anyway usually don’t have “use mouse” ticked, as I prefer to move the cursor with my head.
When i will manage to order pointctrl v2 i will surely use it.PointCtrl is somewhat of a kludge that would be best implemented as SteamVR native controllers, not as an emulated mouse. If ED is afraid of breaking commercial customers' (namely the ANG A-10C procedure trainer) workflow, the feature that people are requesting here can always be implemented as an option.
With TrackIR this was never an issue, because its movement is heavily filtered. With the instant and accurate response that VR requires, this is not an option on the VR compositor level. Even with us healthy people, the human head is micro-stuttering all the time but the brain filters out the movement and stabilizes the image. This does not filter out the in-game mouse cursor movement, however. Those stutters are very apparent if you look at VR gameplay capture on Youtube.
-
21 hours ago, Deano87 said:
HMD cursor? hmm.
I'm pretty sure that has notthing to do with the HMD implimentation in the aircraft.in VR options sub menu confirm that you have "use mouse" selected and "use hand controllers" deselected.
OP is referring to the VR headset with HMD - not JHMCS.
19 hours ago, Dannyvandelft said:Stop using the mouse, and use the hand controllers. Real planes don't have a mouse.
Stop using the hand controllers, because real planes don't have those either. Alternatively, stop trolling when people are trying to have real discussion.
4 hours ago, VirusAM said:Just tick use mouse in the VR options tab.
This way the head movement and the mouse movement will be decoupled
Mmm why do you say that?
The option I mentioned above has been there for a while...
Ticking use mouse in the VR tab is the solution.
When using track ir the mouse doesn’t move with the head by default....
So I don’t understand why you say there is a problem.Do you use VR yourself or are you relaying third party information? If this indeed has been fixed, can you pressure the dev team to release the feature already, because for us mortals it is still a huge issue?
There are two kinds of cursors in the game: the white dot mouse cursor, and the green and blue VR cross. The white dot is used in the menus and whenever the radio menu is up. The white dot cursor behaves like you described above and it's how people want all the cursors to behave: it should be bound to the cockpit grid, not the viewport.
The *other* mouse cursor, the green and blue cross that is used to click switches in the cockpit is what people are complaining about. It indeed follows the HMD regardless of what mouse-related options have been selected.
-
2
-
CBU97
in AV-8B N/A
Posted
You can also use so-called point blank auto designation if you think timing the pickle button press is hard in CCIP. It's mostly comparable to the F-16 VIS and DTOS modes and classic dive toss bombing computers.