Pete Dowson

Thank you very much. It is much appreciated! Regards, Pete

Are you running anything called anything like that? Strange if not. The DLLs attaching themselves to FSUIPC successfully are well known ones, I don't think they are related. Regards, Pete

Sounds good. Nice looking models! You have equivalent performing ones in FS (scaled up presumably ;-) )? Pete

It still isn't a message from anything of mine! ;-) The log shows everything is fine. Sorry, I've no idea what software you have producing that message, nor what it means. Regards, Pete

It is one integer of 32-bits wich occupies 4 bytes 9a byte is 8 bits, 4 x 8 = 32). You also aren't counting correctly. After 02B4 comes 02B5 then 02B6 and 02B7 -- not that any of that is relevant. you don't want 4 separate bytes, you want one 32-bit value. Why are you counting byte addresses in 2's in any case? If you want the IAS that is at 02BC not 02B4. Please do take another look at the information provided. You can also try FSInterrogate2 which is highly instructive. Pete

Hmmm. Interesting. I really know nothing about Multiplayer -- nor even smoke. Have you checked that offset to see if it works locally first? Otherwise you may need to use one of the SMOKE controls. Well, it doesn't seem to provide a great deal for FSUIPC to do -- you could send the SMOKE controls direct to FS in any case. And FSUIPC really has nothing to do with Multiplayer at all. If I were you I'd concentrate on solving the MP side of things and not worry about the actual smoke enabling part until that's sorted. Regards, Pete

Nice to see you making progress, Kaela. Who really needs documentation, eh? ;-) Regards Pete

Sorry, I haven't a clue what it means either. It isn't from any program I've ever written. If you want to check the FSUIPC operation for errors, please find the file caled FSUIPC.LOG in the FS Modules folder and look at that. Show it here if you like. Maybe that weird message if from some program trying to use FSUIPC incorrectly. Regards, Pete

Yes, sorry. The whole of this area of FSUIPC has been revised and works correctly now -- please check the Interim Versions announcement near the top of the Forum. That's a question for the iFly folks. I'm afraid I don't know what they are doing which makes the axis use unacceptable. It would certainly render their aircraft unusable on my cockpit. Regards, Pete

What is the version number of the "older version of FSUIPC" please? FSUIPC has been around now since 1999. It is impossible to help without more information. What program is providing your "ACARS"? Is it one with access accreditation to FSUIPC, do you know? Tell me the program or gauge name and I can check. Possibly you should ask the author too. I assume you've not registered FSUIPC yourself? Finally, there will be a file generated in the FS Modules folder called "FSUIPC.LOG". Let me see that after an unsuccessful attempt. It sounds like the program you are trying to use is not licensed for FSUIPC, but give me some details I can work with and perhaps I can reply more definitively. Regards, Pete

Yes. Unless you want to do clever things with the main X, Y, Z axes, you might as well assign them in FS. You can still calibrate them more precisely in FSUIPC, and assign response curves to get the sensitivity you like. That's the advantage of FSUIPC calibration. The axis assignment facility is a bonus mainly aimed at more ambitious arrangements. I think for you, this is the easiest: forget the Axes tab in FSUIPC. If you have already assigned Axes in the FSUIPC axes section, yes, go there and clear them, otherwise you will have a double action. Then just get everything assigned and working in FS alone. Then, as you like, calibrate the X Y Z in FSUIPC -- that's in the Joystick Calibrations section. Regards, Pete

Ahapologies. The controls are actually named "Trim up" and "Trim down". Looks like the "Elev" bit is dropped. FSUIPC gets the list from FS, it isn't its own, and I think these are converted from the "Num1" and "Num7" control names which are rather meaningless. Yes, but why use FSUIPC to assign controls to buttons which FS supports well enough itself, and normally assigns automatically in any case? In other words, why are you confusing yourself with FSUIPC doing just standard things which FS does reasonably well by itself? There must be more to what you want, surely, than simply assigning X Y Z and trim? FSDUIPC's facilities are really provided to augment what can be done in FS, not simply do the same. Regards, Pete

What were you using to assign the axes (FS or FSUIPC) and what version of FSUIPC? Have you seen the interim updates available above? Yes, this is called elevator trim. If you want to assign the buttons in FSUIPC, go to the buttons page, check the option to use controls, find in the drop down the "elev trim up" and "elev trim dn" controls, assigning them each to the correct button press, and remembering to check the "repeat" option. As I explained before. Using buttons for trim up and down is also the default way FS assigns these, so I really don't understand what you are doing in FSUIPC in the first place. Sorry. Regards, Pete

Well, I originally thought it was a good idea, but it seems that FS puts them back in any case, eventually. So I wouldn't worry about them. If you are doing ALL your button ands axis assignments in FSUIPC, just disable the joystick in FS's Options-Settings menu. (There is a bt of a discussion about this in the FSUIPC documentation). Regards, Pete

There's no such commands. You can assign the Elevator to an Axis elevator set command -- not a separate pitch up or down. It's a normal axis with a centre. There's an Axis set command also for elevator trim. Again, it has a centre, but certainly not a separate up and down. I really don't understand what it is you are trying to do nor how you are trying to do it! What elevator trim up/down setting are you talking about? Please try to separate BUTTONS and AXES. They are entirely different things! What has any of that got to do with the trim? Surely you use X for aileron, Y for elevator and Z for throttle (usually)? You said earlier that you'd disabled it all in FS, so this could be why it doesn't work, no? Why not start again? Remove FSUIPC, delete FSUIPC.INI, run FS and sort out your joystick assignments there. I think until you can say what it is you want to do you will be better staying with the simple things. Regards, Pete

FSUIPC never works in any new version of FS until I've made it so. In fact it doesn't work in any updates to any version of FS until I've made it so, as illustrated by the FS9.1 upgrade. Even if I could I wouldn't be allowed to yet. Sorry. Yes. If I do my job well, why should there be any? Do you know more than me about FS10? (It would certainly not be hard to know more at this stage! ). Regards, Pete

Er, sorry but I am a bit confused by what you say. Are you talking about elevator TRIM? You want a trim up button and a trim down button, right? If so, this is nothing to do with FSUIPC joystick calibration -- you don't calibrate button presses, they are simply buttons. You program the trim up and trim down controls in the Buttons and Switches section. Try that. In the drop-down control lists they are "Elev trim up" and "Elev trim dn". Also check the "repeat" option so they repeat whilst held down. Regards, Pete

Yes, and oddly enough it is described in the WideFS documentation under the heading "PTT (push to talk) for Roger Wilco, AVC and TeamSpeak". Pete

Yes, it is part of the TCP/IP package, and is used by windows in any case I think. Sorry, I've no idea on that one -- I was a staunch Win98SE user, refusing to update any of my PCs until I had to on one of them because Matrox wouldn't do a Win98 driver for the Parhelia. I still resisted with the other PCs after, until the SP1 update arrived -- that made a helluva lot of difference, and I changed my mind! Whether Win2K would have changed my mind I've no idea. I have one machine, running WinXP Pro normally, which has Win2K Pro on dual boot, but apart from testing things in it I haven't formed any opinion. Sorry. Regards, Pete

Sorry, I do not know what the "client manager" nor "IBNet" are at all! Are you sure you are asking this question in the right Forum? You mention FSUIPC, but what has that got to do with it? Pete

Sometimes they will, sometimes they won't -- you can't tell. Windows has loads of other things to do. The Process call (not the others) is not only relinquishing control to FS, but also to anything else that wants to run. You cannot guarantee your 256 Hz in any case unless you have a tight loop in a thread which is set to high priority and shares only with a Sleep(4), say, to regulate it to 250 Hz. You would have to get the FS values in a separate thread, or the main program, probably on a timer tick call (SetTimer) every 55 mSecs (the normal tick resolution), and have your fast driver loop just picking up the last value from wherever the FSUIPC access part dumps it. It may be better to do some interpolation as well, if you can. I haven't done any, but I should think it is all based on the accelerations, not on the pitch/bank and heading values. Then you have to slowly bring the base back to centre before you run out of tilt capability. Only accelerations are felt -- you can add the thump of the gear coming down and the landing too of course. And a continuous gentle vibration (probably easier done with a bass woofer). Regards, Pete

256 Hz? That's allowing less than 4 milliseconds for each double process switch (switching to FS to ask for the data and back to you to process it). I don't think Windows is capable of that on any PC yet, at least not consistently and allowing for any work to be done by either party. It is in the process switching where most of the time is spent. The rest is then mostly taken up with message queuing in Windows. All this is outside FSUIPC's control, which does things as fast as it possibly can once it gets the request. In any case, for most values you will want, FS is only updating them at a frame rate -- not necessarily the visual frame rate, but not much different from it. If I were you I'd regulate FS to a frame rate you can always sustain (say 25 fps) then interpolate for the other 9 values you need per frame. Regards, Pete

For VB.net? I thought he was a Delphi programmer. I'll ask him next time he's around -- I think he has very busy periods work-wise. Thanks! You're a star! ;-) Pete

Hi again Nobbi, I just noticed this: ... so, as I obviously have this aircraft I thought I'd take a quick look. With the default Baron, if I set the thottles to give a steady reading of 1500 RPM on the FS panel, I get the following through FSLook and FSUIPC: FSUIPC: 0898 = 9128 (decimal) 08C8 = 10800 So RPM = (9128 x 10800) / 65536 = 1504. Correct! FSLook gives 9130 or so -- i.e. the same value as 0898. So, I'm afraid I cannot agree with you regarding the Baron. How are you arriving at your conclusions? Regards, Pete

That's very very strange. Is there any relationship? Maybe the scaling value is wrong for some reason. Can you quote some comparative figures for me? I seem to recall that it somehow reads the Gauge values. Not sure how, I'd need to burrow into the code. Are you writing something to run inside FS, or is this an external program? If inside FS you could try reading the Gauge token variables. I *thought* that they came from the same place as those 2400 etc offsets, which is why I'm puzzled. Well, not really sure, but maybe it works on one version of FS and not another -- it is possibly making some assumptions somewhere which turned out to be incompatible. Let me see a two columns of comparative figures, please, see if there's a relationship I can figure. Regards, Pete