Pete Dowson

You can read what you like. The memory map imaging provided by the interface is complete. It does work like memory, at least for reading. Writing is also usually the same, but not always, so needs more care. Pete

Okay, I found how to do that, and some other things. In the next version of FSUIPC there will be several new "FS" controls listed in the drop-downs for Keys and Buttons programming: Traffic labels toggle Traffic labels off Traffic labels on Traffic labels set The last one allows you to have buttons or keys to change the label details shown (if the labels are on), There are 12 options and they use one bit each, as follows ((bit 0 = lowest bit, worth 1): 0 Manufacturer 1 Model 2 Tail # 3 Distance 4 Altitude 5 Airspeed 6 Heading 7 Airline 8 Airline + flight # 9 Route 10 Ref # (as in TrafficLook) 11 Multiplayer name (for MP mode only) Al this is only for FS2004, although the commands can be asigned for FS2002 they won't do anything. Regards, Pete

If the panel accepts keyboard shortcuts for these, then you can program joystick buttons to operate the keystrokes in FSUIPC's Buttons page. If the panel only accepts mouse clicks then you need something like Luciano Napolitano's KEY2MOUSE utility. http://www.wideview.it/key2mouse.htm. Regards Pete

If it accepts keystrokes for these selections then you can program "KeySend" parameters in FSUIPC on the Server, in either the Keys or Buttons pages, and edit the WideClient.ini file on the Client PC to send the appropriate keystrokes direct to SB upon receiving the appropriately numbered KeySend commands. If you make WideClient load SB in the first place (and close it on terminating), then the keystrokes can be directed easily. Otherwise it can get messy using Class Names and so on to hit the correct window. Hopefully the next version of SB will use mappings into FSUIPC offset space for such things. Then it gets a bit easier. Regards, Pete

That surely cannot be so with any individual options. They all do different things. The ones that may do things like that are "Enable V/S sign correction" and "Reverse the elevator trim sense" on the Technical page. Don't enable either of those when using any non-default autopilot. Regards, Pete

What about the King Air? That was in FS2002 as well. Hang on, let me find an FS2002 and check that ... [later] Hmmm -- it is different. The N1/N2 values for the King Air in FS2002 do seem to be similar to the jet N1/N2 values. They've changed something in the turbo stuff between FS2002 and FS2004. On the King Air panel there are two RPM values for each engine -- a prop RPM and what I presume is a turbine RPM. However, even applying the scaler to the N1 values doesn't produce either. I assume you have to know the max RPM rating for the turbine and calculate using the N1% for a turbine RPM gauge. I don't know where the prop RPM comes from in FS2002. In FS2004 the same two gauges read similarly, but the N1 value gives the correct Prop RPM when scaled. I can't see what gives the turbine RPM. I'm afraid I'm a bit lost here. We need an aircraft/panel designer who understands these things to chip in and see if it can be clarified. Maybe the turbo gauges do their own calculations using these input figures, and knowing the specific aircraft. Regards, Pete

Eryou missed out "then dividing by 65536". Makes quite a bit of difference! FSInterrogate only interprets the N1%, it doesn't take the scaler into account. This is okay for Jets, where the % is all that is needed. 10189 is 62.2% of 16384, the max value for that offset. You can see the calculation FSInterrogate uses and work that out for yourself. The scaler is a positive number, always. It varies from aircraft to aircraft. For example, for the default FS2004 Cessna 172, and the Baron, it is 10800. For the Caravan it is 928. These give correct RPM values. However, I just checked the default King Air and it is giving 54144, which is interesting! However, I still get the correct results -- N1 gives 1471 when the RPM on the FS panel shows just over 1200: 1471 x 54144 / 65536 = 1215. I don't know what aircraft you are trying this with, but it sounds as if it may be a jet model pretending to be a turbo and not doing a good job of it. Is it one from FS2000 or FS98 perhaps? I don't think the turbo model goes back a long way in FS history so folks use to fiddle things. Check it out with the default FS aircraft. Then check the model you are using. Okay? Regards, Pete

Please call me Pete. The only FS software I've written which uses COM ports is the PFC driver, for PFC equipment, and GPSout to connect to moving map software. I have written no drivers at all for other hardware connecting to COM ports or USB. The makers do their own. Pete

Without any logs I cannot really comment on this. Can you discuss it with Damian, the ActiveSky author? I'm sure he will mention things to me if there's anything odd. Really the option will do nothing if the dynamics slider is already zero. And there are many other weather programs than ActiveSky I need to consider here. What "earlier" versions, please? I've not changed any of the weather handling for a LONG time. It would be helpful to know when you think this changed. Okay, thanks. Pete

Sorry, I don't know any Embraer panel. If they have their own autopilot then you must ask them how to operate it. If it uses the standard autopilot, like most add-on aircraft, then all the facilities you need are already implemented. Similarly for trim. As for "buttons of screen navigation", sorry, I don't know what you mean. Regards, Pete

Yes, indeed it is "create" -- YOU need to create it. You need to work out the CFG file for what YOU want to do, to suit your EPL program. I only give examples in the documentation. The one you quote above looks like an example. I cannot design your project for you. It is specific to each implementation. Er, F9? What's that? You need to write the EPL code to do what you want to do with the EPIC. I cannot help you there, you need to study the EPIC documents and get help if needed from the EPIC folks. Most certainly, after you have written your EPL program you must compile it before to load it into the EPIC. The EPIC doesn't not read source EPL! You seem to be very confused here. You are mising up buttons with EPICINFO's indications and values being SENT to the EPIC. The PHs (Pigeon holes) and QPs (QProcs) are things SENT to the EPIC for you to program from, for instance to make displays, indicators and so on. This is what EPICINFO is all about. When you've written your Epic program and compiled and and got it working, then you'll know what PHs and QPs are. It looks to me like you need help in understanding the EPIC from the EPIC folks. I've not done any EPIC programming for a long time now, and then it was different (ISA EPIC, not UB, and no Epicentre program). Regards, Pete

1.92 suffers from trying to control the global weather, which becomes not so after a little while. See the comments about this near the top of this forum, and in the FSUIPC documentation. AS2004 set weather at weather stations. The weather at those stations does get set and is reported in their ATIS. All that option does is set the dynamics slider to 0 when the Clear Weather command is used either by an outside program, or by using the FSUIPC button or hotkey. I know WxRe 1.92 uses Clear Weather, but I don't think AS2004 does. The "clear weather call" from where? Where are you seeing such a call? And how does it stop writing? You have me rather bemused. Have you been analysing FSUIPC weather logs? Regards, Pete

Not sure FSUIPC is the best place to do this -- you can assign an axis to the spoiler in FS's own assignments. Are you testing all this on the ground, before takeoff? If so, don't. Get airborne. What happens is that when operating the spoiler lever you are passing through and setting the "ARM" facility. Arming the spoilers is supposed to be done in the air so that on touch-down you get them deploying to 100% automatically. Unfortunately, in FS2004 all the time, and also sometimes in FS2002, if you are already on the ground this action will occur immediately! Get airborne and check them out there. If you like, calibrate them in FSUIPC whilst in the air. Incidentally, the normal maximum spoiler setting used as speed brake would be something like 60-75% ("flight detente"). the 100% is there to spoil lift really thoroughly and is the "ground detente". Regards, Pete

Yes, sorry. I discovered this two days ago and I am fixing it now. It only applies since 3.14, but it is annoying. The only way around it at present is to correct the INI file BEFORE re-loading FS, after any Key re-programming. The error in 3.14 is the inclusion of the extra comma. If that is removed BEFORE reloading FS then all is well. However, if you don't, then edit the keys again, the lines are made even worse, and so on ... The reason for this is that FSUIPC is reading: ,,65913,0 as ,0,65913 (the omission of a number looks the same as a 0). So when it gets written back it LOOKs like it has the control and parameter reversed. In fact it is not the parameter 0, but another 0. If you want a fix urgently then email me at petedowson@btconnect.com and I will send you the fixed interim version (it is a little too big to upload here). Otherwise it will be fixed in the next release, probably middle or end of next week (there are some other things to test and document too). Apologies for the inconvenience! Regards, Pete

Not sure I know how to do that, but I'll have a look. Pete

Hi. My name is actually "Dowson", but lot's of people make that mistake. Yes, the current version of EPICINFO.DLL works okay with the USB Epic. It uses the EpicIO.DLL which should go into your Windows/System32 folder. Welll, install Fs first, and test it, make sure everything works okay. Then, as documented, put EPICINFO.DLL and FSUIPC.DLL into the FS Modules folder. Program EPICINFO by making an EPICINFO.CFG and put it in the FS main folder. The EPICIO.DLL goes into a Windows folder -- Windows, or Windows/System32 will do. Run FS2002 after you've installed all that. Regards, Pete

Well one of my internal test increments since then was 3.142, which is much closer to PI, so it gets the title. Didn't last long though -- up to 3.148 here already. :) No one asked for my 2.718 release of many moons ago to be called "e". Maybe I should make an imaginary release called "i" next? :D Regards, Pete

Both of those errors are simply my program reporting what Windows tells it. That's absolutely all I know. Something is evidently wrong with the network, but I don't know what. If I had that happening I'd have to start on a long process of elimination, trying everything, including swapping/replacing LAN cards, cables, by-passing switches or hubs, and so on, till I found what was doing it. And re-installing drivers, Windows, removing possible interfering programs like ZoneAlarm or other firewalls, etc. Sorry I can't be more specific. Just about all I know is written in the WideFS documentation -- in fact I don't know all of that, much is contributed by the experience of others. With that in mind can you please keep us abreast of what you try and what the results are? Maybe we will all learn. BTW maybe your WideServer LOG has something interesting in it too? Are you using IPX/SPX or TCP/IP? Katy Pluta, who can be contacted in the FS2004 forum here, knows a fair bit about Networks and may be able to help. Regards, Pete

HmmmI was 18 months younger then! :) . Ah, the good old days! Thanks & Regards, Pete

I saw it and, and basically agree with one of the responses you got. Apart from the first reading (which was probably taken before the FS weather had been fully settled), the others are probably where FS is getting readings from WX stations as you fly. Looks like you were flying in an area where there are many stations. I don't think all the WX station weather downloaded by FS are always for the same time-of-day, so there might even be more variation than in reality. When flying through areas of changing pressure below TA (Transition Altitude) you do have to keep adjusting your altimeter if you want to keep accurately level, though whether ATC would be giving you such calls is another matter. Probably in real life it would only do so when descending towards the transition level after flying Flight Levels, and in the approach or landing instructions. You'd be responsible yourself to tune into ATIS's en route to get interim pressure readings. You also wouldn't get told off for minor variations in actual altitude caused by minor changes in pressure. I think RC has a parameter for how accuratey ou want ATC to check this. Of course in FS you can "cheat" and simply regularly press the "B" key to correct your altimeter. Flying in the US or Canada in a light aircraft you are always below the TA (18,000 feet) and so this is a constant problem with real weather patterns. Elsewhere the TA is likely to be much lower and it is less of a problem -- e.g. here, near EGCC, it is 5000 feet. Above that, using Flight Levels, you simply set the altimeter to 29.92 (1013 here) and keep to the assigned altitude with ease. There has been a lot of discussion about pressure calls from RC in the Beta group. I don't remember what if anything has been changed, but you could pose your questions over in the RC forum or Newsgroup or whatever. Regards, Pete

When you register FSUIPC and/or WideFS as a user, it is yours, to use as you like. It can go on a roomful of PCs if you like, provided they are all yours (or your live-in family's :wink: ). I don't like the one-license one-PC system. Anyway from what you describe above you only have one machine actually running FS in any case, so it would only be one FSUIPC and one WideServer wouldn't it? You can have as many WideClient's knocking about as you like anyway. Regards, Pete

Well, except that my attempts to provide the keystrokes for Ctrl + ; all came out as a face (Ctrl+;)), thanks! :D Pete

It is not compatible. I'm pretty sure that the protocol supported for FS and X-plane wasn't even thought of 5-7 years ago. I think the controller board is completely different as well. Sorry, I don't think you have a chance without some serious upgrading. But don't take my word for it. Contact PFC and ask. http://www.flypfc.com. Regards, Pete

Yes, of course. Don't select it then. :wink: I cannot reproduce this here with default weather settings in FSUIPC, but with any of the weather options selected, you would need to reload the current flight (Ctrl+;) or load a new one in order to reset the weather engine -- I think it is probably still assuming something has changed it outside the current "theme" -- which it has, actually. You don't need (or want) to select the "Allow Changes" option just to use an outside weather source -- that only affects FS's own "global" weather in any case, which won't apply if you use an outside source. You don't need to restart FS, only reload the flight (Ctrl+;) or select a new one. By the way, exactly the same consideration applies to FS itself, without FSUIPC. If you go into the weather menu and select "user defined weather", then "customize weather" and go and change something, you then cannot select a Theme until you reset or reload a flight. In other words it is a function of how the themes work in FS -- you either have themes or you don't. If you do but then change something, the weather engine cannot continue the theme operation until it is reset. I think only loading a flight resets it. Regards, Pete

The weather will ALWAYS default to user defined if you tick the "allow changes". Otherwise it will only do this if you have something else manipulating the weather through FSUIPC. If unticking that option doesn't help then something else is doing it. If you wish to make sure that all the other options in FSUIPC are defaulted, either delete your FSUIPC INI file before loading FS, or pressing one of the buttons on the About page in the options. Regards, Pete