Pete Dowson

Okay. Assuming you don't need to swap controls over for different aircraft (for example, joystick for fighter jets, yoke for airliners and GA) then it is much simpler leaving all your axes assigned in FS. Just make sure they all work in FS first, then you can look at calibrating in FSUIPC if you wish. But please do follow the instructions in the Joystick Calibration section of the FSUIPC User Guide. The FSUIPC Calibration tabs don't operate on the hardware axes at all, but intercept the values being sent to the FS flight control engine and work on those. They just identfy which control it is based on your assignments, no matter where yu made them. Pete

Ah, sounds like you are still using FS2004 or before? That's called Controllers in FSx and later. It's the same one though. If you are assigning in FS you need that ticked, if in FSUIPC it must be unticked. Yes, but that's all to do with FS and Windows. None of that is anything whatsoever to do with FSUIPC. Yes, it would be, obviously. But you are not using it for anything? I don't understand why you are posting here at all. If you aren't assigning or calibrating in FSUIPC, why post here at all? Pete

Really either would do, interchangeable 94 rotaries or 8 buttons) but probably best to assign to the INC/DEC controls anyway. Rotary encoders will be seen as two buttons, one for each direction, going "on" and "off" on alternate clicks. You could do it via the offsets -- even with FSUIPC inc/dec controls* -- but you aren't gaining anything. The individual FS controls are doing the same. Pete * The inc/dec controls, if you had one rotary (or two buttons) per digit would simple have the appropriate increment - x1000, x0100, x0010 or x0001, and limit - x7000, x0700, x0070 or x0007 respectively. Pete

So, you have the yoke and pedals assigned in FS, but then you have disabled them -- both of them? So where are they now assigned, and what to? You tell me. You say there are at least two -- yoke and pedals. I don't know what else you have, you haven't told me and I can't see your system from here! By "disable controllers" in FS, I mean the option shown in the settings menu for controllers -- there's just the one option to enable/disable all controllers. Evidently, because you are not making sense I'm afraid. We can help, but we need to know what you've actually done. Just delete the FSUIPC4.INI file ("configuration settings") which you'll find in the Modules folder of FS. Or alternatively you may wish to paste itrs contents into a message here so I can see what you've done, exactly (at least in FSUIPC -- it won't tell me what you've done in FS). Pete

I see Thomas has kindly looked them up for you, but when you say "searching everywhere", did that include the Offsets list provided with the FSUIPC installer and placed in your FSUIPC Documents folder, or, for Project Magenta, the offsets list provided on the PM website? These would seem to be the places to start, and surely searched before "everywhere" else? Apart from the PM cutoff/idle offset bits, in FS generally the fuel cutoff/idle action is handled by the Mixture setting -- full mixture(value 16383) for idle, zero (0) mixture for cutoff. So for more general application, and maybe even yours, you'd look up the mixture offsets -- not very far from the throttle ones I think. Note also that the throttle forward thrust values are from 0 to 16384. The negative values are for reverse thrust, and maybe be more limited than the 0 to -4096 suggests -- that's a max reverse thrust of 25%. The max is set in the AIRCRAFT.CFG file. Pete

Never initially try to set anything up with an add-on aircraft like the PMDG NGX. It is completely non-standard and you have to treat it differently. Start with a default aircraft. Are you only assigning in FSUIPC only? If so you must disable controllers in FS first. Next, are you really assigning to "Throttle1 set" and "Throtte2 set" controls? If so, why choose those over the more usual Axis throttle1 set and Axis throttle2 set controls? Or are you assigning in the mode "direct to FSUIPC calibration"? If so, don't do that for the NGX as it doesn't like it. The calibration option 'REV' most certainly does reverse the throttle input before passing it to FS, but the NGX won't read calibrated values at all. You cannot use throttle calibration in FSUIPC with the NGX. The other questions are answered best by following the instructions in the FSUIPC user guide, but always start with a default aircraft. Pete

Not that FSUIPC is at all relevant here, but version 4.949 is out of date and not supported. This is almost certainly a corrupt scenery file. Terrain is not something which is "computed" so much, but merely loaded, scaled, projected and displayed. The fact that it occurs in a particular place, consistently, should actually help you identify what scenery needs fixing. Why are you searching and posting in the FSUIPC support forum, when it is really unrelated, even more so as you are evidently not even using FSUIPC? You should be asking over in FSX/FSX-SE forums, surely, like the one in AVSIM? Pete

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