Pete Dowson

Did you take into account that the units are different? I think the above are in degrees Rankine and Centrigrade, respectively, not Fahrenheit. Era barber pole is a limit. You won't be able to move one of those, it'll be pre-calculated. And I don't know any mechanical type of ASI which shows TAS. What you're moving is probably just a bug, a reminder. It's to save sticking little bits of paper on the dial. Pete

Ah .. with pmSystems you have to have everything else right too. Evidently you haven't. Do you have the handbook for the aircraft? That's what I use. Please post questions about pmsystems to the PM webgroup site. There are folks there who will help. it sounds like you need to learn more about the overhead. ;-) Regards, Pete

Sounds like you have something else also assigned to the mixture levers. Check the assignments in FS. Pete

No idea. Sorry, but you really do have to actually both develop AND debug your own programs. I can't do that for you too. There are enough tools around to help -- FSInterrogate to compare values with, and the full logging features in FSUIPC. Have you tried using any of those? Also, I would really have thought that Delphi came with a debugger. Doesn't it? Regards, Pete

FSUIPC doesn't have its own list (except for the special additions and the PM stuff). The main list of FS controls is grabbed directly from FS's "CONTROLS.DLL" for the drop-down. I've just checked, and there's "Trim Down" and "Trim Up" listed in the drop down -- i.e. without the "Elev" in front. Strange, I thought. So I dug into the codeand I found that the actual internal names in FS for these used to be "Numpad 7" and "Numpad 1" -- i.e. they were named after the default keys which you used for them. This must have been back in FS98 and FS2000 days. Looks like I deliberately check for the two control numbers and replace these rather inappropriate names by "Trim down" and "Trim Up". Odd no one has mentioned this before in all these years! Anyway, in the very next version of FSUIPC I will re-name them "Elev Trim Dn" and "Elev Trim Up". Okay? ;-) Thanks, Pete

Oh, right -- so it isn't that you've been USING it and had problems, you thought you were taking precautions because of some out of date information? Sorry to have misunderstood then. Good flying! Pete

The only reason that could be is that their users (including you?) are using pirated keys. The only change after 3.40 was better checks against fraudulent keys. If you have registered FSUIPC and you think you paid for it and have a genuine key, AND you are not using a version of FSUIPC older than 3.53, let me know and we'll sort it out. Otherwise, just delete your FSUIPC.KEY file and try again with version 3.70. If the authors of FSHotSFX think there is a problem after 3.40, why is it they've never ever written to me to sort it out? 3.40 was replaced 21 months ago! I'm sure that if they'd had problems for the last 21 months someone would have contacted me. :x In fact, I know for sure that it works properly with later releases, because when I changed the classification of landing AI traffic in 3.45 it affected the reverse sounds that program produced, and I changed it again for the program immediately after (by 3.47 for sure), and it worked fine again. Pete

That's because the read and write calls merely add the request to a queue in your memory. They never leave your program. Only the Process call does anything -- that takes a while because it has to get windows to switch to the FS process, pass the data built up to FSUIPC, wait for the reply, then switch back. NEVER do a Process after each read. The whole point of splitting the specification of what you want to read and write from the actual doing of it was for efficiency. You'll not only slow your program down, but you'll slow FS as well. Ideally ALL of the things you want to read and write in each cycle of your program should be built up and sent in one Process call. The cycle is best if it is timed to be either the same as one FS frame, or a multiple of it (if you don't need things so urgently). If you get, say, 20 fps consistently from FS (set the limiter to something suitable) then sending a Process every 50 mSecs (or every 100, 150 etc) is best. The only exception to saving everything up for one Process is for those cases where what you write needs to be decided upon from what you read. Then you may need to read something, do some calcs, and write something. Even then it would be more efficient to spread that over two of the above cycles, so "Read --- Write & Read --- Write & Read --- etc. Oh, there is one other exception but it isn't likely to arise. That's when the total data size adds to more than the max size for one Process call -- around 30000 bytes. Don't get anywhere near that. Pete

Yes. I have a heavy investment in PFC hardware -- I'm not about to chuck it all away, am I? ;-) Pete

Hmmm. I always thought they did nothing at all. Maybe I never tried them in FS2004. Thanks for the feedback! Pete

Unfortunately it is impossible from what you supply to actually extract what your problem really is. You don't say. The only two clues are these: and Now the latter is completely nothing to do with me. If someone else's program crashes, then it must be sorted out by the author or publisher. Nothing in any of my programs can force another to crash -- that is all within that program's control. It is an error. The former case, duplicate copies of FSUIPC running, can occur in several ways: 1. Having more than one copy of FSUIPC.DLL in the modules folder. For this to occur one of them must have been renamed. NEVER rename any of the DLLs and leave them in the Modules folder. The FSUIPC files which are found in the Modules folder should be: FSUIPC.DLL, FSUIPC.KEY, FSUIPC.INI, FSUIPC.LOG. 2. Some folks have reported that modules placed in the main FS folder also get loaded, so check there too. Personally I've never been able to verify this. 3. Some add-ons cause FS to stay running in the background even after you close it down and it looks as if it has gone completely. When this happens, and you load FS again, FSUIPC detects the other version still running and you again get the 'duplicate' error. It is impossible for FSUIPC to run twice on the same PC, because of the interface for applications. Hence the report. To check for this error, next time you get "duplicate" use the Windows task manager (Ctrl-Alt-Del) to look at the Process list (not the Applications). If there is one (or more) copies of the FS EXE (FS9.EXE for FS2004) listed, that's your problem. forcibly close it from the Task Manager and try again. In future please tell me the VERSION of FSUIPC you are using, and maybe even show me the text in the FSUIPC.LOG file. Regards, Pete

Good to hear. Thank you. Seems like Joaquim , the thread originator, must have been supplied with FliteStar 9.16 instead. Maybe a mixup at the Jeppesen end. They've got my update orders wrong on occasion. Regards, Pete

I don't know those. Are they owned by Project Magenta, pmSystems perhaps? Sorry, I don't know the term 'knitter'. Is that some sort of rotary switch? Sorry, no. Having 1 for decreasing and 2 for increasing seems very odd. If this is programmed in pmSystems, then why not re-program it to accept the values you want? Anyway, I think, if you are talking about pmSystems, you'd be better off posting your query to the PM webgroup for support. There are quite a few pmSystems experts there. Regards Pete

Hmmm. You really ought to try search on relevant keywords in the Programmer's Guide. All of the Autopilot values are together in the 07BC to 0810 area. the altitude value is called, possibly obscurely ;-) "Autopilot altitude value". A search on 'autopilot' or 'altitude' would have found it pretty quickly, but looking for any of the autopilot values would have certainly helped, them being altogether like that! :-( Pete

Does the value you write to the offset read back the same as you wrote (e.g. looking at it in FSInterrogate, or in FSUIPC's monitor)? Pete

Hmmm. That is strange. Does the change you make read back? Pete

According to my records, ActiveSky wxRE ("wxRE.exe") by HiFi Simulation Software was provided with an application Access Key for FSUIPC 3 back in June 2003. It should work as it is. You should not need to purchase any key for FSUIPC at all. Have you tried it? Why do you think you need a key? Yes, but I've got rather more doubts about CFS2 -- it should work with CFS2 -- CFS2 does have controllable weather doesn't it? I don't think CFS1 did. But the problem is that neither CFS1 nor CFS2 were ever officially supported by FSUIPC, they were just lucky by-products. Please just try it and see before spending any money on it, which I don't think you need to do in any case. Why do you want real current weather for an historical sim, BTW? Regards, Pete

It does sound like there may be some sort of spike occurring at one end of the potentiometer. Possibly a slight hardware adjustment will be necessary. I don't know. I've not heard of such a problem before. At least it isn't a flight-spoiling problem Maybe you could get some advice from Bob "Sticky" Church who's a CH joystick guru. Try http://www.ch-hangar.com. Regards Pete

You are five years behing. Is WXRE still being sold? Itwas made for FS2002. You cannot use FSUIPC 2.75 for FS2004. SimMarket do not supply FSUIPC -- you download it from http://www.schiratti.com/dowson (or from many other places). simMarket supply registration keys. If you have any problem with that please go to http://www.simmarket.com and raise a problem ticket. Yes, that was quite true several years ago. Things change. FSX is being released in a little over a month's time. FS2002 is now five years old! FSUIPC3 came out for FS2004 three years ago -- the FS2004 versions of ActiveSky work with an unregistered FSUIPC3, you don't need to pay more. Regards, Pete

I don't think Teamspeak has a direct control for PTT, so you'll just have to program your button to send F12. Please refer to the section in the User Guide on programming Buttons. It's easy enough through the Buttons tab in FSUIPC options. Pete

Those are gauge variable names, nothing to do with FSUIPC offsets. Yes, all the fuel management programs around, including the freeware fuel dumping gauge and pmSystems APU and fuel-switching mechanisms, operate by changing the levels in the relevant offsets -- see the ranges 0B74-0BA8 and 1244-1260. All in all there are up to 11 separate tanks you can alter. This has been the case since FS98 days, in FS2000, FS2002 and FS2004 (except for the extra tanks at 1244-1260 which were added at some stage). Why don't you use FSInterrogate to find all this stuff out? That's what it is for. You can read values, see how they are computed, and write back values to see what happens. This is why it is provided in the SDK! Pete

Yes, it does actually say in the documentation (in the Registration part of FSUIPC's user guide) that your identification details need to be the same for both parts. Sorry.. SimMarket should be able to help, but otherwise I can arrange for an updated FSUIPC key for you. You will have to find the emails from SimMarket for both the WideFS and FSUIPC registrations and send them to me at petedowson@btconnect.com. Regards, Pete

Thanks. Obviously FSUIPC cannot guess whether the inputs it is seeing are reversed or not. You always need to set the Maximum higher than the Minimum. Then it will smoothly spread the needed range between. If the pedals work in reverse, that is give max braking with feet off and zero braking with the toes pushed firmly down, then they are reversed and need the "REV" option checked, BEFORE calibrating. However, the gentlemen here seem to be saying their input values were normally zero with feet off, going negative when pressure in "brake-off" direction (not sure how they accomplish that, mind). This does seem to imply that they are not reversed. Maybe they aren't explaining themselves well enough. Even so, it certainly seems to be a gross misunderstanding as to what FSUIPC does. All of the test joysticks I have here give ranges from values like -16k to +16k, so if I calibrate one of those for brakes I have the minimum brake input set at something like -16000 or less, and the max at +16000 or more. If I reverse them, it still seems right if I turn the joysticks around so the back faces methat really should be flexible enough! ;-) Regards, Pete

The -7040 to +7040 are the INPUT values. You must calibrate to set the minimum and maximum positions, then FSUIPC spreads whatever you give as the input range to the range FS needs: -16384 to +16384. Indeed. Please follow the very simple numbered steps in the documentation. That is what it is provided for. :-( Pete

You also don't understand FSUIPC's facilities at all? What is wrong with the documentation -- where are you misunderstanding the calibration? Pete