Pete Dowson

It is "Dowson", actually, but call me Pete, it is easier. You really needed to mention this when purchasing. But SimMarket can still sort it out for you -- raise a Problem Ticket and explain the situation and give your original login email. The email address itself isn't used by FSUIPC for anything other than tying the Keys specifically to you -- a street address would be used if you purchased by post. Both keys need to be tied to the same identity since there's only supposed to be one user. Regards Pete

There's no such error as "not a 12 digit code". I assume you mean not a valid one? Assuming you bought keys for the version you are using, and not for FSUIPC3, You are making a mistake! In all (100%) of such cases ever reported it has always turned out that the user was not entering one of the three fields correctly. ALL PARTS MUST BE EXACT -- your name, your email address, your key, letter for letter identical to the registration made. Please use cut-and-paste for all three parts if you are not sure! It is easy to mix up 1's and I's, 2's and Z's, 0's and O's, and it never ceases to amaze me how many ways folks have of differently spelling their own names! Regards Pete

FSUIPC doesn't touch anything in your aircraft unless you've told it to. But I don't know this "VASF4", so maybe it is something to do with that? What is it supposed to do? Try not using it. If you've been messing with FSUIPC settings and don't know what you've done, just delete the FSUIPC4.INI file before loading FSX -- then FSUIPC will revert to defaults and not touch your controls at all. You'll find that file in the FSX Modules folder. Regards Pete

Ah. I think the problem here is more that, like many hardware implementations, there's no information about the switch position provided until it has changed. At least, I think that is the case. Certainly the Lua facilities don't have any more access to the switches than FSUIPC -- they are using it directly after all. Looking at my code for GoFlight, it uses a call-back system from GFDev.dll (the GoFlight driver) to receive notifications of changes. I doubt that the GoFlight driver sends any "initial state" information, which is what you'd need. There may be a polling method for the switches implemented in GFDev.dll which could be used to get the initial state. I don't know offhand. I'm not able to access any GoFlight dox at present (I can't find them on this PC -- I may have to re-download the SDK to find out). However, it would be a non-trivial task to add something to get this information even if it were possible. I face the same problem with my PFC cockpit -- I can only read most of the overhead switches when they change. So, on my checklist, before anything else, I have a "run through switches, check all set correctly" item. I think this is pretty realistic in any case -- i.e. good practice. I note that the 747 and most other modern Boeing cockpits use mostly push buttons, so toggle switch states are much less of as problem. Regards Pete

It's possible, of course, but why do you think it is needed? pmSystems has offsets for everything. You can program the switches and buttons directly in FSUIPC's Buttons tab using the Offset controls. Any systems programming can and should be done in pmSystems logic files. Please explain why you want to do extra programming above what is done in pmSystems, and why this wouldn't be better off-loaded to pmSystems logics. Now, if you were NOT using pmSystems, you could instead probably program most of the complex subsystems using Lua. That is another matter altogether, and requires more knowledge about the subsystems logics than is does about Lua. For Lua programming there are several very good books around, plus the stuff on their website. All FSUIPC does is add special libraries for interacting with FS, buttons, keys etc. Regards Pete

Possibly the PCs you were using didn't have the right OpenGL drivers installed. This makes the PM modules resort to emulation, which hogs the processor and starves WideClient of time. On all of the Networks I've ever had for PM, starting over 10 years ago, the data rate has always been able to remain close to the throttled (limited) FS frame rate and provide smooth gauge operation. Either way, all this is probably irrelevant for the demo suite and as you aren't going to spend the money there's no point in investigating further! ;-) Pete

Okay, I've managed to test it with two ports as well, not with connected devices but by using a serial port monitor and checking the data being sent. So, FSUIPC4 version 4.519 is released in the Downloads Announcement now, and you can get it (until the next update) via this link: http://fsuipc.simflight.com/beta/FSUIPC4519.zip . Here's the note about it: 15.[FSUIPC4 only] The GPSout facilities are extended to drive one or two separate devices, or operate via WideFS and a serial port, at the same time. Difference port speeds and sentence selections can be used in each, the only restriction being that the interval has to be the same for both. In other words the outputs, although possibly different, are synchronised, or nearly so (synchronised at the port queuing level). All settings can be managed via the AutoSave/GPSout tab in the Options -- just use the two little scroll arrows, top right on the GPSout side, to swap between the two outputs. Please let me know how you get on with two real devices! Regards Pete

You'll be pleased to know I added the facility for two outputs today. Testing now. Either two serial connections or one WideFS and one serial, with different parameters possible for each output. The only restriction is that the interval has to be the same for both. I tried allowing separate intervals but I got too many problems then keeping the values in sync -- it made it much easier generating the values for both and sending them out together (well, nearly together). I'm not able to test here with two serial ports, but it looks good with one WideFS and one serial port. I'll provide a link for you to download the interim version first so you can test it one two ports for me. Some time tomorrow (Saturday). Regards Pete

No. i've no idea how to tell either! Pete

What version of FS are you using, please? Those offsets date back to FS98 days when there was only global weather. If you are using FS2004 or FSX then these use localised weather, and setting the global weather simply sets the default weather for those weather stations not already populated. Try clearing all the weather down first -- twice, ideally. For FS2000 and FS2002 FSUIPC's best support is the Advanced weather Interface -- at least it does handle most of the intricate details, which the old FS98 interface cannot. however, really that is also superseded by the "New weather interface" (NWI). With FS2004 you can send clear All Weather requests first, then get global weather to set, but within 10-20 minutes all the local stations will be localised again. Having to clear weather all the time to set it causes irtritating flashing as you can imagine. Really, for FS2004 the only sensible answer is to set local stations -- this is what Active#Sky and most other weather programs do. For this you'd use the NWI, "New Weather Interface", provided in FSUIPC. The situation is a bit better in FSX as Microsoft kindly provided a Global weather mode. You can set that through the NWI, then everything gets a lot simpler. Regards Pete

So that output was from the Demo, all on one PC? In that case I am not surprised at the figures -- PM is meant to be run on a Network. And the demo is quite restricted, simply to show you the instrumentation. Those figures are by no means representative. Pete

ESP was Microsoft's "Professional" simulation platform, initially based on FSX but ultimately aimed at simulating almost any real world operations (railways, factories, haulage, etc) for commercial concerns. There were a lot of big names taking an interest. It stopped development at the same time as FSX did, with Aces Studio's demise. Thank you for putting it on the list - don't want to load you down too much. But I believe this would make the GPSOut feature just that much more useful to those trying out multiple devices. Well, odd then that I don't recall it requested before, in the 10 years since GPSout was produced. Maybe it has been and I've forgotten, but I don't think so. ;-) Nevertheless, if it is easy I will slip it in soon. If not it will have to wait a bit. Regards Pete

;-) Okay, will do, thanks, Pete

I wanted to try flying on-line and have SB4 installed, but I fly inside a cockpit and want only scenery on my main FSX screen (projected). SB4 allows the PTT operation from a programmed button (on my yoke, in fact), but I can't find any way to get the Transponder Mode and Ident programmed from my hardware transponder. SB3 provided FSUIPC offsets for these essential operations, but they don't seem to have thought about this for FSX, having moved away from FSUIPC. I've written to the authors several times over the last 9 months about this, suggesting a simple solution using messages, like the PTT operation (originally from Roger Wilco), but they seem to ignore me except for one reply last year apologising for not replying. So, as a bona fide SB4 user, do you know if it is still a "live" product? Have the developers stopped working on it? I'd really love to know whether it is ever going to be something usable in a hardware cockpit, one day. Regards Pete

Looks like the FS frame rate counter is out of range. That 32768 value just means an overflow I think. FS98? Does my stuff still work on FS98? What version of FSUIPC are you using? The first FS version it was actually designed for was FS2000. I only made it run on FS98 in its first few months in order to compare the offset results to ensure ongoing compatibility. The WideFS data rate is regulated by all sorts of loops, priorities and so on, to ensure smooth operation. You should be limiting the frame rate in FS to suit the instrumentation and you flights, to get things nice and smooth. For PM support, and to find out exactly what PM's displays mean, you really need to talk to PM. Regards Pete

Note. It costs $25 for the 64 bit version. George Ah, thanks. I didn't know that. Regards Pete

If you mean "REX", then I think it is primarily a graphics effects program for FSX, and integrates itself via textures and so forth into the sim, not via a network. The HD weather would be referring to the cloud textures. For the weather control it probably uses SimConnect, certainly not FSUIPC. There's a possibility that its control program could be run on a Network (as, indeed, does ASA, another simConnect weather control program), but you'd have to refer to its documentation or support to find out. As Jim says, there is no program for AI traffic running other than FSX -- the AI traffic is defined in FSX (on and FS9 for that matter) in a collection of data files (BGLs for routes and schedules, Aircraft folders for the aircraft models). There's nothing to run outside of FSX, let alone on a Network. Ultimate Traffic 2 provides AI traffic a different way, however. It injects the flights via SimConnect, using a program external to FSX. So, theoretically that program might be usable from a SimConnect client PC over a Network link. I'm not sure if they've allowed for that (the program would probably need intimate access to the Aircraft folders). But either way, I don't see that you'd gain anything -- the work of creating and flying the traffic is still being done by FSX. All the control program is doing is sending the instructions to create it and set the flight plans. Regards Pete

Well, I'll add it to my list for FSUIPC4. I take it you are talking about FSX or ESP use? I'm a rather more reluctant to mess with the ten year old code in GPSOUT.dll. Regards Pete

I don't know it, so I assume it isn't an FSUIPC client program. It sounds like a weather and/or graphics program? If it isn't a separate program (nothing installed in FS) and/or doesn't use FSUIPC to accomplish its tasks, then it isn't Networkable via WideFS, as WideFs only presents a copy of the external FSUIPC interface. If it is for FSX only and uses SimConnect then there is a possibility in that direction, but you'll need to consult its documentation about that. Regards Pete

Ah, is it not there now? I must have missed it out when I had to rebuild the Announcements after they all got lost somehow. Anyway, the MixW one doesn't work on Vista or windows 7. There are some more flexible ones available, one also freeware. Try the freeware one from Eterlogic, here: http://www.eterlogic.com/Downloads.html Regards Pete

Okay, those are the same error codes defined in the C/C++ library code too. But your message box did not declare it as the error returned by the library code. Well, that means what it says -- it sounds like your code decided it didn't like what it saw when reading that first section of data and was retrying -- without closing the previously opened connection first! Maybe you are operating with too tight a time-out, and not checking the data returns? Well, it consistently fails here -- so I guess the timing on your system is a little closer. It still needs attention I think. Regards Pete

Well the log shows nothing wrong. FSUIPC4 is doing little and is not being affected by any SimConnect problem. But it does worry me that you are using such an old version, one which is completely unsupported. I suggest you update to a supported version (4.50 at least) and try again. Let me know when you are using a version I can help with. Regards Pete

I did this and, although it complains that it isn't connected, logging IPC reads and writes in FSUIPC's Logging shows it connected fine. Your Error Code is 1. There are no error messages like those you describe from FSUIPC -- they don't exist, in fact. Your program does all this before it fails: 184594 READ0 3304, 4 bytes: 00 00 03 39 184594 READ0 3308, 4 bytes: 07 00 DE FA 184594 WRITE0 (failed, read-only!) 330A, 2 bytes: 00 00 That part is standard, part of the library, getting the FSUIPC version and FS version numbers (3.903 and "7"as shown). The write to a read-only location is deliberate to get a log entry, as it gives the LIB version number (0 apparently -- not sure why. Maybe one of the non-C/C++ versions where someone isn't filling in the library code level?) These are actual reads from your program, evidently getting aircraft position etc: 185719 READ0 0560, 8 bytes: 00 00 DE EB 7B 98 59 00 185735 READ0 0568, 8 bytes: 00 00 BB 36 F8 84 07 FE 185735 READ0 0570, 8 bytes: 00 00 BD BB 54 00 00 00 185750 READ0 02B4, 4 bytes: 10 52 24 00 185750 READ0 0580, 4 bytes: AF 92 1D FA 185766 READ0 0366, 2 bytes: 01 00 185766 READ0 02C8, 4 bytes: 00 00 00 00 185766 READ0 0020, 4 bytes: D0 53 00 00 Please use logging and your debugger to find out what it is you are doing wrong. There's been no change in the FSUIPC interface since version 1.00, it is the same one as in FS5IPC and FS6IPC before it. Regards Pete

Thanks for confirming! Pete

No, not at all. Do you have a second PC? If so you could use WideFS and drive a serial connection on each PC. On the FS PC you'd have to run WideClient with the "ClassInstance" parameter set to avoid it clashing with FS. I use this system. Regards Pete