Pete Dowson

It isn't really limited except by the maximum size of the shared memory area, which is something like 32,768 byres I think. That needs to contain header data as well a read data space, so with 64-bit requests that's an overhead of about 24 bytes per request. So about 1200 single byte requests or less for larger ones. And it is FAR more efficient to batch them per Process call than to split them up unnecessarily. What is going wrong? Bear in mind that Is supplied these things for your tests, as I don't really have anything sunstantail to test my changes eith here and won'y have time to write a new test program for several days. If you have a program I can use to debug my code, I'd be grateful to receive it. Pete

This sounds like the right brakes axis is not REVERSED (REV) even though the Left one is. If you press right rudder fully down, does the differential brakes message disappear? The REV option is on the Calibration section of each axis. note that you need to RESET before setting REV then re-calibrate, otherwise the values will be all wrong. Pete

Okay, except that it's to "FSUIPC calibration". There's a "Joystick Calibration" tab. Please do look for it! And look in the User Guide as well, please -- there's a whole chapter on it, as there is for the Assignments you've already used. Calibration is the process whereby you match what your axes supply with what the Flight Sim needs. That is probably the single most important part of what FSUIPC offers! (Also the oldest and most original user facility, well before "assignment" was added). Really, the User Guide the first place to look for guidance especially for a self-professed "newbie" ;-) i'm sure you'll get it sorted. It idn't really hard -- just a matter of making use of the tools provided. Pete

The WideClient log only gives halft the story. There are two ends to a connection -- the WideServer.LOg is needed too (in the Sim's Modules folder). The error is 6942 Trying TCP/IP host "DESKTOP-ICKRQAV" port 8002 ... 6942 Error on client gethostbyname() [Error=11004] Valid name, no data record of requested type In other words, Windows doesn't appear to like that name. I thought the max size of a computer name was 12 characters, but you have 15. Maybe that is okay on the Server version of Windows but not on the Client Windows? Are they different Windows versions? The best thing to try, as advised in the WideFS User Guide - see Page 4, and in particular the parts about the ServerName, Protocol, and ServerIPAddr parameters. Try using the IP address as I have the above doubts about the name. You must specify the protocol too (TCP, or UDP which is more efficient if the order of data exchanges isn't important). Pete

Okay. I think I have it sorted. Tested with my 32-bit applications and UIPCHello64. I have no more extensive 64-bit FSUIPC clients, so I would be grateful for your feedback, but I know the mechanisms I'm using work okay. To test, as well as compiling your program with the updated 64-bit LIB in the ZIP I linked in my last email, use this version of WideClient (which will remain on restricted release until fully proven). WideClient7110.zip This should allow 64-bit applications to interface via WideFS to FSUIPC5, FSUIPC4, and even FSUIPC3 (with the existing WideServer.DLL installed). The interface is designed to match the old 32-bit one, with the 64-bit pointers reinserted on the readback, from a table, hence the full compatibility. Of course the application's own pointers aren't used by WideFS, they are just part of the parcels so the LIB functions know where to store the data when it is returned. Parcels are batched hence the need to closely associate the pointers with each requested data item. Pete

Strange. It is fine here, 100% of the time. The Window is completely now invalidated so that the Pain call redraws it all, same as when you change a dimension. Pete

Show me the FSUIPC4.LOG file, from the FSX Modules folder. If there isn't one, then FSUIPC hasn't even run and there's something else hanging FSX. Also use the Windows Event viewer to see if there are any crash reports for FSX. If so, what Module do they state as the reason? Pete

If you are using FSUIPC assignment and calibration, just set the REV option on the calibration entry. But first press "Reset" for that entry, and re-calibrate after setting REV. If you are using FSX-SE's assignments, check the reverse option there. Pete

You need to contact FSC support. I also note from the L-M support forum that 'Martyson' is using FSX97 + FSUIPC5 + P3D4 with no problems, so I think you have some local configuration problem with FSC. Pete

Is that all? Not the controls list i mentioned? That's a simply text file, like the INI but actually named a TXT file! Why would whatever is doing this allow a DLL, which after all IS a program, but not a harmless Text file? It won't help. I suspect you won't be able to place it there. However, you can make one yourself. it is really only a text file. Use a normal text editor and make a file containing: [User] Name=your name as in the Registration Address=your email address as in the registration FSUIPC=your FSUIPC key (no spaces) and save it in the modules folder. See if that works. That is all the Installer registration does, so good luck! The fact that your INI file is written, but no PDFs and not even the Controls List which is a text file is very strange. I am sure you still have some spyware or malware process going on. It is often very difficult to stop these. I myself, though I use few such add-ons, also suffer from files being removed without my agreement, and I haven't found a way of stopping that either. And I am still using Win7. I am sure it is much worse in Win10. Pete

That will work but it very "unfriendly", killing threads is only a last measure. Because of this line: if ipc.testflag(0) then ipc.exit() end It will exit and therefore terminate normally if the Flag (flag 0 in this case) is set. You need to assign the button release to "LuaSet" with the Lua name and 0 as a parameter! Pete

Don't forget that the buttons are pressed and released on alternate "clicks". If you want every click to count then you therefore have to program both "press" and "release". Additionally, turning any rotary too fast will mean that the button scanning with miss some "clicks". You can incread the scan frequency (it's an INI file parameter, but it's a trade off between that and affecting the Sim's performance. The GoFlight rotaries, as on their RP48 module, send back "fast" or "slow" codes -- i.e. effectively 4 buttons for each rotary, fast and slow either way. The fast ones are generally used to do things like increment by 10 whilst the slow increment by 1 (for example). But nevertheless not all clicks will be noticed unless the dials are turned at a speed not exceeding the joystick scan rate. It just isn't possible. You might like to try using the Lua example "Rotaries.lua", provided in the Examples ZIP. This is specifically aimed at rotaries on HID devices. That implements the same sort of fast/slow results for the RP48, treated as a basic HID device, as the GoFlight driver itself does. Pete

I've made the relevant changes so that a 64-bit app can connect to the current (32-bit) WideClient. If you want re-build your application ready, download UIPC64 SDK C Version 2 There's a revised FSUIPCuser64.lib, and its source included, as well as a recompiled UIPCHello64.exe using the revised LIB. No other parts and changed. You won't be ble to test your compiled result yet, because I need to also make changes to WideClient. It's actually a much bigger job than I thought. I have to replace the pointers in the blocks being exchanged by table entry numbers, and build up a local table of addresses so these can be filled back in before returning data to the application. The alternative to this would be a huge number of changes to the WideServer part of FSUIPC's 4 and 5, which I am not willing to do as the process would be very error prone. I don't want to risk its stability. Pete

It all looks okay to me. There'll be no difference in any of the timings, all 128 or 256 buttons will be treated exactly alike by the plug in. With 128 buttons instead of 256 you could shorten the loop to "while i <= 4 do", and only read the first 4 "buttons[]" values, but it won't make any noticeable difference. It looks like only one button connection is made on the rotary being turned, so then it is a simple matter of detecting the buttons being pressed and releaed. What you then do with them is up to you. There are no "values" being skipped because it isn't related to values. Pete

128 buttons? I thought with DirectInput that the maximum was 64. Is it a DirectInput joystick device? See the FSUIPC Offsets list, offset 3340. See what it says there? Virtual buttons, operated by writing to the 36 bytes 0x3340-0x3363, are treated as joysticks 64-73. You have the equivalent of 8 joysticks (8 x 16 = 128), so 64-71 seems correct. Surely you must know: you must have written the program which is writing to these offsets, or at least been told by the author? Well, they are all the same to FSUIPC, just bits in offsets. You'll need to look at your hardware of whatever program you have writing to FSUIPC. Is it an encoding rotary, pulsing one or the other buttons according to direction, or one which pulses both all the time but with different phasing to differentiate the direction? The latter need quite a complicated programmatic treatment to decode. There is a discussion on this in the Advanced Users guide. "Skipping values" is meaningless in relation to buttons. The buttons will simple be "pressed" and "unpressed" alternately. There's nothing to "skip". The rest depends what you do with the button press/release indications. Pete

But each time the button repeat occurs, within a certain allowed time (66 mSecs by default) the Lua thread is forcibly terminated if it hasn't done so by itself, and re-loaded, recompiled and restarted. The time allowed for it to terminate by itself is set by LuaRerunDelay=66 in the [General] section of the INI file. So, your button is repeating at 20 times per second (default joystick scan rate -- same as keyboards) and so the Lua is being terminated and restarted well before the 400 mSecs is elapsed. On average you'll succeed in slowing down the repeat rate by the 16 mSecs plus the time to terminate, reload, recompile and restart, but it won't be by 400 mSecs. You'd be better off NOT using repeat, but having a loop until you detect that the button is released. So even if you assign direct to the Lua plug-in rather than use an event as I suggested, try it as follows: 1. Assign "press" to the plug-in, but NOT repeating 2. Assign LuaSet to the button release, with a flag number (eg 0) 3. Revise your plug-in like this: while 1 do ipc.clearflag(0) ipc.control (70481,2147483647) ipc.sleep (400) if ipc.testflag(0) then ipc.exit() end end This way it is loaded once, and the timing of your increment/decrement actions is fully controlled. Pete

As well as what Thomas says, this is quite possible with a Lua being constantly loaded and deleted. Each Lua is another thread, running in a processor, and creating and deleting threads takes time. Instead of this: use an Event to detect a Lua Flag being set (assign to Lua flag, and toggle it), then put yourr ipc.control call in a function and call it withe an event.flag. Get the Lua plug-in preloaded by using an [Auto] section in the INI file. Of course, your true application must be more complicated than just the one ipc.control, because for that you'd just assign directly. Incidentally, I don't see the point of the ipc.sleep(400). Your repeat is happening (by default) at 20 per second (50 mSecs), so all out of them are simply terminating and restarting the thread, as Thomas said. Why have repeat if you want to slow it down to only 5 actions every 2 seconds (which would work in any case)? You might as well simply press your button or key several times. Sorry, too much has changed in the 6 years (!!!) since 4.858 that I cannot comment on that. I expect thinmgs have been made to work properly or better, but perhaps just not as you expected. Check the History document to see for yourself. Pete

Very strange indeed. I don't understand how it can have an Access Denied failure for a folder it has itself just created. That makes no sense whatsoever. I really have no idea how to proceed on this. There's no debugging I can do because the information is in front of you -- the return from attempting to create a file in the folder just created is Error 5, meaning Accees Denied. No other information is going to be available. The oddest thing is that FSUIPC itelf can create a file (the FSUIPC LOG you showed, and presumably an INI file?) and that isn't even normally running with Admin privileges Mind you that isn't the same as the FSUIPC Documents sub-folder. Though can you check whether there are ANY files in that folder? If there's a file called "Controls list for P3D4 Build xxxxx.txt" (xxxxx = build number, eg, 24048 for 4.2.21). Then I tried other download links for reinstallation Also, if FSUIPC5.DLL can write a Log and an INI file to the Modules folder, and the Installer can write the DLL there, how come it cannot write a KEY file? Actually, this is starting to smell lke an Anti-vius / File Protection action. Have you disabled all of that, in Windows and in any add-on protection program? I can see how it might not like KEY files, and it may not trust PDFs either. And the Plug-Ins ZIP contains Lua programs which it might not like. Best disable them for a re-test. Pete Pete

There's always a delay on the Schiratti updates, but the link points to the same download as the one here. The advantage of that route is that you can see if there are any interim updates which might fix your problem. But the full install will always be the same as on the Schiratti site -- only the text on the latter isn't alwas updated very quickly. Pete

This is probably just the structure in the 64-bit version of the LIB file. FSUIPC5 was changed to recognise both structure definitions -- they are not the same because of the presence of a pointer. The pointer isn't used by FSUIPC, but by the code in the user program designed ot parcel out the received data into the program's locations. Of course 64-bit pointers are larger than 32-bit ones ... I'll have a look at making WideClient recognise both structure types. But it won't be today I'm afraid. Maybe tomorrow but more likely over the weekend. I think you are the first person to come across this. Obviously most folks are using 32-bit. Incidentally, I think that FSUIPC4 (32-bit only) wouldn't work with 64-bit apps either, for exactly the same reason. I'm not sure I want to change that, but I might take a look. Meanwhile, if your need is urgent you can program around it, using relative addressing instead of a full 64-bit pointer. The source for the LIB fuctions is supplied. Pete

The all point to the same file, but it is version 4.974 now, not the 4.972 you appear to be downloading! The install log you posted shows that the Modules folder exists already, so presumable for the "unregistered" attempt. But it also shows "access denied" for the FSUIPC Documents folder. It looks like your Modules folder is marked "read only". Can you check? (right-click, select Properties). This, hpwever, is refuted by the LOG you posted, which is dated and timed quite recently, and if that was in the same Modules folder it cannot be marked "read only". What was the date and time on that Install log you posted? I suggest you delete the Modules folder entirely (check that it is deleted). And try again, bt this time show me the Install log directly after that, without trying again. Pete

Well, there's very little difference to 5.124. But can you try adding this line to the [General] section of the FSUIPC5.INI file: UsePDK=No That will make 5.124 the same as 123e, at the cost of a heavier load on SimConnect (which really should affect add-ons like the PMDG aircraft more). There's no change in FSUIPC for the Options dialogue -- all that is purely a Simconnect function, plus standard Windows dialogue stuff. Pete

What was the previous version of FSUIPC5 you were using, with the PMDG aircraft? Have you tried doing things without loading the PMDG aircraft? Is your PMDG aircraft fully updated? There was a problem with earlier versions, calling a facility in FSUIPC (if it is loaded) in the wrong way (32-but method) which was fixed. What do you mean by "just as the plane systems start loading from 20 sec (I think), it get's interrupted."? Possibly that's where it gets to the point where it calls FSUIPC in the unfixed version. Pete

Is the Registration being rejected by the Installer when you input them, or is it accepted by then not working? Are you using copy-and-paste to make sure there's no mix up with 1/I, o/0 2/z etc? ZIP up your FSUIPC4, WideFS7, FSUIPC5 order details and the FSUIPC5.KEY file (also your FSUIPC4.KEY file if you still have FSX or P3D1-3 installed), and send the ZIP to me at petedowson@btconnect.com and I'll check them. Pete

The WideFS registration for FSUIPC4 is the same in FSUIPC5. If it is being refused you are entering something wrong. The NAME must be the same for both FSUIPC5 and WideFS, the email address can be different and you use the one for your FSUIPC4 WideFS registration. Pete