Gadroc

There is a lighting brightness panel, but it doesn't look like Helios exposes it. I'll get that put in.

Send me a PM with specific switches that are not working and I'll look into them. Some of them where bugs in DCS which I could not fix. As for the correct bindings there are three output bindings from DCS BS in. Panel Lights changed -> Bind this to "Set Power" on your backlight groups with the following lua script value "return TriggerValue==1". This translates a panel lights switch position of on to true and other values would be false. This output comes form the sim and will follow whatever you do in the virtual cockpit or real switches that send commands to DCS. Night Vision Lighting changed -> Bind this to your night vision LED groups with the same lua trigger value. ADI & SAI Lights -> same thing with the ADI & SAI groups. It's been a while since I've flown the Shark I'll have to look to see where/if the dimming knob is for internal lighting.

In the Phidgets setup screen you can set the default brightness for a LED group (slider above check boxes). Set power should just turn power on / off and not change the brightness. There usually is a brightness knob in the cockpit, which would negate the need to do that even. Bind it's output value from the sim to the "Set Brightness" in Helios using a lua script multiplier to get the right range. (Ex: Sim outputs 0-1 and Phidgets expects 0-100 - "return TriggerValue * 100"). Why? Setting the lights based on the position of the switch is the right way to do it. Bind switch entering on position to "Set Power" with a value of true and switch entering exit position to "Set Power" with a value of false. If you do this binding from the outputs of the BS2 switches it will always sync your lighting to the state of the cockpit at mission start (although your physical switches may be out of sync). If you think about it this is how the actual cockpit works, toggle switch completes the circuit to allow power to flow to cockpit lights.

99% of the time you shouldn't need/use toggle. Can you explain how you have your lighting switches hooked up and bound to the sim? If using hardware switches how are they connected to the PC (joystick emulator, open cockpits, etc...)?

There are 13 LEDs on this panel for backlighting. I use the laser max instead of engraving through paint onto a thicker white plate for durability. It's really hard to scratch the laser max material, doesn't take much to scratch off the paint from the acrylic. Green is for night vision lighting. Depending on timing there are red and green version as far as I understand. Unfortunately the landing gear panel I have is non nvis white, so I'm going to stick with white for my panels.

AHCP Completed I have completed the AHCP using a different light plate construction than before. I've more than pleased with the results. I've built it from three layers. Layer 1 - Switch plate - 1/16th inch black acrylic (will eventually replace with aluminum). Switches around mounted to this layer along with 3mm LED holders which allow LEDS to be replaced / removed with out taking the panel apart. Layer 2 - 3/16th inch clear acrylic. Holes big enough for the nuts around the switches and the tops of the LEDs. Layer 3 - 1/16th inch row mark laser max. Holes per real panel but enough for switches to go through and labels engraved on it. I arrange the LEDs about 3/4" inch apart taking care not to put one directly behind letters. Layer 3 is glued on top of layer 2. I think use masking tape to protect to engraved front side and then fill the led holes on the back of layer 2 with putty. I then spray paint a layer of white onto the back and sides of layer 2. Once that's dry I spray paint black over top of the white (do two or three layers to make it totally opaque). Lastly I touch up edges with black paint. This results in a very nice even backlighting and a solid light plate the same depth as real ones. I did make a few mistakes on this one. First the SAFE next to the GUN/PAC switch is to close and second and I put one LED right behind the bottom right of the E in ALT SCE label. It's overbright which caused the distortion in the image.

They are now posted up here. DCS does not export weight on wheels, to my knowledge. The closest I can think of is nose wheel steering as the button that activates it behaves differently in the air. I haven't decided what to do with it yet. I'm either just going to hard wire it to be powered on when the pit/profile is running or I'll remove the linkages. I also got my landing gear panel wired, mounted and working. I need to fabricate the flaps gauge yet. Going to put together a 3D printer so I can print out the mechanisms and gauge tube that will fit in the real clamp. Wife is going to love it when the parts start showing up for that just after completing the laser upgrade.

Coming along very nicely!

Yes, the overlay plugin allows teamspeak to draw ontop of DirectX games and it traps Direct-X like softth does (well different mechanism but high potential for conflict). It's not surprising that it has problems with softth.

It works pretty well and overall I'm usually very happy with it. It is based on audio though which has limitations. To get the "feel" of the engine / wind while flying you have to have the low frequency cut-off pretty high, which makes more of the radio chatter come through the butt-kicker as well. There were in the past a few audio mods that boosted the lower frequencies in key sound files to give it a better feel, but not sure if they are updated. Also make sure you have a way of routing audio to it. You will need to either have a sub-woofer output you split to it, or have a splitter and proper attenuated cable to merge both left and right audio into it.

Sure. I'll get it exported to DXF and post it on my site.

In the real panel there is a solenoid which locks the gear lever when in the down position if no power is applied to it. If there is weight on the wheels the solenoid looses power and you are required to press the override button in order to move the gear lever into the up position. On the lighting panel the anti-collision beacon I believe is a magnetic switch. That's why it will not stay flipped on in game, until you hit a certain point in the startup. It's been a while since I've done it so I can't remember what allows it to stay on. To be honest I'm not sure of the logic for the A-10C on the anti-skid switch. On the F-16 if RPM goes above 85% it will automatically switch off.

*Warning* Programming languages pros and cons are subjective. Different people think differently and some are people are more suited to certain languages. These can be holy wars type threads. Also there is an aspect of right tool for the right job here. C++ is not the best "first" language, and probably overkill for what you have described. C++ can write some tight code and you have access to all the low level graphics APIs, but there are many pitfalls and it's a hard language to master (note I said master not muddle along). There are no training wheels and you can get some nasty hidden bugs around pointers and memory management. C# / .Net is a much easier language to get started with in my opinion. Most of the APIs are higher level and you can get right down to doing your task at hand with out a bunch of plumbing code for handling Windows internals. You do trade off having some lower level APIs, but 90% of them are not necessary for the work you are looking into. C# can easily call the other 10% and native dlls if necessary. The only exceptions to the above is if you are going to do some heavy rendering on your computer screens or doing code for primary flight controls (stick & throttle axis) where latency would be critical. The C# graphics pipeline in windows is CPU heavy. Helios 1.x uses it and I'm looking at alternatives. You could also just do straight C if you don't need much UI. This gives you access to all the APIs except for the GUI frameworks by and large. You loose object orientation, but that may not be an issue with the small scale of the applications your talking about. Object Orientation comes in very nicely with GUI programming and making generic components (think an API which can talk to Epic, PHCC, etc..), but these may not apply to your use case scenario. If you continue down C++ path: 1) Get, read and re-read "Effective C++" & "More Effective C++" by Scott Meyers 2) Avoid STL until you really understand C++ on your own first (then in my opinion forget it ever exists... compiler meta programming gives me nightmares about code maintenance) 3) Consider using managed C++ with .Net C++ is a very powerful language once you master it, but I'd caution picking it up as a leisure activity. If you don't live and breath C++ you can get yourself into a world of bad code hurt quick.

Yes, upgraded over the last few weeks. Built the new one from scratch reusing the optics, laser tube and electronics from the K40.

Nope, I meant 660 cfm. I would not be cutting acrylic with less than a 300-400 cfm fan vented outside, those fumes are nasty.

The controller we use is not g-code. It's a dedicated laser controller and upgrading to it is $500-$700 depending on what you may already have. For me the $700 for this laser machine was the same as just buying a tube, power supply and optics. I used it over the last year or so, but finally over the last month rebuilt it from scratch to a machine which can do a 12x24 sheet. G-code based (Mach 3/Linux CNC) work well for cuts only and are not good for engraving. You'll also be dedicating nearly as much value in computer hardware to make it run.

The fan it comes with is a joke, standard bathroom fans will not be enough either. I've upgraded to a 660 cfm fan and it pulls 98% of the fumes out. Also make sure you put the fan as close to the external outlet as possible. You want the majority of the hose under suction not pressure. Leaks under suction will not vent inside. The parts of your exhaust under pressure need to be carefully air tight.

I use Coreldraw x5 and Alibre to design panels. I export to dig in both of them to go into lasercad. Direct print form Corel works in x5 and below, but really isn't much better than export to DVD first.

I think that screen shot is using Helios on top of another application which drew the MFD displays themselves. Can't remember the name of the application off the top of my head right now.

Not as far as I know (unless something new has been added to lua space in the last few versions.) You can only export a view port like the MFD / ABRIS / SHKVAL. You would have to implement OCR to turn it into raw data usable for physical pits.

I screwed mine together. You can find pictures of my right console in this post.

Nice job on the backlighting there. Are those lighted tact switches or are you lighting it some other way?

Coming along very nicely. I'd love to see some video of those engine gauges working. They look great and are tempting.

That means that there is a missing image file. Double check the path and file extensions on the image. Image path in Helios is relative to the Images folder you referenced.

I was able to get a set of extra syncros for cheap, so I will be running them with steppers and then wiring those syncros to the ADI and altimeter. I need to buy/build a static inverter before I can work on that. Craig