Pete Dowson

I didn't realise GoFlight had made a driver for PM -- interesting. I was thinking of converting my GFdisplay version to a Lua implementation for the MCP, but it seems I don't need to after al!! Good! ;-) Please update. I cannot support anything before 4.60, and next month I shall be moving on to 4.65 (same as the current 4.645) and then 4.60 won't be supported either. .I don't see how any AS or REX can have anything to do with it, unless its a clash somewhere in SimConnect. Regards Pete

To find any regular FS event or control name, just enable Event logging in FSUIPC and operate the control in the default (keyboard or mouse) way, then look in the log. For example, the standard FS9 radio stack has a row of 8 buttons at the bottom for selecting assorted radio functions. Pressed once each, left to right, they log as follows: 81594 *** EVENT: Cntrl= 66463 (0x0001039f), Param= 0 (0x00000000) COM1_TRANSMIT_SELECT 84532 *** EVENT: Cntrl= 66464 (0x000103a0), Param= 0 (0x00000000) COM2_TRANSMIT_SELECT 86938 *** EVENT: Cntrl= 66465 (0x000103a1), Param= 0 (0x00000000) COM_RECEIVE_ALL_TOGGLE 88453 *** EVENT: Cntrl= 65842 (0x00010132), Param= 0 (0x00000000) RADIO_VOR1_IDENT_TOGGLE 89750 *** EVENT: Cntrl= 65843 (0x00010133), Param= 0 (0x00000000) RADIO_VOR2_IDENT_TOGGLE 90891 *** EVENT: Cntrl= 66477 (0x000103ad), Param= 0 (0x00000000) MARKER_SOUND_TOGGLE 91953 *** EVENT: Cntrl= 65844 (0x00010134), Param= 0 (0x00000000) RADIO_DME1_IDENT_TOGGLE 93141 *** EVENT: Cntrl= 65846 (0x00010136), Param= 0 (0x00000000) RADIO_ADF_IDENT_TOGGLE These are of course also all listed in the List of controls document installed for you in the FSUIPC Documents folder, inside the FS Modules folder. I assume the ones you want are in the first three above? Regards Pete

VRi devices only send messages to the PC when something changes. I am pretty sure there is no way at all to request it to supply information. You'd have to read everything it sends and match it to what you are looking for. Use the logging facilities mentioned to log the exchanges between SerialFP2 and the device and you'll see what I mean. Regards Pete

If you call the same Lua script again before the first has terminated there's no alternative -- but an exception is made by button and key repeats which are simply omitted until the Lua in completed UNLESS this takes more than so many miiliseconds. It sounds to me as if you should consider using an always-running (loaded as or by ipcReady.lua) script which contained functions called by events. Apart from using events to program this, you could also just make sure only one button press causes the Lua to run with the others either tested in the Lua, or changing flags for that Lua for it to test. Or you could have separate smaller Lua scripts and use Global variables to communicate between them. If you mean variables declared in the Lua script itself, they are all undefined ("nil") initially. When a Lua plug-in is terminated, it all disappears, so each time it is restarted it is starting afresh. Only Globals have any on-going life as the functions to set and read those store them into space owned by an always-running Lua thread created specifically for the purpose. I'd prefer folks to move to event-driven scripts where they are likely to get as complex as you suggest. Kosta has the idea! (Thanks Kosta). And for simple things like timing a button release, the assignment can call the Lua and the release can set a Lua flag. I've used that as well, where I didn't want to specifically assign the button number in the Lua. Regards Pete

Do your devices work without Saitek drivers? If the buttons and switches aren't seen by FS for assignment, they won't be seen by FSUIPC either. I'm afraid I cannot support Saitek devices directly as they use FSUIPC without permission or agreement. There is some freeware called SPAD which folks use on Saitek, but if that's not useful to you I can only suggest going to Saitek support. Pete

Really? Not FSUIPC.DLL as well? All that looks fine. It found your FS9 installation okay. And FSUIPC knows where it lives ... there's nothing else shown in the log of interest. FSUIPC uses a shortened version of that path above to save its INI files etc. In your later message: Odd, then, that the FSUIPC install log shown above proves that the registry was okay!? And not in the FS9 Modules folder at all? To make sure we are using the same software, should I need to ask for some logging options, please update to the current interim version, 3.989t, in the Download Links subforum. Regards Pete

Not enough, though. Assuming tou actually tried to do the Indent, you need to look for lines involving Client data. If you want me to check, ZIP up the file and send to petedowson@btconnect.com. Pete

As TrafficLook was only intended as a test program and demonstration, and provided as a freebie, I do not anticipate doing any development on it -- especially as there are payware alternatives which do the job already. I use trafficboard (Super TrafficBoard on FSX in fact). Regards Pete

Switch what? Reception, transmission, frequency, or simply the focus selection? Pete

Yes, that's a known bug in FS9. I don't remember exactly, it was so long ago, but I think the bug is avoided by letting FS default in all of the ATC setting, so, yes to that. The only other way is to avoid having a remote but in-range ATIS frequency clashing with any local COM frequency. Regards Pete

On FSX both GoFlight and ASE use SimConnect. I don't know how you are using the GoFlight MCP with Project Magenta. Whose driver? I'm afraid that so far I cannot see anything I can help with. But if you are using FSUIPC, please always state version number -- and if earlier than 4.60, make sure you update. There's also a later version available in the Download Links sub-forum. Pete

If you are trying to calibrate in FSUIPC with axes assigned in FS, be sure to have FS's sliders set correctly -- null zone full off (zero), sensitivity full right (max). As it says in the documentation, in fact. Otherwise If, in FSUIPC calibration there are no changes in the value appearing in the "IN" field, for 50% of the travel, then the problem certainly lies in the device, its driver, or Windows calibration. FSUIPC cannot calibrate for areas of a joystick which give no change in input. Obviously? Regards Pete

Versioin 4.57 is well out of date and not supported. Please update to at least 4.60. There's also a much later version available in the Download Links subforum (4.645). Pete

In that case there is another DLL you have installed which is clashing. It may be possible to juggle the order in the DLL.XML file to get over this. I've not heard of any incompatible DLLs yet, though, excepting an old out of date version of Actigate.DLL. Paste the DLL.XML file into a message here and I'll take a look. Like the DLL.XML file it's only text in any case. Paste it into your message. Pete

The IP address being supplied to Windows for the Router is an Internet address. Here is what it appears to resolve to: IP Address: 208.69.32.145 Hostname: 208.69.32.145 Country Code: US 3 Letters Code: USA Country Flag: Country Name: United States State / Region: CA California City: San Francisco Postal Code: 94105 Metro Code: 807 Area Code: 415 Latitude: 37.7898 Longitude: -122.3942 Time Zone: America/Los_Angeles Your problem is covered by the FAQ subforum entry entitled "WideFS Server names translating into incorrect IP addresses". I don't know where you get this from. You added the ServerName parameter -- which isn't necessary on a normally working system either. Both ServerName and ServerIPAddr are optional, along with Protocol, but unless you can fix the settings on your Router I suspect giving the IP address explicitly is the only answer. Giving the ServerName is no good because Windows is translating that into that internet address. WideClient never "dumps" anything, but only use Name or IP Address, not both. IPX/SPX is not fully supported by MS these days so it isn't installed by default. It can be installed from the Windows Install disk though, or at least it used to be possible. Maybe it's an Internet download only these days. Pete

It is bound to be the same as forcing it on with "UseASEWeather=Yes" makes it operate in both DWC and standard modes. Omit the parameter to only have it working in DWC mode. No idea why it affects your system differently, but, as I pointed out, the ASE route to get whether involved FSUIPC receiving the request from RC, sending it to ASE, getting the data back (as a SimConnect-style METAR string, decoding it, and then indicating its availability to RC (or anyone else). In all tests here this takes less than 1 or 2 seconds. When ASE is not being asked, FSUIPC requests it direct from SimConnect, which is bound to be a little faster. But since RC should be allowing up to 10 seconds to get an answer. Since you should be getting your destination weather 70-80 nm out. I really don't see why such a small delay should be a problem affecting anything to do with your approach. What am I supposed to be looking for in all that stuff you uploaded, by the way? Isn't is RC's logging you need, for analysing by JD instead? Regards Pete

In FS, the reverse activation of "F2" is simply assigned to "Throttle Decr". That's a generic control which applies to all engines (or rather all engines selected by E + 1 2 3 4 -- but by default, all). There are separate "Throttle Decr" controls for each engine: Throttle1 decr, Throttle2 decr, etc. Just assign to those. Pete

Are you sure there's no switch to make them one, or an option in the Game controllers for thatr device? I'm pretty sure they all have such. If there's no other way, you can actually assign both pedals to rudder, in FSUIPC assignments, but you'd then need to use the facilities described in the section headed Additional parameters to scale input axis values in the FSUIPC advanced user's guide to get one assignment of the two giving a reverse 0 to -16384 reading and the other the 0 to 16384 reading (or any similar values -- the calibration can spread them too). Regards Pete

Beware, though. The "Set" control will change all 16 bits, so used with, say, x10, it will set bit 4 and clear all the others. If the value in that offset is only ever supposed to have one bit set (i.e. it is a selector switch) then that's okay, but for bits assigned for different functions you should use "SetBits", "clrBits" or "toggleBits", as appropriate. Regards Pete

Well the latter point seems to confirm that it cannot be anything in FSUIPC specifically. If you are using a mixture of Saitek drivers, MS assignments and FSUIPC I'm afraid you might have a mess on your hands. Best to start from basics. Check Saitek alone, then FS assignments, and only then, if you really still want to, FSUIPC. FSUIPC does not perform miracles, it only offers a little more accurate calibration, and the possibility of automatically changing assignments for different aircraft. Regards Pete

Good. Sounds like the joystick Number changed at some time. You can letter the joysticks instead and FSUIPC will then track them. Regards Pete

No. The registration keys never need to change. You are certainly making a mistake when entering one of the details. You must spell your name as you did when purchasing, and your email must match, and of course your Keys. All three parts must be exactly correct. Pete

Have you tried Saitek support? Their products seem to cause the most pain for everyone. I cannot support their stuff. Why? Get them working in FSX first. What's the reason for using FSUIPC assignments? Calibrate them then. You can make the min and max values occur wherever you like along the axis, provided the IN numbers change all the way. Please read the section of the User Guide about calibration. Follow the numbered steps. You most certainly need to go to Saitek then. If they are brand new perhaps they are covered under warranty? Pete

Why not use the Keys assignment dialogue in FSUIPC options? What is that intended to mean? Where do you get that strange incorrect syntax from? What does "trigger an offset" mean? You either write a byte, word, dword or double value, or set, clear or toggle bits in a byte or word or dword. All of these things can be assigned for any offset by using the options. Trying to figure out how that is supposed to look in the INI file is a bit strange when it is done for you so easily. Don't! That is saying offset x8B4E (not your "8B004E2RL7" which makes no sense and isn't even hexadecimal), which is a WORD (2 bytes = 16-bits = Word, please see the FAQ about bits and bytes and so forth), has something called RL (which beats me) in bit 7 (which is the bit worth 128 in decimal, or x80 in hex. Run FS, go into FSUIPC options, Keys tab, as when you assign any key. In the dropdown find Offset Word SetBits (or Clrbits or ToggleBits), depending whether you want to set, clear or toggle the bit, the x8B4E for the offset and x80 for the parameter. Pete

Sounds like either bad calibration, or possibly assigned to different controls types. One set of axis controls (those starting "Axis ..." use the range -16k to +16k whilst the older set (just "xxx set") go from 0 to 16k. Maybe you've got FSX iterfering and assigning some you thought you'd assigned in FSUIPC? I really cannot be more specific without seeing the Axes and JoystickCalibration sections of your INI file. Only if you "disappeared" them. Everything is in the FSUIPC4.INI file. No FSUIPC update touches that. And 4.645 was just you copying in a new DLL. Regards Pete