Pete Dowson

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

Does FSUIPC work okay -- is it reporting any problem? If not i think you should talk to HiFi Simulation and check before acting. With Gold being FSX + Acceleration combined, the installer lists will only have the one entry for the entire program -- after all, it was just an updated FSX you installed, not a Base FSX and then some updates. Really, my advice for FSUIPC only originally applied to the Base version -- it gets rather fraught with the three versions of SimConnect being there. If ASA is only complaining about the SP1 version, then, if FSUIPC is happy with the SP2/Accel version (check its Log file to see), you might be able to delete the SP1 SimConnect folder only, then run repair from the disk. However, I think you ought to ask HiFi Simulations support about this before doing anything. It may be that their checking doesn't quite match what FSX Gold installs, somehow. Best to be sure it is an actual FSX problem first before possibly making it worse. Regards Pete

Don't you just love self-correcting software? :shock: Pete

I don't knowAre you reading this in the FSUIPC Advanced User's guide? I just copy extracts from the PM documentation at http://www.projectmagenta.com/pmoffsets.html for easy reference. Did you cross-check to see if things have changed? Are you sure you are using PM builds in which these work? Sorry, but I think PM support is the correct place to ask these sorts of questions. I cannot support their software. If you are sure you are sending the correct values, the rest is up to their modules. Regards Pete

Sorry I have not gotten back to you sooner, Pete. It's been chaotic here. The FS9 implementation certainly works "correctly" in 3.908, and I think the FSX does. My memory is giving out. Thanks! Pete

Why are you doing all this manually, when I so carefully designed it to work so well using the in-program options? why restarting FSX when you could merely press the Reload button in the buttons Tab? The format for Controls instead of Keypresses contains a C. If you used the options to assign your buttons you would have obtained the correct syntax anyway, which is: 1=P0,23,CM1:1 2=P0,15,CM1:2 Buttons can be assigned to Keypresses (K) or Controls ©. Macros are just Controls -- as listed in the Controls list in the options. The format you are using is only applicable to [Keys] because Key assignments always must be Controls -- there is no facility to assign keypresses to Keys. There is no 'C' or 'K' for [Keys] because there is no need, but obviously [Keys] would need the 'M' for a Macro. So you get Mn:n is [Keys] and CMn:n for [buttons]. But thanks for the report -- I see there is an error in the Advanced user's guide in this respect, which I will correct. Strange, it has been there all these months. Seems most folks do use the Options dialogue. ;-) I may make FSUIPC accept your format too, however -- there is no reason I can think of not to, and it looks like I was thinking that way in any case when I did the documentation! BTW What version of FSUIPC are you using? The version number is ALWAYS needed, or I cannot usually help. Regards Pete

Okay, thanks. I will be too busy till next week but will look at it then. All of the XYZ world velocities and accelerations are provided, as I pointed out, so you are okay. Don't use the body axes if you want world axes. If you need rotational accelerations in world axes you will have to compute those from the body rotational accelerations. Ah, what you refer to as "differences in update time", we know as "acceleration". It is the acceleration, i.e. the rate of change in velocity, which is felt as force. "G-force" means "Gravity force" and is normally the force felt from the acceleration called gravity. So you want the three accelerations, as I thought. But if you want them to measure the feeling of forces on the pilot, you want the accelerations in the BODY axes, because the pilot is sitting IN the "body" of the aircraft and his left/right/up/down/forward/back are of course NOT the same as the World XYZ axes. Regards Pete