Pete Dowson

I can only think of two possibilities: 1. There's some sort of firewall blocking the connection. Usually if this is the case you'd probably not get the "Connection made okay" message, but maybe it is only a firewall on the Server end. 2. Something else is using the same port on the Server, so the connection is made initially by the two ends do not agree with each other. By default WideFS uses ports 8002 and 9002, but you can change these. You'd need to edit both the server setting and the client setting -- in FSUIPC4.INI on the Server and WideClient.INI on each Client. Pete

If it is in the correct [buttons ...] section, it doesn't really matter where it goes (note, NOT "at the end of the INI file", unless the correct Buttons section is at the end of the file!). However, the entry number, your 'n', defines the ORDER in which the lines are processed. So bear that in mind -- lines referring to the same action button (j,b in your example) may need to execute is a specific order for your logic to work correctly. Pete

Version 0 being reported simply means the program could not read the correct data. Zero data is supplied when there is something wrong, such as a bad registration or a date inconsistency. Please after such an attempt, close everything down and then find the log files -- FSUIPC.LOG and WideServer.log in the FS Modules folder, and WideClient.log in the same folder as WideClient, and paste their contents into a message here. Use the <> button above the edit area for the message to enclose the texts. Pete

Where is there a link to AIBridge? Sorry, but it is not a program I remember at all. Pete

Sorry, you'll have to explain what you mean by all that. Are you trying to make fun of me, another septuagenarium, for some reason? Maybe to you 71 is a young age, but I don't feel young at all, especially with my RP deteriorating still. White stick time coming soon I fear. :sad: Did you rename those two files in the Modules folder? If not I don't understand why there's a ".exe" in them. I'm think the INI and LOG files I think should actually be named FSUIPC4.AFR-FriendlyD3D.ini FSUIPC4.AFR-FriendlyD3D.log though there is no need to do so as such files will be generated automatically when FSUIPC executes. You'd only need to do it with the INI to retain your settings. If FSUIPC did generate them itself with the .exe part included, then, fine, that maybe is how it should be. The names would certainly have an ".exe" in them if the executable P3D file being used had a double .exe (ie .exe.exe), which seems unlikely. I don't use P3D myself, let alone have luxuries like SLI, so I'm not able to repro this in any case. If you want FSUIPC still registered you still need to take another step, i.e. make a copy of that FSUIPC4.KEY file renamed as FSUIPC4.AFR-FriendlyD3D.key, or, perhaps more likely in the event, FSUIPC4.AFR-FriendlyD3D.exe.key Pete PS I hope not to need a wheelchair just yet, but that could depend on just what's wrong with my back. Another physio appointment this morning. :sad:. At least we have the Stannah stair lift installed ready.

Windows and FSUIPC count buttons from 0-31, whilst FS and many devices themselves count 1-32. Pete

Looks like you've simply not followed the instructions given at all. The directory listing picture you posted shows you placed the P3D EXE for the SLI mode you want into the Modules folder. Why? Surely that's the P3D version you want to run! It can't run from the Modules folder! Also you still have Windows hiding the filetypes from you so you cannot really tell what file is which. Please change your Explorer folder options to unhide fitletypes. Instructions are given for this in the FSUIPC User Guide (and I think, even in the Install guide, but i'm not sure about that). Regards Pete

The problem I would have is that I don't know the Lua plug-in you are trying to use. Why would you need a plug-in to operate a cockpit switch in the first place? Isn't it supported in the normal way? Checking the Lua plug-in you mentioned, it seems parameter 17 should cause this section to run: if ipcPARAM == 17 then -- Cycle LVarSet = "L:ignSwL" if ipc.readLvar(LVarSet) == 1 then val = 0 end if ipc.readLvar(LVarSet) == 0 then val = 2 end if ipc.readLvar(LVarSet) == 2 then val = 1 end ipc.writeLvar(LVarSet, val) end so, just monitor the L:Vars and see if that one is changing. You can list LVars in the Log by assigning to the FSUIPC-added control to do that, or you can simply have the Lua plug-in running to log Lvars live, as they change. That one is supplied in the Lua examples ZIP in your FSUIPC Documents folder. Finally, to see exactly what the plug in is doing you can switch on the Lua trace/debug option in FSUIPC's logging tab. That shows the line number of every step of every Lua as it is executed, and the values on any global variables, like "LVarSet" and "val" in the section of code above. Pete

What do you mean "missing from the starting everything now"? Lua scripts aren't listed in the log, and I don't know what you mean the "the starting everything now"? ..These are messages from some Lua script you are running. They are not from FSUIPC itself. No, not unless you are explicitly logging them or they log messages themselves. Why do you think the log should show everything which happens? It would get huge on some folks systems! Sorry, I don't understand. What's a "proper log" in your opinion? Please explain what you are talking about. The logging tab merely reflects the logging options you've selected. They are saved in the INI file. I've really no idea whatsoever about what problem you think you have nor why you are so weirdly concerned about the log. Perhaps if you'd explain the problem instead it would help? That is what it will show if you enable Button logging and press a button. What is wrong with that? What is your point? Pete

Were they all .PNL files? They weren't being deleted until now (with 4.936c) because I didn't know about them. All the other default ones should be managed correctly, in the cycle, no problem. If you have add-ons also creating files those can be managed too, but you have to add parameters to the INI file so that FSUIPC knows about them. Pete

The names of FS controls listed by FSUIPC are the names assigned by FS itself. FSUIPC knows nothing about them. You either need to try them and see, or just enable FSUIPC's Event logging (in the logging tab), then use the same controls on the keyboard and see which ones are sent. If you (temporarily) run FS in Windowed mode you can use the Console Log (another option on the Logging tab) to see the logging in real time on screen. Pete

Right. done. Easier than I thought. Please download the updated installer package: Install_FSUIPC4936c.zip. When you run this and it can't find the Prepar3D.exe you'll get an Explorer window. just find the Prepar3D exe and select it there and it will work. Later it will ask you if you want the Registry fixed. Agree and you'll be okay from then on. Pete

Er, yes. I'm off from first light this Thursday, 25th Sept, back on Wednesday 8th October! Germany-Austria-Czech-Slovakia and back. I reckon L-M are timing these things deliberately! That's every single release since 2.0! There's no point me working with the Beta releases. I did that before but by the time I've sorted it another is out and I start again, so I decided to await the release. Sorry. Regards Pete

It is not really difficult, and not dangerous. Before we start, though. Can you re-check the exact path. You said: This looks a little unlikely to me, as "Prepar3D is not spelled with a space normally. If it is "Prepar3D v2" not "Prepar 3D v2" you'll need to make that change in all the following. If you save the following text as a REG file (eg "FixP3DPath.reg") anywhere on your disk, then double click on it to make it execute, it will fix the entries for you in any case. You will probably need to run it "as administrator" (right-click and select run as ... administrator), and it will ask you for confirmation before it does anything. Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Lockheed Martin\Prepar3D v2] "AppPath"="H:\\Lockheed Martin\\Prepar 3D v2\\" [HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v2] "SetupPath"="H:\\Lockheed Martin\\Prepar 3D v2\\" [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Lockheed Martin\Prepar3D v2] "SetupPath"="H:\\Lockheed Martin\\Prepar 3D v2\\" I'm trying to cover all the bases here -- different installers, different versions of Windows, different places, different parameter names. Extra entries won't do any harm provided they all point to the correct place. Meanwhile, I've now managed to reproduce the case where the File Selection dialogue, asking you to help find the program, doesn't appear. I am working on this now to fix it. Apologies for not quite believing you on this one. It has taken me quite a feww convolutions to actually reproduce it. Very strange, but now I can i can fix it. So, if you'd rather not try fixing the Registry yourself, above, hopefully I will be able to give you a revised Installer to try soon ... Pete

Well, you don't really need much of the language itself. Just one line with ext.run("pathname for program to be run") or, if it needs parameters ext.run("pathname for program to be run", "command-line parameters") Pete

Either. Not much in it really. Pete

Thank you. I am lucky in the sense that the RP I have (and my children, and probably my grand children) is one which starts at the peripheral vision and deteriorates slowly inwards, giving me severe tunnel vision. The types of RP which first affect central vision are much more difficult to deal with, making reading and detailed work very hard. Best wishes, Pete

Just edit the calibration line in the [JoystickCalibration] section of the FSUIPC4.INI file, after calibrating normally. You'll find it in the Modules folder. A typical entry looks like this: Aileron=-16128,-2304,-256,15615 The numbers are those directly saved from the calibration tab in the options screen -- i.e. minimum, low centre, high centre, maximum. Change the first number (eg -16383) to a lower value, one which the actual input cannot reach (eg -16800). The lower that value the further away from idle will be the calibrated back position. Same can apply to the last number, for the maximum position. Of course if you have the axis reversed in FSUIPC the ends would be swapped over. Pete

There is no difference writing a value to 0x66C0 than to any other offset. The SDK has examples I think -- I don't know VB at all so I can't help directly, but many hundreds of others have used the SDK without problems. If you don't know how to interface to FSUIPC and are struggling, as I presume from your questions, I suggest you investigate Paul Henty's .Net package for FSUIPC. See the subforum here on this subject which Paul monitors. Pete

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