Pete Dowson

Sorry, you need to explain more, or, better, show me the Installer log, or at least state the message. I also need to know the version number of the FSUIPC you are trying to install. Regards Pete

What do you mean by "non-default functions"? If you mean L:Vars and mouse macros et cetera, there's no way I'm going to try and catalogue all of the possible ones for add-ons and list them all. Sorry. Regards Pete

No. You've not read the details for event.timer correctly, have you. event.timer (30, gfd.SetLights(GFP8,1,2))[/CODE] Three things wrong there: 1. 30 milliseconds is very short! You want it flashing 33 times per second? I think all that'll do is dim it. 2. The function which the event calls must be its name in "", just like the other event you are using. All the events are similar in that way. Why go and do something completely different? 3. The function it calls must be your own function, not a library one. You cannot specify the parameters it receives. You want something more like: [CODE] gfd.SetBright(GFP8, 1, 15) light = false function FLASH() if light then gfd.ClearLight(GFP8, 1, 2) light = false else gfd.SetLight(GFP8, 1, 2) light = true end end function ENG1FIRE(offset, value) if logic.And(value,0x0001) ~=0 then gfd.SetLight(GFP8, 1, 2) light = true event.timer(500, "FLASH") else event.cancel("FLASH") gfd.ClearLight(GFP8, 1, 2) light = false end end event.offset("94EC", "UB", "ENG1FIRE") [/CODE] Pete

Take as long as you like! I have plenty to do anyway! ;-) Pete

From the description they should be the fuel valves, the ones indicated lit in yellow on the centre DU when starting and which extinguish when combustion occurs. That isn't the same as the starter (idle/cutoff) levers themselves and wouldn't reflect its state. I'm actually a bit puzzled as to why those last few values are marked "used by FS2Crew" as if they aren't for anyyone else. The whole batch of offsets is just a complete copy of the client Data as laid out in the header file from the SDK. FSUIPC doesn't do anything with it at all. The offsets listed have been computed by me based on their relative positions in the header. Maybe there are mistakes in my counting in places. Please do advise if you find any and i'll fix the document, but all those i checked were okay. I didn't check them all, just a sort of randome sample at intervals. There's nothing in the FSUIPC code to change, it is not doing anything but plonking a wodge of data into an area for you to read. Regards Pete

Not realted to installing FSUIPC, though, as it doesn't change any of those files other than DLL.XML. It simply checks that it is correctly listed in the DLL.XML file, and edits that to add itself if not. Nothing else. Regards Pete

In a Lua plug-in, either use a loop with an ipc.sleep statement to set the time "on" and time "off", or use the event.timer facility to call a function to turn it on and off at regualr intervals. Pete

Well, no, I don't really know about such things. But if that is so I would expect that to be taken care of in the aircraft modelling, not by fiddling the input. Really? It's most unlike PMDG to make such mistakes, and they certainly boasted that it was all checked by their own frienly 747 captain. I assume you are one too? Have you told PMDG about this? They are usually very careful about getting things just right. Regards Pete

Sorry, that makes no sense. The 45 degrees on the hardware yoke will match the 90 degees of the FS yoke if the axis is calibrated correctly. The response curves only change the rate of change -- a normal linear change will do the job just as well. No "compensation" is needed. The minimum and maximum input values will reach the minimum and maximum values FS can accept, and therefore its yoke movement. That's the whole point of calibration, which seems to be ignored here. If what you are saying is that he wants the visible FS yoke movement to match his yoke, then he could do that by fiddling the calibrated max and min values in the INI file so values which cannot be reached by the yoke. For instance, assuming the actual max and min inputs were 16000 and -16000, setting the calibrated ones to 32000 and -32000 would limit the input from the yoke to half of the full FS range, so limiting its visible yoke movement correspondingly. This might make flying more difficult in certain circumstances, however, and to me would seem to be a daft thing to do. Regards Pete

Er, sorry. I don't understand what you are asking. FSUIPC already offers the ability to assign FS and FSUIPC controls to axes or buttons in those tabs. That's the whole point of them -- offset actions are merely a small part of the complete list of controls which can be assigned! Have you never visited the assignments tabs and seen the drop-down list of controls? :-( Pete

Yes, they certainly are, that's why I asked you what the true names of those Lua files was. What was being attempted there? I think I asked you for the wrong logging -- I would like to see the FSUIPC4 log file itself with "Debug/Trace Lua plug-ins" checked, not "Log Lua plug-ins separately". That would give us a complete view of what those plug-ins were trying to do at the time of the crash. I would also need to see the plug-ins involved at that time. If this all looks like getting a bit big for a message, please just zip them up and send to petedowson@btconnect.com. Wll, of those some versions of Actigate are known to have compatibility problems, but only older versions I think, and FSUIPC.DLL is the FS9 and before version of FSUIPC and certainly is wanted there at all. Nor, I think, should ViMaCore2004.DLL which is probably the 2004 version. And, please, please, do find the details of the crash in the Windows error log. I need the module name and offset and error code of the crash. Regards Pete

I'd use the method from dazz if I were you. The offsets are only updated by SimConnect when the data is changed by the NGX. If it stops running the offset contents won't change. Unless one of the offsets is some sort of counter or timer which changes all the time, you wouldn't be able to see it disappear. Even if you did it would give a false positive whilst FS was stuck in a dialogue or other menu item. Regards Pete

Hmm. No clues in the FSUIPC INI or Log files. I don't suppose you can narrow it down? It appears that neither Lua program actually got started. I'm a bit puzzled over those weird characters, in 120121 HmÅ` [/CODE] and [CODE] 120106 ZÃ` LUA.0: beginning "D:\Microsoft Flight Simulator X\ModuÀAà 120106 LUA.0: ended "D:\Microsoft Flight Simulator X\Modules\ipŒÃ‘wÒ¥Eüó‚2¤3 [/CODE] Do you know what those strange fielnames are supposed to be? I suspect the crash is simply due to something odd that LINDA is doing. One other change i forgot to mention is that Lua DLLs are now searched in the Modules\DLL folder using the environment "PATH" statement. I'm wondering if this somehow affects Linda. Do you have a Modules\DLLfolder? If so, what is in it? I think we'll certainly need a LINDA person to help here. I got completely lost last time I looked at a LINDA problem. I don't understand anything it is doing, to be honest. Regards Pete

Do you mean the buttons on those panels don't send joystick buttons to FS? How are they supporting the default aircraft? No assignments being made? I still don't get this. Most of the stuff in there doesn't sem to be related to button pressing -- or does it? When you first started this thread you said "When using SPAD as virtual Joystick, it make random Freeze" -- but are these "freezes" really random, or do they occur when you've pressed one of the buttons whhich SPAD is dealing with? If it freezes without you touching anything on the panels, how can it be SPAD? What would SPAD be doing when you aren't using the panels? I see you are using LINDA too. Are you sure it isn't more related to LINDA than to SPAD? Try SPAD without LINDA to see. In the log there are lots of these: 1064644 *** EVENT: Cntrl= 85638 (0x00014e86), Param= 0 (0x00000000) <unknown> [/CODE] What are these doing? Does FSUIPC stop logging when you notice the freeze or are all those repetitive controls being logged continuing all the time, forever? Pete

I'd need a lot more information, and probably help from the LINDA authors. The changes between 4.811 and 4.82 are minimal as far as any of that stuff is concerned. The only Lua-affecting changes were the addtion of the Tracing facilities for Lua (a new entry in the Lgging tab), and the optional prevention of joystick re-scanning when entering the FSUIPC options. I've made no other changes which I can imagine would possibly affect LINDA or Lua specifically. You could start by providing details of the crash -- module and offset as reported by Windows in the Windows error log, and the FSUIPC4 Logs and INI files. Maybe you could also enable the Lua logging so that we can see what Lua module is crashing and when. Regards Pete

The latest FSUIPC which works fine here with P3D 1.3 is version 4.82. FSUIPC cannot really affect FS or P3D menus at all (I wish it could), so I don't know what you have happening there with 4.812f, but if it still happens with 4.82 I'll need to see the FSUIPC4 log file and your INI file. Pete

FSUIPC re-initialises and re-scans all joystick devices on first loading and each time you visit the Options -- though there is an option in the INI file to stop the latter occurring, in which case it only occurs when you press one of the reload buttons (in Buttons or Axes. options). No. Really it can't be done. Certainly not automatically, because FSUIPC has no way of knowing that your USB device is failing to send changes.. And any user-selectable option would effectively be the same as going in to the Options and out, as it has to clear down all the assignments, re-scan all of the devices, and reload the assignments from the INI file. The assorted activities using the buttons and axes would have to be suspended, somehow, whilst this was happening, so it would still need to come up with a modal message box or something whilst it was doing this. I assume you've already turned off Windows power management on al the USB hubs etc listed in its Device Manager? Having that enabled is the usual cause of your problem. I've never heard of a built-in fault like that on a motherboard. Regards Pete

Thanks. I'll revise the PDF. I need also to point out that it only appears to work on the first loading of the PMDG airecraft -- see previous message here. Some can get it working again on every alternate load, but here you'd need to reload FSX to change aircraft and have the Client data supplied still! :sad: [LATER] Okay, the document is revised in the packaged 4.82.. I'll post it separately too so folks may notice. Pete

Really? I've only ever loaded the NGX once per session. I've never heard of such a problem with client data. I wish I'd known about this BEFORE building a brand new release! I was going to have the weekend off! :sad: Hmmm. Strange. Maybe it's a Simconnect bug. Seems more likely if re-connecting does the trick -- it means the Client Data is still being created by the NGX on each load. Do you have to actually re-connect? I would try first just re-asking for the client data instead. [LATER] No, tried that. no good. Tried clearing the data definition and re-establishing it too. What a bummer! I'm afraid i'm not disconnectng and re-connecting SimConnect each time. With FSUIPC's usaage that's too heavy. User's can do that if they wisg (there's an FSUIPC control for it "Re-Simconnect"), or they can reload the aircraft again. The only other way i could consider it is to open a separate SimConnect handle just for that data, but that's a lot more programming they way I have things structured. If you do ask PMDG about it please do let me know what they say, though they may be none wiser than us about this. [LATER STILL] Disconnecting and re-connecting to SimConnect doesn't do it here, and neither does reloading the aircraft again! So things are different here from your system in any case. Regards Pete

Why use the forums? That is precisely the example provided in the WideFS documentation! Why not use the documentation supplied with WideFS for questions about WideFS? (I sometimes feel I am wasting my time writing any documentation at all! :sad: ). You'll find it in the wideFS Technical document. just search for "Teamspeak". The documentation tells you what the numbers mean. That's the point of documentation, to explain things. No, no! You miss the point completely. The keypress is ONLY defined in the WideClient INI file, NEVER in FSUIPC. All you are using in FSUIPC is the keysend number, where you can choose any of the 256 available. Please PLEASE read the documentation! It is not "obvious" because there is NO KeySend number for F1. The keysend number is merely a reference, between FSUIPC and Wideclient, to relate the two -- as I already explained!!! The F1 keypress is what you ASSIGN to the KeySend in the WideClient INI, just like the F12 keypress was assigned in the example above. The keypress codes are listed in the documentation. Why not actually look at it? Pete

This is almost always due to a known problem in SimConnect and occurs before FSUIPC is even loaded, whilst SimConnect is verifying its credentials. Persistence pays, but you may need to re-boot the system. Please see the FAQ on this (FAQ subforum). Regards Pete

For information: Version 4.82 of FSUIPC4 is now released, and contains the PMDG 737NGX SDK data (read-only) mapped to offsets. A full list is provided in the release package. This has been added with permission of PMDG subject to stated usage conditions. Regards Pete

They look okay, except that the FSUIPC log file is incomplete. I really needed to see the complete file, after you'd closed down FS9. I can't check your registration here because there is no one called "Ingo" or "Strokker" who has purchased FSUIPC3 in the last three years. Could you please ZIP up the FSUIPC.KEY file, which you will find in the FS Modules folder, and send it to me at petedowson@btconnect.com. Do NOT post it or its contents here. I will check its validity. Regards Pete

KeySend is correct. You don't send the actual keys, you send a KeySend reference number (0-255) and then assign that KeySend number to your keystroke in the WideClient.INI file. WideClient allows keypresses to be directed in different ways, so this is a more flexible system that just sending keystrokes and hoping for the best. KeySends are also used for other things, like starting and stopping programs on clients. Regards Pete

What's "the configuration manager"? I have no information relating to any of this, not even a version number of FSUIPC. Perhaps you should try to be more, er, explanatory? Pete