Pete Dowson

I think that should be: "C:\Windows\surun.exe" c:\windows\notepad.exe or even just C:\Windows\surun.exe c:\windows\notepad.exe unless "surun.exe" handles the "". And whether or not spaces in parameters are handled depends solely on the program processing them. I'm pretty sure everything after the program identity can be handled in whatever way the program wants to. Pete

Reading and writing to any offset is all the same. I don't really understand why you think there's any differences? Of course, writing to a "free" offset does nothing at all unless something else is reading it! Pete

I think in that last example "c:\windows\notepad.exe" is a parameter to the program. the "" enclosing it all makes it part of the program pathname. Try Run3="C:\Windows\surun.exe" c:\windows\notepad.exe I think only the program pathname needs quotes, and actually it only needs those if there are spaces within. The quotes make the spaces part of the name, hence the parameters get to be part of that name if you keep them within quotes. This is all to do with how Windows accepts command lines, it is nothing to do with FSUIPC itself. The same applies to the OP's query: should probably be: Run1=CLOSE,"C:\Program Files (X86)\VAC System\VACSystem.exe" leveld.xml,True Pete

Any way you like. They are free for users to use in whatever way is useful to them. Yes, of course, any program interfacing to FSUIPC thought its standard application interface can write any value to almost any offset. Have you downloaded the SDK? Pete

No, you should get those requests in any case. There's no way in the program for it to bypass any of the steps it goes though. I'm rather at a loss to understand what is happening on your system. ALWAYS, if it cannot find the program, it asks you where it is, and all you do is select the path and EXE file in the dialogue which appears. I cannot see any way it can b-pass this. And the only way out of the program, without forcibly closing it, it by answering the questions about Registration, like "Not now" or whatever. What you describe is very puzzling and I see no way it can happen, so I have a problem. I may have to make a spcal version with a log more logging so I can see why your system is behaving so differently. So the correct Install path, which would have neren in the Registry for a normal proper install, is "H:\Lockheed Martin\Prepar 3D v2"? not just "H:\" which is all that is in the Registry. How did you manage to insdtall it and get the Registry so badly wrong? If it is a Lockheed-Martin installer bug you should report it to them. Have you been moving thongs around after installing? You said some time back that some folders were left elsewhere -- is that due to you moving things? The best way of fixing all this is to fix the Registry so it points to the right place. I already suggested that, if you recall: Otherwise you should edit the Registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v2 changing parameter"SetupPath" to point to the right place, as it surely would if you'd just installed P3D normally. Currently the stup path is set to just "H:\" which clearly cannot point to the Prepar3D program at all! Use Regedit to correct the path. H: is the drive letter, not the path to the Prepar3D program. "Paths" include folder/directory names. Paths take you to the program, not just to the hard disk drive. Pete

Did you change them to be the same? By default I'm sure the XP workgroup is different from the Win7 workgroup -- don't know about Win8 though. What do the log files show? Both the server and client produce a log showing what is going on -- WideServer.LOG in the FS Modules folder, WideClient.log in the client folder. Please paste them both into a message here, along with your WideClient.INI file. Pete

The problem doing that is that it buries your new query rather deep and mostly unnoticeable. The manual for installing is actually the one entitled "Installing and Registering FSUIPC4" and it accompanies the Installer EXE in the same ZIP. The only other Manuals are those installed for you by the Installer, so obviously not available until after the Installation completes! No no no! The Installer simply uses the path it finds in the Registry. IUt does not care where it points. It uses the path in the same way any installer would. In your case the path "H:\" apparently did NOT point to a place where the Prepar3D.EXE was to be foundd! When the Installer cannot find the EXE it ASKS THE USER to find it instead, using a normal file directory dialogue. Once you so identify the correct EXE the Install proceeds normally. The error message you showed occurs when you cancel that request, effectively saying you don't know where that EXE is. I don't know how you read it that way. I have NEVER installed any version of FS into Program Files, and almost always on a separate disk. The Installer doesn't really care where you place it, it just need the correct path! Before that it would have shown the dialogue for you to indentify the correct path to the EXE. Then, if you'd bothered to click OK to the P3D error, it would have come up with the option for you to Register your FSX installation. The Log file, which would have been placed in the FSX Modules folder (because it knows of nowhere else to place it), would show all this and terminate with a proper termination message. This has all worked for many hundreds if not thousands of users. I really don't know why you disbelieve what I tell you. :sad: Can you please tell me what the actual path is to the P3D EXE? I do have an H drive and can certainly simulate installation into a folder on such a drive, just to prove there isn't something mighty odd about the letter 'H'. (My previous installations have been to D: E: and F: drives. I always traditionally used "F" for "Flight", D for "Data" and E for "Extras". :-) Pete

There's no RunKey option in FSUIPC, it is purely a WideClient facilty. You can do what you want and more using the Lua plug-in facilities. Checkout the ext library, and in particular, ext.run, ext.shell and ext.runif functions. Jun a one line plug-in assigned to your button or key will do the job. Pete

You are lucky I saw this. Adding to page 2 of a year-old thread is simply not a good way to attract attention and get a reply. Please, with new queries start your own thread with an appropriate title. The installer log shows that the Registry entry for the P3Dv2 install path is just H:\: INSTALLATION FOR Prepar3D v2: SetupPath="H:\" Checking version of the Prepar3D v2 EXE: Evidently it doesn't find Prepar3D.EXE there. It would have then prompted you to find the EXE, using a normal directory dialogue. When you find it yourself that way, the installer will even try to fix the Registry entry for you. Judging by the message you then posted you aborted that instead of doing what it asked. Also, the Log file is unfinished, meaning you even aborted the Installer itslef. There is never a need to do that! You said Of course you can't edit the log of what it is doing! The information you need to edit is in the Registry, not in the Installer! You go on to say: As it CLEARLY says, it finds the Registry entry stating that P3Dv2 is installed! It is the actual program, the EXE, which is NOT in the place the Registry says it is in! How on Earth do you find this confusing? Please explain. The Registry is there for a purpose. It registers the software you install and records where it is. Most installers use it to work out what to do, to make it EASIER for you, not to CONFUSE you! I don't know how you got in this mess, but the installer can try to fix it for you if you only followed the instructions and prompts provided. Otherwise you should edit the Registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v2 changing parameter"SetupPath" to point to the right place, as it surely would if you'd just installed P3D normally. No, of course not, not unless you want to use it!!! The Log is just telling you what the Installer looked at. It is the one installer for FSX, ESP, P3Dv1 and P3Dv2, and it will install into all 4 if all 4 are installed. If they are not installed it won't, obviously? Pete

There is no way possible for togglebits to set bit 3 with a parameter of 3 -- you would need a parameter of 8 (2x2x2 = 8 ). I believe you are misinterpreting what you are seeing. If the offset 78EB starts off as zero (0) then toggling with 3 would set the value 3, not 1 or 2, and alternate that with zero (0) I did say right at the beginning that the easy method I was explaining would only work if that offset was set to or 2 at the start. did you miss that point altogether? If you do not believe what I tell you then I think you must prove it to yourself. In the FSUIPC logging tab, on the right-hand side, enter 78EB in the first Offset space, and select type U8 in the type column. Then below check "normal log". Also enable button/key logging on the left. DO NOT PRESS ANY OTHER OPTION, just ok out. Do your test and then get the FSUIPC4.LOG file from the Modules folder. Check that, or paste it here so I can explain it to you. Pete

No no no! The parameter for "Togglebits" is a MASK, NOT a bit number. Why on Earth do you think it is a bit number? Where do you get that idea from? A mask of 255 changes all 8 bits, not bit 255! Every bit set in the mask will be toggled. The value 3 is bit 0 and bit 1. both those bits will be toggled! There are also "SetButs" and "ClearBits" controls. The three of them, together, do the logical operations "NEQ (togglebits), NAND (clearbits) and OR (setbits). If you do not understand logical operations I suggest you look them up -- Google is your friend! ;-) Of course not! Line 0 will reverse bit 0 and set the flag. Then line 1 will reverse bit 2. You certainly don't want any of those things. Think about it. Think logically about what is happening here! Please, please, read what I say and see if you can take my advice? :sad: Pete

You seem to have missed the whole point of using "toggle bits". By having a parameter of 3 then toggling will give you alternately 1 or 2 depending on thether you start with 2 or 1. i.e. 1 toggled by 3 = 2, 2 toggled by 3 = 1. Please re-read my previous reply. To do it with flags is unnecessary UNLESS you cannot ensure the offset starts with 1 or 2. If it does not, then you cannot use toggle bits in any case, but the set control instead, and a flag. But the flag must be tested when setting both conditions -- one for flag not set, one for flag set. But first read my previous reply which you seem to have misreadcompletely. Pete

Sorry, I do not know of anything in common between IVAO software and FSUIPC. Neither is aware of the other and they are totally independent as far as I am aware. FSUIPC itself does nothing on the Network nor on the Internet. I can only suggest you check with IVAO support or its Forum. I know that many on-line flyers with both VATSIM and IVAO also use FSUIPC so I can only assume it is something specific on your PC. Maybe some other FSUIPC-using addon? Pete

Saitek axes jumping idle to max seem to be a frequent problem, and related to Registry settings I think. Check the Saitek support forum. If it isn't that it must be dial assignment, probably in P3D as well as FSUIPC. Bad idea to have controllers enabled in P3D if you assign in FSUIPC. You can calibrate in FSUIPC even if you assign in P3D. You can also assign the hat and buttons in FSUIPC, so I've no idea why you'd risk enabling controllers in both. There is absolutely no difference between FSX and P3D in FSUIPC in this area. The code is the same code, exactly, and it is doing exactly the same things. So, assuming it isn't just a result of your enabling controllers in P3D, which it could be, either there is something preventing FSUIPC writing the results back to its INI file (in the Modules folder), or something else is going on in P3D. Check the Modules folder. Are the LOG and INI files being updated each session? They should be. If you disable controllers in P3D is it then okay? Conversely, if you assign in P3D is it then okay? Pete

There shouldn't be conflicts in any case if you don't actually press the keys. Why does "FSwidgets" program need FS running as Administrator? Are you running FSWidgets as administrator for some reason. Best to run nothing "as administrator" except when installing things. Does the other keyboard work? If they are both standard keyboards then they should both operate identically. When you say FSUIPC won't send commands, what do you really mean? Is it seeing the keyboard or not? If it does, then there cannot be anything stopping it sending controls. By commands do you mean assigned controls? Pete

Ah, sorry, my mistake. Checking the code I see that I eliminate the terminating zero. If you want that you have to set a length of 2. Not sure what you expect to find b Googling. The documentation for all of the FSUIPC Lua libraries is in the FSUIPC Documents folder, nowhere else. If you want to learn more about Lua itself, rather than the libraries, the link to their website is given in the documentation also in the FSUIPC Documents folder There are also lots of examples in there. Because the com library, like all the other libraries added in FSUIPC and WideFS, are specifically for use with FSUIPC and WideFS. The only documentation is that in the FSUIPC Documents folder. What is wrong with it? The information is all there, and lots of examples. You seem to be very confused. Haven't you read any of the documentation I supply at all? I don't know about "COM sniffing", but certainly the program I use, the one I pointed you to, the Device Monitoring Studio, is fully capable of monitoring any COM or USB port. It installs a low level monitor into Windows and needs a re-boot after installation in order to get the privilege to intercept ports. Pete

Yes. Pete

Okay, I think I've nailed it. Unfortunately you didn't post your complete INI files for comparison so I had to go back to your originally posted full INI files to check. The problem is only between your devices D and G. When device D is missing, device G is substituted. The other missing ones have no effect. The reason appears to be the NAME of device D: D=2Axes 8Keys Game Pad This is the entry for it in the Registry. The problem arises because there are some USB devices where the exact same Registry key points to the Windows device ID. Because the device is missing, the normal registry entry for the ID is missing, so FSUIPC uses this alternative key -- and gets the ID as "2" from the name "2Axes 8Keys Game Pad". So, it sees the device is 2 and matches it to the entry for G: G=USB Gamepad G.GUID={92D89300-3063-11E4-8001-444553540000} because G is device 2: 2=USB Gamepad 2.GUID={92D89300-3063-11E4-8001-444553540000} This is why it doesn't comment device D as a << MISSING JOYSTICK >> as it does with the other disconnected devices. In other words, the exchange is a result of a very odd combination of circumstances, which will explain why it hasn't been a problem before in the many years of this facility. I'm not sure it is possible to fully defend against this happening in all circumstances. I need to be able to differentiate between the number in the registry being part of the device name and being the assigned ID. For now I'm assuming that if there are further non-numeric characters after the number then it must be a name. The fix will be in an interim update in the Download Links subforum later today. [EDIT] Version 4.936c, available now. Regards Pete

Your SimConnect is being blocked and stops responding.This starts occurring 26 minutes into your flight, but FSUIPC does recover -- though such recovery may make things very jerky. The stall repeats every minute, almost precisely, and there's another repeat (and extra one) every 6 minutes. So something you have set to operate regularly, like those times, is clogging up. Maybe virus checker, disk defragmenter, autosave? First check on your background programs like virus checking, optimisers etc. The repeated reconnections, at 1 minute + 6 minute intervals continue consistently until 73 minutes into the flight where the retries don't work either. SimConnect and I should think FSX is stalled completely. Pete

I'm not exactly sure what "g" 1 would do -- I think it would make a string containing "G1" and the zero terminator, so sending 3 characters. You'd need to refer to Lua documentation. I found out that Arduino in default settings has 8-N-1 mode Yes, that's just the standard 8 bit no paraity 1 space bit mode. That's exactly what you get. Or maybe am I missing something when LUA Library pdf says that I should use n = com.write( ? What should I in my simple example place instead of n? Nothing. "n" is the variable into which the result of the com.write is placed. It's the number of bytes actually sent -- why not refer to the documentation for such information, it is all there, explicitly!? I think you need to check exactly what you see getting sent both from your Lua and your other method, and compare them. I already suggested Portmon and another program. I cannot help you further, you have to help yourself. I've no idea what your Arduino wants. Pete

No idea, sorry. Both are sent correctly as you can see. The rest is up to FS. But why on Earth are you assigning keystrokes when you could assign direct to controls? Keystrokes are assigned in FS, so you are pressing a button for FSUIPC to look up in an assignments list so it can send a key to FS so it can look up the correct control in its own assignment list! See how inefficient that is? Why not just assign the button to the control in FSUIPC in the first place? Pete

Is this all aircraft of only some, or only one specific add-on? I've never seen anything unrealistically slow here, but I use FSX. If it varies by plane, by model, then it may well be controlled by an Aircraft.CFG parameter or maybe one of the hidden ones in the binary AIR file -- for the latter you'd need an AIR file editor like AirWrench. But if you know better about how the model should operate than its designer, perhaps you should get in touch with him about it and get the modelling improved at source? Otherwise, sorry, I'm not an aircraft designer myself and don't really know anything about these areas. Regards Pete

Sorry, but I cannot support a six year old version of FSUIPC. If you want support you need to install the currently supported version, 4.936 or later. Pete

You really always need to state the version number. It isn't hard to find -- it is displayed in the options, it is logged in the files in the Modules folder, and it makes it clear what you are using. There have been plenty of times folks have reported the same as you but by "latest" or "most recent" they just meant "the last one they noticed" -- sometimes up to a year before! And there is no difference between payware and freeware, only a registration. Sounds like the connection to SimConnect is failing, possibly through overloading. FSUIPC and both PMDG aircraft are very heavy users of SimConnect. But I can't tell from the information you supply. Please, next time it happens, take a look in the Modules folder for the FSUIPC4.LOG file. That will indicate if there are any problems. If you like, post the text from the log here -- use the <> button above the edit area to envelop the text when pasting. Pete

No -- I think you must start PortMon and select the correct port before any program opens it. it the device is using a virtual port via a USB connection then you probably need to have the device connected, but no program trying to use it. But I'm not sure about that -- it has always worked for me. There are more sophisticated programs which can do more, and may work better for you. Try "Device monitoring studio" www.hhdsoftware.com/Downloads/device-monitoring-studio It's the handle, or identifier, of the device you are using. It relates back to the com.open, as you surely must have noticed: handle = com.open("COM3",9600,0) You can have any number of devices open for reading/writing. the handle determines which one! The line com.write(handle, "a") sends the string "a" which is two bytes -- the ASCII character "a" (0x61 in hex) and the zero terminator (0x00) -- i.e two bytes altogether. If you only want the single character 'a' sent you must specify the length parameter too, i.e. com.write(handle, "a", 1) Pete