Pete Dowson

Oh no, not that again. :cry: :cry: :cry: It means it cannot find the correct place to get the lists of FS controls. It gets this through FSUIPC. In FSUIPC can you get the FS control drop-downs to work in the Keys or Buttons pages? What version is FSUIPC? I've changed none of the code that deals with this stuff at all. I don't understand. And I'm afraid I may not have time to deal with it until I return from holiday on March 12th. I will try to make a quick test version for you to try later today ... Regards, Pete

But that's not right. The trim is pre-programmed for all the yokes with the pairs of rockers on each side. When you say "it does nothing" perhaps you aren't noticing the subtle trim adjustments? By default it starts off with very slow adjustment, designed for very good accurate trimmimg. If you hold it down for more than a second (or whatever, adjustable) it speeds up. You can adjust the sensitivity in the Console options page. You can also change things in the INI file to reduce or eliminate the delay if you want it faster straight away. Ahthat is wrong, indeed. The incorrect codes are doing the damage. It looks like there is some wiring problem, maybe a dry joint, maybe a problem in the little CH decoder board in the base. I'm afraid I can't fix that in software, you'll need to check with PFC. But please also look at the default trim programming. You should find it more flexible once you've adjusted it to your liking. I don't know what version of PFC.DLL you are using, but I did increase the default trim sensitivity a while back. But try your own adjustments. In the PFC DLL documentation, look near the end for the Trim parameters there, and also play with the sensitivity in the on-line options (on the Consoles page). Mine is set to 64. This won't fix the spurious codes arriving from your Yoke though. You need PFC's assistance there. Regards, Pete

Sorry, I don't know. Is the Speed correct? Is the COM port correct? Most importantly, is the connecting cable correct? I didn't know that Pocket PCs came with a regular COM port. Have you checked that you are communicating correctly? Is there anything for the Pocket PC that can check and display what it is receiving? Also, you don't mention which version of GPSout you are trying, nor which version of Flight Sim. These things might be relevant. I use GPSout with GGA and RMC sentences all the time, connecting to Jeppesen FliteMap on another PC, and it does work. The communications need verifying. Regards, Pete

Ah, it does tell you not to do thatyou will have to send both original emails to me privately (paste them into a covering email), at petedowson@btconnect.com. Tell me which name and address you want to use. I will send you a new Key for whichever needs changing, and block the old one. Okay? Regards, Pete

Thank you very much. I assume you found the FSUIPC file, then? And you have received your Key by now, I hope? Regards, Pete

Is the yoke connected through a PFC digital control and into a COM port, or is this the direct Game Port version? If the former, then the default programming in my PFC.DLL for the left most rocker is electric trim already. Where is this so set? I'm a little confused here. If this is via PFC.DLL please check the buttons in the Test page. If it is the Game Port version then I really have no idea I'm afraid -- it sounds like the buttons are programmed twice in FS. You aren't programming them in FSUIPC and FS are you? If you are programming them in FSUIPC you need to delete any programming for the same buttons in FS, and vice versa. Regards, Pete

It's on my list, but I don't don't know when I can fit it in. And it isn't as easy -- with the PFC devices I know the resolution of the device. I would have to allow the "closeness" to be a parameter in FSUIPC. And I think it would need the digital jitter filter too. I think I would wrap this up together with selections of response curves for the main flight controls, and try to do it all in one big enhancement some time later this year. Regards, Pete

OkayI hope you can work it out. The problem for FSUIPC in the NWI is simply the sheer amount of data which it needs to be able to map into "offsets". Realistically getting more than one location (ICAO) mapped at one time was not reasonable. Anyway, each such request needs a specific series of events -- request from application -- calls to WEATHER.DLL to get data -- update of relevant offsets. I had some trouble with the stability of FS if I tried to do the Weather calls "aynchronously" -- i.e. during the Process call rather than on a regular frame rate call from FS. Otherwise I could probably get the responses faster -- almost instantaneously for internal callers. But I would be worried about FS crashing, and I don't think it would help with FS performance -- probably the reverse, as you'd be making more requests in a shorter time. Regards, Pete

Can you use FSUIPC IPC logging to check what you are doing? Also you can experiment with FSInterrogate -- that is why it is provided. Since you are trying to write weather data you may also find it useful to enable the FSUIPC weather logging. I can help work out what it is you are doing wrong much more easily from log extracts showing these things. I think it would help you too. In the case of FS2000 and FS2002 weather, you must clear it all first -- use the Clear Weather facilities in the FS weather dialogue, or the Hot Key provided by FSUIPC. In the example you quote above, setting the lower cloud type without also setting the cover, altitude and ceiling in offsets 0F24 - 0F2A won't accomplish a lot. You need to set clouds as entities. Of course you should be able to change an existing layer with individual writes. Regards, Pete

Seven? How odd. Yes, of course. It is at , along with all my other software. YTou don't have to pay for it to download it. You can download it, install it and use it for freeware applications for free. Please check some of the announcements at the top of this forum.FSUIPC and all my other programs have always been free downloads. You only pay to use some of the facilities (or in the case of WideFs, to make it work). This is for Technical Support. You just need to read things a little more carefully I think. It does tell you where you can get FSUIPC on the page where you paid for it. It does also tell you to expect the access key within 24 hours. There are links to FSUIPC on the Schiratti website all over the place, and the program is available in lots of other places too. SimMarket only deals with the registration, which is usually something folks do AFTER they've got the program, installed it, and read the instructions. Maybe you didn't need to pay anything for what you want to do!? Regards, Pete

Phew! That's a tall order. Since FSUIPC weather access operates at the FS frame rate, you'd need FS to run consistently at at least 43 fps to achieve that! When FSUIPC receives your request is schedules it to be done at the next frame cal from FS. How often is your gauge being called by FS? Most are surely once per frame in any case, aren't they? If I were you I'd try to spread it out over many more seconds. Once you have read your 128 stations or whatever, are you then not reading any more? I don't think you need to read the same station very frequently. Weather doesn't change (or shouldn't change) very fast. Once you have your initial batch, updates at just a few stations per second should surely be enough, perhaps so that you get round the whole lot at least once every minute, perhaps 30 seconds? Regards, Pete

It isn't FS, it is the way FSUIPC obtains that value. It is read from PANELS.DLL using normal panel accesses. Since these are relatively slow (involving lots of nested procedure calls and, in this case, computations at the end of it too), they are done infrequently -- only twice per second, which is exactly what you are seeing. This didn't particularly worry me because most of the values I have to read this way don't need faster updates in any case. This is obviously an exception when used directly for instrumentation -- in fact as far as I can see it is the only exception in that particular list. Sorry about this. Evidently it hasn't been a problem before. This value was a late addition to the interface, and pretty much all users did it the "harder" way -- reading the aircraft altitude and correcting this for the difference between QNH and the Altimeter setting. Since the aircraft altitude value is a direct read from an FS-maintained location, not an artificial value from FSUIPC, it is much more responsive. I will change the polling rate for this to match the frame rate. Just the one value so read shouldn't affect performance noticeably -- in everything I do in FSUIPC, zero measurable effect on performance has always been a prime goal. This change will be in FSUIPC version 3.20, which I am planning to release this weekend. Regards, Pete

Just reading the weather, not setting it? There shouldn't be any noticeable frame rate drop -- you surely aren't reading all the weather every frame or whatever? It isn't going to change very fast. In fact for weather at the aircraft and global weather I think I only update it once a second or so. Reading weather at a Lat/Lon or ICAO is heavier as it makes special calls to FS's WEATHER.DLL each time you ask. Two questions: 1) You are using the internal module user's access method for FSUIPC, aren't you? i.e. the one with FSUIPC_Open2? If not, change to that. The external application access method is grossly inefficient for gauges and modules and prone to problems. 2) If you are requesting weather at specific ICAO stations or Lat/Lon locations, you need to place the request then wait for the timestamp to change before reading the results. But you should certainly not wait inside your gauge. You need to exit so that FS can continue, then check on each subsequent entry. Less process calls and all the bytes you want. All that data count is doing is copying more bytes into your memory area. It's a very tight copy loop, probably all in the processor's pipeline at once in any case. Each process call is a Message sent through Windows to get into FS's Message queue, for FSUIPC to process, and THEN the copy of bytes into your area. So by splitting it up you are making everything worse. The only limit on the data transferred is due to the way the count is used in FSUIPC's interface, and some of its buffers. You shouldn't transfer more than about 30000 bytes in one process. Keep it to 16k max in fact, to allow for all the red tape stuff. Regards, Pete

Er, umdon't know. The FSUIPC_Process sends a Message, so how the system then does things is up to it. The code in FSUIPC doesn't do anything except (eventually) receive your message, process it, and exits, at which time whether the system returns control directly to you or not I really don't know. I guess it would depend on lots of things, like whether it had any other high priority things to do. In terms of threading, as I understand it, operating systems like Windows NT, 2000 and XP are pretty good at timeslicing between both processes and threads, but Win 98 and Win Me are not. Considering most folks are moving to Win XP these days I should think judicious use of threading in your own application would be advantageous. You could certainly have the FSUIPC access in a separate thread, with a suitable "Sleep" to control the timing of the requests. That might be better than using Windows timers which can be erratic. Regards, Pete

You are talking about registration of an application program or module, I assume? If so, then, yes, if you are planning to sell a product using FSUIPC for a profit, then I would expect you to come to some agreement with me about licensing and accrediting the program for its FSUIPC access. All the information you need for this is in the FSUIPC SDK -- please see the Access Registration documentation. That is easy. If you are not making a profit out of something interfacing to FSUIPC, then it is in the same category as freeware and it is entitled to a free access key. However, if it is only a one-off, i.e. for your personal use only, you may still find it worth your while Registering FSUIPC as a User, as you then get both automatic access for your program and the use of all the (gradually extending) user facilities in FSUIPC. But you don't need to pay anything if you don't want to use any of that. Please just read the Access Registration documentation in the SDK and contact me on petedowson@btconnect.com if and when you want a Freeware key. But please note I will be away with no Internet access from February 19th to March 12th inclusive. Regards, Pete

I don't understand why you are doing all that. Just write the whole number of metres to the normal 32-bit signed integer in the 4 bytes at offset 0x0574 and the fraction (if any) to the unsigned integer in the 4 bytes at offset 0x570. There's no need for any other complexity. The fraction would be in 1/65536ths, for example 0.5 metres is 32768 in the lower word. When in doubt over anything like this, please look at FSInterrogate and see what that does. You can experiment writing and reading almost anything with that program. Also please use the FSUIPC logging for IPC reads/writes. I'd rather see a log extract and tell you what is wrong with that than plough through code, expecially code which is doing things I don't understand. :? Regards, Pete

Oh most definitely batch all the reads together. They are only adding a little data to your own processes memory and take no time at all. Each and every Process call makes a Windows process change, queues a message for FS to attend to, makes FSUIPC do things, and then process switches back to you. You don't want to do two of those when one will do! (et cetera). There is a limitation though. If the total space occupied by your accumulated read/write requests gets to more than about 30000 bytes you'll cause a problem. If you are reading lots of data try to keep it down to 16k chunks to be on the safe side, even if that means more than one Process call per cycle. Also important for FS performance is the cycle time -- i.e. how often you are reading the same stuff. Attempting to go faster than FS's own frame rate is futile, but definitely try to set a slower rate than that if your application doesn't need frame-rate speeds of operation. Regards, Pete

Sorry, can you elaborate? It sounds like you are trying to run unaccredited programs with FSUIPC and haven't purchased a user key. What has WideFS got to do with it? That most certainly needs purchase if you want to use that. Also, have you tried the support site for the programs you are trying to run? I don't really understand what you are trying to say here. Perhaps if you explained in rather more detail I might understand? Thanks! Regards, Pete

No, sorry. Scenery is not one of the areas touched at all by FSUIPC, though it does bring a few of the BGL-accessible variables to the interface in FS2004, to where they used to be in previous versions. That sort of thing used to be done by the old Lago FSTraffic. Maybe their FS Scenery Enhancer is what you are looking for? Lago's programmers certainly know a lot more about this area than I (which isn't hard, actually, as I know almost nothing! :? ) Regards, Pete

When an external weather control program tells FSUIPC to clear the weather, it clears FS's own weather and any previous weather set in the "FS98"-style and "AWI" weather areas, which may have weather remaining from other previous weather programs. That is all that logged comment means. It will say that all the time when the weather is cleared, and is not a problem, nor is it a message from FSMeteo. The message from FSMeteo won't be in the FSUIPC Log file -- that contains messages from FSUIPC, which isn't seeing any problem. The message you need to deal with is the one you are apparently reading that tells you that there was a timeout. In other words, there's nothing you are showing me that indicates a problem and I don't know what the problem could be because I cannot see what you are seeing, nor do I really know FSMeteo well enough to know all of its possible errors. Sorry. I hope you can get it sorted out with Marc. Regards, Pete

Sorry, I haven't found any way to intercept the weather calls made by ATC in order to change this. The whole weather system changed in FS2004 and the new code is very convoluted and obscure. I am hoping to be able to do more as time goes on, but it takes so much time hacking into those modules and yet still mostly getting absolutely no where that I really have to get on with things I can actually be more successful at. Maybe one day ... Regards, Pete

No, I've no way of getting this sort of information to the ATC. I might be able to fiddle the ATIS, but I suspect not. I think the way both get their weather data has changed. I used to be able to intercept the call the ATIS made and overwrite the wind information. I think your only solution is, knowing the ICAO of your destination, and assuming it is also a listed WX station (not all of them are), to set the local weather for your destination. To make the ATC choose the correct runway you have to do this a good way out -- over 85 nm, the maximum radius at which FS seems to generate traffic. Once it has traffic assigned to a runway it won't change that assignment even if you change the wind -- not until you leave the area again (so it is out of range) and return. Regards Pete

Right. But all I know about the inputs is one bit -- a 0 or a 1. I don't know if it's a toggle or a button or a rotary or what, and I don't really want to have to know. So I would have to apply it as I described. It's all or nothing I fear. This is why it needs thinking through more -- i.e. what sort of adverse situations might be possible if I did this? Maybe none? Perhaps, after I come back from holiday, I will add such an option in a test version and we can play with it and see if it is any good. Anyway, it is on my list. It isn't much work I think. Regards, Pete

Yes, but watch out that you don't introduce small stutters each time you change it. The way FS2004 deals with weather is complex and each time a change is made is seems to need to re-interpolate using all the nearby weather stations -- not just three as in FS2000 and FS2002, but many! And for any weather change made through FSUIPC I currently have to give it a complete new weather structure. I would love to find a way of by-passing all that and dealing directly with the weather at the aircraft, as I did in previous versions of FS. But alas many hours of hacking got me nowhere. That was a fiddle in FSUIPC itself. You could set two wind layers, or maybe three if you need to go anti-clockwise. But experiment first in any case. I hope you don't get disappointed with the performance. Regards, Pete

No. What sorts of settings? As present all my joystick-based programming detects changes. Off to On or On to Off. It might be pretty dodgy otherwise. For instance many rotaries are alternately on and off and the state isn't clear when you leave it. Even most other implementations using switches operate like that. The Aerosoft MCP and PM, for instance, needs me to ensure all the switches are down before I enable them by pushing them up. Similarly the EFIS range and mode dials need setting. You either need to take care to switch everything off (or whatever state your startup-Flight is in FS) before closing down, or make a habit of toggling all the toggles after start-up, to initialise things to suit. Otherwise, what are you suggesting? That I treat every button is see "off" as an initial on-to-off and every one I see as "on" as an initial off-to-on? I could probably do that, maybe as an overall option. I wouldn't want it defaulting that way else there might be some surprises. Timimg is also difficult. Changing some things whilst an aircraft is being loaded can cause crashes. And what if you load a new flight, or restart a flight which has been autosaved? Should I detect the flight change and treat all the buttons as being uninitialised again? This is also possible, but is it desirable? I can add this to my list but I think it needs more thought, and it won't fit into the next version, which I am targetting for the weekend, before I go on holiday. Regards, Pete