Donbinator's A-10C pit

[Boltz]

I'm sure I read somewhere about a new version being printed soon but I don't know when that will be. I think it has been in the works for a couple of years now. I'd love to get my hands on that book also.

[donbinator]

I'm sure I read somewhere about a new version being printed soon but I don't know when that will be. I think it has been in the works for a couple of years now. I'd love to get my hands on that book also.

 

Isn't Deadman producing a book? Someone on here is....

[Boltz]

Deadman is writing one

[Mike Powell]

Two years ago the news was that Jake Melampy (Reid Air Publications) had made good progress toward a second edition of The Modern Hog Guide, A book that many people considered the best A-10 reference. Sadly, that doesn't seem to have happened.

 

http://www.jakemelampy.net/books.html

http://www.reidairpublishing.com/

https://www.facebook.com/pages/Reid-Air-Publications/177633712268219

[donbinator]

Warning Panel almost done

 

Warning panel is coming together, but I need to figure out how to make the front panel better. In order for the LED's not to bleed I'm cutting out each indicator hole from 3/16" plastic, then cutting out the indicators themselves from 1.8" plastic. Made the indicators just slightly too small, but I'm going to try to fill with black glue or maybe paint. Also the fact that my cat bumped it off the table and one of them fell out means I should probably look at a better way to glue them in :).

Circuit board has turned out nice on the first try, accepts 6 to 12V supply, turns it into 3.3V and interfaces with my PoKeys modules over I2C.

[donbinator]

PoKeys software for DCS

 

Here's my PoKeys program as it stands now. In order for it to work along side Helios you have to add another socket in the export.lua. I'll post that later as my latest install of DCS nuked my export.lua, for which I had no back up. It's not a big deal, but I'll have to refigure out where to add the socket and the send and receive. It doesn't handle I2C for the warning panel, I'm working on that now. There's also no help :). Start by adding a Device (PoKeys module). Then Add "IO Nodes" which are associations between PoKeys IO and device/value pairs in DCS. Then on the control screen click start. Right now there's a bug where you can't stop and start it again. Once you have things configured you can save your configuration and load it later. This code is only about half done but will give you an idea of how to interact with export.lua from C# (and I'm a really sucky new C# programmer so bear with me while I adapt from my C/C++ background :book:)

DCSPoKeysManager.zip

[donbinator]

Hey not sure where to post this so I'll keep it on my thread. I have a problem with my program that runs all my IO. I don't get a UDP connection to which I can respond unless something is sent to me from DCS. The weird thing I'm seeing is that unless something changes DCS doesn't send me anything. So for instance, I can turn my battery pwr on but as soon as DCS decides no values have changed, I can't respond with other switch changes. Has anyone figured this out? The really weird part is that sometimes it will catch a couple of key switches (meaning stuff in the list of arguments to send have changed) for a short while, but then it sort of stops having anything to say (nothing in the list of arguments in export.lua are changing) and I don't get a chance to respond. How can I get DCS to "check in" every once in a while?

[FSFIan]

The weird thing I'm seeing is that unless something changes DCS doesn't send me anything. So for instance, I can turn my battery pwr on but as soon as DCS decides no values have changed, I can't respond with other switch changes.

 

It works as designed -- values that are not changing will not be transmitted. When Helios first connects, it will send an "R" to reset the cache.

 

So how does Helios figure out where to send that "R"? The same way you do -- wait for a packet on port 9089 (or in your case whatever port your second connection sends its data to).

 

So if nothing changes, how does Helios ever get that first packet it needs? The answer is simple -- in a running plane, some value is always changing. If an engine or the APU is running, fuel is consumed. If you have it turned on, the oxygen flow indicator will blink. Floating point values such as the altitude may fluctuate slightly due to rounding errors even if the plane is parked on the ramp.

 

If you turn everything off and wait a while for things to settle (I used RawCap to monitor the number of packets sent to 127.0.0.1), it is possible to get a situation where the Helios profile will not work until you cause some value in the cockpit to be changed, e.g. by clicking a switch.

 

How can I get DCS to "check in" every once in a while?

You could remove the condition in FlushData(), so it always sends at least the SimID even if nothing changed. Don't know if that would confuse Helios, though, so you might want to apply that change to your extra connection only.

You could also make your Export.lua listen on a specific port for commands, so you'd have one IP/port where DCS sends export data and another IP/port where DCS listens for commands. It's what I do in my Arduino example.

[donbinator]

Cool, I think the cleaner way would be to create a listener in Export.lua so I'm not flooding the wire with SimID :). Thanks for your feedback.

 

Ian;2127013']It works as designed -- values that are not changing will not be transmitted. When Helios first connects, it will send an "R" to reset the cache.

 

So how does Helios figure out where to send that "R"? The same way you do -- wait for a packet on port 9089 (or in your case whatever port your second connection sends its data to).

 

So if nothing changes, how does Helios ever get that first packet it needs? The answer is simple -- in a running plane, some value is always changing. If an engine or the APU is running, fuel is consumed. If you have it turned on, the oxygen flow indicator will blink. Floating point values such as the altitude may fluctuate slightly due to rounding errors even if the plane is parked on the ramp.

 

If you turn everything off and wait a while for things to settle (I used RawCap to monitor the number of packets sent to 127.0.0.1), it is possible to get a situation where the Helios profile will not work until you cause some value in the cockpit to be changed, e.g. by clicking a switch.

 

 

You could remove the condition in FlushData(), so it always sends at least the SimID even if nothing changed. Don't know if that would confuse Helios, though, so you might want to apply that change to your extra connection only.

You could also make your Export.lua listen on a specific port for commands, so you'd have one IP/port where DCS sends export data and another IP/port where DCS listens for commands. It's what I do in my Arduino example.

[donbinator]

Actually I think I'm better off just hoping something gets sent often enough. I tried a listener but unless I set the timeout to 0.001 it's going to block for too long, and unless the connection is made right at that moment it will fail (which I think is what's happening now). I'm back to wiggling my butt back and forth hoping it changes some value in the sim :).

[FSFIan]

unless the connection is made right at that moment it will fail

 

There is no such thing as a UDP connection. You listen on a specific UDP port and in your other application, you simply send a UDP packet to that IP/port.

Look at CMSPExport.lua here for a working example.

 

If a UDP server wants "connection semantics", it will listen for UDP packets and send its response to the source address of the first packet it gets.

 

When a client wants "connection semantics", it will tell the UDP socket that it only wants to receive packets from the server (with the correct source port).

 

If both communication partners know the host/port where the other listens for UDP packets in advance, you don't need that (and there is no more distinction between client and server). Much simpler, and you don't have to wait to receive a message before you can send one.

Edited July 26, 2014 by [FSF]Ian

[donbinator]

Ian;2128478']There is no such thing as a UDP connection. You listen on a specific UDP port and in your other application, you simply send a UDP packet to that IP/port.

Look at CMSPExport.lua here for a working example.

 

If a UDP server wants "connection semantics", it will listen for UDP packets and send its response to the source address of the first packet it gets.

 

When a client wants "connection semantics", it will tell the UDP socket that it only wants to receive packets from the server (with the correct source port).

 

If both communication partners know the host/port where the other listens for UDP packets in advance, you don't need that (and there is no more distinction between client and server). Much simpler, and you don't have to wait to receive a message before you can send one.

 

Yes I know UDP is connectionless. Let me use your lua as an example to what I think is my problem, you are welcome to correct me if I'm wrong.

 

Here you are setting the timeout for the listener to 1mS.

 

CMSPExport.listenconn:settimeout(0.001)

 

This means that the listener will listen on port 7778 (CMSPExport.listenconn:setsockname("*", 7778)) for 1mS, then return if it hasn't received anything. It also means that if you don't send your packet from your program in that particular mS of time, your lua script won't receive it. That's my problem. It's a broadcast to 127.0.0.1 on that port for whoever is listening, and if no one is listening at that particular time the packet is lost. Obviously yours works, how?! That's my question :huh:. My guess is that unless there's something I don't understand about sockets, the mS that your listener is listening is actually a large percentage of the round-robin timing of your system, that is, 1mS is spent listening, and 1.1mS is the period, so you have a good chance of an active listener when you send your packet. If that's true I want to find another way to do it because that's going to be unreliable...I think?

[FSFIan]

It also means that if you don't send your packet from your program in that particular mS of time, your lua script won't receive it.

 

By calling CMSPExport.listenconn:setsockname("*", 7778), we tell the operating system that this socket is interested in UDP packets arriving on port 7778 on any interface ("*"). When such a packet arrives, the OS will buffer it for us (up to some maximum buffer size, so we still need to call receive() regularly).

 

When we call receive() on the socket and there is data in the buffer, the OS will return that data. If there is no data in the buffer, the receive() call would normally block until data has been received. By calling settimeout(.001), we tell the OS that after .001 seconds of waiting for new data to arrive, we want receive() to return an error condition instead.

 

The important thing is that when data is received while we are not in a receive() call, the OS will buffer it for us and return it when we next call receive().

[donbinator]

Ah!!! There's the missing piece if info. I didn't know that windows is buffering all udp traffic. I'll have to look that up...thanks!

[donbinator]

Oculus Rift DK2 review with DCS

 

Hey all, just got a Oculus Rift DK2 for xmas (awesome wife!) and thought I'd give my impressions so far of using it in my cockpit.

 

It's wonky to set up because I have two video cards and it doesn't seem to like that. To get it to work I have to make the DK2 my primary monitor, then turn it off so I can see again (main monitor becomes primary). Then I start DCS World and make sure "auto detect Rift" is checked. I start the mission and while it's loading turn on the rift. This puts me in a kind of a weird position in the cockpit so I hit "5" to reset my position.

 

Flying around is pretty amazing. The immersion is what's impressive. I'm used to using to my IR tracker so while I used to be able to see 360 deg by just turning my head a little, I now have a realistic range of motion. To look back over my shoulder at my wing man I have to *look back over my shoulder*!

The immersion is so intense that motion sickness is a real problem. When banking left or right my stomach turns when the aircraft banks but my inner ear doesn't feel it. I'm sure one could get used to it much like real pilots have to get used to motion sickness for other reasons.

I have NVidia Geforce 660ti graphics cards with i5 processor and 16 gigs of RAM. Even with that there is enough jidder that it adds a bit the motion sickness and detracts a bit from the immersion. Suspension of disbelief is ruined slightly by jidder, but certainly not completely :).

The graphics are the real problem. The resolution just isn't there yet for this type of gaming. I can't really read any text unless I get really close to it (no chance of reading the text for outside world markers on red/blue units). I can't even see the targets until I get really close. This aspect of the DK2 still baffles me. 1994 is calling and they want their VirtualIO I-GLasses back. Why can't they just take two cell phone screens and stick them in there?

 

In summary: This is *definitely* the future of gaming, including flight sims. All immersion gaming will be using something like this. My kids won't stop bugging me just to play the "swim around like you are a scuba diver" game. It really is a totally different experience. The DK2 in my mind is nothing more than a demonstration of better peripheral vision and head tracking than any other affordable platform has demonstrated, and the power of immersion for gaming (and of course other applications, but I'm just looking at this from a gaming perspective). Otherwise I'm really not seeing any new technology here. First person to put good resolution on a platform that supports the frame-rates needed wins. Oh, and combine that with a Kinect like interface (which I believe people have already done, haven't tried it yet on my Xbox) to track your body movements and insert them into the VR. It really is a strange feeling to hold your hand up in front of your face and not see it.

 

Anyways, I'm having a lot of fun with it, but it's not replacing my cockpit project anytime soon :).

[Socket7]

Display resolution is going to be a big problem with the rift for the foreseeable future I suspect.

 

The display is so close to your face, that it's extremely difficult to get a dot pitch that won't give you a screen door effect.

 

They are also splitting a 1080 display down the middle, leading to aspect ratios and resolutions that modern gamers simply don't find acceptable.

 

Unfortunately, increasing that display resolution and getting rid of the dot pitch problems, mean the rift will require even more graphics heavy calculations. Leading to more stuttering, and lower graphical quality to maintain framerates.

 

To reach a modern HD resolution, the rift would need a computer capable of rendering enough pixels to power 2 HD displays (One for each eye). It gets around this now, by splitting the display in half.

 

The rift is neat, but it's just not ready yet.

 

I'm thinking I might get one after the the second revision of the final product comes out.

Edited December 31, 2014 by Socket7

[bnepethomas]

Thanks for the review, I was tossing up whether to get a kit to trial, definitely sounds like its worth waiting a bit longer.

 

Cheers

 

Peter

[Extranajero]

The immersion is so intense that motion sickness is a real problem. When banking left or right my stomach turns when the aircraft banks but my inner ear doesn't feel it. I'm sure one could get used to it much like real pilots have to get used to motion sickness for other reasons.

 

Some years ago I worked on a 'digital' rifle sight that was basically an LLTV system displayed to the users eye by LCD.

It was fine until the user tried to scan around quickly with it. The display didn't quite keep up with the users head movement and it induced motion sickness and headaches.

Cheaper ( cheap being a relative term ;) ) thermal imaging sights suffer from the same issues, caused by display update lag.

 

It was solvable, but not at the price point which the sight was going to be marketed at.

[donbinator]

Just to be clear though, the Rift DK2 is a *blast* to play with. It's not ready to be a hard core flight sim tool, but man it's fun to put on and just walk around in a haunted house. I seriously can't play "Affected" for more than about 2 minutes before *$&% gets real and I have to whip the display off my head. My 12 yr old son and I have a contest going on to see who can last the longest without removing the head set. You really have to try it to believe what a difference the peripheral vision makes to ones sense of immersion. I think that alone is kind of the point of this product at this phase. It's to say "hey look at what the future of entertainment is going to be like". I can't even *imagine* what the horror movie folks are going to do with this in the future...well actually I can, picture a google map van like view of a horror movie, where instead of looking where the director wants you to look, you can look all around you like you are in the movie. I think most people would run screaming from a decently recording movie script...