Pete Dowson

Your purchase of FSUIPC covers your use of FSUIPC as much and as often as you like. It is sold to you, for your use, not to a specific computer for its use. I am not a fan of the system tying a product to a PC, which is why the Registration ties it to you instead. (But, as Jamie kindly points out, not to your friends! :wink: ). So, just install it and register it on the other PC using the same details as for the first one. It is WideServer which handles the Clients, not FSUIPC directly. And you can't have both WideClient and FS running on the same PC. On a client PC you either have WidevieW and FS running, or you have WideClient and other applications running. You can have WideServer installed in one or both FS installations. The WideClient PCs know which one to send and receive data from by the "ServerName" (or IP address) for TCP/IP, or "ServerNode" for IPX/SPX, which are parameters in the INI file. But if you do want two or more separate WideFS setups running, you should also change the Port numbers in one of them. Choose a number greater than the default -- the one's just under are used by WidevieW I think. Regards, Pete

I see. But if it does this through emulating buttonpressing or keys then those can be transmitted to FS through WideFS as well. But it is of no matter ... Yes, All current registrations apply to all version 3.xxx copies of FSUIPC. All I have at present is an interim version (3.205) with some changes, but no documentation updates. It is on its way to you. Regards, Pete

Ah, I'm not sure how many of the frills work in the demo. You'll need to check with PM. Also, I don't know much about the Airbus versions of these things, but the FCU is the equivalent of the Boeing MCP. So if the demo supports them, most if not all of the FSUIPC-implemented PM controls should work. They only toggle or set bits in offsets used by PM (and documented on the PM website). This sounds like one of the problems in the recent builds. The Mode and Range (and most other INC/DEC commands) each rely on a single bit being set by the requester and cleared by the receiver. Until PM has cleared the bit no further INCs/DECs will be serviced. All this did work fine not so long ago. I think you should report the problem to PM support. I've noted some problems recently and told them, but not this one. Sorry, I've no idea what that means or how it relates to this. If you only have one PC and it is impossible for you to connect your FMC to it, how can you possibly use it? No, there is no demo. You can't use it in any case with only one PC, so it doesn't matter. You are entering a complex world. PM emulates many functions of an advanced aircraft cockpit and once you start trying to achieve any sort of realism with switches and so on you are going to have to deal with complex matters. I have just made and tested a version of FSUIPC which will provide parameter driven PM controls for the following (you will certainly need to refer to PM's "FSUIPC offsets" documentation on the PM site for these -- look them up by the offset given below, the document lists things in that order). * PM MCP kcodes (by Parameter) for the MCP/FCU Throughpass (at offset 04F2). This uses Knnn type Elan Informatique codes. * PM CDU keys (by Parameter) to send keys to the CDU keyboard interface at offset 5428. * PM GC keys (by Parameter) to send keys to the GC keyboard interface at offset 542A. * PM QuickMap keys (by Parameter) to send keys to QuickMap's keyboard interface at offset 542C. * PM Whazzup keys (by Parameter) to send keys to Whazzup's keyboard interface at offset 542E. In each case the parameter entry in FSUIPC's Keys or Buttons page gives the data to be sent. For the MCP/FCU system these are code numbers representing functions, but in all the other cases they are character values in ASCII (eg 65 for 'A', 49 for '1'), with 256 added for Shift, 512 for Control and 1024 for Alt (mixed as needed). There are some special characters too for the CDU: . = 190, / = 191, + = 107, DEL = 46, CLR = 8, Function Key n = 111+n. (These are the same codes as used by FSUIPC and FS and listed in my Advanced Users Guide). Note that you don't need to worry about the business where it says "... other bits must change if you have two same characters ...". FSUIPC deals with that automatically. If you want to try any of this before the release I can send you an interim version -- send me an email to petedowson@btconnect.com. Regards, Pete

PM questions are really better dealt with by posting in the PM Newsgroup, Pm's equivalent of this Support Forum. However: Are you running the PM MCP as well as the GC package? I don't think many of the PM functions work without the MCP. You could try the assignments for the PM GC controls facility, which takes a parameter (see 2999 in the list in the FSUIPC Advanced User's Guide). Also, I've found numerous problems with PM's FSUIPC offset interface in the more recent PM updates, things like the Mode resetting to "APP" when something entirely different is changed. I think Enrico has been trying to improve things and has introduced a few errors in this area. You may want to try a much older version of the GC, just in case. Well, if your CDU is running on a separate PC under WideFS, you could program all the A-Z and 0-9 keys in FSUIPC to send different KeySends, and define these in the appropriate WideClient.ini to send the keystrokes to the CDU, yes. But you'd lose all those keys on your FS PC. It seems far more sensible to have a keyboard on your CDU PC instead. Not sure what that means. Are you saying PM's CDU is not running in a separate PC? It makes quite some difference. If it is running in the FS PC I can see no way to divert keyboard input to it without changing the focus to it, away from FS. If it is running on a separate PC, use the KeySend facility. Ah. That wrecks most of the answers above! (I'll leave them in for other readers, though). Then the problem is one of keyboard focus. That is difficult. PM is not really designed for single PC use at all. What you really need is a facility in FSUIPC, similar to the GC Controls facility, with parameter, to send values to the "CDU Keyboard Interface" offset (see PM's FSUIPC Offsets document on the PM site, offset 5428). I can add that without any problem I think. I'll add it to my list and may fit it into the next version, due at the end of next week (16th April). Maybe I'll send you a test version to try before then. Regards, Pete

The DME stuff is in character string form, it isn't a number at all. it is ready for printing. See the Programmer's Guide. Exactly. It isn't handled in FSInterrogate because FSInterrogate cannot deal with strings. The author was going to add strings but real work got in the way. Try looking at it with FSUIPC's "monitoring" facilities -- on the Logging page. Select the type "Asciiz". FSLOOK is dealing with Gauge variables. If you are writing a Gauge you can use those. FSUIPC doesn't support FS gauges, FS does that. The DME data format dates back well before FSUIPC, to FS95 and probably before. FSUIPC maintains it for compatibility. It isn't a number on those terms, it is a string using ASCII characters and terminated by a zero byte. Please looks at the description of it in the programmer's guide again. It is length 5 including the zero terminator. If you read it into a 5 character string to can convert it into a number by using C library routines like atof() or sscanf(). There will be equivalents in your language. On the other hand if this is simply for display, just display it as is. Regards, Pete

Really? How extraordinary. It's the first I've heard of itI'll check that now! [LATER] Yes, you are quite right. It also applies to the elevator, in fact, so that's all three axes. Interestingly it is only the first change -- i.e. away from zero. Otherwise the effect is certainly equal. For instance 2 presses left are cancelled by 5 presses right, not 8. I think must be by design, but I'm really not sure why. Maybe, as in real aircraft, FS2004 is better modelling the natural return to zero which happens (because of air pressure) when you release the controls, and havong the same large reverse step would make control worse, not better. It is certainly an interesting thing they've done, and there must be a reason for it. No, because it looks like the controls "Rudder Left" and "Rudder Right" (and the other four) are actually implementing this by checking whether the control is centred (zero) initially, as it should be. I've experimented using the Trim controls instead. These are certainly equal both ways even from zero. However, zeroing them doesn't centre the actual control, so they can't be used that way. I really would recommend using the "5" key to centre everything. If you want separate centre keys for each axis you could assign keys in FSUIPC to the "Rudder Set" and similar controls, with a parameter of 0. I think the FS keys are supposed to do that, but not by tapping. When I fly by keyboard (which isn't often, only when stuck without other controls) my fingers rarely leave the number pad. I've not really found any adverse eeffect of your discovery in FS2004. I suppose if you fly by pressing a key then hands off it will matter more, but if you fly with a yoke or joystick you never let it go completely unless under autopilot (or in panic because you've realised you don't know what's going on! :) ). Regards, Pete

Sorry, I really don't think so -- too many hours spent already trying to work that out. Maybe Microsoft will make these things a little more accessible in future versions. Regards, Pete

Done. Pete

That should be okay. If the Ipaq software can talk through it, so can GPSout. Sorry, I don't know any of that stuff. Maybe others have suggestions. There are some folks have used on a Palm PDA. I have a Palm, but it's USB. None. Pretty much all parts of FS need all the other parts. Although I assume your PDA uses "Pocket Windows" or "CE" or whatever it is called, even if it was 100% compatible with Windows98 or XP, which is unlikely, I don't suppose it sports 2 Gb disk space and at least 256 Mb main memory, does it? :wink: Regards, Pete

If it has a serial connection, you need a cable for it, and you need GPSout.dll installed in the FS Modules folder, configured appropriately (see the other post on this for now -- I'll update the GPSout read.me in due course). GPSout is one of the free modules available on http://www.schiratti.com/dowson. No: for that it would need to be Networked and have the folks at Project Magenta produce an Ipaq version of their CDU program, or something similar! Regards, Pete

Oh dear! This is going in circles. I know you said that. And I even gave you a line to try in the Aerosoft configuration. You then said it didn't work and gave no further information. Then you said it worked, but not exactly as you wanted. Please refer to this part of my message in response to that: Then, instead of doing as I asked and showing me the FSUIPC INI entry for the button, you confused matters entirely by saying you didn't even program the button in FSUIPC, here: So, IF you are using FSUIPC to assign the PTT function, I can help, but you have to actually read what I said and show me the FSUIPC INI details so I can program a latching button for you. If, as you said more recently, you are NOT using FSUIPC there is no point in continuing. No, there are no delay facilities. Either your button is the wrong type -- it is making only momentary contact -- or the Aerosoft program is at fault and reporting press/release on each press. Either way you'll need to latch the button and press it once for Talk and again to not talk. It seems to me more likely that you are using the wrong button type in the first place. If you want me to help program FSUIPC to make it work, please please please read what I say. Look for the file called FSUIPC.INI. In there you will find a [buttons... section, in which your button programming for this button will be found. I need to see that and I need to know what Joystick/Button number FSUIPC sees your button as, in the FSUIPC Buttons page, when you press it. I'm not going to repeat all this yet again. Please read things a little more carefully. This is getting quite exasperating. :( :( :( Pete greetings Mark

I don't have any details of paid registrations here. You'll need to send me both the registration emails (send to petedowson@btconnect.com) with a note saying which name/address you want to use. The email address should be a valid one, as the notification automatically goes to that one. When you get replacement details, if the name/address are different at all, you will need to delete the FSUIPC.KEY file from the FS Modules folder before loading FS. This will allow to to re-register from scratch. Regards, Pete P.S. I see now that you emailed this to me also, so you'll have two replies! :wink:

Did you look at the Advanced User's Guide, the section on Button programming and flags? I certainly am confusedif you are not assigning the functions for the button in FSUIPC, and you are not using FSUIPC, what has all this discussion been about? If you are using FSUIPC, and you did assign the buttons to "ptt on" when pressed and "ptt off" when released, in FSUIPC, then there will be entries in the FSUIPC.INI for it. That is where these assignments are stored, and that is what I asked you to show me IF, that is, you still want help working this out! Please tell me now whether all this is anything at all to do with FSUIPC. If not, then you don't really need my help, you need Aerosoft's! :( :( :( Pete

You'll need to be more specific. State which offsets you are reading, the length you are using (number of bytes) and what sort of variable you are reading them into. Use FSInterrogate so you can see how these things really behave. FSInterrogate is the main learning and checking tool. Always check what you are reading with what FSInterrogate is showing for the same values. It will help you understand it all better. The most likely things you are doing wrong are: 1. Reading only part of the total value, eg 1 byte for a 4 byte value. 2. Reading into the wrong data type and so seeing the wrong format. 3. Reading a smaller value into a larger data type (e.g. 1 byte into an Integer) without setting the Integer to zero beforehand to ensure the uninitialised parts aren't misleading you. Please check using FSInterrogate, and also use the FSUIPC IPC read logging so you can see exactly what your program is reading. Regards, Pete

Done. Pete

The value WHERE on the screen? What are you looking at that says it is going to 0%? Sorry, that is even more confusing. What is the difference between this "real throttle" and the one you referred to before? Do you have several throttles? Do you have both calibrated correctly, in Windows or whatever drivers you are using? I don't have a TQ6 or a "Sim-Yoke" (I've not heard of the latter, actually). FSUIPC does nothing with throttles unless you specifically ask it to. If you aren't sure what you've done, just delete your FSUIPC.INI file (or move it out of the FS Modules folder) so that the defaults are set. I don't think USB devices are any worse than Game Port devices -- excepting that I don't think you can normally unplug them and re-plug them in without restarting FS. At least, such hot-plugging has never worked here. I really have little idea about what your problem is. Maybe I can help you, or someone else here can, but you need to explain a little more carefully, please. Regards, Pete

Everything you need (except the VB6 compiler of course) is to be found in the FSUIPC SDK which you can get from http://www.schiratti.com/dowson. Regards, Pete

Thanks for the information. I'll add these details to the read me. Regards, Pete

Why don't you write to me direct then, if it has to be private? See the little "email" button down below? Try that. Regards, Pete

Ahso it DOES actually work!!! Are you keeping the button pressed in? Normal PTT buttons need the button held? Or is the button you connected perhaps a momentary contact one only? If you are using a momentary contact button, or you wish to press it once to talk then push it again to stop talking, you'll need to "latch" it. Instead of programming it in FSUIPC for "PTT on" on push and "PTT off" on release (as I assume you've done?) you'll need to program it by editing the FSUIPC.INI file, using a Flag to make FSUIPC remember the "toggle" state of the button. The same applies even if your button is not momentary, but the Aerosoft driver treats it as such (which would be odd) -- i.e. only reacting to "off->on" and not signalling "on->off". None, now that we know it is working. Check your use of the button, the type of button, and your current FSUIPC programming. You can read the relevant sections of the Advanced User's guide for FSUIPC to see how to use flags. If you want any help on that, show me the Buttons section (only) of your FSUIPC.INI file, and tell me the Joystick/Button number you are trying to program (you can read this in FSUIPC's Buttons programming page on screen). Regards, Pete

It's on its way. Regards, Pete

Yes, to find errors like that you need to log things around the area you suspect, so that you can eventually narrow down the place, in your program, from which the Windows error is occurring. Unless your program is multi-threaded (which can be a real nightmare to debug, believe me!), this should be reasonably easy. You can also write your own error trapper using standard Windows API calls. In recent versions of MSVC this is by using the __try{} and __except{} structures. They can trap access violations, et cetera. I'm afraid things don't really work like that. You need to think through the possibilities and lay the traps, step by step, narrowing it down till you find the cause. This can involve sending different test versions out to your users (the ones experiencing the problem) so that they can return you the information, which you can thereby gradually piece together. Regards, Pete

My AutoSave DLL is not payware, it is free. Why do you think otherwise?In fact most of my modules are still free. Even FSUIPC is free for freeware programs and costs nothing extra for many accredited commercial programs. And it certainly does no harm installed whether you pay for the extras in it or not. Sounds like you have removed some essential parts of FS, not just FSUIPC.DLL and AUTOSAVE.DLL. The module called "traffic.dll" is part of FS2002's built-in AI traffic software. There are no parts of FS nor any of my software that get installed in Windows folders. You are mixing up some wrong DLLs and probably making a bit of a mess. Sounds like you need to first uninstall FS properly then reinstall from scratch. You've probably made a mess of it. And if you've been deleting things in Windows\system32 you may even need to reinstall Windows as well. None of my modules are hard to install or remove. They are simply either in the FS modules folder, in which case they will load and work, or they are not, in which case they won't load and FS will run happily without. There's nothing simpler. Regards, Pete

It's accuracy seems to be in a little doubt, which I'm trying to get clarified (see thread "Paused when in menus"), but here's the proposed entry in the Programmer's Guide for offset 3365: Regards, Pete

Sorry, I've no idea -- but if it is over 24 hours I think you are supposed to press a "problem" button somewhere on the site. I suspect that the usual possibility is that, for some reason, the email containing the key(s) hasn't got through to you. There seems to be a lot of email rejection going on these days -- about 10% of the (legitimate) emails sent to me seem to come from addresses which reject my replies, even though they are from folks asking for help. It makes me feel quite useless at times. Best bet is to go to http://www.simmarket.com (assuming SimMarket is where you bought the registration from) and enter your account. If the keys have actually been sent to you already, they will be retrievable there. Regards, Pete