Pete Dowson

Well, I'm not a salesman and don't want to be, but let's see: Yes, but can't you do this in FS already? Not sure what you mean there. Are there analogue brake pedals on those (i.e. are they the USB variety, not the game port ones)? What exactly is wrong? There is a little confusion there. FSUIPC supports separate reverser levers (axes), up to four of them. But you talk about indents, so are you talking about a reverse zone on your throttle levers, not about separate reversers? FSUIPC can help with either, but they are different subjects. With the interim release available above, yes, FSUIPC can do that -- in fact it is an example in the downloadable documentation above too. Why not download the full FSUIPC.ZIP from http://www.schiratti.com/dowson and browse thedocumentation, then look at the extras in the Interim release above, along with the extra documentation there. Then make up your mind. Regards, Pete

Sorry, I really have no idea what you are talking about. Is FlightSim Commander 7 an Aerosoft product -- is that how your sentences relate? What do you mean by "it shows that the fsuipc is not registered"? What does, what message? There are many FS add-ons which use FSUIPC but you do not get a user-registration for FSUIPC with them. If you want to use the User facilities in FSUIPC please follow the links to SimMarket in the documentation and on http://www.schiratti.com/dowson. If you are talking about some error message from the Add-on, then really you should be asking the folks who supply or support add-on software for assistance if their documentation doesn't help. I cannot support all the programs there are for FS, especially ones I do not know. If there's a problem with FSUIPC itself, and not the add-on, please just explain what it is. Regards Pete

The "zulu" second is identical to the local second in every time zone. Time zones are only hours and minutes different (and I think only 0 or 30 minutes in the latter case anyway). The are no time zones which have an adjustment in seconds!!! Regards Pete

Please don't type ALL CAPITALS. It is very difficult to read, and comes across as SHOUTING. Please review the Announcements at the top of this Forum regularly. They will help you a lot in things like this. I don't think AdvDisplay can have anything whatsoever to do with frame rate drops -- that is another problem you have, possibly related to your sound system, so don't expect miracles by changing the display system. Regards, Pete

I'm not sure how a piece of software could change behaviour. If something works, it works, if it doesn't, it doesn't. Do these buttons have a "push on, release off" effect, or do they simply send a short pulse each time they are pressed? If the latter, then it may simply be that the pulse is too short to guarantee that it can be seen using a normal polling system -- FSUIPC by default polls at 40 per second on WinXP, 20 on Win98 etc. You could try experimenting with the polling time -- check the PollInterval parameter for the main [buttons] section in the FSUIPC.INI. It is described in the Advanced Users guide. FSUIPC uses a Windows interface called "joyGetPosEx", not DirectInput, and this may be a difference between the Windows' Game Controllers and FSUIPC. See how your device behaves with the Thrustmaster utility "joyview", attached to this message. If you aren't using WinXP yet I would advise you to upgrade, as its treatment of USB is far superior to that of previous Windows versions. Regards, Pete joyview.zip

I don't deal with registrations. Please see the announcement above about what to do if you lose one. Pete

Great! Thanks for letting me know! Sounds like some sort of network driver corruption or mix-up. Regards, Pete

You can change the colour to white -- either in the Miscellaneous options in a Registered FSUIPC, or by using the WhiteMessages parameter in the INI otherwise. I have no other control over font or colours -- it is a Flight Sim window, not one owned by FSUIPC. I don't think you can change any of the other FS window fonts or colours, can you? If you find out how to do this, please let me know. It should be applicable to the FSUIPC one too. Regards, Pete

Did you by any chance find the documentation, inside the ZIP file in which you found FSUIPC 3.53? Please browse through the User guide -- it does explain the facilities that are offered to paid-up registered users. Incidentally, you wouldn't need to use FSUIPC for setting up keyboard commands for the PMDG cockpits -- I believe they provide keyboard assignments in their own facilities. Did you look at their menu? If you are talking about assigning Buttons on a joystick to operate keyboard commands already assigned in the PMDG cockpit, then the Tab curiously labelled "Buttons" would be relevant. Did you look there? If it isn't visible then perhaps you've not yet paid for and registered your FSUIPC? "Played about" with what settings, exactly? What are you hoping will appear? It isn't like rubbing a magic lamp you know, there is no genie. What happens after you select options depends upon what options you select. ;-) Regards, Pete

There are simple step-by-step instructions for FSUIPC in the documentation. Please just download the FSUIPC.ZIP file from http://www.schiratti.com/dowson and look at the main document, the User guide. The josysticks section has a series of easy numbered steps for calibration. There's actually nothing simpler, and there are certainly no computer programmes to be written. (Even if you were daft I can assure you that plenty of apparently daft folks have used the facilities before now with no problems! ;-) ). What may be confusing you is trying to use both CH's control manager AND FSUIPC. I'm pretty sure it can be done, but they are not designed to work together at all and it will probably make life more difficult for you if you try. I don't know the CH hardware nor the Control Manager, but Bob "Sticky" Church produced some helpful documentation over on his website, http://www.stickworks.com. I think the file you want is called CMNote02.zip. As far as FSUIPC is concerned, please bear in mind that the Joystick Calibration part of it is meant as a final, more accurate, "finisher". You should get things mostly working in FS using the normal calibrations first. Excepting the new axis assignment facilities (only in the Interim Versions released above at present), all the facilities actually work on FS controls, not on the joysticks themselves. Regards, Pete

Ah. Uh, ok. Thanks. Shame on me for not asking the version right at the start, though I must admit not remembering problems such as those you described in older versions. I guess I just assumed you were on the latest, as I don't support older versions. You may be interested to know that 3.553 is available in the Interim Version announcements above. I'm planning on a full new User Release, which won't be substantially different to that, by mid-April. Regards, Pete

Won't FS's own multiplayer do that for you? Just put the flying computer into MP host mode and the observing one into observer mode with the pabnel showing. If that's all you want to do you only need two installations of FS and a cable. You don't need anything of mine. Regards, Pete

Ernothing magic. What controls don't work? What have you selected in the PFC options? Have you looked at the documentation? Mostly everything works out of the box, and even applying the simple "automatic" calibration provides results which are very usable. Incidentally, there's a much later version of the PFC DLL available in the Interim Versions announcement above. I would rather you used that one in any case, as you are asking for help -- it is the only one I use now. The only reason it isn't on general release yet is that I've not got around to updating the documentation. When you have it installed, try all the controls and switches on the Cirrus, and tell me what does and what doesn't work. Please test it first with default FS aircraft -- third party aircraft may well do their own thing and will just confuse the issue. After this test you should also post the contents of the PFC.INI and PFC.LOG files, which you will find in the FS Modules folder. Regards, Pete

Well, I don't think having too many is the true problem. If the symptoms you are seeing are that the radio changes overrun after you stop turning the knob, then this implies more that the button polling frequency of FSUIPC is too fast for the PC you are using, for the frame rates being achieved in FS. Only this would explain the pile up of messages causing the overrun. Provided you don't actually need every pulse to have an effect (and certainly you cannot expect that unless you have plenty of spare processing capacity), then I should think that all you really need to do is to slow down FSUIPC's poll. Try 20 per second (50 mSecs) for instance, to start with. Experiment. Regards, Pete

Okay. Yes, thank you -- it may well be useful to others! Regards Pete

No sorry I can't. I mean, this is not a "program" that I can follow step by step, but a dll. so that I launch it on another PC with FS and collect the values using a file. Ouch! If I had to develop my DLLs (FSUIPC, WideServer, etc) like that I'd never finish! surely the debugger will let you attacvh to your own DLL code even in FS? With the MS debugger you simply tell it to launch FS with your DLL installed and you are in! Yes, very wrong. "*((DWORD *) m_pView)" reads "the place whose address is given by the DWORD pointer 'm_pview'". The "*" sees to that. If X is a pointer to a DWORD, then *X is its contents, effectively the same as X[0] .... but the latter implies an array, that's all. The compiled code is the same. The (DWORD *) part is a "cast" and temporarily makes the m_pview value a pointer to a DWORD, instead of whatever it was before. In other words, it is this instruction which places the (non-zero) value of dwError, computed by the ASM code, into the first DWORD addressed by m_pview! This error explains both of your problems. Regards, Pete

But it cannot be, if the ASM code is working then the value stored must be the address of the instruction labelled "next". Can't you see what happens with single stepping? No, that should be 54 shouldn't it? You already told me that m_pNext-m_pView is 58! Where are you changing these to a bad value? No. Where are you changing it? Oh, yes. FSUIPC_ERROR_SUCCESS is actually "1" not "0". Sorry. You have the first DWORD incorrectly set (should be that "next" address), and evidently the length of data incorrect. Sorry, I don't know how, from here it is not possible to use your debugger. ;-) Regards, Pete

Because you didn't purchase 3.14, you purchased a user license to use any version 3.xxx. When you update your FSUIPC you don't delete your previous registration, so why should you have to enter it again? You need to save the key securely in case you ever delete the registration file (FSUIPC.KEY), or re-install FS or windows, or move to another PC. You don't need it just to update FSUIPC, which, in the past, has happened almost every month! Regards, Pete

Ah! ApologiesI forgot all about that. Yes, it is one of the differences between the external and internal systems. Sorry. That DWORD should contain the address (of @next) saved by that little bit of ASM code you managed to compile! Ah .. so does the 1st DWORD get filled in before the SendMessage? 00 00 00 00 01 00 00 00 04 33 00 00 04 00 00 00 50 09 D1 01 00 00 00 00 01 00 00 00 08 33 00 00 04 00 00 00 54 09 D1 01 00 00 00 00 02 00 00 00 0A 33 00 00 02 00 00 00 B0 04 00 00 00 00 That all looks okay, provded that 1st DWORD is filled in correctly. What error? This is now saying it is successful! in C the call is: SendMessage(m_hWnd, WM_IPCTHREADACCESS, (WPARAM) (m_pNext - m_pView - 4), (LPARAM) m_pView); The first parameter is the Window handle, the second the message number, the third (your WPARAM) is the size of the data being passed, and the last is the pointer to the start of the data. Note that this doesn't include the special DWORD at the start added for internal access checking. I'm not sure what you are reporting as a problem now. Regards, Pete

But this is for a GF-46. It appears simply to be a copy of the GF46 example I supply in the package. Knobs and switches are not handled by "GFdisplay", which is solely concerned with displays -- hence its name! Knob and switch programming has always been provided in FSUIPC. If it is a GF46 as you imply above, then the example in the FSUIPC_Buttons.INI does the job. If it is actually a GF45 you will need to change your GFdisplay INI and adapt the GF46 example to operate with your GF46 button numbers. I don't know what they are (I don't have the G equipment any more), but you'll find out very quickly in FSUIPC when it responds (see the Bottons options page). Pete

Sorry, I don't understand the question here. What are you asking? What do you want to do? What in the documentation do you not understand? You need to be specific. When I write documentation I try very hard to explain things the best I know how. In the case of GFdisplay I added many examples too, any of which are directly usable. I don't know what you expect me to do here -- there is no point in repeating the documentation, you have it, and as that is my best explanation it wouldn't be any different now, would it? If there's something specific you want to ask, do so, but I cannot answer general questions like "I understand nothing so please do it all for me". Sorry. Regards, Pete

FSUIPC polls the joystick using the (reasonably fast) joystick API "joyGetPosEx". You can see this in operation with the little Thrustmaster "joyview" program I attached to another thread here yesterday. The default poll rate FSUIPC uses on WinXP systems is 40 reads per second (25 mSecs). Your 36 pulses works out at 72 because each 0 and 1 must be visible. You could try reducing the polling time (i.e. increasing the rate) in FSUIPC, but it may well be limited lower in the interface layers in Windows, and in any case to actually guarantee to see them all FSUIPC would have to be able to guarantee more than 72 polls per second -- probably twice that? Something to do with wave sampling theory? Of course the process containing FSUIPC has much else to do besides, so these polls will not necessarily be as evenly spaced as one would hope. I could try to make the polling part at separate thread with a very high priority, but that would certainly adversely affect FS performance. And it couldn't act upon those pulses there, it could only count them and let the main thread act on the count of pulses in the normal FS frame rates. And what would that actually mean? Really, if you do want every pulse counted I think you have to provide a Windows driver for it, at kernel level. But then you need to consider what the result means, what it can do. If you are programming this for radio frequency adjustment, for instance, surely for 72 pulses in a second you are not asking FS/FSUIPC to "increment" or "decrement" a frequency, using the normal INC/DEC controls, 72 times? No. The way to do it is to convert a fast pulse rate to a new button number. This is how the GoFlight knobs are handled in FSUIPC. With the GoFlight driver I can distinguish between switches, buttons and rotaries. Currently FSUIPC cannot distinguish between an ordinary switch and one capable of fast pulses, but I suppose I could add a new facility for this to be selected. Then a difference between "fast" pulses and "slow" ones could be detected and programmed separately -- i.e. instead of a "press" and "release" as now, a "slow" and a "fast". It is rather a lot of work though, and I'd need convincing. It would affect slow pulsing slightly because a pulse would need "remembering" and only acted upon when the time for a fast one has elapsed. You'd presumably then also only process the offs-to-ons, as one pulse, rather than both? I would be very surprised if you really wanted many pulses per second all to be individually actioned. Is this what you means when you assert that "FSUIPC cannot keep up"? Why would you want all pulses to be actioned -- what would you expect to be able to do? Surely, if you are adjusting a value on a display, you do so until you get the value you need. Maybe you are looking at a display which continue to receive commands even after you stop turning the knob. Is this perhaps what you mean? If so, this is inherent in the way the FS control system works -- each separate FS INC or DEC control is posted as a Message to FS's main message processing window procedure. The rest is dependent on how fast FS processes its messages and sends the results to its gauges. There are faster ways to do it. Most of the additional controls added by FSUIPC operate directly on the variables in FS, the same as can be done by external programs. If you look through the list of FS added INCs/DECs in the Advanced Users document you may find what you want. Try those -- they are somewhat less likely to build up a queue where they don't use the Messaging system, as most probably don't (this would vary, I'd have to check eachg in turn). You can also make up your own controls operating on FSUIPC offset values, via the Offset controls. These include INCs and DECs. Of course these aren't directly suitable for radio frequencies which aren't regularly incrementable (they a BCD and many values are not used), but they can easily be used for continuous vlaues like heading bugs, course values, altitudes, speeds, etc. Regards, Pete

Yes, he said that a couple of messages back. Thanks, Pete

Well, it's a bit of a mess. Before I detail the errors, here's the definition of the read and write structures: // read request structure DWORD dwId; // FS6IPC_READSTATEDATA_ID DWORD dwOffset; // state table offset DWORD nBytes; // number of bytes of state data to read void* pDest; // destination buffer for data (client use only) // write request structure DWORD dwId; // FS6IPC_WRITESTATEDATA_ID DWORD dwOffset; // state table offset DWORD nBytes; // number of bytes of state data to write where the ID for a Read is 1 and for a write is 2. Now look at your data: 00 00 00 00 this looks like an extra unwanted DWORD? Are you sure the pointer isn't to the next section? Otherwise everything is out by 4 bytes. 00 00 00 00 04 33 00 00 04 00 00 00 50 F9 D0 01 00 00 00 00 this group of 4 DWORDs plus 4 bytes (for data) is almost correct. But the first DWORD should be 1 (read). The offset is 3304 (correct) and the size is 4 (correct). The destination address is 01D0F950 which is probably okay, and the 4 zero bytes after is where FSUIPC will dump the result. 00 00 00 00 08 33 00 00 04 00 00 00 54 F9 D0 01 00 00 00 00 Again, similar. The read ID (1) is zero instead, but the rest is fine. B0 04 00 00 0A 33 00 00 02 00 00 00 00 00 This is wrong too -- the ID for this Write to 330A should be 2, but it is 000004B0 (1200 decimal) instead. This may be the data to be written. I wonder if you are writing the DATA to where the ID should be? 00 00 00 00 The last 4 zeroes are needed to terminate it all. Regards, Pete

And what version have you changed FROM and TO? Are you user registered with both WideFS and FSUIPC? The email address you are using here isn't listed. Try removing the FSUIPC.Key file from the FS Modules folder, then run a locally connected application such as your ASV6 again. If it works, then your registration is suspect. Zip up and send me the FSUIPC.KEY file and I will check it here. petedowson@btconnect.com. Regards, Pete