Pete Dowson

As well as what Thomas days, please note that you do also need to actually assign the axes to the correct actions, not leave it to pot luck. If you are assigning in FS make sure the FS assignments are correct, because obviously they are not. If you want to assign them in FSUIPC, take care first to disable controllers altogether in FS or there will be conflicts! Pete

Aha! in your original, FSUIPC4 is in the wrong place. It should be right near the end. There have always been TWO modules which like to only be at the end of the DLL.XML file -- one is the ASN one (as_btstrp.dll) and the other has always been, for as long as I can remember, FSCopilot.dll. So when my Installer checks that FSUIPC is in the correct position (virtually at the end), it simply makes sure both of those are placed AFTER it! Are you now reporting that after all these years FSCopilot have changed their methods and need to go before everything else? I can easily just ignore FSCopilot -- it's less code for me, but there were always problems when FSUIPC followed FSCopilot in the list. When did this change? And why do you move FSUIPC4 away from the end? That's not right. Pete

The problem is that you don't have any axes assigned to Joystick "A", so FSUIPC isn't actually scanning any of them. The ipc.axis function only grabs the last polled value for the specified axis, it doesn't institute a poll of its own. "16191" is 3F3F in hex, and that's part of a 32-bit value "0x3F3F3F3F" used to initialise the read area so that the first change will be seen. The ipc.axis function only takes the lower 16 bits. The Lua library description of ipc.axis does say: Returns the current assigned axis value as read from the device (i.e. before calibration). I suppose it could be a little more useful if, when a Lua program did use this function, that it either did its own poll, or maybe add the axis to those to be regularly polled. The former is quite a big addition, being new DirectInput code in the Lua package, and the latter would be rather wasteful if the Lua function was simply a one-off need in a session. However, if it s very important I could look to see how feasible one of these changes would be in the current structure. The assignment need not be to anything of any effect. For instance, assign to <custom control> with a value 65536. That's a reserved control value which does nothing at all. Pete

Ugh! Those awful things are a pain. They mess up the installation entries in registries and don't repair them afterwards! Bad news all round. Why? What changes in the DLL.XML which mucks them up? It doesn't change it if the FSUIPC4.DLL entry is in the right place. What is the difference between "before" and "after" which is messing other programs up?. There's no way I know it can possibly do that. Unless you show me the two results I can't really help you! Pete

Nevertheless, the correct way is by checking "extras". Having offsets monitored is a diagnostic facility and is not so efficient. Pete

Not odd, it is the "Extras" logging option which gives you those entries in the log, the Monitor facilities on the right-hand side don't stop that, they are just not needed for that. Pete

All the offsets relating to FS itself (and this is one of them) are actually listed in the Offsets list installed for you in your FSUIPC Documents folder. As Thomas says, FSUIPC Offset controls such as those you list are entered in the options in the Add-Ons FSUIPC dialogue, in the Buttons & Switches tab (or even Keys, if you want to to assign Keys). Full instructions are included in the FSUIPC4 User Guide, also found in your FSUIPC Documents folder, and there's an example specifically of the offset increment/decrement controls on page 31. With reference specifically to rudder trim, there ARE actually controls for rudder trim. Unless you want a non-standard increment/decrement amount you can assign directly to "rudder trim left" and "rudder trim right" in the assignment dropdowns. Pete

You don't need those. That's only if you want to monitor the VAS in a Window or on the title bar. They do nothing without one of those options ticked below. Also, going back to your first post: Just a clarification: You don't need to tick anything to get FSUIPC to create a log. It ALWAYS creates a log, you can't stop it. And it doesn't matter if it's "full" (I assume you mean "registered") or not. Pete

Saitek seems particularly prone to these installation errors. Did you check the FAQ subforum? The first thread is " Fixing joystick connections not seen by FSUIPC ". As Thomas asks, is it seen by FSX? And looking at your INI: The X-55 is seen twice, once as a Stick and again as a Throttle. Not only that but you actually have an assignment made to the Throttle! There are furthur assignments later, too, in a Profile called "all": Though that section appears to be corrupted, with an incomplete line and duplicate entries. Looks like your FSX crashed or something whilst the INI file was being written. Either that or it's some sort of disk corruption. You also have the throttle calibrated: So, are all these settings wrong? How were they created if the X55 is "flat out not seen by FSUIPC"? FSUIPC cannot guess that you have an X55 and do some assignments and calibration on its own volition. It only does wat you tell it. Pete

Thanks. Got it now. I'll see if I have time next week to look into it further. I'm away all weekend (though I'll be using my iPad to keep up to date, I'll have no access to my development system). Pete

Most unlikely. It is just deleted. It won't come back till next time it is scheduled, unless there's a program injecting them (like UT2) which detects them gone and re-injects them just to spite you (unlike UT2). No minimum. Do you mean maximum? 0.25nm on the ground, 1.5nm in the air -- but adjustable by you, the user. The answers to this (which is adjustable) and more are given in the Advanced User's guide, starting on page 9. By default, the former, within an acceptance angle which you can choose. But there's an option to zap the nearest anywhere around you. See page 10 of the Advanced User's guide. When you need to find information about FSUIPC the answers are almost invariably in the documentation -- either the User guide or the Advanced one. After all, that's what it is for. And with any PDF viewer you can easily search for items. I just searched for "zapper" for you so I could be specific about the range, and the page numbers. Pete

Hmm. It would have been useful to see what the INI file was like beforehand. I can't see how that would get corrupted. Could the joystick IDs have been moved around do you think? Again, comparing the old INI with the new one you've now created woulds tell us. Pete

One more thing I thought I might try. I don't hold out much hope, but i thought if I compared the source of the LuaSockets component files I used with those for the later version, I might be able to see what I need to change just that way -- in the hope that none are a complete re-write. However, following the link you posted much earlier takes me to a directory structure which, yes, does have a "src" subfolder witrh source data, but they are all just text files on scren. I can't find a package to download the complete LuaSockets source as you can with the version I used. So, how did you get them to recompile? Did you copy every one individually to your own files? Pete

One more look at this from me. Do you know which part or parts of the Lua sockets programming has the bug stopping multicast working correctly? I had a thought. If I could narrow down the problem to a specific part of the built-in sockets code then maybe I could fix your original problem -- instead of trying to upgrade my whole implementation of Lua and sockets to a later version. But there's a lot of it, and I see a lot of changes listed apart from the support for lua 5.2 from 5.1, so locating the area to fix without any real knowledge of sockets or the problem is well nigh impossible. So any clues you have might help. Is it likely to be contained just in that one call: udp:setoption("ip-add-membership" , { multiaddr = "230.1.1.1", interface = "*"}) so if that didn't fail, it would work? I'm going to start by adding the error number returned by that to the "setsockopt failed" message. [LATER] The error is 10042, which says: WSAENOPROTOOPT 10042 Bad protocol option. An unknown, invalid or unsupported option or level was specified in agetsockopt or setsockopt call. The parameters being sent to the setsockopt function are: socket id - ok level = 0, This I don't understand. Shouldn't it be 0xFFFF for "SOL_SOCKET"? optname = 5. I think this means SO_REUSEADDR and SO_DEBUG, as the options are bit-oriented. optval points to 8 bytes { 0xC0, 0XA8, 0x00, 0xAA, 0x00, 0x00, 0x00, 0x00 } optlen = 8 This doesn't really make sense to me. What would you expect the "setsockopt" function to be doing, for instance if you were programming this externally not in Lua? Pete Pete

Where did you find 4.954e? It shouldn't be available anywhere since it was superseded by 4.955 on Monday, 4 days ago! The Schiratti page in not mine. I cannot change the text there. But the links point direct to the same versions that I post here, in the Download Links subforum -- except the subforum may also host later, interim, updates of just the DLLs themselves. Pete

Why did you re-program things in FSUIPC? Hadn't you done any of that before. FSUIPC's assignments and so on don't change between FSUIPC or FS/P3D versions. Sorry, but without knowing anything about what else you changed between before and after updating the P3D client, I can't really say what you managed to change in the FSUIPC settings. You shouldn't have to change anything at all to do with FSUIPC. I've used the same INI file for FSX, FSX-SE, and P3D throughout all the versions of those. The only dependency FSUIPC has regarding assignments is the PC itself, where changing versions of Wndows and/or different hardware USB connections will move joystick identities about. Pete

Thanks for the files. I thought I really only needed the DLL module, so I could check the export, and it does of course contain and export "luaopen_socket_core", so the required function "luaopen_socket3_core" cannot be found -- which is what your error is saying. So, it really needs recompiling with that name changed. The same probably applies to mime as well, though I noticed you've been inconsistent renaming mime to mime3 in some places but not others. You'll need to check the Lua sources too as well as folder and module names. In order to run a test, without recompiling, I patched the name "luaopen_socket_core" in the socket "core.dll" to "sockeu" (I can path a one byte change easier, hense not socket3), and renamed it all sockeu throughout. I did the same for the core.dll in mime, changing it to mimd throughout. I see ltn12 is also used, but there was no core.dll for that so i had to leave it be. That allows it to be loaded okay and the socket.lua (now of course sockeu.lua) runs as far as line 14, whis is: local socket = require("sockeu") another require call for the same module. Not sure why this arises here, but I suspect you understand this stuff more than I do. The error logged is: 2171190 *** LUA Error: E:\Steam\steamapps\common\FSX\modules\lua\sockeu.lua:14: loop or previous error loading module 'sockeu' Which is an error I don't really understand. However, I found more references to socket or mime and changed those too, and now I get this error: 3684026 *** LUA Error: error loading module 'sockeu.core' from file 'E:\Steam\steamapps\common\FSX\modules\lua\sockeu\core.dll': %1 is not a valid Win32 application. Now, the %1 here should have been replaced by the relevant filename, so there's something peculiar about the innards of Lua itself there. So I run PROCMON to find what fie it was trying to access, and it wants lua5.1.dll, In fact the compiled core.dll imports all of its lua functions from lua5.1.dll. Probably the two other core.dll's do the same. I did try including lua5.1.dll in the Lua subfolder, but got the same error. I notice it needs the VS library MSVCR80.dll whereas the modules you've built use MSVCR90.dll. from a later version (2010?) of MS. It looks like Lua5.1.dll was built with MSVC 2005, which makes sense given its age. You used, what, MSVS 2008? Maybe you need to build with the same version of Lua 5.1? Maybe, doing all of the above, you can sort things out. If not, I wonder if you can seek assistance via the Lua website. There must be some user Forum over there? I've about exhausted things on my side I'm afraid. Pete

I disable the Firewall on all 8 of my PCs. They are a real pain. I rely on the protection built into my router. Just check that. I think most decent routers have this stuff enabled in any case. Note, on the PC where I do my main Internet accessing I do have an Antivirus running, and kept up to date. On my cockpit PCs I have internet access for ASN real weather and any auto-updates for programs like GSX. If you want to leave the firewall running you need to tell it that WideClient.exe is a trusted program, so it can get through to talk to WideServer. I'm not sure, but I don't think you need do anything for WideServer. But I'm sorry, I've never done this so I can't give you details. It'll be via menus and things in the Firewall settings. Pete

No, that couldn't possible cause such a problem. It would simply result in two probably different axis values being received by P3D and show up as jitter or erratic movement. Only something of driver status could had had the effect you experienced, and I expect the actions Thomas recommended did the trick. Pete

Only with a huge amount of work and very likely introducing lots of errors. It was at least a 4-6 week job back then, plus weeks of testing and debugging, and I was younger and more intelligent back then. I'm 73 and have now forgotten it all and getting more stupid daily, so would effectively have to start again from scratch. I'm really not willing to risk the stability of FSUIPC and its future to do it I'm afraid. The whole reason for implementing Lua into FSUIPC at the time was so I can avoid major programming in a future where I knew I would not want to get into such nitty gritty, allowing others to implement new features. I think it would be quicker and more reliable for you to learn more, and take the source of the module you need and rework it to fit with FSUIPC's Lua module interface. You have a good start as you seem to understand socket programming, which is more than I do. But this is exactly what your Require is doing, trying to load the library you have. It is exactly what happens with other external libraries, sch as saitek.dll for Saitek devices, gd.dll for graphics, luacom.dll for COM component access. It should do the same for your renamed socket DLL, but there's a linkage problem, the export needed to get the module to provide it's list of contained functions is not being seen or is declared differently. I did offer to look at it, to see if I can identify why. Pete

If they are all in the same workgroup, as you say, then the problem must be the firewall. Try disabling it. When you have any problems with my programs it is always useful to show the relevant log files, as these may contain the details which help diagnose the problems. The relevant files in this case are the WideClient.LOG from one of the Clients and the WideServer.LOG from the Server. You can paste these text files into messages here, using the <> button above the edit area. Pete

Seems that the dependency issue to removed at least. But the problem now won't be VS libraries. The error it refers to is a procedure the Lua 5.1. version I have built into FSUIPC-needs to call not being found, or not exported, within the module. Now this is not done by any code I understand. The loading of external modules seems to use one of a variety of loaders, being called via very dense Lua code which is beyond me. However, I think the gist of it will be that the module you've managed to build is not loadable by any of the loaders built into the version of 5.1.I used. Possibly a difference between 5.1 and 5.1.4? I don't know. The package I used dates from not long after 5.1 was first released in 2006. When was 5.1.4 released? FSUIPC's Lua is able to load external modules successfully -- there are other examples which work fine, and folks have managed to build and compile their own okay. So I'm lost here really. If you'd like to ZIP the module you've built and send it to me at petedowson@btconnect.com I could take a look with a Debugger and work out why it is wrong, but I cannot guarantee to fix it. Pete

This business of modules (DLLs) which are obviously present not being loaded with the error "not found" is annoying. It took me ages to find out what the problem was with my SimConnectP3D2.DLL when used with P3Dv3, but only on PCs which had never had previous versions nor FSX installed. It was because of dependencies in the DLL on libraries which were not installed. The "not found" message appears to mean not only "this file isn't found" but also "though this file is found it cannot be loaded because it is dependent on other files not found". There is a DEPENDS utility (http://dependencywalker.com/) which helped me work this out. Maybe you could check? I got around it for my modules by compiling a new one using the P3D3 SimConnect.lib which was dependent on the same libraries as P3D3 itself. If this is the problem your new sockets module has, maybe the source is available and it can be recompiled with a different library set? Or, maybe easier, install the needed VS run-times. FSUIPC, and its built-in Lua parts, is not dependent on any external libraries other than the standard Windows ones. I made sure of that long ago so that I could have one version which applied to FSX, FSX-SE (again different libraries), and all the P3D versions (so far -- obviously a new version would be required for any future 64-bit one). These changes happened because of moves through from VS2005, VS2008, VS2010 and (so far) VS2013. I expect they'll be using VS2015 soon. Each of these has different language libraries. If this isn't the problem I'm afraid I'm lost. As I said earlier, sockets are a puzzle to me in any case. Pete

Do the Clients and the Server have the same Workgroup name set in Windows? If not then the automatic connection cannot work. Windows 7 uses a different default Workgroup name to WinXP and 98. Broadcasting won't work across different workgroups. You can either change the name, or specify the ServerName or ServerIPAddress and the Protocol in each WideClient INI file. This latter way, the Client knows where to connect to without needing a Broadcast. This is all in the WideFS user documentation, which perhaps you could refer to? If this isn't the cause of the problem, then it's the default Win7 Firewall. Pete

Glad it solved your problem! Pete