Pete Dowson

Yes, okay. Those are populated by the FS GPS. Sorry, what does that mean? I don't understand either part of that statement. Why not use the FSUIPC monitor to display them in FS? See the Logging tab, right-hand side. Much easier. Or at least use the tool provided in the FSUIPC SDK -- FSInterrogate. I've no idea what "SIOC IOCPconsole" is. Again, where do you get this from? Why "random gibberish". What have you been reading? As far as I can see these are populated correctly straight away. Report it to whoever supports SIOC then, please. Maybe it isn't reading those offsets as 64-bit double floating point values? Sorry, what does that mean? What conversions? They are in degrees already. Regards Pete

Please, you need to refer to the Announcements at the top of this Forum. All the information you need about versions is there. Version 4.57 is long out of date and unsupported. The earliest currently supported version for FSX is 4.60. And there's no such thing as a "matched pair" for FSUIPC and WideClient. The earliest supported version of WideClient is 6.78, but there's a later one in the Updates announcement. If you have a networking problem affecting WideFS then I need to see the logs -- the FSUIPC4.Log and WideServer.Log files from the FSX Modules folder, and the WideClient.Log file from the WideClient folder. Regards Pete

If that helps then the problem he is getting must be due to the coding in the aircraft, not in the Lua execution, because doing that actually makes the Killing and resurrection of Lua threads more likely, not less -- there's more chance it will still be running when the next rotary repetition comes in and FSUIPC has to run the Lua plug-in again. Regards Pete

Ah, you must surely mean Nico Kaan's Level D interface, FSConv. Are you running that program? I don't have anything listed as being used by Level D directly. I'm afraid I know nothing about Nico's work. You'd be better off talking to him directly. Regards Pete

The LevelD 767 does not use standard FS controls for many things. You probably need to refer to their own SDK. 8b3a? Where do you get that from? That appears to be in the middle of some display control structure, nothing to do with autobrakes or anything else of use that I know of. The standard FS autobrake is at 2F80, as documented in the FSUIPC SDK. Please do refer to the correct references. None of that is true for the correct FS offset, 2F80. It is a number, running from 0 for RTO to 3 for MAX -- not individual bits. I am wondering where you are looking to get this stuff? Regards Pete

All this shows is your system is so much slower that the one i'm testing on, and/or heavily overloaded. It still needs 100 mSecs delay, not the 50 I envisaged. My system needs no delay, but i don't have the AirbusX (yet). Odd that no one else has reported similar problems. Pete

That shows over 30 seconds of turning the knob -- how long do you sit there turning it for normally, then? Very strange. There aren't actually all that many instances of the thread having to be "Killed", but tellingly the last few are. The timings of those killings are interesting: That's 78 mSecs, 63 mSecs and 63 mSecs, respectively -- all over the 50 mSecs I was considering putting in as the limit. Seems, for your system, which is evidently performing quite poorly, you'd need a delay of more like 100 mSecs to be safe. This would limit it to 10 repeats per second. I suppose that should be enough, though. I don't have the AirbusX at present, but I might get it just to see if the problem is specific to they way it is working. Regards Pete

Well, I've been trying GoFlight rotaries programmed to use Guenseli's original Lua, and I can't even get the rotaries sending pulses fast enough to get FSUIPC's Lua manager to even need to Kill the previous thread -- it has always finished by the time the next pulse from the rotary arrives. So, either your PC is rather slow, or overloaded, and the Lua loading itself is taking a lot longer than on my system, or it is somehow peculiarly related to the AirbusX itself rather than anything I'm doing. Tomorrow I'll supply an FSUIPC4 update which does limit the repeat rate, using an adjustable delay, but it may be that this needs investigating with this specific aircraft rather than generally as I have been doing. Regards Pete

Of course it probably was not the parameter 41 entry you really need to separate -- only those you want to assign to the Rotaries, like -- 46 ALT inc slow or fast -- 47 ALT dec slow or fast -- 48 ALT inc slow (100) -- 49 ALT inc fast (1000) -- 50 ALT dec slow (100) -- 51 ALT dec fast (1000) To take 46 as an example, instead of this in the large Lua: -- ALT inc if ipcPARAM == 46 then LVarALT = ipc.readLvar("L:AB_AP_ALTSTEP") LVarSet = "L:AB_AP_ALT_Select" if LVarALT == 0 then LVarGet = ipc.readLvar(LVarSet) ipc.writeLvar(LVarSet, LVarGet+100) elseif LVarALT == 1 then LVarGet = ipc.readLvar(LVarSet) ipc.writeLvar(LVarSet, LVarGet+1000) end end the free-standing version could be: LVarALT = ipc.readLvar("L:AB_AP_ALTSTEP") LVarSet = "L:AB_AP_ALT_Select" if LVarALT == 0 then LVarGet = ipc.readLvar(LVarSet) ipc.writeLvar(LVarSet, LVarGet+100) elseif LVarALT == 1 then LVarGet = ipc.readLvar(LVarSet) ipc.writeLvar(LVarSet, LVarGet+1000) end though, assuming "L:AB_AP_ALTSTEP" is either zero or not-zero, slightly more efficiently as: LVarALT = ipc.readLvar("L:AB_AP_ALTSTEP") LVarSet = "L:AB_AP_ALT_Select" LVarGet = ipc.readLvar(LVarSet) if LVarALT == 0 then ipc.writeLvar(LVarSet, LVarGet+100) else ipc.writeLvar(LVarSet, LVarGet+1000) end Meanwhile, I've looked at the possibility of just restarting Lua plug-ins instead of Killing and re-creating their threads, and there are too many complications. I'd need to take care to re-initialise everything as if it were a fresh thread even though it is not. With the possibility of COM devices, Networking handles and the like it is very messy, and I don't like a partial solution. So for now I'm going with the delay -- not allowing a re-run of a particular Lua plug-in within so many milliseconds of its last start. I'll allow the delay to be adjustable in the FSUIPC INI file, and default it to, say, 50 mSecs to allow up to 20 repeats per second. I'll try various things and may revise that downwards depending what I find. Regards Pete

Crash? what error report does it provide? There's nothing in Lua that I know of which can cause a crash unless you are running so many copies of a Lua thread that you exhaust the process stack. To do that you'd really have to try hard with some bad programming. You will need to supply more information if you want me to help you. Show me your Lua program and tell me exactly what you do to provoke the crash. And are you saying it is only with the AirbusX? Maybe it is a bug in the aircraft rather than in Lua? You can also use logging to get more information. Logging is always the best way to debug your programming. [LATER] After a pointer from Guenseli I found this extea information from a post you made in the Aerosoft Forum: Now what this implies to me is that the way the Lua program is instigated (by button repeats from the dial) is causing the Lua program to be Killed and re-Run each time, and the time it takes to do all this longer than the time between each repeat, so causing the number of simultaneous threads to grow until the process stack overflows. This causes a crash or hang, inevitably. I did take steps in FSUIPC to avoid normal repeats from starting a Lua whilst the same one was still running, but that only applied to regular repeats, as from a button or keypress being held down. The rotaries don't look like repeats because what they do is send on/off pulses alternately. This sort of problem hasn't arisen before now because: (a) the pulse rate of rotaries is actually quite low compared to button and key repeat rates, and (b) most if not all Lua plug-ins used have been very short and fast to load and kill. The Lua program Guenseli has put together is very long indeed, especially for one which is destined to be loaded and run frequently. Each time it is instigated it is being assigned a thread, and memory, compiled and then executed -- and all those "if " commands it has to go through to find the correct action also makes it worse. I will look at the Lua section in FSUIPC to see if I can detect the conditions arising in which such a crash can occur, and prevent it from happening. I think I'd have to do this by starting a timer when I kill a thread and not allow the same one to be started again for a number of milliseconds thereafter. I might need to make that adjustable. It will inevitable slow down the maximum rate Lua threads can be restarted. There might be alternatives, like aborting the thread execution and merely restarting it. This obviously would be more efficient, but I'm not sure I can do that with the Lua interpreter code. I'll take a look. Meanwhile you can try something yourself. Instead of using the one big script for the rotary programming, extract the part of the Lua code which does what you want, and have separate little Lua plug-ins for each one, assigning them directly instead of via a parameter number. For example, instead of the part: -- Altitude rate selection slow (100) if ipcPARAM == 41 then LVarSet = "L:AB_AP_ALTSTEP" ipc.writeLvar(LVarSet, 0) end in the large Lua plug-in, just have a plug-in, called, say "AltrateSlow.lua", containing just: ipc.writeLvar("L:AB_AP_ALTSTEP", 0) then assign your rotary button to "Lua AltrateSlow". If I get anywhere with a crash prevention modification to FSUIPC I'll let you know. Regards Pete

Well it would merely be the map of the current button states (pressed or released), not of any actions which ensued. I'll post again here when I have an update for you to try. Maybe tomorrow (Monday). Pete

Oh, it hasn't arrived yet. Did you send it to petedowson@btconnect.com? Can you try again, please? I'm not back till Sunday nowTomorrow (Saturday) all day at Duxford for the Battle of Britain Air Show. ;-) Best Regards Pete

Hey, that looks very good! I like your way with illustrations. Wish I could do that sort of work. Will your PDFs remain accessible for a long time, so i can put permanent links to them in this forum, or do you think I could upload the FSUIPC part to this Forum for such a link? I'd credit you of course and provide any other links you'd like. Let me know. (I'm away all tomorrow (Battle of Britain Air Show at Duxford, near Cambridge, England), so please forgive any delay in answering again. Regards Pete

Okay. No, you shouldn't have to. the log you attached shows nothing wrong at all. Sorry, whatever is wrong is in the iFly side of things. The FSUIPC installation is working fine. Regards Pete

Thanks for posting it here too. As you can see I've made it "stickie". Have you found any L:vars for throttle control? It seems this aircraft depends on FSX assignments then goes direct to DirectInput, so defeating any attempt to use FSUIPC throttles, or, worse, throttles which don't connect as DirectX joystick inputs (like PFC, for starters). Regards Pete

If the cockpit you are using doesn't use gauges which support the FSUIPC mouse macros, and don't have any access via local gauge variables (L:vars), and doesn't have its own set of keyboard assignments you can use, then there isn't really any alternative but to use the mouse or something which operates the mouse for you. How can anyone help with that? No, the mouse macro calls the code inside the gauge directly. It has no idea where on screen anything is and doesn't care. It simply traps the entry into the gauge code when you program it by clicking the mouse. To do what you want to do you need Key2Mouse, as I said. I am not writing my own version of someone else's program. Regards Pete

Interesting. I wonder what they use it for. If you are using an illegal registration code for FSUIPC then the answer is not to re-install, but simply to delete the FSUIPC4.KEY file you will find in the FSX Modules folder. Version 4.1 is very old and hasn't been supported for several years. I cannot offer support for any FSX version earlier than 4.60. Close down FSX and show me the FSUIPC4.LOG file, which you'll find in the FSX Modules folder. Regards Pete

The real buttons aren't stored anywhere, only polled from the devices -- unless you mean the memory used to see when they changed. Those and the associated button flags are in FSUIPC private memory, not currently accessible outside FSUIPC. The 288 virtual buttons are, of course, in their dedicated offsets from 3340 onwards. Are these buttons seen in FSUIPC as regular joystick buttons? If so there's no current way to see these in FSUIPC offsets, unless they are programmed to set some user offsets via the "Offset" controls. It would be possible for me to map local joystick button memory locations to FSUIPC offsets. That would be the 16 x 32 bit words for joysticks 0-15. Would that do the trick? Regards Pete

Hmmm. Can you try making that macro again? The file was contributed by a user. I don't currently have a working install of the PMDG 737 I'm afraid (I'm all FSX these days in any case). If you can fix it, let me know and I'll update the file. If you have any more questions, feel free. Regards Pete

If you mean programming a keystroke or button to move the mouse pointer and click a button on screen, then that is already done by a utility called Key2Mouse. see http://www.wideview.it/key2mouse.htm . However, i'm not sure how useful this would be with a virtual cockpit as for it to work the button must be in the same place on screen each time. The whole point of virtual cockpits is that the visuals move to reflect where you want to look. Regards Pete

This problem which occurred on a few installations but became more noticeable with Windows 7 was fixed several user releases ago. As Andy says, you are using an out of date and unsupported version. Please always check for updates first. Regards Pete

Have you asked either of their support? Who told you that? I can't see how it could be anything to do with FSUIPC. Does the iFly 747 even use FSUIPC? It doesn't sound likely, and they certainly haven't contacted me about licensing. Very few FSX specific aircraft use FSUIPC. Since you aren't assigning or calibrating in FSUIPC (as you haven't even purchased it), there is really no way FSUIPC is in any way involved. I'm sorry but I cannot support other folk's products. You need to get support from the makers of iFly, as it is evidently their product at fault. Pete

Can you give me any more information? I'm lost. Whose "737 OH Macro DLL" is this? Are you instead referring to some FSUIPC macro file, not a DLL at all? How did you make it? If you are asking about FSUIPC at all, please tell me the version number. Pete

I don't really know -- your preference I think. Try them both out. Your all-in-one Lua is more elegant (now I've added the repeat facility), but the direct assignment one is probably a little more efficient. I shouldn't think there's much in it though. No, no way. You'd need to copy the value to an L:var created by the gauge. There are Lua facilities to read and write named local variables (L:vars). Check that out. Regards Pete

Okay. the change was pretty easy, so it is done already. Check the Updates announcement at the top of the Forum. You need to download FSUIPC 3.989b or 4.625. The event.key() facility is extended as follows: I used your Lua, from your earlier post, to test it with. It works fine if you just change these lines: event.key(77, 8, 4, "whole_inc") -- SEL + label m-key event.key(188, 8, 4, "whole_dec") -- SEL - label komma_key event.key(190, 8, 4, "fract_inc") -- ledig punkt_key event.key(189, 8, 4, "fract_dec") -- ledig minus_key Have fun! Regards Pete