Pete Dowson

Hmmm. Interesting. But I don't really think I can justify the amount of coding changes this would entail for such a limited use. Can you not use several axes instead? Or why not use button inputs instead, in the first place. Each joystick input can have 32. Alternatively, you could assign the axis to a Lua plug-in which would receive then the axis value as ipcPARAM, and you can process it in any way you like. Regards Pete

That's unusual. For most folks the main advantage of running ATC stuff on a separate PC is the separation of FS aircraft and environmental sounds (for the speaker system) and the ATC sounds (from the headset or overhead speaker). I don't know, sorry. I don't know anything at all about either IVAP or Teamspeak. WideClient can launch programs, of course, but it doesn't have anything related to sound. I'm not sure how you think it could possibly help. The PTT facilities work anywhere, not just on the FS PC nor just on a client. The joystick button can be anywhere too. I don't think I understand what difficulty you are seeing? Regards Pete

Yes, in the normal form, because the Lua file is designed to get its COM port numbers supplied by the automatic loading dictated by the [VRInsight ...] section in the INI. This won't happen if it is being run by, for example, assignment to a key press. But for development and testing you can do what I do. Define the VRIdriver and VRIdevice values in the program. If you look near the beginning of the VRU_SetMach.lua supplied in the examples you will see this: if VRImodel == nil then -- Set known ports if testing with Lua not loaded automatically VRIdriver = "COM2" VRIdevice = "COM5" end In my case the COM ports were 2 and 5. You'll need to set these for your setup. The VRImodel value is nil if the Lua is started manually, so these are set automatically. Program a keypress or button to run the Lua program and just re-run it each time you make a change you want to test. Before we go further I notice you are using FS autopilot offsets. They aren't correct for the Project Magenta MCP. You'll need to go to the PM website and get the list of PM offsets. This will be the case for speed, mach, heading, altitude and V/S. You'll only use FS offsets for the two course displays (OBS1 and OBS2). Otherwise you look like you are getting the hange of things. Check out the PM stuff and by all means come back if you get stuck. Regards Pete

Using FSUIPC you would certainly be able to program the MCP buttons and switches to operate the PMDG aircraft (even if it means using keypresses or mouse macros), but I don't know any way to get the A/P values out of the gauges to display on the MCP's displays. Maybe by now someone has hacked this, but I'm afraid I don't have any such information. You could try a GF or PMDG forum to see if anyone else knows a way. But I'm pretty doubtful. Regards Pete

No. Why? Pete

There is no method for changing an email address associated with a specific key, unless you buy another key using the different email address. Why are you trying to change things? The registration lasts forever, the email address is tied to it. What's the problem? Pete

Back to this: I've had a chance to run vasFMC now to see why there's any difference, but I cannot reproduce your results. vasFMC seems completely limited by its own performance problem, not by WideFS, and the logs for both INI settings show identically. The misleading increase in transmission rates (i.e. TO the Server) happens simply because of the polling rate being changed to 200 mSecs (5 per sec) instead of 2000 (1/2 per sec). The frame rate of FS on my Server was around 39-40. WideClient with vasFMC on my Client PC ran at 25-28 fps (depending on how much logging I asked WideClient to do). What I do notice from the logs is that vasFMC requests large areas of FSUIPC offsets, areas which include non-populated and unpredictable values. On FSUIPC3 this is very inefficient as it makes FSUIPC call lots of routines in FS to obtain values which are either useless or which are unlikely to be used by vasFMC. On FSUIPC4 it is less of a problem because the offsets are all within FSUIPC's own address space. With all of the possible vasFMC windows displayed I found it extremely unresponsive -- entering ABC in the CDU's scratchpad shows nothing for a few seconds, before the letters appeared. I can't believe it is like this on your PC, so something is evidently wrong. I notice the package you sent me announces itself as an Alpha test version. Is that right? Is there some configuring I ought to be doing? I think that unless I can get its performance to be reasonable, there's no way of determining what possible affect any WideClient parameters can have. It's all swallowed by vasFMC sitting unresponsively. Regards Pete

Sorry, but as clearly stated in the Announcements, I cannot support old versions. Please get up to date first. Anything before 4.60 is not supported. If you still have the same problem after updating it will be due to interaction in SimConnect between two or more programs being initiated by SimConnect. That's why I asked what other add-ons you are running. Mostly this only occurs the once, as SimConnect then asks you if you want the program added to the Trusted list in FSX.CFG, and the next load then works without error. So, try simply telling FSX to carry on. But update FSUIPC4 first, please! Pete

As the manual says, "about half a dozen options in these pages that can be set and held by an external weather program". If you had any program which used this facility, you would have already seen the said options "greyed out", again, as stated. If you never have seen this then the option to prevent it is irrelevant, isn't it? If you want more information about what external programs can do, like this, you need to refer to the Programmer's Guide in the SDK. Regards Pete

Er, can you be rather more specific? I have no idea what you are talking about. Pete

There hasn't been any registration for FSUIPC inside FS for a long time. You must run the Installer. Please read the Installation and Registration guide you will find in the ZIP, alongside the Installer. The DLL hasn't been supplied outside of the installer for a long time, excepting interim updates. Current main user release versions are 3.98 and 4.60. Pete

FSX? Of course. Also in FS9, as I've just tested. See the pic below, taken at Seattle (mag var about 20 degrees!): I think you must be making an error someplace? Pete

at the aircraft? Okay. That is 0E92. Correct. Okay. Understood, now I know you are reading 0E92. Not at present. I would need to load up FS9, which I've not done for a long time. Nothing about any of this has changed in many years, but I'll re-check for you when I can. I only have FS9.1, not the original release though. Regards Pete

If the FSUIPC menu entry is present, then there absolutely MUST be an FSUIPC log file! I suggest you look again. If FSUIPC is running it ALWAYS creates a log file! Pete

That refers to the old FS98 offsets, the ones remaining compatible with FS6IPC and FS5IPC (the FS95 version). Is this actually what you are "supposed to do"? How do you work that out? What wind direction are you reading? That will make a lot of difference, because there are separate FS98 offsets for surface wind, lower, middle and upper layer winds. Obviously the correction for "magnetic" direction only applies to one of those. If you are reading the wind direction BEFORE checking the latitude, how on Earth can you make sure you read the correct offset for the direction? FSUIPC transmits nothing. It merely provides access to FS values. What bug? I think you need to check what you are doing. You need to check the altitude in order to determine which offset to read. either that or, for wind at aircraft, read the ambient wind data. Pete

Why do you think replacing a file with the same file will change anything? I cannot support old versions. 4.57 is not supported, you must run 4.60 at the earliest. Regards Pete

Please show me the FSUIPC4 installer log, which you will find in the FSX Modules folder. Also please state the VERSION NUMBER of FSUIPC4. I would also need more information than simply those few words. Doesn't it say anything else? No details at all? And please list the other add-ons you have running. Pete

The FSUIPC.LOG file is in the same folder as the Installer log file, which you already found. In other words, in C:\Program Files\Microsoft Games\Flight Simulator 9\Modules If there is no such file, then FS has never been run with FSUIPC. Additionally, I notice that, according to the Installer log: Looking in registry for FS9 install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\9.0 Parameter"EXE Path" ... >>> OK! FOUND FS9! <<< ... you are running the original version of FS2004 (i.e. FS9.0), not the fixed updated version 9.1. I would advise you to apply the update as it fixes a lot of FS9 problems. Regards Pete

So, make your assignments, for the same buttons, aircraft-specific. Regards Pete

You've got problems with your "" characters. The only reason to use those at all is to keep things with spaces in them from being treated separately. The first recognised space indicates the END of the program name and the START of the parameters. You've made the whole thing look like the pathname of the program, so naturally it is not valid. Put the final " character after the exe. No others are needed. And those are only needed because of the damned spaces in the path name. This is wht I always put things in nice easy short paths, like C:\VSPE. Pete

I don't think FSInn and FSCopilot use FSUIPC in any case on FSX. Try running without either and I expect you'll be okay. I'm afraid I cannot support FSCopilot or FSInn, and there's nothing in your error message which points to FSUIPC. But if you want me to check FSUIPC please show me the FSUIPC4.log file from the FSX Modules folder. Regards Pete

It wasn't the FSX installation I was asking about, only pmSounds. It sounds like you have Windows set to hide filetypes from you. Best to switch that option off -- it disguises the names of all sorts of files. Anyway, if it is a Text file called FSUIPC it will likely be the Log. It should not be very many lines long unless you have enabled lots of logging options, or something is drastically wrong. In FS9 go into the FSUIPC options and uncheck any logging you've enabled, then close FS9, restart it, close it again. then show me what should now be a short log! Regards Pete

"latest version" is meaningless I'm afraid. I need to know actual version numbers. pmSounds uses a parameter file to define the sounds. If you are using the exact same folder containing pmSounds that you were using with FSX, there's no difference whatsoever. Tell me the version number of FSUIPC. Show me the FSUIPC.LOG file (from the FS Modules folder). Pete

Sorry, I'm lost, again. Are you assigning them as buttons or axes? What is the context. You'll have to forgive me if I should remember this stuff, but my day is full of so many little different things that I need to be reminded of context, especially after a gap and in a new thread. No, it cannot because POV positions cannot be read, unlike button states. If you are using Events to register when a POV is operated then you could then start a separate Lua for that POV value (or call a generic one with the POV number as parameter) using ipc.macro. That Lua would perform the loop as in the example you found, until it is signalled to exit. That signal would be by your POV event handler detecting a DIFFERENT POV or the "up"event for the original. One way of signalling would be by using a Global variable set in the handler (ipc.set) and tested in the slave POV loop executing Lua (ipc.get). Regards Pete

Do all those aircraft use the standard FS controls for A/T and A/P on and off? If not you'd need to find out how to do it for each one separately and assign the appropriate controls in an aircraft-specific way. FSUIPC4 allows any control or axis assignments to be aircraft or profile specific. Regards Pete