AMVI_Rider

What is VRK? Given the latest improvements of VR hardware, the most limiting factor for VR flight simulation in VR is the inability to access the documents and taking notes. So, the name says it all: VRK or VR Kneeboard is a kneeboard application for flight simulators. It designed to be used in the VR environment where accessing paper and taking notes is annoying to impossible. How does it work? The application generates an overlay in the VR world that can be placed and sized at will. When focused (looked at) the kneeboard can change its transparency and size to increase readability. The kneeboard is divided in tabs that can be created at will. Each tab can contain either: An imported PDF (useful for charts, frequency tables, briefings, etc.). An empty Notes tab, single or multiple pages per tab is supported. PDF and Notes can be used with a pen (digitizer or pen tablet) to take notes either on existing documents or on the bank sheet. Scrolling and zooming are controlled by gestures or physical tablet buttons. Starting from 1.3 client/server mode has been remove from the application. Users that need to use client/server should stay with 1.2 that will be supported with the current 1.2 feature set. Supported tablets are: Wacom (all Intuos line is expected to work in WinTab mode) Huion (using the custom driver, see Appendix A of the Quick start guide provided with the installer) Reported working models: Wacom: Intuos S, Intuos M (both BT and USB version) Huion: HS64, H640P, H950P XP-Pen devices are not working with VRK. What else? Here are some plans for this tool for the future: Use the tool during my squadron activities :pilotfly: Fix bugs! Kneeboard graphics (borders) OpenGL support for OculusVR (experimental) Supported platforms The tool is compatible with both OpenVR(a.k.a. SteamVR) and OculusVR. Beacuse OpenVR is the only platform supporting external program overlays "out of the box", OculusVR requires some configuration black magic. VRK tries to simplify the process to the maximum extent, but some user patience is required to survive the initial impact. Most non Oculus HMDs are expected to work in SteamVR mode. Pimax 5k, HTC Vive, Valve Index have been tested by users. All the other models of their families are expected to work as well. Where to download the tool? Like DCSMP and the other tools I designed for flight simulation, the installer is hosted by my squadron website: VRK Installer Version 1.4.3.07 Discord channel GitHub for Changelog, Issues and alternate download Any comment and suggestion is appreciated, just consider that I write code and support the tool in my very limited spare time. Example videos: For those who wants to stick with 1.2 and the Windows Tablet here is the link to latest 1.2: https://drive.google.com/file/d/1wy0M4-Vq4YC7HMq2lRNTif2YMWuUwQIv Mind that this version is not supported anymore and the experience with tablets is not even close to the latest VRK and a pen tablet: more ergonomic, more features and much better pen-to-display latency.

It is always a pleasure to receive feedback about DCSMP, even more since I didn't made any official announcement about the availablity of the full 2.1 yet. I will put the fix in the next minor release. As you will see the version checking is automatic now. Thanks!

2.0.2.3 has been released Major changes: A proper installer so DLL blocking by windows is not an issue anymore. Two major fixes for external tank fuel computation (both A-10 and F/A-18) and a regression on the TAS conversion The work on the Hornet continues.

DCSMP 2 has now entered beta stage and it is available for download. In this release the F/A-18C has been introduced and the whole application has been refactored. Most notable limitation is that the cruise data for the Hornet is still in progress (only optimal data is computed). My plans are to release the update in a few weeks from now. If the tool doesn't start please check that DLL files (expecially the ones in plugin directory) have not been blocked by windows. Follow this tutorial to check/unblock the files: https://blogs.msdn.microsoft.com/delay/p/unblockingdownloadedfile/ It is suggested to unblock the ZIP file before extraction.

Problem has been addressed in the latest openbeta. Thank you ED :thumbup:

Modding is possible but it will break the Integrity check. Last contribution I can give is the attached xlsx file with all the values I was able to retrieve from RL docs and the calculation to generate data for the lua file. Marked in yellow are some not extremely reliable sources. A10C Rockets Calc 1.0.zip

I was referring to the acceptable error on the TER weight evaluation: 2 lbs vs 800 lbs. (sorry I'm on the mobile and I can't report exact values) Given the links is obvious that I already reported (and I forgot about that).

Thanks about the link ... I removed just in case. About the 131, frankly speaking, I have no data on how many versions are there. If you do and you can share I think everybody will be happy. Personally speaking, I can stay with the simplification of the ballpark value as far as it is reasonable.

From the document you cited I see that the TER-9/A is 93 lbs. The TER-9/A MOD is 105 lbs, but it is also reported to be used with the F-16 only as it is designed for high speed. The TO1A-10A-1-1 reports 95 for the 9/A. I can live pretty well with 2 lbs of difference :smilewink: The problem I'm trying to bring to the attention is almost three orders of magnitude larger.

While reviewing DCSMP data I ended up in something odd which i noted years ago, but then forgot to report. Given real world data: LAU-131 = 68lbs MK151HE + MK66 = 9.3 + 13.6 lbs TER-9/A = 95 lbs The total weight for a single launcher (1 x LAU-131 + 7 x rockets) should be 229 lbs and the Mission Editor reports 220 which is quite similar. The complete TER weight should be 1xTER+ 3 x LAU-131 + 21 x rockets = 780lbs In Mission Editor I see a weight of 1548 lbs, roughly the double of the expected value. UPDATE: looking in the db_weapons_data.lua I see that the single launcher is defined as: { CLSID = "{69926055-0DA8-4530-9F2F-C86B157EA9F6}", Picture = "LAU131.png", Cx_pil = 0.00146484375, displayName = _("LAU-131 - 7 2.75' rockets M151 (HE)"), Count = 7, Elements = RocketContainer("LAU-131"), Weight = 100, wsTypeOfWeapon = {4, 7, 33, 147}, attribute = {4, 7, 32, 117}, }, So the weight is obviously expressed in kg. But if you look at the TER: { CLSID = "LAU_131x3_HYDRA_70_M151", Picture = "LAU131.png", Cx_pil = 0.00244140625, displayName = _("LAU-131*3 - 7 2.75' rockets M151 (HE)"), wsTypeOfWeapon = {4, 7, 33, 147}, Count = 21, Weight = 702, attribute = {4, 7, 32, 136}, Elements = RocketContainer("BRU-42_LS_(LAU-131)"), }, It is obviously in lbs ... It should be pretty easy to fix!

A little teaser below :music_whistling: :music_whistling: It will be a long way to reach the release level, but work has begun. I did a complete rewrite of the previous GUI so some new issues may appear in the A-10. Good is that also the hog is receiving some fixes and new things. Why not a simple implementation will be straightforward at least for Bingo. I will add them to the list. Adding an aircraft requires a lot of effort and documentation. I own the Harrier, but I lack both flight manual and performance charts for it. Are them available?

I did a test today and the difference between standby and hud altimeter is not related to airspeed/mach number. Seems that the only parameter considered is the absolute altitude, so, what we have is not the altimeter position error. I tried 30 angels from 0.48M up to 1.02M and the standby needle didn't move at all.

18k is just for US/Canada, in most countries there are Transition Altitudes when climbing (published on charts) and Transition Levels when descending (given by ATC). https://en.wikipedia.org/wiki/Flight_level Legacy Hornet are not RVSM capable. Only E/F/G have been certified.

Only for the sake of correctness, that's not fully correct: switching to standard pressure is needed because altitude measure with QNH or QFE reference is valid only in proximity of the departure airport (where QNH/QFE is measured). When leaving "local area" your altitude referenced to QNH means nothing compared to other aircraft with different departure location and this is a big safety concern. Compensation and accuracy of the instruments have an influence to the evaluation of the standard vertical separation by the ICAO which must consider all kind of avionics (if any). That's why only special equipped aircrafts may flight into RVSM airspace.

I should have had a look to the performance data before posting :doh: Nice to see that level of detail!

I completely agree on the cause of the difference, I just thought that the ratio implemented is a little high. Obviously it is not. Thank you for answering.

Comparing HUD and standby radar altimeter shows a difference of about 70ft every 10000ft of altitude. This happens both in multiplayer and single player session. The problem is present in version 2.5.2.19682 Steps to reproduce: - load a mission (free flight instant action is ok) - fly to 10000 ft (baro) and check stanby - repeat at 20000 and so on

Link updated :music_whistling:

The stack trace is similar to the problem I reported yesterday: Crash in Hotfix 3 during SP mission Same problem?

It doesn't work. BIGNEWY already answered that question:

Same "problem" with our official server, I setup another machine using the integrated Intel HD4000 which is enough to host out training sessions (also in Hotfix 2)

Playing single player mission "Kashuri Gap". Contacted JTAC and looking for target then crash happened. Log, track and minidump attached. DCSCrashData.zip

I don't think the memory access/rate is causing this issue.

I'm experiencing the same drop with a GTX Titan 6GB. I did some screenshots where the difference is clear: Object count is similar Frame time is similar Shadow time is similar FPS is 83 vs 29 (I expect the value to be over 60 considering the frame time) This makes me think more of a CPU rather than GPU issue. System specs: i5-3570k @ 4.5 GHz - 8GB DDR3 1600 RAM - Win10 64 - Geforce Titan 6GB Hotas Warhog - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 32" 1440p main display + 22" MFCD/Helios display 256 GB 840Pro SSD - 2Tb Caviar Green No trees: Trees: Full images are attached to this post.

The rockets are there: LAU-68 and LAU-131 on stations 2,3,4 and 8,9,10. As far as DCS does not take into account weight differences by rocket type, to keep the ordnance list simple I just used the plain launcher name instead of launcher+rocket. A little update: I'm working on the next version (mostly save/import functions) and I know I promised to release it in November. I had some extra projects at work that kept me busy also in the free time. The good is that is just a delay, the bad is that the data for the Ka-50 is less than the expected so I don't think I will be able to release anything at the proper level of detail in the next release timeframe. Last but not least: my (late) Christmas and New Year wishes to all of you! And may DCS 2 come soon :smilewink: