Pete Dowson

If it is assignable in FSX you could assign your buttons to it in FSX! If is it so assignable, it will be one of those FS controls I mentioned. If you enable Event logging in FSUIPC's Logging tab, then operate those actions, you should find the correct FS control name logged in FSUIPC's Log. then you can assign them directly in FSUIPC. But I would have thought the names would be obviouslike, perhaps, MP voice capture start and MP voice capture stop or maybe the other pair listed, MP broadcast voice capture start and MP broadcast voice capture stop? Why not just try them? Regards Pete

Yes. The interface is identical. Version numbers are different, of course. There are a lot of new offsets and some of the old ones do not work, or very occasionally work slightly differently. That is all detailed in the Offsets Status document for FSUIPC4. Yes, no difference at all. FSInterrogate itself is a Delphi program, and there are lots more, all still working fine. The interface to FSUIPC has not changed in the 10 years it has been around, and in fact it is identical to that for FS6IPC before it, in FS98. Ah, if you have the source code it should be very easy to find the problem and fix it. simply compile it in Debug mode, run it with debugging enabled, and when the failure occurs, see why. If it is something simple like unexpected version numbers you should be able to find that by inspection of the code. If it might be some other offset value which upsets it, try enabling IPC read and write logging in FSUIPC4's logging tab, see what it does prior to the crash. Regards Pete

Erwhat is this "transmit" facility in FSX? Tell me how you do it normally. I'm afraid I'm not at all familiar with Multiplayer. There are COM1 and COM2 Transmit Select controls in FSX -- they will be found in the FSUIPC drop-downs for assignment. There are also a number of multiplayer controls, named "MP ..." -- for example "MP Activate Chat". These are also available for assignment. Could it be one of these you need? Regards Pete

There's no such error message in FSUIPC. How does this message appear? What is actually producing it -- the add-on program, or FS? Aha. It could be some incompatibility with an installed Windows or Delphi library then -- though why it would be different with FSX compared to FSX I've no idea. It may be a generic range check error in the Delphi program itself. I'm afraid you will need to contact the support for FSHWPanel. Maybe it is something quite simple, like the version number of FS or FSUIPC being out of the range they catered for. I'm sure they will be able to fix it if it is reproducible. Regards Pete

If it works in the TAB test but not when assigning, you are doing something wrong. You are probably not assigning unique macro names, or similar. I cannot see what you are doing from here, but if you show me the Buttons section of the INI file, and the Macro file you made, and tell me what buttons you were assigning, i can probably tell you what you are doing wrong. Erthat doesn't make any sense! How are you assigning buttons to FSUIPC macros in FS? There are no facilities provided by Microsoft to access FSUIPC macro files! If you know the macros are working well you must be able to assign them in FSUIPC! There's no other way to use them -- unless you write a Lua plug-in or an FSUIPC program to do it! Regards Pete

It has never changed. It is still ZapCylinderAltDiff in the code and in the issued binary. It sounds like your INI file got corrupted sometime? It cannot be anything to do with FSUIPC as it never writes out that parameter, it is a user-instigated option only. Pete

I don't know the LevelD, but I'm pretty sure that its use of offsets is well documented in their own SDK. I assume you can download this from their website, but if not try Niko Kaan's site: http://www.lekseecon.nl/sdk.html That said, I would have thought that minor things already well-implemented in FS are still the same as in FS -- e.g. the light switches via the bits in offset 0D0C. Regards Pete

First off, that IP address is VERY suspicious. It simply does not look like a local network address, but an internet or gateway one, as seen from outside your system. Please check the actual IP address on the Server, or assign one explicitly yourself (that's what I usually do -- I assign all of my PCs a known fixed address so I know exactly where i am). Well, here it says it connected -- but according to its own log WideServer never saw it! And the error is a forcible closure by the Server. Therefore it is one of two things at the Server end -- either you have a firewall blocking the access, or the Port is being used by something else. I see you are using FSX. You haven't assigned port 8002 for use in SimConnect at all, have you? Since SimConnect starts first (it loads FSUIPC4), it will grab that port first. Regards Pete

It means that the data in the memory-mapped file is not in the correct format, the one defined in the fs6ipc.h header. There's one format for reads and another for writes. Use your debugger to break into your program during the assembly of data by FSUIPC_Read and FSUIPC_Write to make sure it is building the data correctly. There also needs to be a zero DWORD at the end of the list of requests. Make sure you set the options for structures to have single byte alignment. Regards Pete

Well, obviously you can connect it, but I don't know of any free-standing drivers to utilise it in FS. My PFC drivers are intimately entangled with FS and FSUIPC, they are not external programs. Why not simply use a longer serial cable? Unlike USB connections there's no problem with longer connections. Regards Pete

Er, the fuel valves are NOT the same as the idle/cutoff levers. In a Boeing 7xx aircraft the fuel valves open automatically when you operate the starter. The fuel cutoff/idle levers are those below the trust levers on the centre pedestal. In FS the idle/cutoff levers for jets are operated by the MIXTURE controls -- MIXTURE LEAN is cutoff, whilst MIXTURE RICH is the idle (enable) position. Hmmm . But if you had read the answers in this topic more thoroughly you would have seen that the facility for the TAB test to cycle through multiple possibilities was not added until version 3.905. Interim updates are provided in the Updates announcement, as it also clearly said. It is currently to version 3.907, in fact. Pete

There's no message like that either in FS or in FSUIPC. And updating 3.85 to 3.90 is simply a matter of putting the later DLL into the FS Modules folder. Please explain more carefully what the problem is. I cannot support old versions. Pete

Oh, that. Yes, I'm using that between a firewire connection and an Ethernet connection, to connect my co-pilot CDU to the system via my pilot CDU -- the built-in Ethernet port on the RCDU PC (a mini-PC smaller than a shuttle) is broken so i had no choice. There's no problem with that -- it is all invisible at the socket level. Maybe it's something to do with its settings, but not the bridging per se. Regards Pete

What is "port bridging"? WideFS uses a basic level of standard Winsock programming, lifted straight out of Microsoft examples. All I know about networks is based on simply following those examples. All the stuff below the standard Windows "sockets" API is really a matter for the correct drivers, the correct settings, and working hardware. Maybe there is a clue in the logs, but it might need interpreting in terms of what you know about what you've set up there -- especially if you are using some hardware or software arrangement which is non-standard. Regards Pete

Okay, good. You are all set, then? Regards Pete

There are some packages around which do implement external cockpit gauges. Do you mean WideFS? No, FSUIPC is not a networking program. It is WideFs you might need, plus a package which implements the cockpit gauges you are interested in. But you should find and check the package first, as some of them don't use WideFS but implement their own networking instead. Two video cards don't help. You have two drivers working hard, slowing things down. I don't know ATI cards very well, but they should be capable of supporting two monitors on their own in any case. You then run FS in Windowed mode and undock the panel and drag it over to the other monitor. Providing you use 2D panels, not the virtual cockpit, and also don't open more than one 3D window (the outside view), the frame rate should hold up quite well. At least it does with nVidia cards. As for external cockpit implementations, the ones I recall are FreeFDS (if that's still going), Sim-Avionics, FlightDeck Software, and of course Project Magenta. Check them out first -- the FDS suite does not use WideFS (only FSUIPC), but I think FreeFDS does, and I know PM does. Not sure about Sim-Avionics. [LATER] I've also just found this site: http://www.flightdecksoft.com/software/index.php Regards Pete

Since the complete C source for the FSUIPC interface is supplied in the SDK, you can simply adapt it or recompile it to suit whatever compiler environment you have. This is why the whole thing is supplied. It has been used successfully with many other compilers, and translated into other computer languages, as some of the additional contributions in the SDK attest. If you still want to use the LIB, recompile it with your compiler. Or just incorporate the source into your program. There's also a DLL version, if you prefer, kindly contributed by another user. See this thread: viewtopic.php?f=54&t=75706 You'll find the DLL in an attachment near the end. I've not had a chance to try it yet, so if you do please let me know how you get on. Regards Pete

Version 3.70 is extremely old -- nearly 3 years, in fact, with nearly 20 major releases since as well as uncounted interim updates. And it has been unsupported since nearly 3 years ago! The current major release version for FS9 is 3.90. I suggest you update your copy immediately! Pete

That seems a bit extreme. If FS9 is running okay and FSUIPC.DLL is in the Modules folder, then it WILL run and it WILL create a Log file. Since you are using Vista, it may be that you've let FS9 install into the Program Files folder, which is protected by Vista. Since FS9 is not Vista-\aware, and needs to write to its own folders, Vista creates aliassed folders for it -- the ones you can see and access are NOT the folders which FS9 is actually using! To get around this, run Windows Explorer by right-clicking on it and selecting "run as administrator". THEN see if FSUIPC.DLL is installed, and if so, if there is a Log file (it will be described by Vista as a text file I think). If you do re-install FS9, try installing it someplace more useful, like C:\FS9. If you leave it in Program Files you are likely to get problems with other add-ons in any case. What about FSX? That doesn't suffer from any of this because it is Vista-aware, yet you said you had nothing working their either. Or was this because you expected the FS9 versions of IVAP and SB to run with FSX? Regards Pete

Thanks for the data, just received. It appears that you are entering the Key incorrectly. Please do make sure that you get EVERY character in it correct -- especially take care to get 0 and O, 1 and l, and 2 and Z distinguished. They ARE different characters! This is why we always suggest using cut-and-paste. Pete

In what way does it indicate that it is not working? Is the entry rejected as "invalid", or is it accepted, but then FSUIPC4 still appears unregistered when you run FSX, or does it appear to be registered but not working correctly? It is important to differentiate between these things as the cause of each is completely different. If the details are rejected as invalid when being entered then you are most certainly making a mistake when entering one or more of the three fields. There has never been a case where this is not so except in the very first release of FSUIPC 3.00 where accented characters were converted incorrectly. If you truly believe you are entering everything absolutely correctly, character for character, then please send all the details -- name, address/email (whichever you are using) and Key, and I'll check it. Don't post it here, send it to petedowson@btconnect.com. I've no idea what "site" that is, as I don't have one, and there's certainly no messages in any of my programs like that. Ah, you mean signing in here, in the Forum -- I assumed you were talking about your name in the Registration. I don't care how you enter this forum, that is totally and completely irrelevant to FSUIPC Registration. Please let's just stick to the subject else it starts getting weird and confusing! ;-0 Well, naturally, there's no need if you have one of your own and not someone else's, as you seemed to imply. All we've got to do is get you inputting the correct data, and I'm sure it will be fine. It was only that you did ask how to get a new key and I told you. Regards Pete

How do you know FSUIPC is "without error"? Did you look at the FSUIPC log file and interpret it yourself? More information is needed if you want help here. Please show me the Log files -- FSUIPC.LOG for the FS9 Modules folder, FSUIPC4.LOG from the FSX modules folder. BTW the FSX versions of IVAP and Squawkbox do not use FSUIPC as far as I know, so please explain your FSX reference. Regards Pete

If you want to buy a new key you go to the sales booth in SimMarket. I removed the key from your message here as you are forbidden to publish it. Sorry, I don't understand this part. I do not try to access anyone's computers than my own! You are most certainly making a mistake somewhere if the key is being rejected. If you want me to check, send all the information you are entering (name, email, key) privately by email to petedowson@btconnect.com and I will check it for you here. "work it out"? You really do just need to use EXACTLY the same details as supplied to SimMarket when you purchased the key! If you are using another person's Key, you and he are breaking the license agreement and the key must be revoked. You must purchase your own key, in your own name. The registration keys are locked exclusively to the original name/address of the purchaser. Regards Pete

I really don't understand why you'd want to use that facility, which is really meant for programming in a program, not assigning as you wish. I think it was added years ago just for compatibility with some existing programs at the time which did use that rather unwieldy protocol.. For pilot's BARO setting, use the normal FS controls ("Kollsman inc/dec"). They are certainly fast enough -- you don't need fast and slow varieties. For the MDA/DH you will need to use the FSUIPC Offset controls, to inc/dec the PM offset for this. You could use the FSUIPC Offset control for the pilot's BARO setting as well, but since it is the standard FS facility there's really little point. Incidentally, "ROUND" is not really a much needed function when numbers are automatically converted to integers when needed. For rounding you just add 0.5 before writing as an integer. Or, if you need to work with that integer in Lua, use n = math.floor(m + 0.5) The "floor" function gives the largest integer smaller or eual. adding 0.5 first therefore gives the rounding to "nearest". Regards Pete

Strange. Sounds like some sort of glitch on that Client PC -- maybe in the WideFS communications? Did you check the WideClient and WideServer Logs to see if any errors were reported? Mind you, if the Sever stopped receiving reports from the client, it would time-out and stop sending the data which was updating your displays, and wideclient would also show "waiting for connection" again. So, I can only think that something happened in the USB chain of things, or WideClient's link to GFDev.dll, the GoFlight driver. Isn't the GF device receiving power from a powered hub in any case? And as you surmise, I can't imagine the USB link would continue to work in one direction only. So it isn't a one-off glitch? Hmm. That is suspicious, then. Possibly pointing more towards hardware. Things to try in a process of elimination: 1. A different GDdev.dll driver -- I put the very latest in the Updates Announcement recently. Try that. Or even try a much older one, also there. 2. A different USB socket -- well away from the one you are using (the PC USB sockets are usually in pairs, sharing the same internal chips, so try to use one from a different pair). 3. A different USB cable. 4. If you are using a hub, a different socket on that hub. 5. If possible, try it on the FS PC for a while, see if it ever occurs there too. If all 5 tests still give the problem, I'd strongly suspect the GF unit itself. Otherwise the tests should show where it is in the USB chain of things. Regards Pete