Pete Dowson

In that case you aren't using the altitude hold option and therefore the FS AP won't use the altitude value you've entered. I've implemented several hardware-operated versions of FLCH and ALT HOLD and both use the FS A/P exlusively. I've never found any need to invent a different altitude location for anything. Not sure about FS's attitude hold, but the V/S hold is not connected inside FS at all. The control simply does nothing. I have implemented pitch and bank holds in FSUIPC (documented in the latest FSUIPC SDK). There's also a speed and mach hold, but those still need some tuning. They implement a complete A/P, not just make a separate copy of the Altitude value. It is only this odd thing which I don't understand. Sorry. There again, from inside the cockpit you cannot see either rudder or nose wheel in any case. The only difference between tiller and rudder is the effective steering angle. So, for the PFC Jet Cockpit, which does have a tiller, I simply implemented a more "forceful" rudder input at low speeds on the ground. As speed increases the tiller becomes less effective and the rudder becomes more effective. You can get quite good results that way. I am not trying to discourage you from doing whatever you think is best, I just think that maybe you've not considered all the options, yet. Regards, Pete

I think it is better for the programmer to design the program and derive the data needs from that. You specify the sort of information your need, he designs the code and therefore knows that data space requirements. Besides I don't deal in bits. The altitude will be 2 bytes -- a 16 bit word. As for 60 indicators -- what have you got there? Some sort of decorative cockpit illuminations? :) . Even so, that's only 10 bytes altogether. But it's your programmer who needs to determine this. BTW, if this panel is not using the FS A/P to climb or descend to a selected altitude, why not have the altitude written to the normal place for the FS AP Altitude? It will only be used if the FS ALT Hold flag is set and the FS A/P is on. Regards, Pete

that wasn't the question. Are you the ONLY user of Espen's panel? He is writing this panel especially for you, and no one else? Ah, just one gauge, not a whole panel? Okay. Even so, it seems to me to be a shame to re-use already allocated areas and therefore possibly cause conflicts in future. If the number of bytes required is kept small I don't mind allocating them especially. There is no change to FSUIPC needed for me to allocate an area and reserve it for a specific purpose. Do not worry about that. Regards, Pete

Ha, so "Espens" is a person, not an aircraft? Sorry, I didn't read it so. Okay, so Espen need to work out exactly how he is going to supply this information and therefore how many bytes in total he needs. Then he can write to me and I will find the offsets for him to write to. He will of course need to interface to FSUIPC and therefore he will need the FSUIPC SDK. No, that really is not a good idea, unless Espen's aircraft is ONLY ever used by you and will never be released to anybody else. It seems to me that the programmer should contact me directly, or are you his translator? He needs the complete FSUIPC SDK. In particular he must use the Module User's interface, for which a library is provided. Pete

The FS autopilot altitude value is already readable in FSUIPC. If you are talking about a different value, from the panel, who is going to change the panel programming to put the value some place you can read it? This is really the question. There are some terminology problems here. 3 bits can only accommodate values from 0 to 7. You mean three decimal digits, 000-999. You could accommodate those in two bytes using BCD (Binary Coded Decimal), but little works in decimal insternally -- it would more likely be a binary value in a 16 bit word. And, I ask, who is going to set these for you to read? I have no idea how the offset zone for PM is managed or what it does, however I will check their site to see if maybe it could be usefull. If so, there is no need for you to create an extra zone. Maybe you can tell me already before I finish the PM info if it could be used for passing those kind of data out of FS. (no write, just read!) There is absolutely no use in having a location which is "read only" with nothing being written to it! Please think this through a bit further. Just what is writing these values to whatever locations we agree upon so you can read them? This was the main thrust of my last message, where I was asking what is talking to what -- you've now said what is reading the stuff, but not what is writing it! Regards, Pete

Yes. There are actually two areas. And they are not used just for PM talking to itself, they are used for external control and information too. This is why PM publish the details on their documentation page. FSUIPC makes use of these areas to provide the special "PM" controls in its Keys and Buttons programming pages. Possibly. For what project? .... what talking to what? But to get details from a third party panel into FSUIPC offsets and vice versa will need programming in that panel. So, are you the panel maker? PM uses them for their documentated purposes. How would you propose to use them? If you are a programmer and need to get stuff from your programmed panel to somewhere else, or vice versa, there are a number of ways you could probably do it. The 767PIC implementation, for instance, did it by having an interface DLL. I think PMDG are contemplating something similar. The advantage of using FSUIPC offsets is that you can network things via WideFS then, and program Buttons and Keys using FSUIPC instead of having to support both in your panel. Regards, Pete

Yes. There are actually two areas. And they are not used just for PM talking to itself, they are used for external control and information too. This is why Pm publish the details on their documentation page. FSUIPC makes use of these areas to provide tne special "PM" controls in its Keys and Buttons programming pages. Possibly. For what project? .... what talking to what? But to get details from a third party panel into FSUIPC offsets and vice versa will need programming in that panel. Pr are you the panel maker? Pm uses them for their documentated purposes. How would you propose to use them? If you are a programmer and need to get stuff from your programmed panel to somewhere else, or vice versa, there are a number of ways you could probably do it. The 767PIC implementation, for instance, did it by having an interface DLL. I think PMDG are contemplating something similar. The advantage of using FSUIPC offsets is that you can network things via WideFS then, and program Buttons and Keys using FSUIPC instead of having to support both in you panel. Regards, Pete

Well, for full documentation on such offsets you would need the Programmer's Guide from the FSUIPC SDK. You might find that useful in any case -- the Keys and Buttons programming facilities in FSUIPC options both include many Offset value setting/clearing/toggling controls, and these can be used to do almost anything through the FSUIPC offsets without actually writing a program. In terms of what you want to do, using one bit on one of the bytes in the Virtual Button offsets I mentioned actually simplifies things quite a bit, as now you can TOGGLE a bit each time the Key is pressed -- in other words you can make the Key Press look like a latching toggle switch just by programming it to toggle a bit. Once you've done that, programming the button "Press" to switch TCAS on, and the "Release" to switch TCAS off is easy, and you don't need conditional programming, flags, or any editing in the FSUIPC.INI file at all! By all means get back to me if you are still puzzled. Regards, Pete

Hmmm. Doesn't the encoder come with any software for programming it? Or is it just a plain "you get one code per key" option? Sorry, I haven't provided conditionals for keypresses. Yes, of course -- you can use it to toggle a bit in the virtual buttons offsets of FSUIPC. This is an area from offset 3340-3363 where each bit is a "virtual button", which can then be recognised in the Buttons programming section. Regards, Pete

Did you see this paragraph in the WideFS documentation? In other words, whilst I'm not sure why it is happening, it won't do any harm, and after a period the number of connections shown by the Server should correct itself. (The most likely reason for it occurring is that FS itself is very busy and prevents WideServer sending stuff to the client for more than two seconds or so). If you are having problems, this is a different matter of course. Regards, Pete

No, 99% of the use of FSUIPC facilities is from external programs -- EXEs on the same PC, or via WideFS. It would work from a DLL though, as they won't unload when you load a flight. Regards, Pete

That's out of date. 3.30 is current. Yes, it is conditional. Just make it conditional on the Flag for the same button (assuming the button is recognised on a Joystick number from 0 to 15 -- I only provide flags for those -- else it is more complicated). The example is the Advanced User's Guide is for the case where your button is NOT in the Joystick range 0-15: However, if your button is on joystick 0-15 the Flag is toggled automatically each time that button is pressed, so you simply have two entries, one conditional on the Flag being set and the other on the Flag being clear. e.g. assuming your button is J1, B5: 1=CP(F-1,5)1,5,C2999,51 ;TCAS Alt 2=CP(F+1,5)1,5,C2999,50 ;TCAS Off Regards, Pete

Yes, exactly. When you load a Flight it also unloads the current aircraft panel (including all the Gauges) and loads the aircraft and panel specified in the flight file. You are trying to load a flight from a gauge which will, by the time the flight is loaded, simply not be there -- FS returns to the place where your gauge used to bebang, crash! Regards, Pete

Strange! I'd report that to Goflight if I were you. Maybe it's a known defect easy to fix, but whatever, they ought to know about the ways their hardware can go wrong. Good flying! Pete

Ah, sorry, didn't read carefully enough. I'll go try it in the Learjet. [Later] They work perfectly in the Learjet too. Please try some other buttons too. It seems most odd. Are you sure the RP48 is not also programmed in the GoFlight driver and maybe there are conflicting controls? Also can you remind me what version of FSUIPC you are using please? If it is 3.30 or later you can get some more information as follows: Edit the FSUIPC.INI file and add the lines Debug=Please LogExtras=2 into the [General] section. (Replace the LogExtras line if there's one there already). Then, when you press the buttons/turn the knobs you'll get entries in the log like this (the important bits are "FS Control Sent". The lines with bRes=2 are Press, bRes=1 Release -- it'll be a little different with GoFlight I expect. sorry, my GoFlight stuff isn't connected at present): 71704 [DNSCAN] J0.1, B2, bRes=2, Flags=01, ulValue=65896[0x00010168], lParam=0, TimeNow=20868625, TimeLast=0 71704 FS Control Sent: Ctrl=65896, Param=0 71985 [DNSCAN] J0.1, B2, bRes=1, Flags=01, ulValue=65896[0x00010168], lParam=0, TimeNow=20868906, TimeLast=20868625 73454 [DNSCAN] J0.1, B0, bRes=2, Flags=01, ulValue=65897[0x00010169], lParam=0, TimeNow=20870375, TimeLast=20869703 73454 FS Control Sent: Ctrl=65897, Param=0 73735 [DNSCAN] J0.1, B0, bRes=1, Flags=01, ulValue=65897[0x00010169], lParam=0, TimeNow=20870656, TimeLast=20870375 82110 [DNSCAN] J0.1, B3, bRes=2, Flags=01, ulValue=1021[0x000003FD], lParam=0, TimeNow=20879031, TimeLast=20871312 82110 FSUIPC Control Action: Ctrl=1021, Param=0 82360 [DNSCAN] J0.1, B3, bRes=1, Flags=01, ulValue=1021[0x000003FD], lParam=0, TimeNow=20879281, TimeLast=20879031 83594 [DNSCAN] J0.1, B1, bRes=2, Flags=01, ulValue=1020[0x000003FC], lParam=0, TimeNow=20880515, TimeLast=20879968 83594 FSUIPC Control Action: Ctrl=1020, Param=0 83844 [DNSCAN] J0.1, B1, bRes=1, Flags=01, ulValue=1020[0x000003FC], lParam=0, TimeNow=20880765, TimeLast=20880515 Regards, Pete

Why aren't you docking the AdvDisplay window? That display is only the initial one for you to position and dock, or lock. You can associate it with any one of your many cockpit parts -- please check the documentation. As to why there's some interaction with that panel, I really don't know. Maybe the panel author is getting up to some weird or fancy tricks which gets things confused. Oh, BTW, AdvDisplay won't be "hammering" anything. It does virtually nothing except display a window. It will be some interaction with the panel which is doing the "hammering", but why it doesn't like the AdvDisplay window I can't say. Something to do with video drivers probably? If that's the PMDG display, can you tell me what you mean by "flashing between FS9 panel views, ect." and "using any panel that opens separate views, when moving that sub view ...". Does it do the same in maximised windowed mode as well as full screen mode? Do you have "render to texture" set -- that seems to be quite problematic with 2D panels. I have the PMDG stuff (though I don't use the panels normally), and I can run AdvDisplay docked, locked or undocked anywhere on the 2D panel (737-700 tested), both in Windowed mode and Full Screen mode. This is on a Matrox Parhelia video card. I see you are using pretty much the latest nVidia drivers. Have you tried some earlier ones? Sometimes the very latest aren't the best. Regards, Pete

Both AP SPD VAR DEC and FSUIPC's own added AP SPD VAR DEC FAST both work fine and consistently here. Really there's no difference to the INC versions except they call a decrementing function instead. They won't decrease below zero of course. Test them out on a default aircraft, and maybe with Key press programming first. Also try other buttons to cross-check. I assure you that the controls themselves are fine. BTW you are not programming these by hand, in the INI file, are you? There's really no need to show me the INI file bits unless you are. Best to use the FS options dialogue for simple (non-Conditional) assignments. Regards, Pete

You need to read the section in the documentation about how to buy the access key, or refer to the announcement at the top of this forum about "Paying for FSUIPC -- the Why and How". There's also a link to the registration page in SimMarket in the Schiratti download page, and in the list of supported versions above. Regards, Pete

Assuming you are on the ground at KMCO, then: 1. The direction is more or less correct. The difference between ATIS 097 (True) and WeatherSet's reading of 094 True will simply be that you are not positioned dead at the METAR station coordinates and are therefore seeing an interpolated value, influenced a little by another METAR station nearby. 2. Some of the difference between the 094 Tue and the Shift+Z 103 Magnetic is the Magnetic Variation at KMCO, which is 3 or 4 degrees I think. Not sure about the rest. The Shift+Z does give the Ambient Wind, at the aircraft, which doesn't have to be exactly whatever is predicted or measured at the Station, though it usually is pretty close. It might be worth just taking off and checking the wind off the surface. 3. The wind speed of 1 knot is coincidentally the exact speed set by FSUIPC if you've got TaxiWinds enabled, either manually or on automatic. If automatic, then this speed will change (slowly if you have wind smoothing on) to the correct speed when you take off. Regards, Pete

Normally you'd set that 'grey screen' to be minimised, or at least only showing the title bar so you can see the status. WideClient, which is what that screen represents, is the substitute for FS on that Client PC. It is providing the FSUIPC interface for your FSUIPC applications to interface to. All you need to do is, instead of running the applications on the FS PC, run them on the Client. That is what WideFS is for, as it says in the documentation. Oh dear. You cannot run FSNavigator that way. It is NOT an FSUIPC application -- it doesn't use FSUIPC at all. Not only that, it isn't even a separate program, it is an FS DLL. It can only be run in FS. It is because of early misunderstandings like this that I added the big boxed IMPORTANT NOTE near the beginning: If you want to run a map program, find one which is actually a program, and which interfaces to FSUIPC. Then just run it on the Client PC. There are no settings to try. You have it working. Now just run the applications you want to run. Regards, Pete

Where is FS2004 showing this 181/46 wind? In the Shift+Z display on screen? Try using WeatherSet2 to check weather. When you download real weather you don't just get one set of weather, you get a set for every METAR station. I should think that a 30 mile circuit in Florida will take you through several different areas, so the weather you see will be interpolated each time from a number of stations. I don't know this "ABGC " ND, but if it is written correctly and interfaces to FSUIPC to get its wind details, it should be showing the same as Shift+Z. Regards, Pete

No, sorry, thee's no way I can detect those really, let alone specify them. The way it is coded you can have one of more shift key (Ctrl, Shift or Alt) plus a normal key. Alt isn't a good idea anyway as it brings up the menu and the other key press parts are then usually lost. to make up for that, in the FSUIPC end of things, I allow TAB as a shift key. This should give you ample combinations not otherwise used. I really think you can find enough combinations of (any 1 or more of Shift, Control, Tab) + (almost any other key). Regards, Pete

They are all okay. Hmmm. It's a bit of a puzzle. This is where I would start trial-and-error. As you say, reinstall Network cards, and so on. But I don't understand why there are no error messages. I assume there are still none if you allow WideClient to run longer than the 4 seconds you showed in the first log? Pete

That shows no errors either. So, sorry, there's not a lot I can tell you. you might try running the client for a bit longer than 4 seconds of course -- terminating it so soon doesn't give it a chance. Also, check that you have not changed the Port number in either case, no have one set for TCP/IP and the other for IPX/SPX (I can check for you if you show me the INI files). But if these things are okay, or left defaulted, and you are never getting connected, then, I'm sorry, but there's no erros being reported. it is just as if they are on different Networks or something. If it was okay once then obviously you have changed something. You really do need to try to work out what it was. Regards, Pete

That was the log from the Client, and at least it got the IP address for your Server. What does the Server say? If this problem only recently started, you need to think what you changed. Did you add a firewall (eg. XP SP2) or something like that? Or a router? I see no error messages in the Client log though. However, you closed the program after less than 4 seconds, so it may simply not have had time to exchange data by then. Was FS already loaded? It may simply be waiting for FS to be loaded and ready to fly -- WideServer does not offer its services until then. Regards, Pete