Pete Dowson

The values 181 to 359 are arriving as negative numbers, which is screwing things in bytes 0 and 1 up a bit. Is this with FS2004? I'll look to see if this has changed. If so I'll see if it can be fixed. The data is actually there though, if you want to use it as it stands. ============== Frequency set on Radial 068 154397 PH029 = 068 001, 00168 [Hex 44 01, A8 00], orig val=30621 This is 168, not 68. If you are only reading the first byte you will get the units and tens only. The 3rd-4th bytes give the correct binary, the 1st and 2nd are split inot units, tens in one, hundreds and thoiusands in the other. This is for the convenience of some display systems. It is all covered in the documentation. It is going wrong for the -ve values it is receiving -- I think this must have changed in FS2004, if that is what you are using: Frequency set on Radial 247 252753 PH029 = 242 255, 65422 [Hex F2 FF, 8E FF], orig val=-20782 [0xC0D44B7FFFFFFFE5] NAV1_VOR_RADIAL This -20782 value represents -114, as in bytes 3-4 of the PH (65422 is 16-bit -114). -114 is the same as +246 (not 247). Frequency set on Radial 289 283343 PH029 = 184 000, 65464 [Hex B8 00, B8 FF], orig val=-13076 [0xC0C989FFFFFFFFDE] NAV1_VOR_RADIAL 65464 is -72 which is the same as +288, not 289. Frequency set on Radial 333 322227 PH029 = 228 000, 65508 [Hex E4 00, E4 FF], orig val=-5020 [0xC0B39BFFFFFFFFE6] NAV1_VOR_RADIAL 65508 is -28, which is the same as +332 not 333. ================= So, you see, you can derive the correct positive number. But if you'd like to wait a couple of days, I'll look to see what has changed. Derivation: if top bit of 4th byte is set, then do this: value = 360 - (256 - 3rd byte). i.e. 104 + 3rd byte. Regards, Pete

A way to stop people altering the file. Regards, Pete

A couple more questions, if you don't mind. Please, when you go into your registered FSUIPC options, does it say it is registered or unregistered? Are there just the About and Logging tabs shown, or all of them? Can you show me a complete FSUIPC.LOG of you loading FSUIPC, then closing it when it has failed to register your program. Thanks. So far, the only explanation I can come up with is that the actual DLL file, the FSUIPC.DLL, is not exactly as it was when it left here and is falling foul of some anti-tamper mechanism in the code. Either that, or the method used for this is not foolproof. But I can tell more from your answers, please. Regards, Pete

OkayI installed it. I swapped out my English "LANGUAGE.DLL" for a French one, so my FS2004 looks French, then I ran FS2004 and the Registered BN_VR with the access key above. When I ran BN_VR there was no rejection, and it is logged okay. Here's the Log with IPC logging enabled so you can see it is accessing okay: I really cannot see any way it can go wrong -- it is reading the Program's details correctly, it has the correct Key in the FSUIPC.KEY filethere is nothing else to go wrong! I'm really scratching my head over this one! :cry: If there's anything else I can think of I'll get back to you. Meanwhile, just in case they are relevant, could you email me your FSUIPC.INI, FSUIPC.KEY and FS9.CFG files -- please Zip them up and send to petedowson@btconnect.com. Oh, also tell me the exact Windows version, build, etc. Thanks. I may need you to run tests with some extra logging built in, to try to get to the bottom of this. Pete

The switch on the panel and the controls/offsets do the same thing. As to what that is I am not sure, you have to experiment. Try the panel switch anyway, see what it does. You can set the same things by control or by offset -- you can see the switch change to match. Whether it does what you want I have no idea. Sorry. Pete

Hey, thanks! Can I pinch some of this for my Announcements, and maybe my documentation? Didn't those changes hit your frame rates in FS rather hard? I think disabling AGP really knocks mine for six. Hmmm. Well, that, then, would be a brilliant solution! I wonder if that'll work for others. Thanks again! Pete

There are tank selectors, though not actually connected up in the default cockpit. Some of the add-ons are better in this respect. The crossfeed switch at the top in the default 737 acts in both capacities I think. Try it and see. No, some aircraft (mostly GA aircraft) do have switchable electrical fuel pumps. These are often needed in low-wing aircraft, and aerobatic aircraft where gravity feed cannot be relied upon. If you have a fuel pressure gauge it would show an increase in fuel pressure when you switch the pump on. None of this applies to the default 737 though. I don't think you can switch the pumps off -- try it though, if you are curious! No. If you go thorugh severe icing in clouds you may well find your performance falls, and (in FS2004) even your ASI may fail (despite pitot heat -- this is maybe not so realistic). In such cases Anti-Ice is the solution. The "De-Ice" switch in the cockpit operates all the separate anti-ice switches for you. Try it and see? Regards, Pete

Play, that may be significant. I will check here. I have a French "Language.DLL2, which hopefully is the only significant difference. Normally this will be because the DLL itself has been tampered with -- there are anti-piracy measures to detect this. However, since you only show part of the log I cannot tell that this is the case. As this seems very unlikely, I will assume not and look for something associated with the French version of FSUIPC. I take it that the Windows is French too? That may be a problem I don't have one of those. Is it easy to install? I don't want anything permanent, I just want to reproduce your problem. I am currently holding up the release of 3.08 until it is resolved. Regards, Pete

I don't see how. I don't understand this at all I'm afraid. It works well here, on FS2002 and FS2004 on two different systems. The "blunder" I made in 2.12 was certainly reversed in 2.122. First I need to reproduce the problem -- but how? Which version of FS2002 are you using? English language? Which Windows? :cry: Pete

In that case it sounds like the one you are using is 2.12 or 2.121, as those problems were certainly present then and in fact were the reason for releasing 2.122. Here's the relevant extract from the notes in the "recent versions" announcement above: So, please double-check the version you have -- right click on the DLL and select Properties - Version. Regards, Pete

You have to lock it or dock it. It will never stay enabled otherwise. what was your previous version of AdvDisplay? There's been no change in that for a long time. There should be an Advdisplay.INI file in the Modules folder. that's been created for many versions, certainly since the position locking was implemented. It's the only way it can remember the locked state and position. If it isn't docking then it isn't finding a panel part to dock onto. Or maybe you docked onto a panel part you don't normally have showing -- because of the changes I had to make to stop flashing and to give more consistent results. When you checked the PANEL.CFG you should have seen the name of the panel part it thinks it is docked to -- for example in this entry: [AdvDisplay] Window=1619,398,265,97,1,1 Font=Courier New,-13,0,700,0,0,0 HideWindow=No AutoHide=No AlsoATIS=Yes MultiLineOnly=No Scroll=Normal PanelPart=Overhead Panel the window is docked to "Overhead Panel". this means that it only appears on screen when that panel part does. The names of the panel parts are near the top of the PANEL.CFG file, like this: [Window Titles] window00=Main Panel window01=Radio Stack window02=Throttle Quadrant Window03=Weather window04=Overhead Panel Window05=GPS window06=Compass You can change the assignment yourself if it is not correct. AdvDisplay does not choose the panel correctly all the time -- it depends upon the order in which FS draws them. the position of the window itself is now fixed independently of the panel part to which it is "docked". All this stuff is described, perhaps too briefly, in the doc. Regards, Pete

I assume you are talking about EPICINFO? You don't actualy say. I'm sorry, but I don't use it any more so cannot really check what you are saying. But it has not been changed in years, and certainly the correct radial was always shown on my KR1 back when I used it. Can you use the logging facilities, please? That's what they are for. If you cannot understand the logging just send it to me and I'll check it for you. Regards, Pete

There's really no change between 3.06 and 3.07 in any area anywhere near the Key validation part, and your keys are not time limited so they will not expire. I don't understand why they should start failing nowthat is very odd. I would like to be able to test here, so maybe you can email the programs (ZIPPed please) to petedowson@btconnect.com? Thanks. There's something up your wend then, as it is always live and I've been receiving and sending a steady stream of messages constantly. I really do need you to get that to work. Regards, Pete

The scaling facilities only apply to the FS Token Variables, because they have to be converted in any case -- FS supplies them as 8-byte floating point values, and just taking the integer part or whatever is generally useless. When you access FSUIPC data directly, you are mostly on your own. You are generally reading 1, 2, 3, or 4 bytes of raw data, which could mean or represent anything. They are not even necessarily numeric. You have to do whatever manipulation you want in your EPL code. The exception to this is, of course, when you specify "F" or "D" types, for the 4- and 8-byte floating point values. Since EPL cannot handle floating point, EPICINFO does it for you -- there you can provide a multiplier, as documented, so enabling you to avoid losing fractions. That's as much scaling as you get from EPICINFO. Regards, Pete

It sounds like the previous copy of the DLL you had got corrupted. I could probably have deduced that from the Log and so on, and suggested you re-download, but there's no need now. :) I'm working on 3.08 at present, along with the SDK, and hope to release both within the next couple of days. Regards, Pete

Where did you enter the Key? Did you also enter your name and email address? Are they showing in the Registration dialogue? Except for a brief problem with accented characters way back in version 3.00 in August, and the early difficulty with Windows XP/2000 (where registration needs Admin rights), now notified correctly, every problem with registration so far has turned out to be incorrect entry of the details. Your name, email address and KEY must all be exactly correct, and as included in the email you got from SimMarket. If you believe you have entered them correctly, please send me a copy of the original email, plus the FSUIPC Log and Key files, ZIPPED, to petedowson@btconnect.com, and I'll check them out. That isn't an FSUIPC function. sounds like you have the power off or flat batteries. Whether FSUIPC is registered or not would make no difference, unless you get it registered correctly and use the "magic battery" facility to extend the battery life. Regards, Pete

I've not really got time to chase other threads. If I started doing that I'd get nowhere! I'm sure if anyone has anything important to ask or tell me they'd do it to here, otherwise it cannot be all that important. Very small occasional stutters are almost inevitable if there are any weather changes through the only interface I have for them. This is particularly noticeable if the 3D clouds are not set to 100%, as I note in my documentation, but they are substantially reduced with the latest weather updating facilities I provided and which are starting to be used in the weather programs. If default weather is used (no outside weather program), and the FSUIPC option to change FS weather is not checked, then FSUIPC is really doing very little except responding to external programs on request. Regards, Pete

Well you can use the FS2002 published lists for now. I'll make a new one as soon as I have the SDK done -- later this week maybe. Regards, Pete

Well, not necessarily. Yes if you want to use the facilities without paying, no if you see in any of the release details (which will be posted in the Announcements here) anything you want or need which may be added in Version 3, as time goes by. Regards, Pete

No. (A quick answer! :D ) Pete

Those facilities were added to deal with bugs in certain FS panels which were actually occasionally sending FS controls with full deflections. They so-called "spikes" are not transients in hardware, but single absolute maximum values being set by software. The elimination merely ignores any maximum values, and should ideally be used with calibration in FSUIPC, which sets the maximum to one less than the true possible maximum. This sort of spiking is very difficult to eliminate by software without destroying responsiveness. I have put some smoothing into the PFC driver, mainly to help a user in Myanmar with dreadful power supplies. But really the answer is to clean the pots or replace them, and to make sure that the power supply is good and that nothing is interfering with the drivers. I am surprised you have any trouble with USB devices which should be relatively immune, but it was always a problem with game ports used on sound cards -- the two functions often didn't live well together. I really think you should seek the advice of your supplier, who may well suggest replacement pots or some cleaning operation. There's are sprays which may help. Regards, Pete

It's just one view. The Parhelia surround mode works by making the 3 screens one wide window. That's why I quote the overall resolutions, like 2400 x 600 or 3840 x 1024. The view is just one view, which will be normally the forward view. But it is at Zoom 0.50, so you effectively get most of what on a 4:3 screen would be forward left and forward right as well. When I use a views button to look around, all three screens change, of course (it is one window), so when I look forward left I get some of which I already saw, but now on the right, and so on. Some Parhelia users have their zoom set as wide as 0.31, but I find that rather unnatural from where I sit, and you start getting a marked "fish eye" distortion at the edges then, which I don't like. It used to work on FS2000 as I had stuff like that saved when I used to use WidevieW. But I don't know if it applies now. I suppose it should. Try it. Yes, I would say so. But there are some panels where this may not be so true! :) No, but WideFS won't allow you to move FS panels. You'll need to look at Project Magenta or FreeFDS or some other type of external panel applications. FS panels need FS. WidevieW might let you when it is available, but with multiple copies of FS you really start needing similarly spec'd machines. Regards, Pete

Rightwith the further information you gave me I was able to reproduce this problem. It is a timing thing. What happens is that the "AlsoSave" file is getting saved immediately AutoSave is loaded. This is before any flight is actually loaded by FS, so the FLT file is bereft of important data, like aircraft, position, and so on -- everything in fact. FS then tries to load the default flight, which is this "empty" one just saved! That's what is giving your error. It only occurs with the AlsoSave method, which is why probably hardly any one else would notice. As to why it occurs with recent versions but not with 1.40 I can't say - I cannot see any code I've changed there, but maybe AutoSave starts off a bit earlier than it used to, for some reason. Ah, yesI think it might be because I made it independent of FSUIPC sometime recently! Before that it would probably have waited till FSUIPC was ready, and that was deliberately delayed by a few seconds. Anyway, the solution was to change the method of timing for the AlsoSave files, and make them only save AFTER the first interval -- which in your case would be 5 minutes. Try the attached version 1.491. It seems to work fine here, with your CFG file too. It's a bit of a shame I hadn't known about this a few days ago. I don't really want to make yet another release -- that would be three in a week. :( Ah well ... Thanks & Regards, Pete AutoSave1491.zip

I missed this in your original. The advantage is that FSUIPC 3 is supported and developed. As and when new facilities are added, if any are applicable to FS2002 (and undoubtedly some will be) they will be added to version 3, not 2. If any bugs are found they will be fixed in 3, not 2, and so on. Otherwise, at present there are no significant differences for FS2002. There are a few additional values mapped for applications -- one immediate example is in 3.08, to be released this week, where the Tail Hook position is now mapped for both FS2002 and FS2004. This would be useful for cable arrestor programs. There are others. But at present, no, there are no additional user facilities for FS2002. Regards, Pete

Ah, so AutoSave is not causing the crash -- the file which it gets FS to save is not liked by FS when re-loaded!? That is totally weird. AutoSave doesn't save the files. It merely calls upon the FS routine to do this. If this cal is resluting in a z.FLT files, then that must surely be the correct one. Okay, then what it needed is to find out what the difference is between the z.FLT saved by 1.49 and the one saved by 1.40 -- they are both saved by FS so they should both be okay. Can you load the flight saved as z.FLT, via the Flights menu? If so, then it is correctly saved. In that case I can only think it is some sort of timing problem. Perhaps the first "save" attempt made by AutoSave when you load FS is a bit earlier, and this is causing a problem? No. Please don't. FSUIPC won't make any difference in any case. Now that you've explained that the loading failure occurs when loading, and not when autosave is saving (which was my big puzzle with your first message), all we need to do is find out (a) whether the z.FLT file saved by 1.49 is okay -- i.e. will it load, and (b) if so, why won't it load initially? Is it maybe a timing matter. Please try loading a z flight explicitly. If it loads, then it is not (a). You could actually run version 1.40 to generate your z Flight. Then close FS down, install 1.49, then run FS. If it fails then, it must be something to do with a small difference in timing -- maybe AutoSave is saving when FS wants to load the same flight. I would need to check -- it probably shouldn't save for 5 minutes. Regards, Pete