Gadroc

I understand your frustration. It's possible to write a utility to help but I have not had the time. I would highly recommend re-reading DickDastardly's posts, he explains how to set these things up much better than I do. There is a decent learning curve to what is in the Black Shark config files, but once you have the grasp on them it should be easy to move everything where you want it.

The touch screens are Dell E153FPTc.

I have a couple BU0836X boards that work just fine under Win XP, Vista 64bit and Win 7 32/64bit.

According to the research I've done and Matrox's specifications it is only 1680x1050 and that only with a funky 57hz refresh rate. http://www.matrox.com/graphics/en/products/gxm/th2go/ The Digital edition (DVI) is limited by the DVI bandwidth which means you will probably never see it go above that resolution. Now the Display Port version does have more bandwidth and can support 1680x1050 at 60hz (at least according to their web site). That will require a video card with a display port to work properly. You will also have to buy 3 display port to DVI adapters unless all of your displays also support display port. I don't know if it's possible for the display port version to be upgraded beyond 1680x1050 as that will be dependent on the speed of the hardware inside the TH2Go.

Very nice!

The gauge graphics are yet again DickDastardly's work. I take no credit for pretty.... I just make them move. I'm not running BSVP at all. ggg87 almost ready to release details, but my current project would make switching these to 1280x1024 trivial.

I never did post pictures of the HOCAS all mounted up and functional. You can't see it pictured well but on the underside of the collective is another brake lever. I don't have this one hooked up to an axis but it does trigger a button, which I map to the collective brake in the simulator. The brake cable runs to a project box in the enclosure which as a pivot point and a lever spst switch. Pulling the trigger causes a bracket to rotate around the point and depress the lever switch. Next time I'm in there I'll make sure I take a picture of the assembly. In addition here is the current in progress shot of the touchscreens. There is still a lot of work to do laying out all the controls onto the touch screens. But it's very flyable now.... which has of course slowed progress. :doh:

Well yes and no. You loose quite a bit of resolution on the axis if you do that. You can gear up or down the movements in the gimbals/pots to maintain resolution, but we are going off topic :pilotfly:.

Has anyone seen anything on cost for this? I'm very tempted.

Still not the point, your stick only moves above your legs. My stick is floor mounted so a narrower base for the pedals would cause my legs to restrict the deflection of the stick. In MY setup there is no way the CH pedals would work and be comfortable. As I said originally it depends on your setup. One of the biggest differences between these level of pedals is the width. Of course I would assume there are bigger differences in feel and quality when you talk about the much more expensive simpeds that TBag references.

I think it depends on your setup. I have the saitek pedals and they are good, not great. I have not tried the CH Pedals but there is no way I could use them anyways. I have a center mounted joystick and the CH pedals are far to close together to make it possible. The tension adjust is nice and they feel pretty good. The travel doesn't feel as smooth as I would like (G940 pedals travel well, although I'd avoid that stick for other reasons.)

Possibly a poor choice of words on my part. I did not intend on picking a fight. I truly hope that they do improve on what's there for the component displays (and back port it to Black Shark :music_whistling:). Both methods would be good, but if I had to choose one I would choose giving us the raw data instead of an image. That gives us the ability to implement many different solutions. Having an image significantly limits our options for implementing a CDU in the pit.

You may want to rethink your assumptions as well. DCS's current implementation of multi-display for the ABRIS and Shkval are very inefficient. It requires defining a huge overall screen just to display that image that affects overall performance drastically, the FPS hit we take when displaying the ABRIS and Shkval on secondary displays is HUGE. Try this little experiment. Setup your display using the 1camera mode. Load a mission and hit ctrl-pause to pull up the FPS counter. Look around and jot down your average FPS. Now exit the mission and switch to Camera+ABRIS+Shkval and leave all other settings the same. Load the exact same scene and watch your FPS hit. On my setup it's on average 20fps slower. Next look up the commands for turning on shared memory texture exporting. Set them up in the Export.lua and watch your FPS bottom out (it cuts my FPS by half). While in general you are correct about rendering text to an existing 3d scene being very fast. And you are correct about rendering to a texture and mapping that to an object being an effect technique again for rendering into an existing 3d scene. But neither of those scenarios have any relevance on building a cockpit and the most efficient way to get data to the respect electronics or displays in that cockpit. Currently Black Shark exports the EKRAN which is also an LCD type screen via text. Text is much much more flexible for those of us who are building pits. It means we can run a true LCD display or do our own glass display. I currently render out the EKRAN to glass cockpit display using this text, much faster than the hit it would take to display it with the current image supported for ABRIS or Shkval. In addition it would be impossible to take that image and send it to anything other than a full color lcd display driven by a video card.

Based on the rest of the items on the site it's the interface to the simulation software.... wraps it so it can talk to there instruments. Notice that they don't have simulator specific instruments they have generic ones that talk to the wrappers. Maybe a translator would be a good analogy. The DCS wrapper translates DCS specific information to the simmeters standard format. It looks like the gauges themselves only speak standard format. This is totally based off assumption from the unfinished product list on their main site and my experience writing cockpit interface software for DCS. So take what I said with a grain of salt.

Well today I ripped the collective back open and replaced the pot with a hall effects sensor. The pot was getting a few spikes and the range of movement was restricted due to the handle extension. Of course in my hurry to fly again I completely spaced on taking any photos. Once I had the throttle base ripped apart I removed the existing pot. My original though of mounting magnets in the existing barrel of the throttle wouldn't work. It would have force me to drill through the end of the assembly. I didn't want to weaken it at all and it would have forced me to strip all the existing grease off and re-grease it... yuck. While thinking I picked up a pen to play with. I realized it's body was the right size to turn around the hall sensor. I then cannibalized the pen and glued a small section to the end of the throttle barrel. On the outside of this I attached two pairs of rare earth magnets. Next I mounted the hall sensor in a small hobby brass tube. I then found a rubber gromet which allowed me to mount this tube in the existing pot mounting bracket. After wiring it up and electronically centering the sensor everything is working again. I'm still not fully happy as the collective only has a 30 degree turn. Form this I'm only getting a voltage change of about 1 volt from lowest to highest. This translates into about 750 steps once I get into the raw values in windows. That's not bad for a traditional joystick, but it is about a quarter of what I'm getting on the joystick pots as I'm running them through a 12bit controller. I've read that if you use stronger magnets you can increase that, so I'll have to keep an eye out. I used two 3/16" rare earths from radio shack as they where readily available. After flying it still feels better than it did, but of course it's never good enough :pilotfly:

LOCALIZE("ABRIS Brightness"), elements["ABRIS_BRIGHTNESS_PTR"] {class_type.LEV} action = {device_commands.Button_8}, arg = {517}, arg_value = {0.05}, arg_lim = {{0,1}}I've successfully set ABRIS brightness via lua. Whenever you see class_type.LEV and do not see a relative=true you can send this command button an absolute value between it's arg_lim values. The arg_value is the increment that the naitive ui will use to increment and decrement. For example this code will set the ABRIS brightness to half. local dev = GetDevice(9) dev:performClickableAction(3008,0.5)The cursor control is a little bit more complicated. LOCALIZE("ABRIS Cursor control (rot/push)"), elements["ABRIS_SHUNT_PTR"] {class_type.LEV, class_type.BTN} action = {device_commands.Button_6,device_commands.Button_7 },stop_action = {0,device_commands.Button_7} ,is_repeatable = {}, arg = {518,523},arg_value = {0.04,1},arg_lim = {{0,1},{0,1}}, relative = {true,false},gain = {1,0}When you see two class_type this means that item does different things with right and left clicks. As far as I've been able to tell the first class_type is the left button / mouse wheel and the second is the right mouse button. In this case the left button is also class_type.LEV but note the the relative = {true ,false} that signifies the left button mode does not accept absolute values. Instead it expects the amount to add to the current value for the control. The arg_value is the amount to pass into the performClickableAction. For example this increments the cursor: local dev = GetDevice(9) dev:performClickableAction(3006,0.04)And this one sends it the other way: local dev = GetDevice(9) dev:performClickableAction(3006,-0.04)Now the right click is a standard button. The arg_value tells you the value used to depress the button. 0.0 releases it. This code presses the cursor button local dev = GetDevice(9) dev:performClickableAction(3007,1.0)and this releases it local dev = GetDevice(9) dev:performClickableAction(3007,0.0)

Your pit is an inspiration as always! I had a similar problem with my collective. I solved it by extending the shaft past the pivot point (I used an old X45 throttle) and adding a counter weight. My only problem now is the collective settles a little right after releasing it. This wobble makes it a little difficult to settle in after changes but after that initial settle it stays put. You should be able to extract all the information needed to do the leds now. That's how touchpal and BSVP get their data. Send me a PM maybe we can hook up over IM to see if I can't help you get started.

If you look through the Black Shark clickabledata.lua the things marked with class_type.LEV and realtive = false expect an absolute value in arm_lim defined range. These can be mapped to a pot. The only ones that would require an encoder type approach would be those marked class_type.LEV with a relative = true. In general it looks like in cockpit things that would be pots (limited rotational travel) have relative = false and those that would be encoders (spins freely with out hard stops) in real life are relative = true. I assume they'll use the same approach for the A10 module, but we won't know for sure until it's out. In almost all cases you will have to write code that does some mapping which could be as simple as converting your hardware readings into the necessary value range (in the case of a direct x axis from 0-65535 to 0-1). The only time you would not need any code is if you where reading a Direct X axis and the game configuration screens allowed you to assign an axis to them. Black Shark does not expose things like brightness knobs in this way. So I would plan on having to write code.

That link worked fine for me. Note that it is an FTP site not a web site. I would suspect you have some firewall software/hardware/isp that is blocking the FTP port.

Man. I'm going to have to stop watching your videos. I watch to many more of those and I'm going to have to get a CNC..... in the process loose a wife :helpsmilie:. I can't wait to see that in action.

Hmm... looks like there is a left over debug section in the ProcessInput. Just have him comment out these two lines and try again. io.write("---AcksExpected:"..gAckExpected.."-----", "\n") io.flush()

Essential that mean it's only exporting the 5 times per second. I can't remember why I went back to exporting the data every frame. I don't remember a dramatic difference in performance, but it could only help slower system and it has been a while. I'm about to start picking the interface code back up. I'll do some testing as I do and let you know what I find.

The map itself and town labels where in the image last time I tried. It did not include things like the North arrow in the upper left, nor did it include the text below the map.

Be careful if you pulled the hat off an older game port joystick. The old hats used resistance to determine direction and not individual switches. If the hat your trying to use has 5 leads on it then you should be able to wire it up to the existing 4 tactile switches. If the hat your trying to use has two leads you may be able to doctor it up to work. I had to de-solder resistors and cut traces to separate the tactile switches in an old hat to hook it up to new electronics. Essentially these old hats are the same 4 tactile switches just prewired to set of resistors so you could read them like an axis.

Nice find. I'll have to keep that in mind when I get to that panel.