Pete Dowson

Did you check with logging? I had some time here today to do some checking on this myself. You'll note from the FSUIPC4 History document that the writing/reading of 310A has had a rather complex history. Well, to cut a rather long and complex story short, I believe I've found out what might be going on with your system and 310A delays in clearing it down (not in setting, only clearing, and then only when clearing all (except optionally the 2^3 bit). After a number of tests here, I found some odd code which can delay a full clearance (except the 2^3 bit) by up to 5 seconds. I cannot remember the reason for this at all nownor why it would apply to FSX but not to FS9 or before. Strange. There's must have been a good reason for it, but I'm blowed if I can think what it is! So, sorry, I owe you an apology. I think your original report, implying both setting and resetting bits was affected, and delays of up to 20 seconds, took me down the wrong path in what I was looking at. Please download and try version 4.533, which will be up in the Updates Announcement in an hour or two. Regards Pete

No. there's really no way anything you do like that can get an "assignment" to another function. When you "cleared" the assignment, before reassigning, did it still operate the landing gear? That's the only way really to check if you do have another assignment, maybe in FS itself, for instance. You can also enable button and event logging (not axis logging) in FSUIPC's logging tab, then operate the switch, and see, from the FSUIPC Log file (in the Modules folder) what is happening. Regards Pete

It really sounds like you have something else going on there. In FSUIPC this is a simple read/write location. What you see is what you last wrote, except after FSUIPC's timeout when the whole byte is written zero. There's really nothing hidden about it, no other actions whatsoever. Perhaps you'd try to use FSUIPC's logging and monitoring facilities to see what you have going on there? Pete

Actually the timeout is about 10 seconds. I advise rewriting every few seconds, especially if running from a Client PC, in case of delays. There are no places in FSUIPC offsets which need rewriting as frequently as 0.5 seconds. Here I can write with FSInterrogate, demonstrate the disconnection of the axis for several seconds, before the timeout makes the connection good again. Erhang on! You have one FSUIPC_Process call merely to write that one byte? And how many separate ones doing those reads or other things? Each Process call means a process switch and another message. You should be only doing one process call per cycle, eg. once per 50 mSecs or so, less if you aren't doing real-time control as an autopilot. No, not relevant. I think 32k is the max for an external program, but from a GAU or DLL, as you are, up to 64k. Regards Pete

Good grief! How are you writing to it? Using the normal FSUIPC interface it can only take a maximum of something like a 100 mSecs or so (i.e. a tenth of a second). Requests are placed in the Windows message queue and then processed as soon as FSUIPC gets them -- always within one FS frame from then. In fact the complete cycle is usually within 20-40 mSecs even when performed from a networked PC using WideFS! There are autopilot programs (e.g. Project Magenta's MCP, also those from Sim-Avionics and Flight Deck Software) which operate from a client PC over a network and which would be completely unusable with response times exceeding a fraction of a second! There is no way FSUIPC has of "storing up requests for 20 seconds"! Something must be happening in your software BEFORE the request gets into FS. Have you tried doing the same thing with FSInterrogate, for instance? It is instantaneous as far as the user can tell! Regards Pete

What software are you planning to use in the Client PC? Regards Pete

Two points here: 1. The "fix control acceleration" fix is on the Miscellaneous Tab, and is documented in the FSUIPC4 User Guide. 2. Version 4.1 is well out of date and completely unsupported. Please download and install the latest, the only supported version -- 4.53. Regards Pete

Oh, right. Sorry. The title had no clue about all that, and really I had no idea how WideFS or FSUIPC parameter files were relevant to anything I was dealing with. My problem was simply that mixW would not work on my Vista installation, not that FSUIPC or WideFS would not work. Without the pair of ports defined no parameters in any files of mine would assist. Sorry, what mistake? Not identifying the subject? Are you hurt or something here? I really don't understand what the problem is. I get about 50-100 emails per day, I attend to about 10-20 often rather complex messages here per day, and i do try to help on the other Forums I visit, when I think I can contribute. It is very hard to tie a message "out of the blue" (as it looked) to anything in all the rest, especially when its content did not seem to relate to anything I was dealing with. I apologise if you think I'm in the wrong in some way, though I fail to see it. Perhaps you'll enlighten me? Regards Pete

What are you trying to test here? The keypress function doesn't return a result, it is a request TO FSUIPC to send a keypress. Are you perhaps wanting to test a Flag? As with if not ipc.testflag(0) then ...? Again, what does sending a keypress of 0 do for you? Perhaps if I knew what this plug-in is supposed to do, exactly, I'd be better able to comment. Quite honestly I do not know. Have you done what i suggested, to see if I need to make a change first? You remember, surely, I said this: In other words, without testing I just don't know if the ipc.keypress() function will send its keypress in a way which gets it processed inside FS's dialogues. If it does, well and good, if not, I think I know how to make it do so easily enough. Regards Pete

Yes, but it means editing the INI file, or making a "macro" file. To keep the on-line options dialogue easy to use for the vast majority of users, I don't provide facilities for multiple assignments to one button or switch there. But by editing the parameter lines in the FSUIPC INI file you can have almost any number of actions from one switch. The best way to do this is, in FSUIPC options, assign the first action you want. Remember the Joystick Number and Button Number. Then, with FS minimised or put to one side, temporarily, open up the FSUIPC INI file (from the FS Modules folder) in a text editor like notepad. Find the [buttons] section containing your assignment (e.g. n=Pjoyno,button, .....) and write it down or copy it to the clipboard. Then, back in FSUIPC options, change the assignment to your second need. Go back to the INI file, and you'll see that assignment now for your button. Add the one you wrote down, or paste it in, after the new assignment but with a new number (eg n+1). Or reverse the order if order is important -- they are obeyed in parameter number order (i.e. the n= part). For more information about all of this, and full details of all the things you can do with a little editing, have a look in the Advanced User's guide. Regards Pete

Nothing I've changed would have made a difference. It sounds like there must have been some sort of corruption in the Installer file you were using, though if that were the case, if it installed a corrupted DLL, that would have caused the signature to fail, and the Installer checks that. Actually, because the Installer checks the signature immediately after it writes the file, it may be that the checking is only occurring on the pre-written cached copy. If the copy actually on disk were corrupt, then it would cause the error you were getting, but maybe not when the installer checks it. If this is the case, and quite honestly I cannot think of another answer, then what happened when you copied the update in is that it was written to a different part of the disk, with the other merely being erased from the directory. Mine are really mostly technical background things, nothing really of the type you might be looking for. They are all listed either in the Updates and Goodies Announcement, or in the http://www.schiratti.com/dowson page. Apart from WideFS all the rest are freeware in any case. Good luck! That's how I started in serious simulation. Learned to fly, but couldn't get a license or fly solo because of my severe eyesight problems. So, I fly computers only. Regards Pete

Okaythat looks fine, which is worrying. You said it worked okay when you initially installed it, but not on subsequent loads of FSX. Can you think what might have happened between the two? Evidently it isn't anything in the FSSUIPC package itself, as that has been completely replaced by the same one which worked before. Just one last easy try before we have get down to dirty details -- download 4.532 from the "Updates" Announcement above. The ZIP will contain only the DLL. Just put it in the FSX Modules folder. Let me know if that loads okay. If not, I have to assume there's some conflict going on with another add-on to FSX. Do you think you could get the details the error shows more exactly, please? (No "Peter K. Dawson", for instance), and see if there's any buttons on it to get further information. I'd also need to know what else is installed in FSX. Perhaps you could find these two files (in the same folder as your FSX.CFG file -- "C:\Users\AGFS\AppData\Roaming\Microsoft\FSX"): DLL.XML EXE.XML and paste their contents into a message. They can be opened in Notepad if you wish -- double clicking them may just try to open them in Internet Explorer or something. Regards Pete

Hmm. Don't think it would have said "Peter K. Dawson" -- don't know him. But if it did then your FS installation has certainly been invaded by an imposter DLL. Either way, it seems as if your setup has become corrupted in some way. Re-run the FSUIPC4 installer. If you still get a problem, show me the Install log file -- it will be in the FSX Modules folder, and it is a text file so you can paste it into a message here. I'm not sure why you'd want to, but it is easy: FSUIPC4.DLL is the whole of it. Delete that and it has gone. The remaining FSUIPC files will be the LOG, INI and maybe KEY files, which won't do anything with no DLL, and the documentation and so on, the files listed in the Installation instructions. If it is only FSUIPC4 which has got corrupted, re-running the installer should fix it. If it doesn't then you may have a problem, but it will be in Windows or your hard disk. I doubt there's anything in FSX would could do this. Regards Pete

No, never use unlisted offsets. They might simply be mapped to unknowns in FS, or get allocated and used in a later version. There are 64 bytes of user offsets, for any use you like, at 66C0. This is listed. However, I'm not sure why you'd need to do this? There are assignable Lua controls to set and clear sets of 32 flags specific to each running Lua program, testable in Lua by special library functions. You can send any Lua command via offset 0D70 (parameter in 0D6C). Regards Pete

Because the spin control is used to set the pairs of numbers relating to the intermediate flap positions, of which there are 5, numbered #1 to #5. Number #0 is the "flaps up" position, or minimum, and #6 is the flaps down position or maximum. The min and max positions are denoted under their headings, #0 and #6, on the left and right -- those are the normal calibration min and max values which you would have set during normal non-detente calibration. This should be obvious also from the example in the document section you just quoted. Look: "So, for a 737, the headings end up as #0, #7, #8 (for a total of 9 positions 0–8)." See the #0 on left, the #7 (max for 9 positions) centre and #8 (full flaps) on the right. When counting from 0 the maximum flap number will be one less than the number of positions -- i.e. 6 in your case, not 7. So the final figures above the numbers will be 0, 5 and 6. Regards Pete

By "fsuipc client" I assume you mean the FSUIPC options dialogue? There's no such thing as an "fsuipc client" in FS. What is CTRL+ESC supposed to do? I don't know that one. It sounds very much as if you have a video driver fault. I assume you are running FS in full screen mode? Try Windowed Mode (ALT + ENTER), see if that helps. But really, the first thing I would do is to download and install some different drivers for your video card -- maybe the latest ones, but possibly there are older ones which are more stable. Regards Pete

By "programming" you mean assigning and calibrating? About 2 minutes per lever? Or am I misunderstanding you here? What do you really want to do? How many throttle levers do you have? 1, 2,3 or 4? If you have 4 why not simply use them for Engines 1, 2, 3 and 4 -- for aircraft with less engines the other throttles will do no harm. But if, as it sounds, you have 2 throttle levers and want 1 engine: 1 -> 1 2 engine 1 -> 1 and 2 -> 2 3 engine 1 -> 1 & 2, 2 -> 3, or whatever 4 engine 1 -> 1 & 2, 2 -> 3 & 4 then you need just three Profiles defined -- one for 1 & 2 engines, and one each for 3 and 4. Then you simply assign the profile to the aircraft as you load them, and FSUIPC will remember this and change the assignments automatically. If you insist on mixing FS assignments with automatically changing FSUIPC assignments you are bound to run into trouble. There's no way FSUIPC can stop FS doing what you ask. You need to make a choice. Regards Pete

Sorry, I'm a bit lost here. Which way is the "way to go"? You mean having 10 instances of WideClient and your program linking to all? No, no. As I said, each Client to Server link is a one-to-one. You'd be writing 10 times, once to each client. No it wouldn't. Each Client would only receive from its own Server. No confusion. Your program could tell the different data from each Server because of the client it was talking to. I think you've misunderstood something since the last message in this thread, a few weeks ago? Regards Pete

You can use a 32 bit number provided you only do the Write to FSUIPC as size 2 (bytes), else you are overwriting the next value at 32FC. Pete

Pay for? Only if you want to use the user facilities. The interface, the part you are talking about, is free for all freeware and end user purposes. By "current versions" do you mean 4.53 or 4.532 or what? Folks have stated this before when they actually meant "the last one I saw", and it turned out to be a year and 6 versions out of date. It isn't difficult to find the version number -- it is shown on the first tab in the options, in the DLL properties, in the Log. Characters? Well "5" is ASCII 53, so that's why you see 53 there. Why are you writing a string of characters? It is just the binary number of seconds, never a string! It's a 2 byte or 16-bit signed number, so you define it as a short int, or whatever the equivalent is in the language you are using. It would be 49, the numerical value of the character "1". Yes, I know, I wrote. it. Do you see where it says "... then write a number to this offset, 32FA... "? When it says "number" it means number, not "string" or "character". Pete

Why are you reading it? I think it is a write-only parameter (though I'd need to know which version of FS and of FSUIPC to check). What is the purpose for you reading it? And how many ways have you found to write it? If by "old DLL" you mean an unsupported version of FSUIPC, then yes -- the difference is that I cannot help you until you update to a supported version. AND, please, you always need to tell me the version, and preferably whether you are talking about FS98, FS2000, CFS1, FS2002, CFS2, FS2004, FSX or ESP. These things can make a difference! Regards Pete

Sorry, I don't understand what you are trying to say. I don't see any difference between the manual's "n=CP(F+j2,b2)(F+j3,b3)j,b, ...." and your "n=CP(F+j2,b2)(F+j3,b3)j,b, ....". Do you? Where? All of your previously posted examples had F's in both parentheses. And it certainly isn't true that "each paranthesis have to have the "F" before this works correct.". The F signals a FLAG. It can be omitted when it isn't the FLAG you are using, but the button itself, the real one. For each of the up-to-16 conditions you can be testing a real button (no F) or a Flag (F needed). Pete

Ok, but I'd rather see the section of log at least including the "Logoptions" line, which shows what log options you've selected. Anyway, this shows the control being sent to FS. I've checked this here, and I think you are mistaken about 11451 being correct. I did some experiments here with the default 738, whilst in the air (never test spoilers on the ground -- they behave differently). This is what I get Logged with Buttons, Events and Axis logging enabled (the "7" at the top of the LogOptions indicates these options): However, the spoilers don't move. I moved them with the mouse, with the logging enabled, to the Flt detente and got this: So, I altered my parameter to 8218, tested it, and voila! It sets the Flight detente! So, where did you get your 11451 from? And how is it you get so much less logging than I for, as you say, the same Log options selected? Regards Pete

Yes, it is just a set of axes, with, I seem to recall, a button operated by pulling the levers full back. I notice from your Axis assignments that you are assigning all of your axes in FSUIPC, but directing them all via FS controls. This is fine, but for all normal axes you would actually find it more efficient to direct them to FSUIPC calibration, bypassing FS. That is, unless this method doesn't work with your aircraft (some aircraft insist on seeing the normal FS controls). These look like aborted attempts at calibration. With minor exceptions they are just the default values, not allowing any variation, and hardly likely to be applicable to any particular hardware. Really, I would advise you to deal with calibration of all of the controls, properly, following the numbered steps as in the user guide. Do this for the flaps as well as all the other axes. Until you get these right, and know what you are doing, I'd really advise you to stay well away from slightly more ambitious efforts like flap detentes. If you leave the values as shown above you might as well not be using FSUIPC, as it isn't doing you many favours. Anyway, looking at the flaps parts: Several things wrong here. You've once evidently tried to calibrate flap detentes -- but only 4 positions. You set the ranges Flaps position 0 (up) = -16384 to 14448 (i.e. most of your range!! Flaps position 1 = 1 to 16380 (huh? Overlaps like crazy with flaps 0, and pretty much reaches your max position Flaps position 2 = 16381 to 16387 (pretty much non-existent! Flaps position 3 (full down) = 16379-16384 (okay) I don't know how you got into such a mess, but you evidently didn't follow the instructions? Best to delete all those lines and start again. If you don't understand an instruction, by all means ask. In any case, it looks like you then clicked the button to turn off the detente operation (the FlapDetents=No) The Flaps=0,16380 line seems to indicates you have not calibrated the flaps axis first, in any case. Please 1) calibrate the flaps axis as a normal axis, first. 2) Then select the Detentes option, and ensure that the first and last values are sowing correctly, the minimum and maximum values as in the calibration. 3) Then calibrate each flap position in turn, following the instructions, providing lower and upper values for each position (they must always have a range, not a point, in which to be recognised), until you have all 7, including 0 (full up) and 7 (full down). Here's an example from a 737 (9 detentes including #0 up and #8 down: FlapDetents=Yes FlapStarts=-16384,-12873,-10532,-5201,-910,4352,8832,11904,16382 FlapEnds=-16384,-11572,-8842,-3121,-520,4992,10752,13312,16384 Flaps=-16384,16383 Regards Pete

It would have been much easier for me if you'd simply paste the relevant part, as I asked, into your message. What's a "RAR" type file, what looks at it? I doubt that I can explain better and without pictures than I've done there. It would amount to reproducing part of the manual here. I don't see the point in that. If i could have explained it better I would have done. What exact parts don't you understand? Do you need someone to translate it for you, perhaps? Sorry, I really don't think you want to mess with a delay, unless you are out to make your aircraft difficult to fly, as some sort of test. Maybe with poor models, yes, but I'm sure PMDG have got their response correct. Adding a delay in the controls would be foolish. Not for throttles. The slope allows you to change the sensitivity of things like airleron and elevator, near the centre, to avoid overcontrol. Really throttles should be linear. If you have wildly different devices for your throttles 1+2 to 3+4 then you will never match them fully, though prior calibration correctly in Windows , and then more precisely in FSUIPC, will help a lot. In real aircraft the throttles are rarely exactly in line for the same thrust. Regards Pete