Pete Dowson

Just to note that you should do all the reads and writes you want to do in each "cycle" of your program, whatver, then one Process call. The FSUIPC_Read and Write calls take no time at all and do not invoke FS or FSUIPC, but every FSUIPC_Process call means a process switch into FS and activity in FSUIPC to heed your requests. If you are simply responding to humans pressing buttons and so on, then the single Write/Process sets as you have there will be okay -- with each being instigated manually there is no performance hit to notice. But group them when you do have several things to read/write. Regards, Pete

No, sorry, I have absolutely no idea how to do that. Regards, Pete

Not sure what you mean. Have you got is assigned separately in FS? What are you seeing that indicates it won't "calibrate separately"? Always check things with default aircraft. If you want to assign functions in something like the PMDG or PIC aircraft I think you have to use their keystrokes. They do their own autopilot which is separate from FS's. I don't know what that is. If the CH buttons look like buttons to FS you can assign them in FS, or, for a wider choice of functions and the possibility of keystrokes (eg for PMDG aircraft) you can assign them in FSUIPC. Also, with FSUIPC, you can make assignments for PMDG aircraft specific -- FSUIPC will automatically change according to what aircraft you load up. Regards, Pete

It does? That amazes me, and shows how little I know about VB. I would have thought that: Dim doGear(4) As Long would define an array of 4 longs (i.e. 4 32-bit or 4-byte integers). Does it not? If it does, then Call FSUIPC_Write(&HBE8, 4, VarPtr(doGear(1)), dwResult) would only write the first one, which contains hexadecimal FF -- or does it? To write all 4 parts of the array you'd need a length here of 16, which would then overwrite the actual gear position values (but not for long as I think Fs would quickly replenish those). I am thinking here that what is really happening is that your doGear(1) = &HFF is actually setting "doGear(1) to &HFFFFFFFF. This would be that strange invisible extension which VB seems to do secretly and which keeps cropping up here in the Forum. If you set it as &HFF& to stop it doing that, then I expect you'd only write hex FF to the gear, not enough to operate it. If I am right, then your other declarations: doGear(2) = &H3F doGear(3) = &H0 doGear(4) = &H0 are a waste of time and space. Why not just declare "doGear" as an integer, not an array, and set it to &H3FFF? Or even more in keeping with the documentation, set it to 16383, as defined? On your other question, I think (but I am not 100%) that the WriteS variant was added because of the way VB treats strings -- apparently strings are passed by value in VB not by pointer as in C/C++. The different declaration of the WriteS variant helps sort the VB compiler out. I hope someone who knows more than me about VB will jump in and correct anything stupid I've said here. Regards, Pete

Good! Thanks for confirming! Regards, Pete

I've fixed it in an interim test version of FSUIPC, which I did send to the original reporter (though I've not heard from him since then). Do you want one as well? Otherwise it will be fixed in the next official release, early December I expect. Regards, Pete

No, sorry, it would be impossible to maintain. But pretty much anything which is an external program to FS and interfaces to it through FSUIPC is a potential candidate. Some of these have links on the http://www.schiratti.com/dowson page (right-hand side). Really I think you are going about it the wrong way. Work out what you want to do, then find an application which will do it for you. FSNavigator not only is not an external program (it forms part of FS), it doesn't use FSUIPC at all. As for others, I think there are a few though I can't think of all their names off-hand. The ones that spring to mind are Project Magenta's QuickMap and Ted Wright's "NAV3" (or it may be later now -- I'm a bit out of date with these things). There's also a package called CoursePlanner, which you can use on a network without WideFS -- see http://forums.simflight.com/viewtopic.php?t=28211. I don't know much about it apart from what was said in that thread. Regards Pete

Yes, you would need 2 because you are trying to transfer 32 bits (4 bytes) or data whilst the axes can only transfer 16 bits (2 bytes). 07D5 is the second byte of the 2 bytes used for the 16 bit value in 07D4! They don't "work", they are just addresses, numbers. In Intel processors, memroy is referenced by addresses. Each byte has an address, from 0 up to whatever memory size is used. "Offsets" are merely differences from the start of a block of memory to where the specified data is. 07D4 is hexadecim 7D4 bytes offset from the start of the reserved FSUIPC memory. The hexadecimal number 07D4 is decimal 2004, so there are 2004 bytes lower in that memory. The word "offset" means just that -- "set off, or away from". As documented in the EPICINFO documentation!!! It is listed there as an EpicInfo parameter -- how come you found the FSUIPC_WRITE stuff and by-passed all the easier ones? Sorry, I am trying to advise from memory. I've not used EPIC for years. I think most people now use FSCommunicator or something else, whiich is probably easier to use, than my EPICINFO stuff which was designed mainly to work with the IPC.VXD on Windows 95 with an ISA EPIC Rev D board. As I said, I think the AP ALT VAR thingy uses feet. Certainly not feet min though. I don't really know where you are getting your terms from in any case, but in Microsoft C/C++ the term "WORD" is reserved for a 16 bit unsigned number whereas a "short int" is a 16 bit signed integer. Similarly Microsoft C/C++ uses "DWORD" (for "double word") for 32--bit unsigned and either "long int" or just "int" for 32-bit signed integers. 8-bit bytes are just "char" which may be signed or unsigned depending on compiler options, or "BYTE" which is unsigned The "smallint" may be 16 bit or even 8 bit for all I know. Where are you looking? If it is FSInterrogate then I think the terms there are from Delphi, which I don't know, but there are separate terms for 8-bit, 16-bit and 32-bit unsigned and signed numbers there. They should be reasonably intuitive to work out, otherwise try the documentation. If you need more help with EPIC I would recommend trying the new EPIC forum. I think it is http://www.simengineers.com/yaf/default.aspx. Regards, Pete

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