Pete Dowson

I get that too sometimes. I think it is an error in FS to do with textures at certain places, in certain seasons and at certain times of the day, with some video cards and some drivers. I have some routes which I never fly at night because I get that sort of crash most of the time, half way through. Yet it is okay at night. On a different PC with a different video card it is fine, never crashes. No, I don't think it can be. That's a very popular combination and there would be reports all over the place. I did hear of a 'fix' for a seasonal texture bug which does this, but I can't locate it now. But compare results flying at night versus day, Summer versus Autumn, etc. And maybe try different video drivers, not necessarily the latest. There jolly well ought to be! Before FS2004 I've never ever seen any program crash to desktop (CTD) with no message, no dump, no trace whatsoever. I really don't know how it is possible! Even if I have one of my debugging tools running it doesn't catch it. Incredible! During the Beta testing of FS2004 there were really many of these -- hence the abbreviation "CTD" -- but they did eliminate most (evidently not all) before release. Sorry not to be of much help. Please let us know if you do find any answers. Regards, Pete

Don't "reassign" them in FS, just properly assign them as toe brakes, as they should be recognised in any case if FS recognises your pedal set --which it should. If it doesn't you may want to try deleting the FS9.CFG file and getting FS to configure itself all over again. When you've calibrated them in FS and they work okay there, if you want to refine them further, THEN go to FSUIPC. But, in fact, you said they were inoperable!!? :? If they are working fine in FS, then in FSUIPC press "SET" to start calibration. It won't intercept them unless you do that. Pete

No idea without seeing the weather actually downloaded. Bear in mind that the weather you get from downloading is complex, it includes most of the weather stations, each with their own weather. I've no idea what you mean by "haze" -- you could be experiencing clouds rather than actual visibility limits. Weather in any one place is interpolated from all the neighbouring stations. When there's a haze layer, FS puts a very thin cloud layer on top, so you see the haze when looking down. Maybe some of your experienced changes were due to this thin cloud. If you flew through a different zone with a higher haze boundary that layer would have been higher and may account for you going through it twice. If you have a registered version of FSUIPC why not try to use the recommended visibility settings there -- limits, graduation, and smoothing? Of course, if it's clouds you are seeing this won't change anything. Regards, Pete

Yes of course. Even FS out of the box supports axis-driven spoiler setting -- check FS Options-Controls-Assignments. With flaps you'll need to tell FSUIPC which axis you are "stealing" for this (it's an FSUIPC.INI parameter -- please see the Advanced User's guide for FSUIPC), assign it to that (otherwise unused axis in FS, then calibrate it in FSUIPC. For specific flap detents you will need to mark them by testing -- they will be different for different aircraft with different numbers of detentes. Regards, Pete

You surely don't need to set negative V speeds? Anyway, the MCP IAS is not a V speed but the target speed setting for the autothrottle in the MCP. And it cannot be set negative. If you are thinking more of values like the Vertical Speed, then, yes, you need negatives. EPIC doesn't support negative numbers anyway, but if the recipient, as in this case, accepts 16 bit signed numbers then you simply sent the positive equivalent -- it will look negative when it gets there. In most all computers these days negative numbers are represented by what is called "2's complement". This is basically the "NOT" (logical bit reversal) of the positive number, plus 1. For example, in 16 bits: +1 = 0000 0000 0000 0001 -1 = 1111 1111 1111 1111 +120 = 0000 0000 0111 1000 -120 = 1111 1111 1000 1000 Arithmetically you can derive the latter from the former in a 16-bit capable system (like EPIC) by neg = (65535 - pos) + 1 Note that although this looks the same as "65536 - pos" you cannot use 65536 in a 16 bit word as it needs 17 bits. However, the following MAY work: neg = 0 - pos but I'm not sure what sort of checks EPIC applies -- this would "look" negative and it may zero it. I can't remember, but I have a horrible suspicion that it does. Last time I programmed EPIC was years ago. Regards, Pete

Are you using either FS2002 or FS2004? If so, are they recognised by FS? If so, simply assign them and calibrate them in FS (Options=Controls-Assignments-Joystick Axes). You don't need FSUIPC for any of this in FS2002 or FS2004, but if FS doesn't see them nor can FSUIPC. Once you have them working in FS you can refine the calibration in FSUIPC. If you are still using FS2000 then you need to do some assignments in the FS CFG file to get FSUIPC to see them. This process is defined in the FSUIPC User Guide. BTW, I really cannot see how a change in your graphics card can have any effect whatsoever on your pedals. Weird. Regards, Pete

No idea. It probably depends how the gauge is written. I don't know much about them I'm afraid. I'm afraid that there will be milliseconds between pushing the P key and everything pausing in any case, and if you are also reading things through FSUIPC there will be milliseconds there too -- process switching (twice), message processing, and so on. And in any case, if there were a millisecond local time count, how would you know that this was being stopped at the same time as the last time your VSI adjusted itself? It might be stopping before or after that. Since the only evidence you have of a so-called "time lag" is the movement of a needle on one gauge, only (?), I can't see how you can do it programmatically at all. You'd have to use a stop watch, or if your reactions are not quick enough, make a high speed film of you pressing P and the VSI needle still moving, then count the frames on the film. I really don't see the point though, I must admit. Regards, Pete

As far as I know FS doesn't maintain any simulated time in milliseconds, sorry. Why would you want this? If you are merely needing to timestamp something, to show the order of things and time between them, try the millisecond counter in offset 3378. This is the one I use in my Log files. It shows the number of milliseconds since FSUIPC was loaded (which is a little after FS starts of course). Actually, you could work out simulated time using that value, by noting it when the simulated second changes. But you'd need to scale it by the sim rate if that ever changes, and discount time in menus, time paused, etc etc. It's pretty horrendous. FS does also maintain its own "tick count" at offset 0310, but this is approximate, is only updated every 55 mSecs or so, and would still not reflect sim rate, pausing and so on. Regards, Pete

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