ckovoor

Dear Pete, I currently use FSUIPC 4.974b and WideFS/WideClient 7.148, and the setup and method described in this thread has worked flawlessly on my System, with Clients running FSX on both Win7 x64 and Win 8.1 x64. However, yesterday I added a new Client running FSX on Win 10 x64. This time I found the keystrokes were not being transmitted to the local FSX window, and the WideClient.log showed this: ********* WideClient Log [version 7.148] Class=FS98MAIN01 ********* Date (dmy): 10/09/18, Time 19:44:26.551: Client name is INSPIRON3567 172 Attempting to connect now 172 LUA: "C:\FS Files\WideClient7148\Initial.LUA": not found 172 Trying TCP/IP host "SERVER" port 8002 ... 172 ... Okay, IP Address = 169.254.152.178 172 Connection made okay! 276172 Can't SetWindowsHookEx! (Action request 3) 278312 Can't SetWindowsHookEx! (Action request 4) 391906 Can't SetWindowsHookEx! (Action request 3) 394984 Can't SetWindowsHookEx! (Action request 4) 397766 Can't SetWindowsHookEx! (Action request 2) 399297 Can't SetWindowsHookEx! (Action request 4) 1373719 Can't SetWindowsHookEx! (Action request 5) 1375594 Can't SetWindowsHookEx! (Action request 4) The corresponding WideClient.ini : [Config] ServerName=SERVER Protocol=TCP ButtonScanInterval=20 ClassInstance=1 NetworkTiming=5,1 MailslotTiming=2000,1000 PollInterval=2000 Port=8002 Port2=9002 ResponseTime=18 ApplicationDelay=0 TCPcoalesce=No WaitForNewData=500 MaxSendQ=100 OnMaxSendQ=Log NewSendScanTime=50 Priority=3,1,2 Window=515,349,405,365 ReconnectMinutes=0 [Sounds] Path=C:\Program Files\WideClient6999b\Sound\ Device1=Primary Sound Driver Device2=Speakers and Dual Headphones (IDT High Definition Audio CODEC) Device3=SPDIF (Digital Out via HP Dock) (IDT High Definition Audio CODEC) [User] RunKey1="C:\Program Files\IrfanView\i_view64.exe /capture=0 /sharpen=20 /jpgq=100 /convert=\\SERVER\Flight Simulator X Files\ScreenShots\S4_$U(%d%b%y_%H%M%S).jpg" ;RunKey1="C:\Program Files\IrfanView\i_view64.exe /capture=0 /sharpen=20 /jpgq=100 /convert=C:\Users\Chakko Kovoor\Documents\Flight Simulator X Files\ScreenShots\S4_$U(%d%b%y_%H%M%S).jpg" KeySend1=RunKey1 KeySend2=39,8,FS98MAIN KeySend3=37,8,FS98MAIN KeySend4=36,8,FS98MAIN KeySend5=38,8,FS98MAIN KeySend6=40,8,FS98MAIN And here, for reference, is a WideClient.log from a Client running FSX-Win 7 x64 which successfully intercepted and responded to the keystrokes: ********* WideClient Log [version 7.148] Class=FS98MAIN01 ********* Date (dmy): 10/09/18, Time 19:43:50.431: Client name is SILVERZERO 140 LUA: "C:\FS Files\WideClient7148\Initial.LUA": not found 140 Attempting to connect now 140 Trying TCP/IP host "SERVER" port 8002 ... 140 ... Okay, IP Address = 169.254.152.178 140 Connection made okay! It seems that on a Client running Windows 10, WideClient cannot transmit the required keystroke to the local FSX window. I wonder if you could help me solve this problem. Thanks and Regards, Chakko.

For my own home-built hardware EFIS+MCP for the PMDG B737 NGX (SP1c) I use a FSUIPC mouse macro for this and it works: Capt EFIS Ctr=RX19770*X8bcc I don't remember if I tried the control and reverted to using a mouse macro because it didn't work.

Dear Pete, After a couple of flights on the Level-D B767 with my hardware MCP running with the old and new lua's alternately, I can also confirm that the new version does not suffer from the same 'bug' (i.e. short press also acting with long press). I will therefore be using the newer version from now on. I look forward to seeing a commented version of this new lua. Thanks and regards, Chakko.

Hi Pete and Pizman, I seem to have encountered the same issue, while using TripleUse.lua in my Level-D B767 MCP, as reported in this post: in which I have stated: I decided to live with the problem, at the time, and it has been a while since I have flown the LD-B767. But I will now be taking out the MCP and making a few tests with your new lua to see whether it solves the problem. Thanks, Chakko.

Did you mean to use ipc.readFLT(0x6C34) ?

(1) For ADF1: -- adf1 (active) display adf1f_main = ipc.readUW(0x034C) adf1f_frac = ipc.readUB(0x0356) adf1f_upper = ipc.readUB(0x0357) and: -- adf1 (active) selector ipc.control(65666,1) ipc.control(65648,1) ipc.control(65667,1) ipc.control(65649,1) ipc.control(65668,1) ipc.control(65650,1) ipc.control(66453,1) ipc.control(66454,1) I think you would plan to write to the offsets, rather than use the FSX (incremental) controls that I have. I could not access ADF1 SBY nor indeed ADF2 ACT or ADF2 SBY, and PMDG has not provided any information about these. (2) For COURSE: -- course display 0x6520, "UW", "MCP_Course1" 0x6522, "UW", "MCP_Course2" -- course 1 selector ipc.control(70008,8192) ipc.control(70008,16384) -- course 2 selector ipc.control(70041,8192) ipc.control(70041,16384) I do not know whether it is possible to write to the COURSE offsets, as they might be read-only. As you can see I used the incremental controls supplied. Regards, Chakko.

Dear Holger, I fly the PMDG B738 NGX and have constructed my own hardware MCP+EFIS for it. I recently also constructed my own hardware Universal Radio Panel and am able to use it with the NGX without any modification. My hardware is based on Arduino Megas. Here is a screenshot of the B738 NGX radio panels in flight: And here is my radio panel which I am using to emulate it: As far as the NGX is concerned, absolutely no modification was necessary to my hardware/software to manipulate the COM and NAV frequencies, ACTIVE and STANDBY. As Pete surmised, all the default radio controls do in fact work with this airplane, and I was able to manage the frequencies entirely with the standard FSX/FSUIPC offsets and controls. (There is a problem with ADF2 and both ADF STANDBY frequencies, however, in that I have not been able to find where PMDG stores those.) From my screenshot, this does not appear to be so. Each radio has its own control knobs. Again, from the NGX panel screenshot, you will see that you do in fact need to turn knobs to increment/decrement the COM and NAV frequencies, and do not set specific frequencies directly through a common keypad. Finally, if your only requirement is to set the frequencies (values) directly through a keypad-like device (though that is not how the PMDG version works), you would need to write to the standard FSUIPC offsets: 0x034E, "UW", com1_freq 0x311A, "UW", com1_sby 0x3118, "UW", com2_freq 0x311C, "UW", com2_sby 0x0350, "UW", nav1_freq 0x311E, "UW", nav1_sby 0x0352, "UW", nav2_freq 0x3120, "UW", nav2_sby Regards, Chakko.

Hello David, It's nice to know of people still using WidevieW with networked scenery clients. I operate a WidevieW+WideTraffic-based network of 11 pc's (all Win7x64 + FSX-SP2), of which the Server generates 2-D cockpit panels only, 7 Client pc's generate the out-of-cockpit-window scenery views, 1 Client pc generates an external spot view, and 2 more remote Client pc's are used as Instructor Stations. I have used FSUIPC-WideFS, FSUIPC-LUA, Input Director, AutoHotkey and Autoit to address the tasks of communicating with Client PC's in the WidevieW network. To send Ctrl+J to Clients and Server to toggle jetway operation there: (1) Although one could use FSUIPC-WideFS to achieve this, I prefer to use Input Director for this task, because Input Director has a keyboard-macro feature which can be set up to send such keystrokes to the Clients (individually or collectively) as well as the Server (as you also need to do, because your Server also displays scenery). I would recommend that you consider this option, because Input Director is primarily a solution for using the Server's keyboard and mouse across your entire network, which is anyway a great help in a WidevieW-based network. (2) While Pete has explained what you need to do to get this working using WideFS, these are the specifics of how one might realize it: On the Server FSUIPC4.ini: [Keys] 1=74,10,1006,1 2=74,10,66695,1 Use TOGGLE_JETWAY = 66695 from the List of FSX and P3D controls, in order to toggle jetway locally (as an alternative to sending Ctrl+J to local FS). I have not tested this, so please let me know if this works. At the Client PC WideClient.ini: [Config] ServerName=SERVER ClassInstance=1 [User] KeySend1=74,10,FS98MAIN I hope this helps. Chakko.

You could try ipc.control(69997, -2147483648) or ipc.control(69997, 2147483648) to increase, and ipc.control(69997, 536870912) to decrease.

deleted

From the Lua Library documentation: it would appear that you would write: ipc.macro("Lua B777PowerUp") without an intervening colon when executing other Lua plug-ins, though I am not sure that this is the cause of your problem.

Lua also has a feature called Coercion, but that does not work with comparison operators, and that is probably why you saw the error you reported. From http://lua-users.org/wiki/NumbersTutorial:

Lua 5.1 has a tonumber() function which might do what you are seeking. Please see: http://www.lua.org/manual/5.1/manual.html#pdf-tonumber for example: > = tonumber("123") + 25 148 > x = tonumber("123.456e5") > print(x) 12345600 > y = "234" > z = tonumber(y) > print(z+10) 244

I would suggest that you post all of the relevant code so that it could be checked for any other lacunae.

I would imagine (though I have not used this function myself) that you would use: ipc.set( "KiloPoundFaktor", KiloPoundFaktor) to set it, and KiloPoundFaktor = ipc.get( "KiloPoundFaktor") to retrieve it.

I have not myself worked with setting and accessing global variables across separate LUA threads, so I hope someone better qualified will step in here to advise you, but you might find something useful in this thread: http://forum.simflight.com/topic/81176-lua-ipcset-and-ipcset/#comment-489713

The length does not matter, but the data must be purely numerical, so decimal dots or commas would not be acceptable. In my code you can see that 'battery' has a different length.

Yes, that should work, just as my script works......... In a subsequent post in the same thread: http://forum.simflight.com/topic/77525-updating-radio-frequencies-for-wideview-network/?do=findComment&comment=470781 I have shown how several values can be written as a code string, just numbers with non-number separators......I used pure text separators like "COMone=". I have also shown how that string can be decoded.

It is possible, and you can see an example in this thread: http://forum.simflight.com/topic/77525-updating-radio-frequencies-for-wideview-network/ Get back to me for any clarifications.

From the FSUIPC4 for Advanced Users document, page 20:

(1) Yes, they are separate LUA files, like B777Captain.lua etc (2) Placing a LUA filename in the [Auto.B777] section causes that LUA to be run when the aircraft is loaded. You would not need to make entries within the LUA for that.

I don't see the need for a "Lua File as MainControl". You could simply create an [Auto] section for each aircraft which ensures that the (listed) LUA's specific to that aircraft are run when that aircraft is loaded. Here is an extract from my FSUIPC.ini which should illustrate this: [Auto.B777] 1=Lua B777captain 2=Lua B777centrepanel 3=Lua B777copilot 4=Lua B777overhead1 5=Lua B777overhead2 6=Lua B777throttle 7=Lua B777radios 8=Lua b777inputsLeft 9=Lua b777inputsRight 10=Lua B777outputs1 11=Lua B777outputs2 [Auto.Dash8Q400] 1=Lua D8Q4inputsLeft 2=Lua D8Q4inputsRight 3=Lua D8Q4box [Auto.A320X] 1=Lua trimwheel 2=Lua A320Xlights 3=Lua A320Xinputs1 4=Lua A320Xinputs2 5=Lua A320Xbox The LUA's you see here interface the simulator with Arduino Mega's which either accept inputs from hardware switches and encoders or drive outputs on LED's and OLED's.

You could use either (depends on the variable): (1) ipc.control(xxxxx, 16384) to increase, and ipc.control(xxxxx, 8192) to decrease, or (2) ipc.control(xxxxx, -2147483648) to increase, and ipc.control(xxxxx, 536870912) to decrease. Please see thread: Chakko.

Addendum: With the earlier panning procedure using Swivel or Ordinal methods, I found it necessary to use Virtual Cockpit views to get full functionality. But the power of this SimConnect_CameraSetRelative6DOF method is that it works equally well with 2-D cockpit views. Here are some settings I used to test this with my A300B4-203 at VOML: The Camera definition selected must contain an InitialPbh, in this case I have selected the left-of-centre view at -26 degrees: [CameraDefinition.001] Title = Cockpit Guid = {B1386D92-4782-4682-A137-738E25D1BAB5} Description = This is the description of the cockpit view Origin = Cockpit ShowPanel = Yes SnapPbhAdjust = Ordinal SnapPbhReturn = True PanPbhAdjust = Ordinal PanPbhReturn = True InitialPbh = 0.0, 0.0, -26.0 Track = None ShowAxis = FrontOnly AllowZoom = TRUE InitialZoom = 1.0 SmoothZoomTime = 0.0 ShowWeather = Yes XyzAdjust = TRUE ShowLensFlare=FALSE Category = Cockpit HotKeySelect=2 And the same camera is selected in the .FLT: [Window.1] Order=0 Active=True Undocked=False Maximized=True ScreenUniCoords=0, 0, 8192, 6144 UndocCoords=0, 0, 0, 0 CurrentCamera={B1386D92-4782-4682-A137-738E25D1BAB5} : [Camera.1.1] Guid={B1386D92-4782-4682-A137-738E25D1BAB5} Zoom=2.5569632053375244 Translation=0, 0, 0 Rotation=0, 0, 0 And here are the screenshots: You can see how the scenery views remain perfectly aligned even after rotating though 56.25 degrees to the right and 5 degrees down. Chakko.

So here is the refined method: Objective: With FSX CONTROLLERS DISABLED on the WidevieW SERVER, to be able to transmit view-panning commands to networked WidevieW CLIENTS. Requirements: Registered FSUIPC4 and WideFS Summary of Process: When a panning-command (via Hat-Switch button) is applied at the SERVER, FSUIPC-WideServer sends a KeySend number to all networked Clients. At each CLIENT, WideClient receives the KeySend number and sends a key-press to FSX-FSUIPC. An auto-started LUA script intercepts this key-press and rotates the view appropriately using the SimConnect_CameraSetRelative6DOF function. Certain options in the wideviewx.ini file at the CLIENTs and SERVER need to be set to ensure that it does not interfere. A new Camera Definition is also installed on the CLIENT(s) to keep this option separate. ______________________________________________________ (1) The WidevieW SERVER will require FSUIPC4 and WideFS-WideServer (both registered). On each WidevieW CLIENT we need to install FSUIPC4 and WideFS-WideClient as well (and because FSX is also running there we need to use a different Class Instance = 1). So the first few lines of the [Config] Section of each WideClient.ini looks like this: [Config] ServerName=SERVER Protocol=TCP ButtonScanInterval=20 ClassInstance=1 NetworkTiming=5,1 MailslotTiming=2000,1000 PollInterval=2000 Port=8002 Port2=9002 : Note that each WideClient is linked to the SERVER FSUIPC (2) On the SERVER, we set up the Hat-Switch to send KeySend numbers across the network (to activate panning at the the Clients). Here are the relevant entries in my FSUIPC.ini file on the SERVER, showing 5 buttons on my Sidewinder Joystick [left, right, up, down and trigger (for reset)] mapped to KeySends 2 through 6. [Buttons] 43=RL,32,C1006,5 -{KEYSEND 5 for WideFS}- 44=RL,34,C1006,2 -{KEYSEND 2 for WideFS}- 45=RL,36,C1006,6 -{KEYSEND 6 for WideFS}- 46=RL,38,C1006,3 -{KEYSEND 3 for WideFS}- 47=PL,0,C1006,4 -{KEYSEND 4 for WideFS}- (3) On each CLIENT, WideClient must receive these KeySend numbers, and transmit the mapped keystrokes to FSX-FSUIPC locally, so the WideClient.ini file at each Client has the following entries in its [User] section. [User] KeySend2=39,8,FS98MAIN KeySend3=37,8,FS98MAIN KeySend4=36,8,FS98MAIN KeySend5=38,8,FS98MAIN KeySend6=40,8,FS98MAIN I have mapped the KeySends to the arrow (l/r/u/d) and home keys. Using FS98MAIN ensures that the keystrokes are sent to the FSX window. (4) FSUIPC-LUA residing on the CLIENT intercepts these keystrokes from WideClient, and writes the rotated view-point to the appropriate FSUIPC offsets mapped to the SimConnect_CameraSetRelative6DOF function. Here is the LUA entitled networkrotation.lua: -- initial values lX = 0.0 lY = 0.0 lZ = 0.0 lPitch = 0.0 lBank = 0.0 lHeading = 0.0 -- increments delHdg = 11.25 delPitch = 5 -- camera rotations function rotate_right () lHeading = lHeading + delHdg if lHeading >= 180 then lHeading = lHeading - 360 end set_eyepoint () end function rotate_left () lHeading = lHeading - delHdg if lHeading <= -180 then lHeading = lHeading + 360 end set_eyepoint () end function rotate_up () lPitch = lPitch + delPitch if lPitch > 90 then lPitch = 90 end set_eyepoint () end function rotate_down () lPitch = lPitch - delPitch if lPitch < -90 then lPitch = -90 end set_eyepoint () end function rotate_reset () lPitch = 0.0 lHeading = 0.0 set_eyepoint () end -- set the eyepoint function set_eyepoint () ipc.writeStruct( 0x86A0 , "6FLT" , lX , lY , lZ , lPitch , lBank , lHeading ) -- X, Y, Z, P, B, H end event.key ( 39, 8, "rotate_right") event.key ( 37, 8, "rotate_left") event.key ( 40, 8, "rotate_down") event.key ( 38, 8, "rotate_up") event.key ( 36, 8, "rotate_reset") You may notice that the LUA has been refined to allow continuous rotation (i.e. beyond +/-180 deg) in yaw, but limits the rotation in pitch to +/- 90 degree. Here are the relevant sections of the Client's FSUIPC.ini: [Auto] 2=Lua networkrotation [LuaFiles] 4=networkrotation (5) Okay, but we also need to ensure that WidevieW will not try to do the same thing. Since I came from a setup where WidevieW was previously doing the network-panning, I needed to go back into the wideviewx.ini file (on each Client) and change a few entries, till each airplane's section looked like this: [WidevieW_Dummy Dash8-Q400] ApplyCurrent=1 ApplyGlobal=0 RaiseLG=1 RaiseLGBy=18 p_headingdelta=45 p_pitchdelta=30 p_setviewangle=0 p_processreorientation=0 p_pitch=0 p_pitchf=0 p_heading=0 p_headingf=0 p_deltax=0 p_deltaxf=0 p_deltay=0 p_deltayf=0 p_deltaz=0 p_deltazf=0 The crucial lines are: p_setviewangle=0 p_processreorientation=0 This ensures that WidevieW will not manipulate the view on the CLIENT, except for locating the aircraft correctly (which is its basic job). I did this for each airplane individually, rather than globally; above is my extract for the Majestic Dash 8 left-side-view Client. Additionally within wideviewx.ini on the Wideview SERVER I set: [Views] HatEnableServer=0 HatEnableClient=0 to ensure no panning commands are sent out by WidevieW (6) I also created a new Camera Definition and added it to the cameras.cfg on each CLIENT. This is because I wanted to keep this new technique separate from the old method: [CameraDefinition.999] Title = "WidevieW Virtual Cockpit" Guid = {01021987-E220-6507-1024-462840738999} Description = Specialised virtual cockpit view. Origin = Virtual Cockpit MomentumEffect = No SnapPbhAdjust = Swivel SnapPbhReturn = False PanPbhAdjust = Swivel PanPbhReturn = False InitialPbh = 0.0, 0.0, -26.0 Track = None ShowAxis = YES AllowZoom = TRUE InitialZoom = 0.7 SmoothZoomTime = 2.0 ZoomPanScalar = 1.0 ShowWeather = Yes XyzAdjust = TRUE ShowLensFlare=FALSE Category = Cockpit PitchPanRate=30 HeadingPanRate=75 PanAcceleratorTime=0 HotKeySelect=4 The initialPbh value in this case shows that this is the left view at -26 degrees from centre. It is not necessary with this method that the Client's view be a Virtual Cockpit view; in a subsequent post I will show how it can work with 2-D cockpit views as well. But I prefer VC-views because in that case the SDK unequivocally states that the eye-point is as defined in the aircraft.cfg. I found the following documents helpful to understand camera definitions: http://www.fstipsandaddons.com/tutorials/understanding-fsx-cameras.html https://msdn.microsoft.com/en-us/library/cc526984.aspx#CameraConfigurationFileFormat (7) I use saved flights for each WidevieW Client airplane. So for the Dash8 saved flight (.FLT) I ensured that this particular camera view was linked: [Main] Title=WVD D8Q400test Description="" AppVersion=10.0.61472 FlightVersion=1 [Window.1] Order=0 Active=True Undocked=False Maximized=True ScreenUniCoords=0, 0, 8191, 2600 UndocCoords=0, 0, 0, 0 CurrentCamera={01021987-E220-6507-1024-462840738999} : : [Camera.1.13] Guid={01021987-E220-6507-1024-462840738999} Zoom=2.5567879676818848 Translation=0, 0, 0 Rotation=0, -26, 0 Here are some more screenshots showing the near perfect alignment between views displayed on adjacent monitors in pitch and a combination of pitch and yaw. They are taken from a Dash8 Q400 parked at the Gate at VOBL: