Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Phew, how old was your previous version of FSUIPC? You missed all the super updates expecially for RC users -- by popular demand? Please do take the time to read the documentation. If you are not using Advdisplay (as per the RC documents), why not use the nice new FSUIPC window facilities? See bottom left in the first FSUIPC options screen. Please also take the time to help yourself by simply perusing the FSUIPC user documentation, especially after performing updates. Seems I waste my time trying to meet user's needs. :-( Pete
  2. And what version number do you think that is? Please please ALWAYS quite version numbers. "Most recent" means the most recent one you happened to see, it doesn't mean anything to me. What has "installing the most recent FSUIPC" got to do with this part? What version of WideFS are you using, and what do the Logs say? What would such a utility do? I'm sorry, but the information about what is going on will be in your system. Check the FSUIPC Log, the WideServer and WideClient logs. If you've not changed WideFS at all (why not?) then perhaps you have a bad registration. I can tell from the FSUIPC Log, but it must be a complete log, from start to end with FS closed first. Keep the session short. And EXACTLY what did you do? Changed only the FSUIPC.DLL from version 3.??? to 3.??? (fill in the ?s please). You deleted nor changed any other files, at all? No renaming, no editing, no deleting, nothing? Regards, Pete
  3. I'm not sure what you mean there, but I cannot and will not support old versions. If you ever want my help at all you first need to update to the latest version, not stick with an old one just because that's what you got from somebody else. That makes no sense. You evidently need to sort it out with them, then. Have you tried re-installing? Something may not be right with the installation. Regards, Pete
  4. :-( I would really much prefer you to use 3.70. just remove the + signs in the comments on those three lines for now, please. Put "plus" if you like. Pete
  5. Okay, it was easy after all. I suddenly had the bright idea of correcting those three lines in my regurgitated [Keys] section, and running FS again. It worked okay! That was the big clue! The only difference was those comments at the end of the line, after the ";". The problem is actually caused by the "+" sign in the comments, which occurs on those three lines only! Phew! The FSUIPC change which was responsible is this one (quoting from the History document): Evidently, when I added that facility (it was in version 3.60, back in April) I obviously took a rather lazy approach and didn't check things so well. I'll fix this and the correction will be in the next version -- maybe only an interim release in the Announcements above, for now. Meanwhile, please just remove the + signs in the in-line comments and you'll find it all works fine. Regards, Pete
  6. Okay. There's definitely a bug and I'm trying to find it now. it is very odd. The log was okay, nothing I could see wrong there. The best test to see what was happening was to load your [Keys] settings into FS, add one more Key assignment IN THE DIALOG (to force a change so that it would re-write the section), then check what FSUIPC intrerpreted from your input [Keys] section. Obviously you've never used the dialogue to edit any of these, so you wouldn't have seen the results, here: There's only four differences, and one was my change. I've marked the differences clearly with rows of ##### and ???? (the last change was simply my additon to force a write). Note that all recent versions of FSUIPC retain the line numbers, and line comments. You lose the comments added to the ends of lines though. Anyway, your three problems are cause by rubbish in my tables for those three keys, which get regurgitated as: 32=66,11,128244,128244 36=75,11,640244,640196 70=67,26,25700,25600 which is very weird. I am investigating this, but I have other commitments too so I can't promise a quick result. But I'll do my best. Regards, Pete
  7. Yes, received on 29th July at 22:34 BST and replied at 23:21 on the same day, a mere 47 minutes later! Here is what it contained: Seems you email system thinks I'm a spammer, or maybe your ISP? Regards, Pete
  8. No attachment. But why not just include the [Keys ...] sections only here? (ARE you using aircraft-specific assignments at all? If not there will only be the one [Keys] section. Indeed. And yu say there are NO other changes excepting the 3.53/3.70 swap? Because it really sounds like something else is pinching those particular key presses. There are two ways of getting more information on this. 1) Try assigning those three non-working controls to ordinary keys, like A, B, C, temporarily. See if they work. If so it's the keys you are using originally being trapped someplace. If not, try assigning other controls to A, B, C, see if others work. If so then something somehow is getting in the way of those controls. 2) In the Logging section of the FSUIPC options you will find, on the left, places to sleect logging for "Button and Key operations", and 2Events". Select both of those, then try out your keys -- those that work, those that don't. Write down the order you do things so I can work out from the log what is going on. Regards, Pete
  9. This is not the PMDG support forum, sorry. You need to re-direct your questions to their support. It does, however, sound like you have a faulty PMDG install as I use that aircraft a lot and get no such problem. Try re-installing it completely. Regards, Pete
  10. Two questions on that already: First, please never ever say "latest". I always need VERSION NUMBERS. Folks have been known to say "latest" but mean "the last one I saw" which turned out to be 12 months old! The version numbers are there for a purpose -- to precisely identify the version. You can get this in any of three ways: (1) Right click on the DLL itself and select "Properties" then "Version". (2) In FS, go to FSUIPC options (via the menu) and read it right there. (3) After running FS, look in the Modules folder, find the FSUIPC.LOG file and look at that -- it is right there in the first line. Second, you say you get a message " module was unable to start because FSUIPC could not be initialized", but you don't say what program or module it is that says this! It is certainly not FSUIPC. Such information must surely be shown? Otherwise some developer somewhere wants a good telling off! Yes. It is an ordinary text file. Show it here. Now, hold on. you said earlier "... renamed my unregistered fsuipc.dll ...". And then it magically becomes registered? That isn't possible. You are omitting something very important here aren't you? No. There are only two possible causes: either you are using an old version of FSUIPC after all. (NEVER rename FSUIPC and leave it in the Modules folder. If you want to keep old copies make a subfolder "Saved" or something, or move them to your own archives). Or you have an illegal FSUIPC or WideFS key. Regards Pete
  11. Well, I've assigned it to a key here, as a test, and it works fine. Are you using a default aircraft? Test it on one first. FSUIPC does not differentiate between any of the FS controls. It just passes them on. If that one doesn't work, none of them will. Have you got any other assignments in FSUIPC? Do any of them work? Maybe you should show me the appropriate [Keys ...] section of your FSUIPC.INI fileare you using aircraft-specific assignments, or any other complications I should know about? Regards, Pete
  12. Adam has been in the FS team at Microsoft for years now. That was one of the reasons he couldn't continue with the FS5IPC, FS6IPC series. Regards, Pete
  13. It isn't an FSUIPC control, it is an FS one. FSUIPC has nothing to do with it. Regards, Pete
  14. If I knew I wouldn't be allowed to say. Unlike MS spokespersons (it seems) most others involved are subject to very strict NDAs. There will be an FSUIPC for FSX. I can't say any more, but whether that is because I don't know or can't say I'm afraid you'll have to guess. Sorry. Regards, Pete
  15. Use offset 3110. You can send any FS commands you like. Regards, Pete
  16. Well, of those you didn't need to do (1) or (4) or (5). Nor really (6) if you hadn't deleted your registration. As it clearly says in the User Guide, registering FSUIPC, means that it accepts all applications, with or without keys. It simply won't use the freeware AFCAD key any more. And, no, you are breaking any 'law', as also explained in the User Guide. Your User Key is for the life of FSUIPC 3 -- you are, in fact, EXPECTED to update your copy of FSUIPC each time a new version comes out. I simply cannot support a variety of old versions, you see? If you had already registered before, your shouldn't have needed to do so again. Evidently you must have deleted your registration as well. Please, one day, have a read of some, at least, of the FSUIPC User Guide. It does tell you how to install FSUIPC -- basically "copy the DLL into the FS Modules folder". You never have to delete anything, and you only create more work for yourself if you do. Regards, Pete
  17. No, you are correct, that is the way it works. No, sorry, I can't do that. with keys it is easy, as I simply have ot intercept the Windows messages which arrive for key presses in any case. The non-pass option simply means that I discard the message after processing instead of passing them on as I would with 99% of other messages. With joysticks, I have my routines reading the buttons, and FS has its own. This doesn't use any Windows messages I can intercept, and I really wouldn't want to go messing deep in FS's directInput code to find out how to remove buttons there. It might have been feasible back in FS2000 days and before when FS used the same Windows interface as me (the Windows Joy API), but since FS2002 it uses directInput, which gets pretty complex real fast. Regards Pete
  18. But if it supplies the same value each time (like 0) then it won't have any effect as it was the same as last time. The only occasion I can think of where that will have an effect is if the cockpit you are using is "emulating" the throttle control and sending throttle axis controls to FS -- if it is doing that then it is fooling FS. Any software which does that need to disconnect the actual axis input if it is going to provide its own. That's a must. Your device is not unique. It might for for a USB device (I don't know), but all Game Port axes are polled. They don't send information regularly or when it changes, but are polled continuously by Windows' joystick drivers and the values fed through to whatever program wants them, which will also be polling. Hence, as you must see, a joystick throttle is always providing values. The secret has always been not to have them change, then they are ignored. I think you've already proven to me that your joystick IS changing all the time -- you said that it was hard to get FSUIPC's axes page to register another axis because it always sees Z, but my code, which is polling by the way, IGNORES unchanging axes. Your throttle is obviously wobbling away and providing changing values. Calibrate it with a bigger null zone and park it. No, that really isn't true. Sorry. FS ignores successive identical values, as does FSUIPC. You have got something else changing them. Regards, Pete
  19. You simply need a larger null zone in the idle position so that there's no change in the values. That's exactly why I added the facility to temporarily ignore axes. Didn't you try using that? Well, I don't think you need it, but there is already an assignable FSUIPC control to turn the throttles on and off. In fact there are three -- 'off', 'on' and 'toggle'. Autothrottle has always been a problem with "jittery" throttle axes, ever since I can remember (FS4?). The solution which always works is to make sure you have good reliable dead zones at both max and min positions, and park the throttle when engaging autothrottle. I normally park it at max on climb-out, and reduce it to min at the start of the descent. This works because FS ignores axes which don't change. The same answer applies to your 3. FSUIPC has offered such facilities now for years, and they are fully utilised in a number of aircraft, including some "fly by wire" implementations. Regards, Pete
  20. No!! Completely the opposite! You cannot supply any single offset in FSUIPC which will allow you to calibrate anywhere at all. The offsets are a direct way into FS, BYPASSING ALL CALIBRATIONS! They affect the FS controls directly. The whole point of the IPC interface provided by FSUIPC is that it is an interface TO FLIGHT SIM, it was never intended as an interface TO FSUIPC! Admittedly, a number of additional facilities are by now provided by FSUIPC which also have offsets, but axis control has never been among those. If you want to calibrate joystick axes they need to be input to FS or FSUIPC as joystick axes. You can write Axis controls using the 8 byte offset at 3110 -- you write the axis value in one 32-bit word and the FS control number in the one before (or both together as 8-bytes if your software can handler that). However, at present the "tiller" axis added in FSUIPC only doesn't have an FS control number, nor even an FSUIPC one. It is something I could consider -- but are you even able to use the 8 byte offset 3110 in any case? Regards, Pete
  21. Nothing in the way FSUIPC or WideFS has been supplied has changed in the ten and more years I've been supplying them. Every version comes in a ZIP which is complete -- DLL and Documentation, every time. As most of it does get changed, if only a little, each time there's no point in confusing things by having lots of separate packages. Whether you are a new user or an existing one, the install is exactly the same -- copy the DLL into the FS Modules folder. That's it. This applies to both paid-up registered users and those who just need it for applications and are not registering it. If you have already registered, that fact is kept in the FSUIPC.KEY file which you don't delete (unless you really want to re-register). I think you are confusing yourself by assuming things are much more complicated than they really are. I've deliberately kept things as simple as they can possibly be. There's no install program because the install process is so simple -- copy one DLL -- and the program does not put hooks into the registry or do any other complex thing which makes it any more complicated. Keeping it so simple also makes it easy to reverse the installation (i.e. un-install it) -- you simply remove the DLL from the Modules folder, and that's it, it's gone. Installing for FSX will not be quite the same I'm afraid. But I'm making other simplifications to compensate. Regards, Pete
  22. There isn't one, as it is just another assignment to the rudder, so use 0BBA. The point about having a separate assignment is so you can have a more sensitive calibration, suited to ground steering. But by using offsets going directly into FS you bypass all calibrations completely in any case. The same would apply to any other FS axis of course. Regards, Pete
  23. Ah, I donated (registered). Regards Pete
  24. No, it isn't. It only tries to keep the seconds correct, that's all. The offset in minutes or whatever is not corrected. That isn't its function. Now why do you refer to FS RealTime like that? I use it all the time, and it does the job perfectly for me. I also run "Atomic.exe" in the background to keep my PCs system clock right too. ;-) Sorry, I don't understand. FSUIPC's little facility is not a substitute for something like FS RealTime. It simply tries to keep the seconds aligned, so that FS doesn't get further and further away from your PC's time. It does nothing about offsets from the PCs time. After all, your PC could be in Australia and your FS aircraft in Timbuktoo. Or you may have paused it, or used the menus, or used the go faster or go slower modes. Yes, but it'll stay off by the same amount. If you want it better, try FSRealTime -- it works well with the FSUIPC facility, because the latter saves it having to correct by much or often. But then the traffic and scenery would reload and it would be off again, as you just found. You'd need to set it at time+x where x is the time it takes to do the reloading, which only you can measure. If you can reduce the traffic and scenery densities to a point where the whole lot reload in well under 60 seconds, then you should be okay as it will get fixed by the seconds-checking only. Maybe that's why I don't have a problem? Fast PC and hard disk? Big memory so much is cached? Regards Pete
  25. You don't purchase downloads, just a Key (or two Keys, one for WideFS and one for FSUIPC). As it clerarly says both in the Announcements here and in the User Guide, the Keys cover version 3 or FSUIPC and 6 of WideFS. Your receipt says this too. You are, in fact, EXPECTED to keep up to date. I cannot support old versions, and, again, if you peruse the announcements here you will clearly see that only the most recent versions are supported. They are not "free", you paid already. You only pay once for Version 3 of FSUIPC and version 6 of WideFS. If you don't update you don't get support. The user guide clearly tells you how to install. Simply copy the DLL(s) into the Modules folder. That's it. Don't delete or change anything. You don't have to re-register. Updates are simply new versions of the DLL (and updated documentation). Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.