Search the Community
Showing results for tags 'input'.
-
There is a red exclamation mark on the trim input for the KA-50 3. Hovering over it reveals nothing. I have cut the .lua for the warthog joystick and keyboard out and repaired. If anyone has any idea what i can do to fix this i would appreciate it.
- 1 reply
-
- input
- input device
-
(and 2 more)
Tagged with:
-
Hello fellow Pilots! As @AlphaJuliet wrote in one of his Threads there has been a known Bug - Am I the only one not beeing able to edit existing waypoints or create new ones by LAT / LONG coordinates? My standard procedure (not working anymore): - EHSD-->DATA page - WYPT active - choose waypoint or create new one - edit POS by entering LAT/LONG (same way as in INS alignment) - press ENT - same for ELEV - (check setting again) - exit Data page To be honest, I have not been sitting in the Harrier for a few months. Is there a new procedure now? But the entered coordinates do not save anymore. Therefore I cannot fly my CAS... On Reddit you can read a lot of postings that this bug has still not been fixed: Tried a few solutions such as creating a MK1 or creating new TOO first and editing coordinates afterwards. --> Nothing seems to work for me! Your help will be apprecaited Thanks & best regards, LonestarR
-
Hey there, I have been using Vaicom Pro with Voice Attack for DCS for a little over a year. Recently I updated DCS world and Voice Attack(I believe the problem is voice attack), and no matter what commands I give, or how I give them, they will be recognized but will never be confirmed or sent. I will continuously get 'awaiting additional input.' Never had this problem before. It is quite frustrating. Just want to be able to use Vaicom Pro again. Any ideas? Additionally, lately anytime I run DCS I have to repair it before hand or I will not be able to get the communications menu to show up and work. The communications menu that has ATC, Flight, AWACS, etc... that you use to communicate where to land, air-to-air refueling, command AI to engage bandits, let ATC know you're inbound, etc.. ----> I believe Voice Attack or Vaicom Pro is what is causing this issue and is probably related to the other issue above.. Or maybe it is not, but just one of a couple different issues making it impossible to use Voiceattack/Vaicom in DCS right now. Regards,
- 2 replies
-
- vaicom pro
- voice attack
-
(and 2 more)
Tagged with:
-
Программа для эмуляции ввода с клавиатуры при использовании игровых контроллеров (джойстиков, штурвалов, педалей и т.д.). Изначально делал для себя, так как готовые решения по разным причинам не устраивали. Основные особенности: Работает с любыми устройствами, определяемыми в Windows как игровой контроллер Определяет до 128 кнопок на каждом устройстве + переключатели вида (Point of view) Возможность работы с осями устройства, настройка зон осей Произвольное количество профилей для разных игр / конфигураций / джойстиков Настроенные пресеты (паттерны) возможно использовать в нескольких профилях Поддерживается эмуляция системных клавиш, разделение клавиш Win, Alt, Ctrl, Shift на левые и правые Раздельный маппинг на нажатие и отпускание (удобно для тумблеров) Не требует установки, не требует дополнительных драйверов или устройств Страница проекта: https://github.com/tjden88/JoyMapper Скачать: https://github.com/tjden88/JoyMapper/releases Скриншоты:
-
Hi everyone, With the newly added technicals and for pintle mounted weapons in general, would it be possible to facilitate absolute input devices for the turret azimuth and elevation controls? At the moment we only have a relative control input scheme, where displacing your controller controls the slewing velocity. Some users have built DIY pintle mounted guns which are intended to be used as absolute pointing devices, whereby displacement controls the position, not the velocity; these work very well on things like the Huey, but don't work so well on CA's fairly wide array of controllable, pintle mounted weapons.
-
It's been several times now that I had to manually clear the keybind that enables the camera to automatically track a launched weapon, it interferes with gameplay and ruins immersion and recordings. While I'm ok clearing the keybinds manually this isn't always (ever) possible, as I only find out it's bound again when it's already a problem. Completely disabling certain keybinds would prevent this issue, along with the issue of having keybinds that conflict with other software reappear over time, forever.
-
Hello, I've created a small button box with a few toggle switches for DCS and have had some trouble mapping a few functions. Master arm and ALT HOLD inputs work fine, I push the switch up, the switch ingame goes up, I pull it down, it goes down ingame, but things like Laser ARM don't work and I have to switch it twice for it to go up/down. Anyone know how to fix this? Thanks.
- 1 reply
-
- input
- input device
-
(and 1 more)
Tagged with:
-
Before I type my bug report - a positive note. The latest patches have introduced an enhanced fidelity if the collective blade pitch is changed either for the airframe reaction and orientation. Not only the nose or airframe vector but also the entire tilt and drift change in a very fidelic way. This is especially noticeable if the КРЕН and ТАНГАЖ dampener channels of the ВУАП-1 suite system are in use, and the НАПРАВЛЕНИЕ dampener channel and the высота maintain channel are turned off. This is a very positive sign and I hope this is a small symbol about the intent to have a fidelity gradient for this module this iconic rotary frame deserves, Now for the less positive - aka the bug report. Unfortunately the situation described in this bug report: and especially in its mysteriously vanished parts have worsened and are now clearly a more systemic issue that is a culmintation of various (in parts acknowledged and already being worked on in insularity) issues that cause cascading issues. The missing weight (mass) and inertia is leading to more oscillations, especially with a "light" configuration (less fuel, light munitions load) that is itself problematic during a terrain final (hover) on non-flat "terrain" surfaces. Clearly noticeable is now that the DCS trim settings ("control helper" or "special tab" options) of "default" and central position are NOT reliably working during any instance, even within the same DCS client session. Further the INGAME settings of "AP trim" (trim button setting) and "manual trim" (fe coolie hat) seem to cause cascading issues in the game code, resulting in more and more offsets to the point that even a full reset result in progressive input necessity and corrections (cyclic stirring). On top of this the constant exception catcher events of the DCS proprietary settings result in more and more input necessity during a longer flight (no reinit of airframe and or world load). Another sympton is the drift-gauge suddenly showing random indications, while the player can notice the airframe behaving completely differently. Sometimes this even results in mirror indications of what is going on or the gauge switching from random left/port-right/starboard indications with the airframe having a TVI in an entirely separate third orientation. On top of all of this there seemingly is a threshold where - again as reported before - VRS seems to suddenly occur like a trigger event (the attentive enough can even see the airframe frameblink before the VRS effect kick in as if an ingame event was triggered). Where before VRS might have been recoverable, it now is an unrecoverable disatrous quicktime event.. even if this even occurs already on the ground or at 1-2 m AGL. More disturbingly this event can occurr in a stable hover and a sinkrate of -1 or -2 on the VSI (radar alt on) and the Doppler-hover system working. So apart from the bug state in each part mentioned, there is a cascading interaction on a systemic level. If the results are caused by this cascading interaction cannot be judged by an enduser and it evenly shows the possibility of an unerlying fundematal source issue causing said interaction or even gradients of the insular bugs in each keylog submodule. Which could be the clearly hardmodified weight variables, the currently missing physicalized inertia, anything. That there IS a bug can not only be noticed by the osciallation issues, the VRS states, the inability to trim at a certain point (or the "trimlock bug) but also by clear exception catcher and outlier events. Example: if these bug in any subset have started occuring.. an RBS effect will result in the airframe rolling at 3-4 times the speed it would normally RBS roll to the right in a comparable, replicable scenario. Test scenario: Singleplayer and multiplayer with repeatable scenarios in direct comparison to prior bug notice x52 sets magnet modded, spring modded, zero signal stutter, controls cleaned (not double binding of active peripherals) trim setting (DCS proprietary) "central position" including "rudder" ingame settings as described above current workaround of constant "reset" and retrim from zero applied Dxdiag irrelevant but attached. Trackfiles: 2x singleplayer, direct comparison to prior scenarios, chosen because of drastic showcase and 8+ repetitions and chosen because of lean trackfile. https://drive.google.com/file/d/1ojlq_M56d2skyne8_9QmqmFvgFqcHZE2/view?usp=sharing https://drive.google.com/file/d/1ok5VXQnXas7UBmTQgEIrHr_4wcDA3e91/view?usp=sharing DxDiag.txt
-
I'm making a dedicated thread on a throttle nozzle quadrant build that I'm working on. This is something that started a while ago with a pretty detailed design effort that was put on hold for two reasons: 1. my 3D printer was having issues that needed to be investigated, and 2. designing the throttle grip was quickly determined to be too difficult based on the information I had at the time. Since then I have bought a new 3d printer and the old one has now been stripped down for parts for the quadrant. I have also stumbled across several excellent photos from @mattjonesgr9 that were posted on a UFC build thread. This is now enough, along with a short break in work travel madness, to allow me to hit this project hard again. I'm hoping I can keep enough momentum to get a working prototype finished in a few weeks. These are the original renderings of the quadrant enclosure assembly: I did manage to print out this first grip effort, but it was so far off the mark, I didn't know where to start. Since then I have come up with this design for the shell: Whilst not perfect, for a solid body, it's close enough. I've also scaled down the component by a factor of 0.9 as the printed version felt a tad too big for an ungloved hand. This first prototype won't be made of sheet metal as originally planned, but will be assembled from 2020 extruded aluminium and 3D printed parts. I will also be using a hall effect sensor for each of the three rotating axis instead of potentiometers.
-
Some of the key binds have special key binds that turn an option off when the key is no longer held down. An example would be the auto pilot mode switch for the A10-C. This is presumably because the Thrustmaster warthog throttle sends a separate and continuous "button" for the up and down position but no button for the center position. I would like to use the thrustmaster warthog throttle for other aircraft too. For example I use the EAC switch for master arm in most planes and the radar altimeter switch for laser arm. However most key bindings don't have that second, special option, so I have to toggle the switch twice to toggle the switch in the aircraft once, because it toggles only on the pressing part. I propose the solution to the problem: Don't have those special key bindings and get rid of them. Instead every single key binding has a selectable option (for example make it a checkbox) that toggles the binding "on release". This option should not be in the key binding itself, but rather in the key press you set up for the switch. This ensures that all bindings can stay as they are right now, only expanded by default with the on release option off. In my example I would set "Master Arm - ON" to the button press. Because the button press is continuous it will stay on. Then I set "Master Arm - OFF" to the very same button, but check "on release". So when the button is released (ie. I put the switch back into the off position on my physical device), the continuous button press is no longer a thing and the on release key event fires, putting the switch back into the off position. This requires that the same button may do multiple things, so long as on release is set on one but not the other key binding. To go along with that I would request that all switch positions have their own keybindings, all switches have a toggle key bind and all switches with more than 2 states have a cycle up and cycle down key bind, with the option to wrap around or stop at the highest/lowest position. The generation of those key bindings could reasonably be automated by labeling switches, switch positions and switch categories in metadata. Doing this would allow the greatest freedom for setting up our input devices in any combination we desire.