Jump to content
The simFlight Network Forums
Steve38

GoFlight EFIS and MCP PRO Full Interface for PMDG NGX

Recommended Posts

Hi Steve, it is completly crazy.

I went into FSUIPC and played a little bit with all the button to see if something was attached to one of them like you told me, I went back to FSX activate the lua script like I always do, and guess what now it works ....

I dont know if the test program as done something, if the fact that I went to FSUIPC without activating the script and play with the button did something, but now it works again.

Anyway, a big thanks for your patience and your help, and of course for your EXCELLENT script.

Hope I wont come back again i few days ;)

Thats very odd Frank. Something isn't right somewhere; but see how you get on and give me a shout if needed.

Best wishes

Steve

Share this post


Link to post
Share on other sites

Hi Steve038, I am sorry to disturb you again, but I have a question, could you please tell me what is the function of this part of your code :

local function toggleVORL(state, unit)

if unit == GFEFISU then

if state == 0 and ipc.readLvar('ngx_switch_358_a') ~= 0 then

ipc.control(69990, -2147483648)

ipc.control(69990, 524288)

ipc.control(69990, -2147483648)

ipc.control(69990, 524288)

elseif state == 1 and ipc.readLvar('ngx_switch_358_a') == 0 then

ipc.control(69990, 536870912)

ipc.control(69990, 131072)

end

else

if state == 0 and ipc.readLvar('ngx_switch_414_a') ~= 0 then

ipc.control(70046, -2147483648)

ipc.control(70046, 524288)

ipc.control(70046, -2147483648)

ipc.control(70046, 524288)

elseif state == 1 and ipc.readLvar('ngx_switch_414_a') == 0 then

ipc.control(70046, 536870912)

ipc.control(70046, 131072)

end

end

end

local function toggleADFL(state, unit)

if unit == GFEFISU then

if state == 0 and ipc.readLvar('ngx_switch_358_a') ~= 0 then

ipc.control(69990, 536870912)

ipc.control(69990, 131072)

ipc.control(69990, 536870912)

ipc.control(69990, 131072)

elseif state == 1 and ipc.readLvar('ngx_switch_358_a') == 100 then

ipc.control(69990, -2147483648)

ipc.control(69990, 524288)

end

else

if state == 0 and ipc.readLvar('ngx_switch_414_a') ~= 0 then

ipc.control(70046, 536870912)

ipc.control(70046, 131072)

ipc.control(70046, 536870912)

ipc.control(70046, 131072)

elseif state == 1 and ipc.readLvar('ngx_switch_414_a') == 100 then

ipc.control(70046, -2147483648)

ipc.control(70046, 524288)

end

end

end

Here is why I am asking you the question, I have an EFIS from opencockpit, and I use a lua script from roarkr on AVSIM, and when I push the VOR 1 switch to VOR 1 , I have my MCP Pro HDGSEL button that light up, and then immediately light off, and of course on the NGX, I can see that the VOR1 swicht goes back to off, even if on my Opencockpit EFIX the switch is still on VOR 1. Have of course the same problem using ADF 1 / VOR 2 / ADF 2.

Do you have any idea what can I make to solve the problem.

Share this post


Link to post
Share on other sites

Hi Steve038, I am sorry to disturb you again, but I have a question, could you please tell me what is the function of this part of your code :

local function toggleVORL(state, unit)

....

end

Here is why I am asking you the question, I have an EFIS from opencockpit, and I use a lua script from roarkr on AVSIM, and when I push the VOR 1 switch to VOR 1 , I have my MCP Pro HDGSEL button that light up, and then immediately light off, and of course on the NGX, I can see that the VOR1 swicht goes back to off, even if on my Opencockpit EFIX the switch is still on VOR 1. Have of course the same problem using ADF 1 / VOR 2 / ADF 2.

Do you have any idea what can I make to solve the problem.

Hi Frank,

You must make sure you have disabled the EFIS code in my script including the stuff you quoted. To do this, go to the user customisable section near the top and change:

DISABLEEFIS = 0

to

DISABLEEFIS = 1

That way, no EFIS code will ever be executed by script. If it persists I would firstly suspect the script you are using for the EFIS is sending the wrong LUA commands.

Let me know how you get on.

Best wishes

Steve

Share this post


Link to post
Share on other sites

Hi Frank,

You must make sure you have disabled the EFIS code in my script including the stuff you quoted. To do this, go to the user customisable section near the top and change:

DISABLEEFIS = 0

to

DISABLEEFIS = 1

That way, no EFIS code will ever be executed by script. If it persists I would firstly suspect the script you are using for the EFIS is sending the wrong LUA commands.

Let me know how you get on.

Best wishes

Steve

Hi Steve, the EFIS is set to 1 into your sript so it is disable.

The other script I am running is this one : NGXEFIS_PP_2.02.lua, you can find it on AVSIM by searching opencockpit. I prefer to tell you the script than copying it here without the authorization of the writter.

Share this post


Link to post
Share on other sites

Hi Steve, the EFIS is set to 1 into your sript so it is disable.

The other script I am running is this one : NGXEFIS_PP_2.02.lua, you can find it on AVSIM by searching opencockpit. I prefer to tell you the script than copying it here without the authorization of the writter.

Hi Frank,

I've just had a quick look at the other guys script and found the problem. It uses the same offset's as my script for the MCP so that when data is written by the open cockpits interface it is interpreted by my lua script as a change in the MCP state. Esentially the memory addresses 0x66D0 to 0x66DD are used by both scripts and therefore clash.

The only way around this is for the scripts to be changed so they do not use the same offsets. Its late here, but a quick check seems to indicate that if you do a search and replace in my LUA file for every occurance of "66D" and replace it with "66E" and then save the file, that should sort out the conflicts.

Best wishes

Steve

Share this post


Link to post
Share on other sites

Hi Frank,

I've just had a quick look at the other guys script and found the problem. It uses the same offset's as my script for the MCP so that when data is written by the open cockpits interface it is interpreted by my lua script as a change in the MCP state. Esentially the memory addresses 0x66D0 to 0x66DD are used by both scripts and therefore clash.

The only way around this is for the scripts to be changed so they do not use the same offsets. Its late here, but a quick check seems to indicate that if you do a search and replace in my LUA file for every occurance of "66D" and replace it with "66E" and then save the file, that should sort out the conflicts.

Best wishes

Steve

You are a god, that works, just tested quicly but VOR/ADF is now working without interfering with the MCP, will test during a full flight tomorrow ( this afternoon lol)

thanks again, for your kindness.

Franck

Share this post


Link to post
Share on other sites

You are a god, that works, just tested quicly but VOR/ADF is now working without interfering with the MCP, will test during a full flight tomorrow ( this afternoon lol)

thanks again, for your kindness.

Franck

LOL, hardly. Glad its working OK though.

Best wishes

Steve

Share this post


Link to post
Share on other sites

I can’t get the CMP Pro to sync correctly with the ngx. It loads up fine but then the stitches start going nuts. The EFIS works like a charm but the mcp is temperamental. It appears that something is directing the left and right FD switches on then off repeatedly. If I put both FDs and the AT in the up position they stop stitching for a while but then the dials stop working correctly. I am using GF 1.93.2 setup as I can’t get the 2.03 zip file to open on my pc. McAfee also thinks the download site is a Trojan. I’m running a registered version of FSUIPC 4.8 I also use EZdok and TrackIR.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.