Hawkeye_UK

Excellent thanks for the update - hopefully this can make it into the OB as its a really immersion killer in VR

In the Interim check out https://www.mudspike.com/chucks-guides-dcs-a-10c-warthog/ This is updated for the new A10C 2 and has the updated Hotas controls. Also from the ED website, check out kneeboard pages. https://www.digitalcombatsimulator.com/en/files/3313817/ Also this is excellent as a quick check, https://www.digitalcombatsimulator.com/en/files/3312541/ Appreciate the OP post of how important manuals are and confident ED will deliver but in the interim id recommend using these. Lastly have fun with the A10, its an excellent module to invest time in. PS - i'd also recommend running OB - the reason being is stable is not bug free and you get fixed quicker on OB, also next month will see the 2.7 release with the eagerly awaited weather updates.

More to the point can we have an update from ED on when this is going to have an actual dev fix - needs to be an option in settings please. Cleary its easy to do - why the near year wait - has it been forgot?

@Fri13Your not on your own - hence why i started the thread. The whole situation is a total nonsense moving non resolved bugs to resolved. I am also aware as an active member of one of the larger PvP servers quite a few people who also think this system is totally flawed. Nothing personal against Elmo and wish him all the best but as some constructive feedback nothing can justify this methodology, it is a recipe for disaster and things are going to get missed. Also to implement something incorrectly, which is broken for it to be then marked and dismissed as a future implementation is again a nonsense. Its a bug, and should be treat as such (eg Rose Compass on TGP). I also do not expect to be told that its "as per SME" as it makes them look incompetent, builds mis trust especially when there are those of us here that have worked with some of these systems in the real world. Also there is some reference about numerous messages from other users who agree with this approach. Lets just say that i have not come across one person, that is an experience harrier player (i'm over 1700 hours and other's i know are not far from this) who concludes that the current approach makes sense. As I hypothesised I think the only way we can get this back on track is to start the community bug tracker again if we are not going to get a formal, professional and structured approach from Razbam directly.

Ok so i have an ongoing log with Oculus Support and will provide feedback as i hear back. I also would like to clarify has anything changed with the way ED handle the flow from Mission editor, cockpit, to F10 map in either the Hotfix/end of Jan Feb patch. This started for me two weeks ago. It happens both in SP and MP. I can replicate it now 100% of the time on say mission editor where build a mission, click play and when you get to the choose slot screen and select one, you briefly see the aircraft loading in for a milisecond before it crashes back to the Oculus home within the headset. It looks as if on the monitor the game is still running. I do not understand however why despite showing the fly screen (as in stationary image and not yet pushed the fly button an i7 9700k core is maxed at 100%?). 95% if not more in MP if i say choose tac command or jtac to look at the F10 map, or even inflight checking the F10 map will dump the link. To note there is a long standing F10 map issue with this that causes FPS loss anyway. This for me has made DCS and Quest 2 completely unflyable, especially when associated with the FPS drop in game that sometimes can be corrected by al tabbing to another app and back in. Checking in the Oculus logs i get his every time there is a disconnect. Service_2021-02-19_17.32.16.txt] 19/02 20:07:28.851 {!ERROR!} [xrstreaming] WinUsb_ReadPipe(handle:0x000001D27A1A7610, ep:129, len:1024) failed: (433) A device which does not exist was specified. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] WinUsb_WritePipe(handle:0x0000000000000000, ep:255, len:4096) failed: (995) The I/O operation has been aborted because of either a thread exit or an application request. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] RemoteHeadphones: pipeCallback: sendAudio() failed to send audio buffer: -1002 {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [RemoteHeadset] Error getting user settings from session. Result=-1002. {!ERROR!} [RemoteHeadset] Error getting audioControlfrom session. Result=-1002. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [RemoteHeadset] Error getting hands from session. Result=-1002. {!ERROR!} [RemoteHeadset] Error getting hand skeleton data chunk from session. Result=-1002. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [RemoteHeadset] Error getting tracking from session. Result=-1002. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [RemoteHeadset] Error getting body from session. Result=-1002. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic 9 {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [xrstreaming] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [xrstreaming] inbound data processing loop exited: I/O error (13) {!ERROR!} [Kernel:Error] OVR Error: [Service_2021-02-19_17.32.16.txt] 19/02 20:07:29.199 {!ERROR!} [xrstreaming] Failed to parse PCI vid and pid from string "" {!ERROR!} [xrstreaming] Failed to parse PCI vid and pid from string "" {!ERROR!} [xrstreaming] Failed to construct channel for winusb,2833,ff,89 {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [DisplayManager] [DisplayManager] Failed to set power profile. {!ERROR!} [xrstreaming] Failed to construct channel for winusb,2833,ff,89 {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [Kernel:Error] [Aggregated 24 times] OVR Error: {!ERROR!} [xrstreaming] [Aggregated 20 times] Reference to topic is NULL in enum XrspResult __cdecl XrspTopicClose(struct XrspTopic *): topic {!ERROR!} [DisplayManager] [DisplayManager] Failed to set power profile. {!ERROR!} [MobileConfigWrapper] getBool() received invalid param: oculus_store:is_rift_redesign_enabled {!ERROR!} [MobileConfigWrapper] getBool() received invalid param: oculus_store:is_rift_redesign_enabled {!ERROR!} [MobileConfigWrapper] getBool() received invalid param: oculus_store:is_rift_redesign_enabled {!ERROR!} [LifeCycle] Leave VR with unregistered pid: 2864 (Unknown) {!ERROR!} [xrstreaming] WinUsb_ReadPipe(handle:0x0000000000000000, ep:255, len:1024) failed: (995) The I/O operation has been aborted because of either a thread exit or an application request. {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] inbound data processing loop exited: transport closed (12) [Service_2021-02-19_17.32.16.txt] 19/02 20:08:33.601 {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Failed to parse PCI vid and pid from string "" {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [xrstreaming] Failed to parse PCI vid and pid from string "" {!ERROR!} [Kernel:Error] OVR Error: {!ERROR!} [DisplayManager] [DisplayManager] Failed to set power profile. [Service_2021-02-19_17.32.16.txt] 19/02 20:08:35.443 {!ERROR!} [IpcRouter] Command /bug_reporter/get_bug_info caused an error: OVR54112166 Would appreciate a Dev's thoughts on the issue and feedback!

Yet so when something is implemented and their is a bug , its not a bug, its to be future implemented. Oh Dear. Painful.

Is it resolved though? - we have had a patch nearly 2 weeks after this post and there is still the same issue?

I go back to my original post i still fail to see why posts are being marked as resolved when they are not in game. Things that have ALREADY been implemented marking it as Future implementation is an absolute nonsense its its a bug that is highlighted as a way to not fix it. How can you then track what has been resolved (as in physically in game) using this method, you cant! Or are we going to have them doubly resolved for when they actually do get resolved. What happened to the Razbam bug tracker - i remember after i highlighted last year that it was woefully inept it was removed from their website with a promise that a new one would be introduced - i've yet to see this evidenced. How can anyone keep track of what's outstanding? I think we should start a new community spreadsheet again to be honest.

zero response @Fri13. Couldn't agree more call me cynical but its also a very good way of hiding issues and on appearances for anyone superficially checking the forums be it new customers (as many do prior to purchasing a module) or senior ED management having a quick synopsis of customer feedback/bugs. Strange how Razbam are the only 1/3 party to take this strange approach in "order to cut down on clutter". It's a total farce to be honest.

There is a thread, running nearly 3 years about the Harrier TDC slew problems for the analogue axis. As yet still outstanding bug.

You have got some type of confliction or hardware / software issue. Or your CPU or memory is not upto standard. I know this because I play on Syria alot, in VR no less on a 2080ti. Msaa x2 also, terrain visibility medium, trees 100%, flat shadows and low shadows for cockpit. Your doing something wrong or your pc is not healthy. I rather suspect it's down to your ram as 24gb is an odd number to have. Have you got odd units? Whata your CPU? Incidentally now I would not recommend playing DCS with high settings unless you have 32Gb of ram on a newish spec m2 SSD (samsung evo, preferred plus). Just putting a 3080 in a rig will in all fairness give you little improvements in FPS over a 2080ti as DCS is just not optimised to run the latest hardware. Thinking otherwise is just ignorant I'm afraid. You can have a 3090 but if your memory, cpu or SSD are not upto scratch a 1080 is going to perform better lol if it's in a wells setup rig. Ps note your other comments - I have no affiliation to Urga media.

This continues to be a problem for VR users - i do wish ED would take this one seriously and start looking into what's locking out the game and eating memory suddenly. Clearly its something code related the fact it suddenly bottoms out and that jumping in and out of the game can clear it more times than not. I also have experienced the same issue on the Quest 2 now, that is in addition to the Rift S and Reverb G2.

And that my friend is not the full picture. Why try and fight to the strength of your opponent, it's about the worst thing you can do. In the right player the Harrier is extremely useful, i have lost count of the amount of tomcats / viper / hornets i have virtually shot down. The biggest mistake you can force is the overshoot and many players just don't anticipate it early enough. The harriers ability to lose energy is unmatched in game or for that matter its "thrust vectoring" akak viff. You highlight it as a negative aspect however if flown correctly its actually a key attribute in winning a fight. Also it is no slouch when unloading. The key is getting to fox 2 range / the merge. The safest tactic against a harrier is to stay high at distance and fox 3, but if your over mountains and you go down to play you could very well have your pants pulled down and spanked. Also i would recommend reading Shaw's book on BFM if you can get a copy, as relevant today as it was the day it was written all those years ago. There are also guides that will take you through basic BFM.

Yes on the surface to new players it appears quite comprehensive. However with knowledge of the real life functionality and how the systems flow work then you tend to lose that appreciation quite quickly. I mean the TGP pod for a start is comical - good job there not like that in the real world otherwise the current collateral damage tally would be rookie numbers. I mean just try and talk on another aircraft or ground FAC from features on the ground by giving ground stabilised bearings from a VRP. Unfortunately also there are bugs with current implemented systems that are being marked as resolved and/or for future implementation instead of actually solving them. As for the quality in ACM, i regular shoot down tomcats, vipers and hornets PvP in a high standard server (not GS lol). If you have mountains and within visual against a skilled harrier player be careful thinking they are easy pray. Once merged even in open surroundings your equally going to struggle, those nozzles have a value!

Elmo, It is not future implementation - the rose compass is already in the TGP feed to the MFD. Your statement is incorrect. It has been coded and implemented incorrectly. This is a bug as its already been implemented by using your argument, how can it be resolved and nullified - to say the latter is pure nonsense. How can this be clutter? If your SME is claiming the the current representation of the data feed is correct - he is mistaken. I mentioned this as it was stated on one of the threads that it was as per SME. This need's resolution and i would suggest a review of how you handle bugs. Be under no illusion that moving issues to resolved was part of the historical problem with the fracture last year. Many thanks.

Guys just to be clear I do not want this thread to turn into a Razbam bashing exercise or a critique of their business model (its been done to death last summer) or time taken for new modules or old ones to be finished. What i would like is just to raise awareness with ED on the specific issues of community (genuine) bugs being reported and them marked as resolved. Just trying to pre-empt posts on this thread going forward.

Dear ED - hopefully Nineline / Bignewy will pick up on this. As a customer of ED please note once again we are beginning to have issues with Razbam. Genuine bug reports are getting marked as resolved when they are not correct. AS an example you will note there is an issue with the rose compass of the TGP. It constantly aligns in relation to the aircraft nose not the position on the ground track (as it should). This makes it a nightmare for CAS work when operating with ground tac commanders or indeed talking with other flight members. Apologies for reaching out but its getting to that stage again where they are just trying to reduce the bug schedule without actually resolving. We even got told that this was as per SME (which is incorrect, its clearly (or hopefully) a communication issue as the current implementation is not how it works in real life). What was the outcome of the internal review following the fractions with the community last year? What is the sign off process now as clearly currently something is broken in the quality and authenticity control process. Please can you discuss within ED and Razbam and report back. Greatly appreciated just trying to move the development in the right direction. Thread post here

The minimum volume is still to loud !! After 2 years please can you actually bottom this out and resolve so the players can actually control. A key binding would also be helpful......like every other developer for ED. Maybe even after the 2 year wait, introduce an analogue axis also Blood and stone springs to mind

Thanks for all the posts - i actually prefer the moving map with the black outline. The post i was originally relating to was every MFD normal screen, so the menu screen, stores page etc etc RAZBAM DO YOU INTEND TO JUST IGNORE THIS THREAD ???

Yep, gives me real concerns on whoever the SME is, as this is not reflective of real world operations or hardware.

Don"t be daft they do not have a good history in responding to the forums on genuine bugs. They like to use their own Discord and Facebook. Final predictions for the outcome of this issie to include; I1) It's as per SME (the same one that thinks the rose compass display is correct on the TPOD lol, instanty loses all credability ). 2) We've tested this and cannot replicate or find fault. This must be down to user hardware not being able to render correctly (as per TDC slew issue). No doubt either of these response's will mean the thread is closed and moved to resolved lol.

They should appear at the top of the MFD as two separate munitions however at the moment they do not - there lies the problem.

Moki, can see your new to posting so good advice on the forums is to search back through the posts prior to posting. Rather than just logging in a posting without looking for the issue. The forums are here to also get advice and you only do that by searching also! As you can see i have already logged it literally one post down from below yours.

Unfortunately it's fair to say that the testers do not always complete a thorough job, outside the scope of this issue way to many things get missed that are pretty obvious. I'd like to see an increase in alpha testers that have more real world knowledge also with a military background rather than say a few thousand followers on youtube being a criteria. Appreciate there are some excellent testers within the community with these credentials that do an amazing job, but there are others that really i'd question whether they have the right skill set. I think the minimum criteria would be say 1500 hours with the specific ED module they are actually testing. That said when you see the developer flying around for the launch video with 10 degrees of nozzle it might to too much to hope for lol. At this point i even have serious concerns over the Razbam SME given that they are claiming the rose compass depiction on the TGP is correct. Anyone that has seen that data feed knows the reality yet here we are moved to resolved. Razbam need to be careful im picking up on quite a few things moved to resolved that have not been. Have leopards really changed their spots because this is what caused the fracture with the community last year! I should have in my original post highlighted that the EHSD txt is better however that is purely because they have put a black outline around the txt. Every other MFD screen is 50% worse if not more. Things such as engine management and take off performance being a case in point, or the cas page. I cannot see how this was a higher priority than say introducing a new weapon system at the degradation of other systems. Fly first, fight second. I perceive this is another case of the Razbam dev getting tunnel versioned about how good SVG is without actually looking at the reality. It should not have made it past his dev screen, certainly not an alpha build let alone beta.

As im sure many others are about to say - F18 will be your next module investigating the same level of commitment. Its a good time as it gets nearer to feature complete.