Pete Dowson

FSUIPC does not affect how FS interprets your keyboard inputs. It has no way to do that, unless you've reassigned them in FSUIPC. If all you've done is Registered FSUIPC and not used any of its facilities, then it is exactly the same as not registering it -- unless, that is, you have used an illegal registration, or your PC's system date is wrong and makes the registration look illegal. Perhaps you'd better show me your FSUIPC log file (close FS first) so I can check? You'll find the file in the FS Modules folder. If you post again, please state the version of FS and the version number of FSUIPC. These things are ALWAYS needed. Regards Pete

In that case FSUIPC never really got started, as creating a Log file is one of the first things it does. It means that FS is going wrong when loading FSUIPC. Is the description of the error there the same as the English from FS? Seems there's no other explanation anywhere? That was rather extreme. Did you not even bother to try the current release, 3.988, first, as I advised? I don't understand why you won't try the things I suggest. :-( Anyway, your results show there was something corrupted in your original installation. It is likely to have been some sort of corruption in the FS installation. I'd just install your favourite add-ons, but check after each install. This is good practice in any case -- never install more than one thing at a time without checking in between. Why do you think that? There was no 3.97 in any case -- the previous main release was 3.96, and there were about 15 incremental releases in between. And in any case, how would it possibly help? What would you learn? There have been no changes in anything that FS does before it creates a log, not in a long long time. The problem will be more related to an interaction between whatever got corrupted and the memory arrangements internally, which will be different for every single issue of FSUIPC because of its changing sizes and memory structures. Regards Pete

No disturbance caused! Glad you sorted it. Good flying! Regards Pete

Sorry, I've not got enough information there. What is F11(toggling) programmed to do, and how different to your "programmed switch"? If you really have programmed the switch to set 7B91 correctly, and Ivap takes no notice, then maybe Ivap does not use those offsets after all? If it really does then you have made a mistake, but I can't tell what because you give me nothing to work with. Maybe show me the lines in the INI file which your programming produced? You do know that there are now built-in FSUIPC controls to operate the Squawkbox transponder offsets (which it looks like Ivap also uses from what you say)? Check the Updates Announcement. Pete

You need to update that. The oldest supported version of FSUIPC4 is 4.60, as stated in the Announcements above. There are also later versions of both FSUIPC4 and PFCFSX.DLL available in the Updates Announcement. You need to seek support from PFC, because a jerky input from an axis can only arise from dirty potentiometer slides (they are linear slide pots in the quadrant), or possibly, and less likely, a dodgy power supply. The digital filtering option is really designed to remove severe spiking which arises from dead spots or from really bad power smoothing. It can't help much with small random up/down effects or sticking. It I implemented a much stronger filtering action it would affect responsiveness too much and become useless. Erwith the same PFC quadrant device? In that case it cannot be the hardware or the PFC driver. It's something wrong with the aircraft modelling. Seems you need to find better aircraft models. I don't know which turbo models you are using, but there's nothing specific about different aircraft which makes any different to the inputs, only to their reaction to those inputs. If you think the problems with the aircraft can benefit from different sorts of response curves applied to the levers, you could try disabling the axes in the PFC driver and instead assigning them via the Axes assignments tab in FSUIPC. Then, in the calibration section, you can apply response curves of different types. Regards Pete

Unfortunately none of the information you posted to me differs in any way from what has gone before and therefore provides no new information. If you refer back I was reasonably specific in what I asked you to do, viz: 1. Try swapping the DLL with the latest increment from the Updates announcement above. 2. Get more information in the Windows event logging. Right click on "My computer" and select "Event Viewer". See if there's anything relevant to FS or FSUIPC in either the Application of System sections. The report from FS itself provides no information of any use whatsoever, and all of the pictures you provided are pictures I can take myself here any time. They show nothing useful or different to anything anyone might show. Additional useful information would be a list of other Add-Ons installed into FS9 -- possibly one of those is an FSUIPC user which is attempting to do something too early, and the later version is taking longer than the older one before being fully ready to take orders. YOU could also try using a different default aircraft if the one you are starting up with is an add-on which may be using FSUIPC. Oh, if FSUIPC produces a log in its short run, please show me that too. You can paste it here. Regards Pete

Okay. Post such images in email thenpetedowson@btconnect.com. But I will reply here, okay? Regards Pete

No. Nothing here. Why a PM? I don't like those much in any case. There should be nothing confidential in your problem report. If you want to erase names and email addresses just do so. If you need to send me any files or confidential information then we'd need to change to email. But I like to keep the threads here coherent and informative, for others following the problem and, hopefully, solution. INI files are managed by the Windows private profile API and don't really allow for any commenting. I did make provisions for comments in the Buttons sections, though, as that is perhaps the only place where things might get so complicated as to warrant comments. Please refer to the Advanced User's guide to FSUIPC, the section entitled "FORMAT OF BUTTON DEFINITIONS", the paragraph starting "you can add comments ...". Regards Pete

The broadcasts are not working at all. This either means your network is not working or one of your systems is faulty (a corrupted operating system). Both Vista and Win7 support Broadcasting and that will work, even through firewalls, provided both PCs are in the same workgroup. So, first off, does your Network actually work? Using Explorer can you share files or folders and see and access them from the other PC? Have you by any chance configured the Win7 PC to only use the new (in Win7) "HomeGroup" network configuration? If so then I don't think you can link to it from any non-Windows 7 PCs -- they all then need to be Windows 7. If you have done such a thing I think you will have to delete or undo it and configure a non-"HomeGroup" type of network. Assuming the Network is actually working but for some reason the Broadcasting doesn't (which would be the first time I ever heard of such an anomaly), then you could try again to get the connection working by getting the parameters correct. Add ServerName=Upstairs Protocol=TCP to the [Config] section of the WideClient.INI. Even if this doesn't work, it will at least try to connect (currently, because of the lack of broadcasts, it is not even able to try). The log files might then tell us more. If you know your IP address is fixed then you could also try: ServerIPAddr=n.n.n.n (whatever it is) Protocol=TCP Regards Pete

Okay. That shows no connection, no attempted connection shown either, properly matching the client logs you showed. However, it shows something pretty bad. You have a Client named "ANGELO-PC" and a Server also named "ANGELO-PC". How do you think those can be distinguished on an Network. I don't think you should ever do that! And ...? Are you okay now? (You are being a bit cryptic). If there is still no connection then rename one of ypur PCs. All PCs on a Local Network must have different names -- that is the point of names, after all, to distinguish things. If still no joy, I will need to see the WideClient and WideServer logs from the revised attempt. Otherwise, if you are happily connecting now, please say so. The thread should be concluded properly, please. I am going to bed now, so it'll be tomorrow when I see your answer, either way. Regards Pete

That's the workgroup name, is it, "WORKGROUP"? Well you certainly have an error in that file: The line "Angelo: ..." will be ignored as "Angelo: Protocol" isn't a known keyword. Therefore you've not specified the Protocol, and you must do if you specify a ServerName or ServerIPAddress because those parameters make it ignore the Server broadcasts which tell the Client where it is and what protocol to use. If both your PCs are in the same workgroup, as you say, why are you specifying a ServerIPAddr parameter anyway? It shouldn't be needed. No, the Wideclient0.log is simply the previous WideClient.log. the Server part of the story is told in the WideServer.log file of course, which you've omitted. There's the problemremove the ServerIPAddr parameter from the client INI, or correct the Protocol line. You need to be more careful when editing files, though really you should not need to as defaults work fine in one workgroup. Be aware to that unless you've fixed your server's IP address as 192.168.1.84 you would be better off specifying the Server name, or nothing at all. IP addresses assigned by routers can change. Regards Pete

Yes, and I did so for the only piece of code you posted for me to look at. I would also have done so for any other sample, but you never posted anything else as i asked, nor did you bother to do the Logging which would have told me what you were doing wrong in a way much more clearer to me, seeing as I don't use VB. That should not be necessary. I can write to 0570 or 0574 here, using something as simple as the facilities in FSInterrogate, and the aircraft will go to that altitude. There is nothing keeping it on the ground if you don't want it there. I'm sorry you see them like that, but if you do come asking for help and then don't bother to help the person who's trying to help you by supplying information, and in fact apparently ignoring requests for information, then really I think it is you who is being rude. Please review this thread properly, actually reading it as you don't seem to have been doing, and you'll certainly see that this is the truth of it. Please never bother coming back if you don't want me to help in the ways I know how. Pete

What is that "same error"? It was never really presented, which was why I asked for more details before. And did you do as I asked before, i.e. try swapping the DLL with the latest increment from the Updates announcement above? First of all an accurate description of the problem, please. Second, you could possibly get a bit more information in the Windows event logging. Right click on "My computer" and select "Event Viewer". See if there's anything relevant to FS or FSUIPC in either the Application of System sections. Pete

No, but it is much much more likely that problems of lost key presses when holding down a joystick button are related to the joystick driver that to any program like UT2! Good news! And good flying! :-) Regards Pete

Actually the existing Squawkbox/Roger Wilco PTT controls in FSUIPC4 do work with SB4 just as they did with SB3. They were never a problem. That facility never was dependent upon FSUIPC offsets, it always used the original Roger Wilco messages supported by pretty much all the on-line ATC programs including SB3 and SB4. Regards Pete

Not the code which you said "stored the integer of 618 at 0574". The last code you posted had that glaring error in it which I pointed out: Please refer back through the thread. You seem to be mixing yourself up! I'm sorry, but you are wrong. You are making a mistake, and you are not helping yourself. And I long-ago concluded that VB is an awful language, from many interactions like these from folks who get lost in its lack of abilities, as it lacks many essential programming things, like unsigned integers, which causes awful problems with technical interfaces like those to FS. If you are such an expert in VB I would have thought that you would have debugged your way out of your problems many hours ago, if not days! That is not the "on ground" flag which is at 0366. That is a special part of a completely new facility in FSX to set all of the values -- optionally Speed (starting at 0558), and always including all of Lat Lon Alt Pitch Bank Heading all in one single FSUIPC_Write -- i.e. as a complete structure. It is clearly documented, and operates the "INITIAL POSITION" facility in FSX. It is no use for moving aircraft around, only for setting things up initially. Please do read more carefully! I have tried to be patient, and provide as much help as I can in the circumstances, but it seems to me that in fact the patience is more lacking at your end. If you cannot do the simple things I suggest I don't see any point in continuing here. Do you? Pete

It is easy to use 0570. That isn't a problem. Even writing a 32-bit Metres value to 0574 is not a problem. You need to Google for more help using VB6 and in particular "Currency", not 0570 where it would be pointless. None of this explains your error in writing a simple 32-bit integer to 0574, which is really really easy. Since you won't show your code and won't even try using the Logging, I don't see much more point in you posting further here, do you? If you really want help please try your end too. Pete

Didn't you copy your INI file over from your previous installation? There's no difference, and installing FSUIPC never touches the INI file. You need not have made any changes whatsoever. You are using FSUIPC version 4.152, which was a Beta version issued nearly THREE YEARS AGO, back in July 2007, as is very clearly shown in the picture you attached. Didn't you even bother to look at it? Why go to all the trouble of posting a picture of something which tells you straight-away you have got something so very very wrong? Profiles were not invented till much later!, and no FSX version before 4.60 is supported in any case! At the top of this Forum there are a number of Announcements. Please do take a look. ALWAYS refer there before posting requests for support. It would save us both a lot of time! Pete

Many VB6 users seems to find Currency as being sufficient for this. I know it sounds strange, but if it is really a 64-bit integer as has been stated several times by others (including, in your Lat/Lon thread, the expert Paul Henty, author of the .Net DLL interface for FSUIPC available from the stickies at the top of the Forum.) Googling VB6 and 64-bit I also find several other confirmations of this: http://vb.mvps.org/hardcore/html/largeirrency.htm http://bytes.com/topic/visual-basic/anstegers-vb6 (but this one says Currency can't handle max values? Something to do with x 10000?) http://www.vbforfree.com/?p=260 You could try searching for help like this. I really neither know VB enough to help nor do I have enough time these two weeks -- I'm on holiday later next week for a while and have a lot to finish up before then. Google is your friend for problems like this.Or changing to a decent language. ;-) No idea about that, sorry. No, it cannot be, it is only a flag set by FS according to whether the aircraft is on the ground or not. Where's the log of IPC writes showing what you are, or are not, writing to 0574? Regards Pete

You are making an error then. You have not shown me any good code yet. Try using the tools available to check your work. The FSUIPC Logging facilities can log what you are really writing. You can also test the exact same action using FSInterrogate. e tried saving the integer of my altitude (in feet) * .3048 in memory location 0574. For instance, my initial altitude is 2027.48 feet. 2027.48 * .3048 is: 617.975904 meters. If I stored the integer of 618 at 0574, the plane still sits on the ground while its moving. You are certainly making an error then. As I say, please use the tools available to debug your work. If you don't understand what you then see in the Log, show it to me. Regards Pete

The logs show nothing wrong except that the Client is not receiving broadcasts from the Server and you've not bothered to tell the Client what the Server name is nor the Protocol it should use. You don't have to tell it these things if broadcasts work, but as it clearly says in the User Guide broadcasts only work if you make both PCs part of the same workgroup -- i.e. they must have the same workgroup name. The one important thing you should have done after installing WideFS is to at least read the section of the User Guide called Configure your Network which does say at the very beginning, and in RED: IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! Pete

Why are you multiplying the number of metres by 65536? The upper 32-bits, i.e. the integer starting at 0574, is the whole number of metres. You are setting an impossible altitude (for FS, that it. You might get that high in X-Plane). Is a metre good enough accuracy for what you need? Mind you, I see you are approximating the Lat/Lons too. Regards Pete

Why not show the code you have? I don't know VB so I cannot construct a compilable example for you, but i can probably spot the error in your code. Note that (like the latitude and longitude) it is a 64-bit (8-byte) integer, and the value is in units of 1/4294967296ths of a metre (4294967296 = 65526 x 65536). For a value accurate to a metre you can instead just write the number of metres to the 32-bit (4 byte) value at offset 0574 (the upper half of the 64-bit number). The lower 32 bits are the fractions of a metre. Pete

Hmmm. I've been using UT2 successfully now ever since it came out. mind you, I run UT2 on the FSX PC and IYP + RC on a WideFS client PC. It is still difficult to fathom how the "switch" can do anything like that. This is why I started to think it must be related to the holding down of the joystick button -- irrespective of what it was programmed to do. Didn't you try any of the tests I suggested on Saturday? I was trying to narrow the cause down. Removing symptoms often isn't a true solution. Are you sure this is not just another manifestation of the same problem? This is the trouble if you only remove symptoms and not tackle the cause. It was the KEYDOWN codes which were being lost -- your log showed ALL of the KEYUP codes arriving okay. Something is trapping the KEYDOWNs, and for most uses those are the ones that matter. Since it appeared that KEYDOWNs, even from the real keyboard, were going missing when the joystick button was being held down, I am guessing that something provides a joystick option along with Shift and Control. I can't see how it is anything specifically to do with IYP -- it is simply that with IYP microphone switch you hold a button down whilst other things are going on. The only way it could be IYP is if IYP itself were trapping Control and Shift KEYDOWN's whilst its microphone switch is held down. The tests I asked you to do would have shown us a lot more about all this. The Windows Message was WM_KEYDOWN, with the Virtual Keycode 49. Igonre the waiting flag. The repeat flag simply shows if it is marked as an auto-keyboard repeat (from being held down), and the shifts are a collection of bits denoting which other ("shift" type) buttons were still pressed. Windows virtual Keycodes and shift values are listed in the FSUIPC advanced user's guide as well as in many Windows' message references on-line.. Please try the tests I suggested, else I'm really not interested any more. :-( Regards Pete

Well I think they are documented as such in the FS help or knee boards, or some such place, and they are logically correct because it is the mixture control which controls fuel supply to the engines both on jets and Props. It is just that on jets it's an on-off thing rather than a continuous adjustment. Regards Pete