Jump to content

LhuanDula

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by LhuanDula

  1. Well I guess LeapMotion is more interested in having their own implementation for hand/gesture interaction rather than having to fit into the OpenVR specification. Ultimately, you can't blame them for that, mainly because the OpenVR specs are focused on interaction for physical devices (button pressed/released and so on) rather than modelling a virtual hand.
  2. That's good to know you already tried SDraw, there wasn't any mention of it in the thread. It's a shame, I was hoping for it to be a good answer to hand tracking in VR. Do you have any guess as to what is the root problem for these weird behavior?
  3. Hi there, just to add to the discussion, a possible solution would be to emulate valve's controller with the leap motion. This guy did it, and it's seems to work "nicely": His implementation is available here. According to the code, it should be possible to remove any controller inputs and just keep the finger tracking. However, it still leaves you at the mercy of unwilling cockpit interaction because of hand/cockpit collision coded by ED. But if such problem were to be solved (I do hope it will) then this would remove the need to go through an overlay. Thus, you'll also have depth test on hands vs cockpit (such that a hand behind a cockpit feature will stay behind, which is not possible with an pure overlay). Then, if ED ever attaches arms to the VR hands and add lighting interactions (shadows etc..), VR with a physical cockpit would truly shine :).
  4. I'll try in Stable, however this requires me to switch from stable and then back to OB :/. But if this solve the problem, it's worth a shot :)
  5. More thoughts on that matter; I found that when gear down, full flaps and air brake on, it is not possible to trim the aircraft in pitch (elev value does not change). However, as soon as I retract the airbrake, trimming works as expected. Don’t know if the problem lies in AB supposed to be retracted automatically when in dirty config or just trim bug. Any of you able to reproduce this?
  6. Managed to get it working, the clue was post#168 of this thread. I hadn't any chatter.dll installed. I had to install the chatter.dll (even though I'm not using it) to have it working again. @Holywood, if you're seeing this, you might want to take a look at that dll dependency ;). (I'm using last Vaicom.dll release v2.5.2)
  7. Hi all, I'm having some weird issues with VAICOM PRO.. VAICOM seems to force my DCS to switch to easycomms.. Even though I have unchecked the easycomms options in DCS. I tried uninstalling VAICOM from DCS, repairing DCS and launching DCS alone; The easycomms were correctly disabled. But as soon as I reinstalled VAICOM PRO (via a reset, relaunch, reinstall), and then relaunched DCS, the problem appeared again. Moreover, seems that the "update" button does nothing wether I'm flying the 2000, FA18 or TF51.. It's allways in default mode/easycomms on.. Does any of you have a clue of what's going on?
  8. Hi towsim, thanks a lot for this quick answer. I understand the emitter energy is not implemented for know, the rest is working fine for me so thanks again for this software. I do concur with your stated observation about the three steps of communication quality as I regularly heard them in my ACC. The terrain profile and horion works pretty well in Aries, so that's already an awesome feature :) I will be looking forward the implement of the emitter power in Aries with great excitment and if you need any help writting done some power disipation equations, do not hesitates to contact me.
  9. Hi towsim, First of, thanks for this nice piece of software that allows my friend and I to improve the simulation quality of the DCS series. We have been using ARIES with the Mirage 2000-C and noticed (maybe) some odd behaviors with the range limitation. Let's consider my friend and I both in a 2000-C. If I fly less than 40nm from him, I can clearly hear his voice with little to no interference from loss of signal energy. However, as soon as I go further away, the background noise suddenly kicks in with no linear variation (I was expecting a gradual loss of the words over the background noise, is it correct?) It is also independ from the radio and frequency used (VHF nor UHF) (And it is the same for my friend, meaning it is not a problem with my configuration, I think?) Is this behavior normal? I know the 2000-C has an emitter power that can be adjustable beetwen 5W or 25W. If my calculation are correct in terms of energy, with a 12dB SINAD level, we shall in theory be able to hear ourselves correclty: - from 75nm in UHF, 150nm in VHF with 5W - from 150nm in UHF, 250nm in VHF with 25W So I can think that hearing the background noise starting to appear clearer at 40nm is normal in UHF set at 5W but not in VHF at 5W, is it a possible bug? Finally, did you implement the switching capability of the 2000-C radio emission power? If not, do you conrfirm that the used value is 5W? Thanks in advance for your answers, and appart from that, we've been really enjoying the ride with ARIES. Carry on on this one ;)
×
×
  • Create New...