Pete Dowson

One further question: how are you closing FS? I think that may make a difference too. My normal way is by ALT F X, effectively the "exit" entry in the Flights menu. I think methods like Ctrl-Break, Ctrl-C and pressing the "X" close button may be bypassing some of the code. I'm not sure of this, but please experiment and let me know. I may also ask you to turn on some logging so I can see in detail what the Client is and is not getting. Regards, Pete

I've been scanning through the EPICINFO documentation (I've forgotten most of it, as I've not used it in years). And I found another idea there. You could try, instead of the direct FSUIPC offset, the panel token assignment, AP_ALT_VAR_SET_ENGLISH=U2 I think you should find this works in feet, which would be easier for you. Regards, Pete

The values 0 to 35000 written to 07D4 will amount to a maximum of just over half a metre (35000/65536). As documented, the value the AP uses is metres times 65536. A smallint is 2 bytes long and has a maximum value of 32767 (65535 if unsigned), a longint is 4 bytes and has a maximum value 65536 times as big. If you only want the Altitude to the nearest metre, write the number of metres as a 2-byte shortint to offset 07D6. The fraction would go into 07D4 (eg 32768 = half metre). If you want accuracy you'd need to write two values I think, as EPL only caters for shortints I think. Regards, Pete

And are you saying that the auto-shutdown option never works, even then? I really would need to be able to reproduce this to do much about it. the facility is very simply, it merely sends a frame out to all clients before closing. I wonder if your Client having Win2000 running on it has anything to do with it? I have one of those here some where, but I won't be able to try it till next week. Regards, Pete

How do you do it? Do you use PCi cards to add monitors? My main two FS PCs both have Parhelias. The FS one only shows the outside view, and is 3 x 18" LCD monitors. The view is 2400 x 600 resoultion (though I can use up to 3840 x 1024 the extra resolution isn't really helpful for scenery only and takes away a few fps). I use a zoom of 0.50 which seems to give me the correct perspective from where I sit. The main PM client has 3 x 15" LCD monitors and runs 3 copies of PM's PFD.EXE program -- Captain's PFD/ND, Standby+EICAS, and First Officer's PFD/ND. I think the performance would be a lot better with only one copy of PFD running, and, indeed, Enrico did start work on a mode which allows these all in one window. but alas is is not yet finished. As it is the three PFD programs compete for wideClient's attention, and the only way to get them to cooperate is to have two of them running a bit slower and with "UseTimer=On" parameters. There are PFD.INI entries for this and to set limits on performance. Regards, Pete

With the hotkey shutdown, WideServer (and therefore FS) is kept running for many seconds after the keypress to make sure all clients see it. With the "auto shutdown", WideServer sends the shutdown notification out to the Clients as a last block before terminating -- it does not try to hold off FS from closing for long. From your logs, I think the problem is that the performance is so poor (!) that the message about the shutdown isn't read by the Client before the link disappears: Server: Client: Average LESS than 1 frame per second! And you have no client applications running at all. What is it going to close? It all works 100% here on all sorts of different Client PCs. If you can tell me how to reproduce this, I will try to do so, but please run some client applications. With "AllowShutdown=App" in the Client's INI all it will try to do is close the applications in any case, and you don't have any running! Regards, Pete

Hmmm. Very strange. The both polling rates are pretty slow in any case. There are many add-ons which poll FSUIPC variables much faster than 5 or 2 times per second. I really don't know why it is/was crashing on your systems, and without being able to reproduce it I may never know. When I get time, if you still need me to, all I can think of doing is adding some code to trap these errors and log details. I can stop them crashing FS and things will carry on, and I can check the details in the log to see what happened. It may take a number of iterations to decide what data to log (I can't log everything) -- one of the problems with remote debugging. If you still need me to look at this, shoot me a reminder in about a week's time, and then maybe once a week thereafter for a while. I should be able to get to it before Christmas. Regards, Pete

I did such a program for Enrico. It is in his hands. The problems now are writing interface programs for the other simulators. I think XPlane was nearly all done, though with insuffient data for PM to operate correctly, but then a new version of XPlane came out which ruined that work, or something like that. I think they are holding off, possibly pending something from Austin Meyer. I don't know anything about FlightGear, but if that's the open source sim then it should be relatively easy for someone to deal with it. The problem then is financing. These things are full time jobs for Enrico and his team, and certainly I'm not really interested in spreading myself any thinner I'm afraid. That doesn't need anything from me, only someone to request spare offsets in FSUIPC's address space and persuade PM to reprogram everything to them, but it doesn't seem to me to be a good or cheap way to go. In fact it seems downright daft really, as it would still need someone to write the interface for the other simulators, so you gain nothing and work harder to do it. Best to just write the interface for the other simulators direct through WideClient to the IPCServer. Regards, Pete

In that case one or other of those programs must contain explicit code to turn off the sounds if FS loses focus. After all, to them, WideClient looks like FS, that's its job. There's no way WideClient could change that. Maybe there's an option in the SB programs? Have you asked on the SB forum or newsgroup or whatever? Regards, Pete

Sorry, what's the visual flight path? I don't know. Have you tried? I thought you either had panning or specific cardinal views. I've always used the latter. You can pan up and down in any of those views, and there are lots of "eyepoint" type controls which I've never tried. Have you tried posting these questions in the FS2004 Forum? They tend to deal with these general FS questions a bit better there. Regards, Pete

No. You use two USB cables, probably provided with the serial adapters, to connect the USB ports to the serial adapters (pieces of hardware). THEN you connect the two serial adapters with a null modem cable. you install the drivers that come with the serial adapters and this makes those USB connections look like new COM ports. Regards, Pete

Sorry, you need help from a VB programmer. I have no idea what may be wrong with your code. Oh, except for one possibility: &HC800 I think VB does a very nasty thing with that. It changes it to &HFFFFC800. Don't ask me why -- because it's a daft language, I'd say. It seems all VB programmers need to know these daft antics. Worse, it even does it to &H0000C800 !!! Would you believe it? I seem to remember someone telling me that to stop VB doing such silly things you have to add an & at the end, so: &HC800& but I wouldn't swear to it. Best to look it up in some VB reference book. In the languages I know you can define structures, Those 1024 bytes are not just an array of bytes, they are a mixture of integers, strings, shorts, and so on. However, for the purposes of Reading and Writing to FSUIPC, yes, you treat them just as a bunch of bytes. And 1024 of them can be written in one block -- your problem in in the VB code, which I'm afraid I know nothing about. Maybe I am wrong and someone will see this and help. There are a few very good VB programmers who visit here. But meanwhile you should realise that you do not have to write all 1024 bytes. In fact that is very inefficient. Just write what you need to write. To clear the weather you only need to write the command (short at C800), and a signature (unsigned int at C804). You can write them separately or together, but if they are two writes make sure the writing of the signature is last as it is that which triggers the action. [CORRECTION]: make sure the writing of the COMMAND is last as it is that which triggers the action. Sorry. It is the signature when reading weather, not when writing it. Similarly for all the other weather stuff. Only write the weather you need, you don't need to send all 1024 bytes. Regards, Pete

I really very much doubt that is possible. It seems that Garmin only provide such facilities on their aviation GPS's, and then it's via the AV400 format. I have two different Garmin GPSs and it certainly isn't possible on either. But the Garmin GPS III Pilot and the GPS 196 units both have "AV400" protocol support, and that is what has to be used with them, in simulator mode. This is an aviation protocol. Your box may look similar, but it will be the program in its ROM which is different. Regards, Pete

You can't do that I'm afraid. Well, not easily. WideClient and FS9 both try to provide the same services to the applications. WideClient will not run, at least in default mode, with FS9 also running in the same PC, and vice versa. Another problem there in any case. There aren't that many video cards/drivers which support OpenGL hardware acceleration on multiple monitors -- even if you are only using one of them it may not work. PFD needs OpenGL hardware acceleration. But try it (without FS9 running) and see. There is a way to make WideClient and FS run together on the same PC -- you have to tell WideClient to use a different ClassName. Please check the WideFS documentation -- the parameter you need is there someplace. This may not allow the PFD program to connect to it --- that may have to be changed. I don't know if PM provides for possibly different FS classnames, you'd have to check with PM support. There may also be a conflict if FSUIPC is installed in that copy of FS9. Regards, Pete

Really? I can't imagine what WideFS has got to do with it. There are no sound producing routines in WideFS. Do you mean that Squawkbox sits "within" WideClient, in the same way as it might in FS if run there? If so, then it seems that's the way they've programmed the SB sounds. You would need to ask them if it can be changed. I suppose they've done it like that to be similar to FS -- FS's own sounds do not play if FS doesn't have the focus. Regards, Pete

I think you have it wrong, at least according to the expert Bob Church. Most of my replies in this thread were before Bob wrote to me and explained things. Apparently you can either use the CH manager, with or without FSUIPC (it doesn't matter), and use its buttons for the reverse, or you can use FSUIPC to calibrate the reverse zone on the axis itself, ignoring the buttons. Bob says to try the CH Hangar at http://www.ch-hangar.com. He visits there more often than here. Regarding your kind advice, I'm afraid I am not really interested in buying any more devices, thank you. I already have enough to populate a Museum of Flight Simulation as it is! :o And I will leave advice about the CH quadrant to the experts. :wink: Regards, Pete

In normal circumstances, SendMessage should be able to deliver its message within that time, yes, but not if FS as a process is tied up doing something which stops it processing messages. This can happen on large or slow disk accesses, such as when FS is building its scenery indices and so on. What do you mean "no data was ever sent"? The SendMessageTimeOut details don't relate to date you've prepared? You've prepared no data? I don't understand what you mean by that. If FSUIPC receives read and write requests in the data which is shared via the SendMessageTimeout parameters (for that is what they are for, to convey details of memory-mapped file data), then it has certainly "received" data. If FSUIPC finds anything wrong in the data it is asked to process it returns "FS6IPC_MESSAGE_FAILURE" -- it might actually process some good data then find something bad, in which case you'd get this return. Generaly it would mean an unrecognised request -- for instance, a missing zero terminator on the data would do this. You'd also get such a return if the access FSUIPC had to make in order to obey the data caused an access violation or any other serious would-be crash in FS -- FSUIPC traps these and logs them. Check the FSUIPC Log file. You don't get a failure return if FSUIPC simply doesn't read or write some of your data because that part of FS isn't yet ready. In that case Reads normally return zero, and Writes are discarded. It sounds like a bug in the data being provided. I think the above scenarios are the only cases of a Failure return code from the SendMessageTimeout, if it doesn't timeout or fail to get sent for any reason. If you are multi-threading then check that you are not changing the data in the memory mapped file area before it has been fully dealt with. Regards, Pete

I don't see why -- by all means experiment, though. My main testbed (not my flying PC) here is a lowly Athlon 2000, much slower than yours, so if anything a too-fast polling rate should cause more damage. Not sure it is worth doing that, after all you said the problems occurred on both machines in any case, didn't you? Or not? Regards, Pete

Only if you convert them to COM ports (serial ports) by buying a pair of adapters. Pete

Ouch, that sounds like something is really wrong with the pedals, or their driver. All I can advise really to to go over to the CH Hangar: Report this there, see what they say. Bob "Sticky" Church, the world expert on joysticks and especially CH stuff cvisits there, so you'll be in good hands. Regards, Pete

No, they work fine together, or so I am told. FSUIPC doesn't really care at all about what happens to the values before they get through to FS's simulation engine. Remember, FSUIPC is not dealing with the joystick inputs themselves, it is dealing with the values FS is just about to use, just before it uses them. All that happens is that when value the IN value gets to the value shown in your "Max" box, FSUIPC makes the OUT value 16384. Similarly, it makes the OUT value equal to the minimum FS requires (e.g. -16383) when the IN value is less that or equal to the value shown in the "Min" or "Idle" box, whatever it may be labelled. For any values in between, it scales them to fit that complete range. That's it. Very simple really. Are you sure you have actually asked FSUIPC to calibrate (i.e. the left most button says "Reset" not "Set")? What are the values in each of the boxes? Maybe if you took a snapshot? You could also show me the Joystick calibration section of your FSUIPC.INI file. Regards, Pete

If you want to calibrate axes in FSUIPC you just need to follow the steps ennumerated in the documentation. The "IN" values are not important, it's the "OUT" values which are sent to Windows! In your examples, moving the levers so that the 7040 or the 15500 shows in the "IN" box, and pressing the "Set" button over the "Max" box will calibrate that end. I'd advise setting it a little lower so you can always achieve maximum even when there's some variation due to temperature and so on. Take care of the idle end too -- you need to allow space that end as well. Just follow the steps. You'll get there. The input values don't matter too much -- though for maximum sensitivity you need to make sure FS's sensitivity slider is set high too. Your readings of 7040 and 15500 are typical and fine -- in fact the 15500 is very good, most unusually high. The values from my Saitek wireless control device, which I use for testing, are almost all less than 7000 but it is easy to calibrate to full range in FSUIPC. Regards, Pete

Two things there: 1) I may not have tried for long enough then. 15-20 minutes is a long time for a developer writing and testing programs. It sounds like I would have to do a real flight too -- I was just checking things statically. Do I really have to have everything going? 2) The accesses Esound is making into FS are occurring all the time, so it can spot the changes. All that is happening differently when a sound is triggered is just that -- the call to DirectSound to make the sound occur. So it certainly sounds (excuse unintentional pun) like it's somehow related to the sound subsystem. Also, so I could definitely hear if your sounds were being triggered or not, I turned the FS sounds off (Q). Do you still get crashes with FS's sounds off? What version of DirectX are you using? I'm on DX 9.0c. But the PC I'm testing on (the only one with all my debugging aids installed) only has an on-board sound system, an Avance AC97 chipset I think. The drivers for that date back to March 2002. Regards, Pete

Hmmm. It did here -- but I admit I tried changing the Frame type first. When Katy suggested the Authentication, I put the frame type back to Auto and disabled Authentication, and it was okay. But maybe changing frame type altered something else more permanently. Hmmm. Yes, even though they say "auto detect", it doesn't appear to successfully do so. I have mentioned that. But I'll do some more tests with Authentication. Maybe I'll change the wording to "try this, but if not, then ...". You've lost me there. How do i see if I have one and then remove it? Isn't a bridge something that joins two Networks? Is the original slow/reconnecting start-up fixed too now? Regards, Pete

Hmmm. Are they all with complex add-on panels, do you know? You are the only one reporting this to me, that's all I have to go on. If others have anything to add they should really come here. I don't have time to scan other places. I'm not sure how the small changes I made (and they are indeed very small -- just one line commented out, to stop it comparing the name of the new aircraft loaded with that of the previous one) can really affect the normal use of the program, but I will try to reproduce it here. Regards Pete