Pfeil

Those are for the backlight bulbs: https://hackaday.com/2018/07/24/milspec-teardown-c-1282-chaff-controller/

Nice, finally we get a missile warning and even countermeasures so we're no longer a sitting duck! *Tires screeching* Wait, what? What's next, a paid RWR for the huey, even though that's had non-functional radar detectors on its nose all along?

Saitek, like other hardware manufacturers, use drivers that provide mouse and keyboard devices that can be controlled using software. So if you press a button that's mapped to a keyboard key, it will function just as pressing a key on your physical keyboard would. If the mini stick is set up to control the mouse, that too will work just like your physical mouse would. For keyboard and mouse there is no concept of input "authority"; If it's a device connected to your computer, it can provide input (even if it's a virtual device, which you installed with the Saitek software). So, yes, this is perfectly normal.

This question is also answered on the official VoiceAttack forum, with information on where to find the file. If you want to find the profile database quickly, you can enter %appdata%\VoiceAttack into the address bar of an explorer window, the search bar in the start menu/on the taskbar, or the run dialog. There is also a link to that folder on the "System / Advanced" tab of VoiceAttack's Options window.

I believe the multiplier argument for numeric ranges(VoiceAttackHelp.pdf page 17) would come in useful here. Using a "When I say" phrase like "[1..49] [Nautical Miles;Kilometers];[10..60,5] [Nautical Miles;Kilometers];[4..15,100] [Nautical Miles;Kilometers]" would mean you can speak values from 1 to 50 in increments of 1, 50 to 300 in increments of 5, and 300 to 1500 in increments of 100. Optimizing the required accuracy like this will allow you to bring down the number of generated command phrases from hundreds of thousands to a few ten thousand, meaning the profile will load much, much quicker. Also, you can rename the timer command to "Give me 1 minute;Give me [2..300] minutes", to reduce the amount of generated phrases for this command by half. As you're using global variables, something you could add is a command that uses the calculated value to set a timer directly. That command could simply use your existing timer command by passing the value to it like this: Execute command, 'give me {DEC:eta} minutes' (by name)

It could still be a corrupt driver, or a more general Windows issue(though it is strange that it occurs on two machines), but if you're upgrading anyway it's probably not worth chasing down, providing you don't have issues with the newer hardware. Good luck to you.

Use the Windows search in the start menu(or your taskbar) to find "Device Manager", it should come up with one entry with the subheading "Control panel". Click it, and it should show you a list of the devices installed in/connected to your computer. It'll likely fold out the unknown device and mark it with a yellow triangle sign. Right-click it and choose "Uninstall device" in the context menu, that should remove the entry. Click "Scan for hardware changes"(the blue monitor with a magnifying glass over it, above the list), it should find the device and attempt to install it again. If this still fails, you can try right-clicking and choosing "Update driver" in the context menu, here you can choose to either have Windows try and find a driver(though it may just use the "bad" driver again), or manually select one by picking from a list(which should include all compatible drivers currently installed).

I assume for the laptop you're not using a USB hub? If the device appears in Device Manager, I'd try uninstalling and/or manually selecting a generic driver for it.

Did you manually install drivers on the laptop as well? Does the device show up in device manager at all?

These pedals should work as a DirectInput joystick device, without any extra drivers(I.E. they come with Windows, and have since XP at least). Have you tried removing any third-party drivers you've installed manually?

Pretty sure the first item is a normal screen, it's just that the front panel controls for power and the built-in onscreen menu are touch sensitive rather than traditional pushbuttons(I.E. they are used to control the screen itself, and don't send anything to the computer it's attached to). The second item is likely a resistive touchscreen, judging by the type of stylus. These types of screen do technically work without the stylus, as they register pressure on the screen from any object, but they're not as sensitive to touch as your phone would be, for example. Where a modern phone using a capacitive touchscreen will in some cases detect your finger even before it physically touches the screen, a resistive touch screen will often require a reasonable amount of pressure before it responds to your input, making for a less pleasant experience.

If you're referring to the CRT monitor, that's pretty much unavoidable; Any type of picture-in-picture requires that view to be rendered separately. This is also the reason why mirrors are so performance intensive(notice how in most games, mirrors are either limited to small rooms, broken, or just plain don't exist).

Fixed link: Mi-24 Pit Build

Are you aware Oculus Go isn't a PC-compatible headset? It's supposed to be used standalone, like a smartphone-based VR system.

Huh. I've always had this behavior with the Gazelle, so I figured it was just the way the flight model/SAS system works; I shelved the module because of it. If it is a bug that can be fixed, I'd love to be able to give it a second chance. I'm using an MSFFB2 with FFB on(the trim was completely unusable last time I checked as well). Curves are untouched.

Shouldn't be a problem, you only need two servos acting on the gimbal. Unfortunately, it's not that simple, even without the patent issue. Servos won't work because they're too weak, too noisy, and too notchy to serve as FFB motors. I believe what WindyTX is implying is a non-FFB implementation, where rather than relaying control surface forces through force feedback, the stick is merely held in place. This would function like most real-life helicopter cyclic sticks, by holding the stick at a position set by the user, which can be adjusted on-the-fly, with a spring effect as it is moved away from that position. I.E. force trim. This would mainly(perhaps only) be useful to helicopter pilots, but is from a software perspective much simpler to implement(and may indeed not violate FFB patents).

...Care to elaborate?

In the Huey, the throttle is generally only used at startup. The only reason to use manual throttle control during flight is if the governor, the system that automatically keeps RPM within a certain range, is defective. In simpler helicopters, like the Robinson R22 for example, the throttle is adjusted to compensate for RPM differences that occur as the pitch of the rotor blades is changed by operating the collective, as the engine workload increases or decreases. The tail is balanced using the anti-torque pedals. During forward flight the aerodynamic surfaces on the tail should assist with that task above a certain airspeed.

From what I can see, you have a few millimeters between the panel and the monitor; Not enough to accommodate the original button, but could you use the plunger to push a microswitch instead? One of these things: It wouldn't feel as good as the real thing, obviously, but it'd be functional.

Silly question: Is the Day/Night switch supposed to be labeled NGV? I'm not saying it's a mistake, just wondering what it stands for("Night Gision Voggles" came to mind :D).

Neat. You could use a double pole toggle switch on these pins so you can turn both on/off for programming without fiddling with jumpers. You can even add a hidden latching double pole pushbutton behind a small hole in the front panel that you can depress using a paper clip, to allow programming of panels you don't have easy rear access to. EDIT: Although you'd still need physical access to plug in a USB cable, doh!

A while ago I looked into this for my own private skin, I made some comments in my description.lua that could be of use to you, though they're not complete or guaranteed to be accurate: {"UH1-cpt-door", 0 ,"UH1_door_c",true}; --Door, footrests, pedal linkage {"UH1-cpt_karkas", 0 ,"UH1_karkas_c",true}; --Front cockpit interior inner framework {"UH1-cpt_karkas2", 0 ,"UH1_karkas2_c",true}; --Front cockpit interior outer skin, flight stick stem, nose inside framework {"UH1-cpt_panel", 0 ,"UH1_panel_c",true}; --instrument panel, collective switches, circuit breaker outer nuts, some instrument panel controls, whiskey compass box {"UH1-cpt_central_box", 0 ,"UH1_boxs_c",true}; --Center pedestal, collective tube and throttle, overhead panel, overhead vents, overhead lights, overhead box(inverter?) {"UH1-cpt_dev2", 0 ,"UH1_dev_2",true}; --Gunner flex sight, windshield wipers, compass bezel, localizer bezel, altimeter inside, ADF signal strength dial {"seats_mat", 0 ,"uh1_seats_c_gray",false};--{"seats_mat", 0 ,"uh1_seats_c",true}; --Seats, windshield wiper motors, copilot nose bubble wiring {"uh1_int", 0 ,"uh1_int_gray",false};--seatbelts, external flight controls, external windshield wipers, external cockpit door handles, flare dispensers --{"ab212_int_panel", 0 ,"uh1_int",true}; --External view instrument panel {"ab212_int_white", 0 ,"uh1_int_gray",false};--{"ab212_int_white", 0 ,"uh1_int",true}; --External AND Internal cabin, when white or no dome light on {"ab212_int_green", 0 ,"uh1_int_gray",false};--{"ab212_int_green", 0 ,"uh1_int",true}; --External AND Internal cabin, when green dome light on --{"uh1_int_dam", 0 ,"uh1nope",true}; --Unknown, presumably when cabin damage occurs --{"UH1-cpt_seats", 0 ,"uh1_seats_c",true}; --Not working, somehow not seat texture? Windshield wiper motors too? Some of these I found in other skins, for others I opened the model files in a text editor and looked for sections defining textures(I'd tell you which ones, but it's been too long and I didn't make proper notes for that). I think the default "missing texture" texture has changed, as it used to be bright orange, making it relatively easy to discern which parts were which texture, however it's a green camo pattern now last I've checked. You can still try this by setting the name of the texture to something nonexistent({"uh1_int_dam", 0 ,"uh1nope",true}; would be an example). The cabin(where the bench seats and gunner positions are) appears to be the exterior model without the front section, the cockpit is a separate mesh sitting inside that with a number of different textures, some of which I've listed above.

I had a semi-quick look around the bug reports forum, but didn't come across this one: The crew compartment has a texture mapping bug where a small portion of the ceiling is actually mapped to a tiny part of a low resolution instrument panel, included in the same file as the other ceiling textures. For me, now that I know it's there, I can't help but notice it every time I look back into the cabin. See the attached screenshots for the exact placement.

Possibly a silly question, but you never know: Did you plug in the power cable? Aside from the USB connector, there is a figure eight shaped socket on the back of the base of the stick, this should have a cable in it going to the mains. Aside from that, what does the LED light in front of the handle(on the base) look like? Is it blinking? Under normal FFB operation, the LED will be steady and dim when the FFB is powered but not active, and steady and bright when active. If it's blinking, the FFB section is not receiving power. By "active", I mean you're wrapping your hand around the stick in such a way it covers the infrared sensor and allows the FFB to work. This is a safety feature.