Pete Dowson

If you write an external library (DLL) which interfaces to SimConnect to obtain the data or send events, and include in it functions designed to be called by Lua, following the proper rules so that Lua could interface to it, then, yes, you'd be able to write Lua plug-ins which controlled the NGX without needing to use any offsets at all. The built-in libraries you mention are part of FSUIPC code. An external DLL would be more like those third party ones I list at the end of my FSUIPC Lua Plug-Ins document -- saitek.dll, gd.dll and luacom.dll. Regards Pete

Please clarify. You want specific fixed views, not panning? Is that right? I don't think you can in virtual cockpit mode, You probably need to be in 2D cockpit mode for the FS fixed view controls to work. If you want to use panning, just assign the Hat to Pan View in the Axis assignments tab. FSUIPC will view it as separate buttons, but you need to assign to FS controls which actually do what you want them to do. It's getting the controls right which is the important part. The Hat can be interpreted in either or both ways -- a set of buttons and/or an axis with specific direction values. Pete

No. Such an interface program would use SimConnect to get the data from the NGX, exactly as shown in the example in the SDK, and use the FSUIPC interface, according to the FSUIPC SDK, to write that data to specially assigned offsets. Then other FSUIPC-interfacing programs can read those offsets. When and if someone wants to start on this, they'd need to write to me for an assignment of offsets in order to ensure those chosen do not clash with anyone else. If not sure I will be willing to assign as much of the restricted offset space as would be needed for a complete one-to-one mapping of the NGX client data -- it looks like it's about 2 kb. It could be compacted quite considerably by using bts for BOOLean flags instead of complete 32 words as defined there. Maybe it could be a little selective too. Probably not all of the listed data is of use. Regards Pete

No. Not in FSUIPC itself, but you can certainly write a C/C++ DLL which can be called from a Lua program being run in FSUIPC. There are several such DLLs already available, as noted in the FSUIPC Lua documents.You can't call just any old C/C++ functions from Lua, they need to follow certain rules. All of the library functions in the many libraries built into FSUIPC are written in C following these rules, and the libraries are then simply pre-opened for your Lua plug-in so you don't need to use 'require' in their case. Regards Pete

Yes, I think so -- it lists events for every CDU button. Just program one of your buttons to send the event number as an FS control. Look in the .h file, find the section starting: // CDU #define EVT_CDU_L_L1 (THIRD_PARTY_EVENT_ID_MIN + 534) The value THIRD_PARTY_EVENT_ID_MIN is defined earlier on as 69632, so that one is 70166. You can either send it via a Lua "ipc.control", or possibly just be editing the FSUIPC INI to set number 70166 as the control numer after the C in the button assignments. I'm not sure what the latter method will do to the FSUIPC dropdown display, though. I might try it later. Regards Pete

Yes, but I reckoned without the "UseAxisControlsForNRZ=Yes" setting, which changed that. And in fact it was stupidly forgetting that important fact which led to my programming bug with the "Sync Pos" facility (which is now fixed). Regards Pete

The correct parameter, which is actually the default setting in all recent versions of FSUIPC, is "ShortAircraftnameOk=Substring". If you have started with a freash install, no INI, you do not need to change anything, it is already correct. Show me your INI file and I'll tell you. Pete

Thanks! Yes, found it when I installed SP1c. Wasted some time last night searching for a separate download! ;-) The Event numbers, 69632-84232, for operating switches and so on, confirm what a lot of folks have found in any case, judging by the Lua and macro contributions already made for NGX users. But there's enough information there to ehnance those quite a bit I think, especially with the info that a lot of the events take numberical parameters, and I see there are events to operate switches via mouse-type operations. Getting data out, however, is a bit different. it uses the SimConnect "client data" facility. That's easy enough for a programmer, though, and someone could write a program to map the useful parts of that client data to FSUIPC offsets. I cannot build that into FSUIPC myself since there are clauses prohibiting use in payware programs without express permission -- which essentially means licensing. Someone else, however, could make a freeware interface much like Nico Kaan's "LekSeeCon" for the LevelD 767. It will be interesting to see how things develop now ... Regards Pete

I've searched all over the PMDG site and can find nothing about the SDK at all. They released the SP1c update for the aircraft package yesterday. I've downloaded that and will install it in the next couple of days or so, but where is this 'SDK'? Regards Pete

Looks like you've made a complete mess of the FSX installation. You have SP1 SimConnect installed in the side-by-side libraries but your FSX is not updated properly with SP1. So SimConnect is incompatible with your FSX installation. I recommend you reinstall SP1, then reboot, try FSX, then install SP2, then re-boot and run FSX again. Then install FSUIPC 4.80 -- the version 4.703 you are using is too old and is not supported. Regards Pete

Try this: -- create one or more windows w1 = wnd.open("Paused", 0,0,200,140) wnd.font(w1, WND_ARIAL, 30.0, WND_BOLD) --Font, Size, Properties -- function to operate window colour function Paused(off,val) if val ~= 0 then wnd.backcol(w1, 0xf00) --Set red when paused wnd.textcol(w1, 0xfff) wnd.clear(w1) wnd.text(w1, "\n\n\tPAUSED") else wnd.backcol(w1, 0x0f0) --Set Green when unpaused wnd.textcol(w1, 0x000) wnd.clear(w1) wnd.text(w1, "\n\nUNPAUSED") end end event.offset(0x0264, "UW", "Paused")[/CODE] Save it in the same folder as Wideclient.exe version 6.95 or later, named, say, "announce.lua". You can add more windows, for events, more offsets, colours etc. This isn't really the sort of application I had in mind for this facility. It was more for text displays like checklists, logs, performance data, whatever. For this application you'd really not want title bars ad thick borders and so on. I'll look at putting Lua programmable features into the ButtonScreen facilities in any case. Regards Pete

Okay. I have to go out this evening, but I'll make a little example later. You can run multiple copies using TCP protocol (the main one can use UDP), but setting different numbers for the "ClassInstance" parameter. I have one client running several programs and two button screens, Applications only connect to the ClassInstance=0 copy. Regards Pete

I've just finished working on a Lua library called "wnd" (short for "window"), which allows text windows to be created, closed and text written in them. This doesn't support images, but it does allow both the backgound colour and the text colour to be changed. So you could, at a pinch, just have one or more small windows, clear of text, but with different colours, which you could change at any time based on offset values. The windows have a sizing border and a title. You could put the indication label in the title, or have it like a backlit label in the window itself. I can't think of any other way at present without additional programs or other changes. The wnd library is in WideClient 6.95, just released, but I've not updated the Lua documentation yet. I can give you a little plua plug-in to do this, though, if you like. I'll be doing the documentation tomorrow, with luck. No, not at present. I could have a look at that. Currently the ButtonScreen is completely independent of other parts of Wideclient. If I implemented that it would have to be by the Button Number controlled by that position, so any change wouldn't be seen if the page with that button number wasn't currently shown. Regards Pete

Please try version 4.805, from the Download Links subforum. I've checked and double checked the code but it isn't tested as my cockpit network is down for some repairs at present. Please try it and let me know. Regards Pete

Found it! It was a really difficult one, spent most of the weekend on it. But it also showed up some errors in the "sync Pos" facility which might have otherwise gone unnoticed. Sorry it has taken so long. Try version 4.805 (or 3.999f for FS9), which appears to work okay here, now. Regards Pete

If they are FS control numbers, like 66191 or whatever, you can probably just send them using the ipc.control function in a small Lua plug-in. If they are named custom events you only need to list them in an evt file and they will be assignable. I'll take a look at the SDK when I get time. not today, for sure. Regards Pete

Sorry, no. Are these numbered FS events, or named PMDG events? If they are custom events then you can list them in an "events" file. Please see the chapter in the FSUIPC4 Advanced User's manual called "Add-on Custom Events". Once they are listed you can assign to them in the normal way. Regards Pete

One will be 0 the other will be 1, and I'm pretty sure the Goflight DLL IGFDEV.DLL) numbers them in the order Windows provides them in its list of USB devices. And I think that's based on a hardware scan. So unless you unplug things and plug trhem in again the IDs should remain stable. They certainly do here. If you do have cause to disconnect them and reconnect them, and they turn out to be the wrong way around, simply swap their USB connections over. Pete

Yes, that's what I thought. Yes, after you change it for a T8 (the earlier script was for a P8), and get the ID number correct (0 for the first T8, 1 for the second, and so on). Pete

No no no! you are getting yourself all mixed up! I don't think you are reading what I am actually writing. :sad: The Lua plug-in to read and write the Goflight devices on your remote (client) PC RUNS on that remote PC! It doesn't NEED FSUIPC to scan it. What do you think FSUIPC would be doing with it? It has no need! Think about it! The WideClient program supports the Lua libraries you are using in your plug-in!!! Just put the Lua plug-in into the same folder as Wideclient on the PC to which that Goflight device is connected! Pete

You haven't calibrated them correctly then. Follow the steps for calibration in the documentation. You should always leave a dead zone at the "feet off" end, pressing both a little before setting the minimum -- otherwise you cannot guarantee that the brakes are always off with feet off, and also they may come onunwanted when using the rudder. FSUIPC doesn't "amplify". You misunderstand what calibration is. Calibration is matching the input range, the figures coming from the device, to the actual needs of the simulator control you are calibrating. It looks to me, also, that you have the brakes operating the wrong way round. The output value should INCREASE as the pedals are pushed. Most toe brakes need REVersing -- do that BEFORE calibrating! Pete

Client Lua plug-ins are just run automatically. If you need to talk to therm from the server you'd need to use offsets like the free user ones at 66C0-66FF. Looking back at your original Lua in this thread, it is event-driven in any case, not one with functions called from outside. Both the events you used there are supported identically in WideClient. What is this "function calling" you want to do? Pete

Two points: 1. WideFS for FS9 comes with WideClient.EXE which runs on the Client PC, and WideServer.DLL which runs in the Server PC and must be placed in the Modules folder. If you downloaded the WideFS package you'd have both parts, AND documentation which tells you such things! I don't know what sort of WideFS package you've found without the Server!? 2. Version 3.99 is out of date. The earliest supported version is 3.999. Regards Pete

What isn't waiting for clients? Have you installed WideServer.DLL? Show me the WideServer log file if so. Regards Pete

Re-installing FSUIPC never does anything, unless you are updating to a later version. All your settings are in the INI file, not in the Installable part at all. It sounds simply that you had dual assignments. Maybe you are assigning in FSUIPC and forgot to disable controllers in FS? Without know what you are doing I couldn't say. In any case you do not have to assign in FSUIPC in order to calibrate in FSUIPC, so if you are so assigning, why? What do you want to achieve? Different axis assignments for different aircraft, maybe? Sorry, with no information I can't help much, can I? If you've got everything in a right mess, start again -- NOT be reinstalling FSUIPC, which achieves nothing, but by deleting the INI file before loading FS. Then, yes, calibrate by following the numbered steps. Don't just read the manual over and over, follow the steps as you are doing them. That's why they are there. There's no such thing as "assigning to a Z axis". If one of your axes is Z you assign IT to something else, not the other way around. Why not forget about FSUIPC assignments intially, and just let FS assign everything and then do the calibration in FSUIPC? Start simpler, don't confuse yourself so much! And start with a default aircraft, NEVER with a complex add-on. That just makes it harder. Pete