Saitek X52Pro Mfd and Fip how to home

if you are getting the display to produce the intended items from the sim , then all is good.

The LUa for windows install may not have installed correctly the first time.

We got Moved !!!!!!

 

Just a heads up .......

A new release for a new home!

 

I added a new feature to the KA-50 exporter. At the moment we have lots of pages with information that is readily available on the normal HUD/instrument panel, so I tried to think of something that would really ease the normal workload of flying the chopper. I realised one of the most annoying things was quickly checking the autopilot states. I'd often get in situations were I'd accidentally leave auto turn on target on, or embarrassing times when I'd forget to turn on the autopilot assists on a cold start and even with my freetrack I'd have to take my eyes off the "road" as it were to check and change them. As such this release has some skill-o ascii art representations of the autopilot lights on the MFD! I'm quite pleased how this came out and think it makes a genuinely useful addition to the game (I'm aware that so far a lot of the stuff on the MFD is a little gimmicky - it's often simpler just to look at the relevant gauge etc in the game). Here's a picture of it running:

 

 

In this picture I've got Auto turn to target and Moving ground target lights on the left panel, and bank, pitch and heading hold on the right panel. The top right can also show the Flight Director light, marked with a D when on.

 

Saitek Ka-50 Exporter 0.3

 

New Features

 

- Auto Joystick Profile loading. This is commented out in the release file. To enable it, remove the "--" comment marks from the start of line 10. The path shown should be the default for the SST software on a standard Windows 7 installation, so you should be able to just change the filename specified at the end to the filename of the profile you are actually using for your Ka-50.

 

- New page showing autopilot light status as above. Shows the status both for weaponry assist modes and also for the actual autopilot.

 

Installation

 

If you're using my autoloader export.lua from (download here - highly recommended), then just save this file as-is into your Saved Games\DCS\Scripts\ folder and it will automatically be loaded every time you fly a Ka-50 mission. If not, rename it to export.lua and put it in there.

saitekka50.lua

Another post before bed..

 

I spend some time over the weekend working on my own A-10C exporter. I got a lot of stuff working, but have been largely stumped by the damned radio controls (I can see why algerad3 was having so much trouble now!). I've got the ILS, and AM and FM VHF radios reporting their information to the screen, and also fully controlling them from the rotary dial. Sounds great, but "working" really needs to be in inverted commas - none of them behave as I expected.

 

I'm in over my head on the rotary stuff, and I really need to sit down and work out the theory behind how the bitwise operations work (never done this kind of mathematical stuff before). I actually managed to successfully replace the bitwise AND code (the only operation used by algerad3's Ka-50 code I cribbed off so heavily!) with a shorter supposedly faster one someone had written, but it doesn't seem to have made any difference to performance or stability.

 

Stability is also a big problem. I don't know if it's the bitwise operations code not being quite right, or the dll file or a combination of both ( crash logs seem about 50/50 that I can make out), but as with the Ka-50 exporter the rotaries cause guaranteed crashes. It's hard to test stuff out as I'll often get a crash just moving the dial twice five seconds into a mission.

 

I really wanted to get this kind of "hard" stuff working good first as I think some really interesting things can be done with the A-10C's controls, and really add to the game, but for now I have to admit temporary defeat!

NO, Not a good idea. Giving up is for someone else. As far as you have gotten , a nap is in order and a fresh look later. I think I have found some info that may make things come together for the rotaries. Let me study more and work it out. Also, I think a lot of crashes are coming from the fact that DCS products only use two threads and we are adding directoutput commands to the mix, in other words I think we are over working the threads/program. we need to kick the info over to another receiver program that operates alone and sends/receives info to and from Dcs module. The addition you created for selecting modules/lua export is just the ticket we needed. I will work on a Saitek lua socket and from there we can better control input and output, thus we should be able to eliminate the crashes.

The lua export we are working with were meant to show that it works , it now needs to be separated from the main program. That is my theory for now.

Forgot, I do agree with Moburma ; most of the things that has been done with the mfd is a little gimmicky considering the position of the mfd on the throttle.

I have the option of tearing apart my x52 and creating a panel that will house my switches and mfd screen. Once done , I will be able to set it up in front of my monitor and be able to glance at the readout.

Haha, don't worry, i'm not going to give up, just take a break for a while. I might even try messing about with the SU-25, I've not even tried to fly that yet, so maybe making an exporter for it would be one way to learn how it works.

 

The most annoying rotary problem I had was dials not increasing by the amount I expected. I had the same bug with the first ILS dial as this guy where it doesn't behave in a logical way. I also had problems with all the other dials not going increasing their values other than two or so different extreme settings that is almost certainly just bad code on my part. I also had a weird thing where it seems the second ILS dial outputs null values when set higher than 0 that causes the x52 page its on to completely die, really weird.

A tiny update seeing as the thread has all but died. I tried investigating the crash behaviour, and it seems to be something to do with the bitwise operations. I don't know if it's the game receiving values it doesn't expect, or simply too much data is being pumped into the process, but even I remove any end processes, simply calculating how the dial has been moved consistently crashes the game. I've even tried it with a simplified of code to B and and this doesn't make any difference to stabilty compared to the code Algerad3 was using. It's annoying as I just don't know where to begin to fix the problem. It's a shame, as essentially getting a new free control on your joystick would be one of the very best features of this script.

 

Despite all this I might release an A-10 script soon. I might just take all my dial code out of it as it just seems to cause crashes and none of the dials behave properly anyway, but I'll think of useful stuff to add in and you'll have the usual features such as auto profile loading and landing gear lights on the LEDS etc.

Moburma,

I think the crashing has to do with the way it is currently ( radio dials callback) is set up. I removed all but one of the dials and was able to make it work without crashing. I need to work on the loop. Also on the black shark, there was an issue posted about the wrong values being exported in some cases when moved too fast. About to head home so, no internet for a few days, will update when I get home.( In about ten days, don't let this thread die....LOL.)

Yes , it is hard coded to use lua 5.1 I actually had to re-install my c drive and I tried to use 5.2(?) the new lua module. It failed and I spent half the day trying to figure it out.

 

Awesome job on the guide.

 

Indeed, 5.2 has some changes that make it fail.

 

Haven't look at it yet.

The recent Huey release has spurred me back into action!

 

Getting the A-10 to behave drove me round the bend, but thankfully the Huey has been reasonably simple to get working with the exporter dll. As such here are two new releases - an update for my auto export loader, and an exporter for the UH1.

 

Automatic Saitek Export Lua Script V 0.2

 

-- Now suppots the new UH-1H Huey module. To create your own, just call it saitekuh1h.lua

 

Saitek UH-1H exporter version 0.1

 

-- Basic information on one page, airspeed, altitude and vertical speed.

-- Airspeed is NOT correct at the moment, but I think I know how to fix it. At the moment it's just "ballpark" accurate. Altitude goes weird under 100 feet or so as with the P-51 exporter, but again I can fix it, just need to get round to it.

-- Auto loading of joystick profiles. As ever uncomment line 10.

-- Toggle LEDs represent from left to right: Master Caution Lamp, RPM Limit lamp, Fire warning Lamp.

 

As you can see this is pretty crude, but it's a start! The Huey seems a pretty easy mod to get going, so once I've flown it a bit more (and can manage to not crash every 10 seconds) I'll try and add useful things to this.

Export.lua

saitekuh1h.lua

Well, Someone is all over it. I am on vacation soon, I will give the radios a whack.

Saitek UH-1H exporter version 0.2

 

-- New page with info on engine related gauges

-- Fixed odd altitude behaviour

 

Haven't sorted out airspeed yet, will get to that eventually!

saitekuh1h.lua

Fixing the dial

 

So far for me the most exciting yet also frustrating aspect of the new possibilities of Chrillith's DLL is the use of the extra rotary dial. I mean you're literally getting a free new button out of the blue! The problem is as we know that it is just not useable as-is, you are guaranteed constant crashes if you try and use it. From my experiments it seems this is caused by the overhead of processing the bitwise operations to work out when and how the dials have been operated. This just seems to be too much work for the export.lua/DCS to cope with. I tried finding a simpler bit of code to run BAND than the one Algerad3 used, but there was no real difference - just constant crashes.

 

I'm determined to find a solution to this, but I'm hampered by very little knowledge of Lua and what can be done with it, as well as just plain little programming knowledge overall, if i'm honest. I understand that the problem is that Lua 5.1 doesn't have bitwise operations built into it, so these have to be written by hand as functions in the code - and this seems to kill DCS.

The one thing that does seem to offer a ray of hope then, would be to offload the overhead of the bitwise operations to an external dll file.

 

Looking at the Lua 5.2 release, it seems to come with this built in, an external bitwise dll that handles all this stuff for you, minimising the overhead. Sounds great, let's just use that then! The trouble is that I just can't get it to work. DCS reports it as not being a valid Win32 executable. I'm not sure if it's due to it not being a 64 bit dll, or if you just can't use it this way with DCS World's handling of Lua, or if I've just done something obviously wrong. Can anyone with some more knowledge of these things chip in and give a guiding hand?

 

Displaying stuff on the screen is cool, but ultimately not that useful, and indeed not useful at all if you have the throttle mounted in a realistic position, but getting the rotary dial to work would be a real coup. Someone? Anyone? :D

I am afraid that the Lua module needs to be a 64 bit module and that there were many changes in lua 5.2 that made it incompatible with the Saitek Dll and Dcs's lua dll ( It appears that they are using 5.1 as well.)

As for the rotary iirc I had used it for landing gears without issues.

It should work for simple state buttons ( on /off) when using it for the Black shark radios, I can use it if i go slowly for the most part. for any other module it will not stop at the desired rotation point.

I believe that is because even though the scroll wheel rotates, it does not send out a rotary type signal and basically tells the program that we made a complete rotation of the dials.

The Saitek Flight instrument panels have the same effect on the abris when I tried to program it.

Bottom line , we are not sending the right info on the "button" press to the simulator.

I finally have a day to myself and I will investigate further as soon as I can clear off my desk and find room.

I've got the Pro version coming in the post this week any tips heard the software isn't great and to just program using the in-game stuff once the driver is installed?

 

Helpers can have rep :thumbup:

 

Wow just read the thread great going guys! Gonna download these files and get them working once i got it.

 

Is there a place to download all the different mod x52 files

Edited May 7, 2013 by TimeKilla

Ahh, that's interesting. I've seen the behaviour you are talking about on the A-10, the dials go screwey as hell, landing on numbers that are impossible to normally reach. However, I've experimented by commenting out the actual "outcome" of any of the dial functions (i.e. the performClickableAction code that actually does anything with the information that the dial has moved) and I was still getting consistent crashes if I e.g. just constantly span the wheel around. I'll try it again, but to me it suggested that it WASN'T the code that actually did anything that was causing the crashes, but the act of seeing what state the physical dial was in that was messing it up. Your info does make a lot of sense though. Even if radio dials are out I can think of many other uses for the rotary.

 

Looking at the page for lua bitops it seems the newest version is backwards compatible with Lua 5.1, so should be useable for it. The problem is it's only a 32 bit dll and don't know what I'm doing to compile it as a 64 bit dll. I'll see what I can make of it.

 

Edit:

 

Oh yeah, one more thing that's more of a general export.lua question anyone familiar with that could probably answer: did you export stuff like the airspeed indicator from the A-10c? I just get weird null values that crash the MFD if I export it and it's driving me mad. It also happens with altitude and the LAST dial of the ILS indicator (!?). It's just weird as trying to get the info from them behaves totally different to any other instrument in a DCS module, and to the other dials in the A-10. Is it just me being a moron or is there some trick to it (seeing as people have been exporting that info for ages)?

Edited May 7, 2013 by Moburma

I've got the Pro version coming in the post this week any tips heard the software isn't great and to just program using the in-game stuff once the driver is installed?

 

Helpers can have rep :thumbup:

 

Wow just read the thread great going guys! Gonna download these files and get them working once i got it.

 

Is there a place to download all the different mod x52 files

 

I actually think the X52 software IS pretty good, and personally would not recommend setting it up in game. One thing I think people get confused on is that AXIS controls must be set in game only, they can't be set in the X52 software (good examples being the throttle/collective in any of the aircraft, which DCS annoyingly defaults as the slider control on the throttle. you will need to set this by hand in DCS World itself to use the throttle properly). You also miss out on the "shift" modes of the X52, which is one of the big selling points of it in the first place, if you set controls directly in game. I couldn't imagine flying the A-10 without lots of use of shifting. I also have what I consider a quite clever profile I made for the KA-50 that uses the shifter to switch the gun trigger state somewhat like you would do in the real chopper by using the saitek software.

 

Getting the stuff mentioned in this thread going is admittedly quite confusing. I wrote a guide here, but it's still a bit clumsy and some info is slightly out of date. I might write another one, and I've been thinking of starting a blog for this and other things I've been up to. If I do I might stick it on there. For now just read that, and I recommend getting my framework loader and the latest version of each exporter you're interested in from my posts to be up to speed.

 

Any feedback would be much appreciated, especially ideas for what should be on screens etc. Algerad3 did a great job with the KA-50 but mine have been a little bare in comparison!

Oh yeah, one more thing that's more of a general export.lua question anyone familiar with that could probably answer: did you export stuff like the airspeed indicator from the A-10c? I just get weird null values that crash the

MFD if I export it and it's driving me mad. It also happens with altitude and the LAST dial of the ILS indicator (!?). It's just weird as trying to get the info from them behaves totally different to any other instrument in a DCS module, and to the other dials in the A-10. Is it just me being a moron or is there some trick to it (seeing as people have been exporting that info for ages)?

 

Well for now it is a self learning curve. Not much help from others on this matter. As for the dials on the hawg. You have to go three decimal places to get any real values to show. Then figure out the math to make it read right. Unfortunately, I have not figured that part out yet.

The new click able data is giving me grief so I am still testing mostly on the stand alone modules. Right now I am going to go through the frequency dials individually and figure it out.

You do know that there are various switch types (rotary, lever...etc each one has to be programed differently., hence the learning curve.)

Time Killa, It really depends how you want to work things. Before I got the X-65 I used both the keyboard and some functions/buttons on the joy stick.

I never really played with the software since Falcon 4.

Like Moburma stated , it would be useful to have a shift state function working .

I understand that for some people had issues running the Saitek programm with dcs, those complaints have seemed to all but dis appear since world.

Any question about your gear feel free to ask us here. It will help us stay in the active column and we are eager to reply to post here.

 

 

Maybe we should figure out how to organize the current run of information into the wiki?

Edited May 8, 2013 by algerad3
forgot to ask a question.

Ok, some good news and umm, massively bad news.

 

Good news: I managed to compile a 64 bit version of bit.dll and get it working perfectly with DCS world.

 

Bad news: It still behaves in exactly the same manner as before and is just as unstable. Just like the other implementations it will crash the game even if the script does nothing with the bit information; it seems it's the act of calculating the difference itself that still causes the crashes.

 

I've tried shifting around where the bitwise code runs in the script, but nothing seems to make any difference.

 

If you want to try yourself, download the dll file included with this post, and stick it in DCS world/bin, and add this code to your export.lua:

 

local bit = require ("bit")

function bitSet(value, bitMask)
    v = bit.band(value, bitMask)
   return v ~= 0
end

This will only work in the KA-50 exporter at the moment (only public one with dials), and you need to delete all the old bitwise code at the top. Better still, don't even bother as it doesn't give any advantage to using that code anyway. :Flush:

 

So yeah, back to the drawing board. I really need someone much smarter than me to study the crash logs and work out why the hell this happens.

bit.zip

Actually, I just tried another test.

 

This time I ripped out all the bitwise code, all the radios code, etc. All I left in was the softbuttoncallback and an empty function to send its info to, just enough to keep the lua code running. Spinning the rotary STILL caused the crash, even with the bitwise code removed. So therefore it looks like I'm an even bigger idiot, and it probably ISN'T the bitwise code that is causing the problems, and also why it still behaves exactly the same way despite using three different ways to tackle the problem.

 

Is it actually a bug in Chrillith's dll/the way it interfaces with DCS World that causes the crash all along?

Actually, I just tried another test.

 

This time I ripped out all the bitwise code, all the radios code, etc. All I left in was the softbuttoncallback and an empty function to send its info to, just enough to keep the lua code running. Spinning the rotary STILL caused the crash, even with the bitwise code removed. So therefore it looks like I'm an even bigger idiot, and it probably ISN'T the bitwise code that is causing the problems, and also why it still behaves exactly the same way despite using three different ways to tackle the problem.

 

Is it actually a bug in Chrillith's dll/the way it interfaces with DCS World that causes the crash all along?

 

Hi there,

 

Well I think I have to take a look at this now. I already worked on some changes to have a better handling of multithreading but stopped the work since the problem seemed to occur in Flight Simulator only. I'll go back to work and give you a new DLL. Unfortunately I cannot work on it before mid-next week :(

Moburma , I am still under the impression that inserting the code for the saitek device directly into the Lua export is the issue.

I believe ( my uneducated guess) the lua is for sending and receiving info and all the other commands are to be created in another program(thread).

By introducing our button commands in the manner we are using is causing memory errors.

I took another look at a partial debug instance and keep finding access violations, which if i am correct means that the values being accessed by the sim and sent tot the mfd are changing in a manner that is difficult for the program (export ) to get a good read. More simply put, we are trying to get a freq value and when it is time to be read out of memory, the value is changing, the export lua has a deadline to get the information, before frame /after frame. The information is not changed and read fast enough or the information is in flux at time of reading. Move wheel slowly and info is read , move faster and the info is still changing and not ready. Let me get a bead on the rest of your experiment before I comment on that part.

Chrillith,

It seems you replied while I was typing up my response to Moburma, Good to see you are back.

Currently we have questions in regards to control of the Rotaries. What kind of output are they giving us?

Is it a rotary type value or button type? I.e mouse wheel vs. mouse click?

Not sure if you have time to look at the lua export maybe you can clarify thing as far as command inputs.

Trying to tackle this in between other pressing matters.