Pete Dowson

I know, and the reasons are shown in the files you posted. But I am not asking you to assign anything at present. Please read my suggestions again. I'm sorry I keep having to repeat myself every time, you do not seem to read my messages! :sad: FIRST (to repeat) Please can you try running HidScanner for me --: HidScanner and show me the log from that. That may help me see the reason for the above. SECOND (to repeat also): Then try getting proper IDs assigned to your pedals and yoke, using JoyIDs (as linked in that "fixing joysticks" thread I gave you a link to earlier. Also, you did not bother to answer my last question, so I repeat that too: Did you delete your FSUIPC4.INI at some stage, because there are no assignments to any device in the file you pasted here. We won't get anywhere if you keep ignoring me. I'm trying to help and I desperately want to solve this issue. But I need you to help, please! Pete

Okay. did you yet try the third thing, using JoyIDs to assign your joystick IDs? Something very strange has happened. Here's the device scan in FSUIPC's log: So, your Rudder pedals should be joystick #0 and your Yoke should be #1. But the FSUIPC.INI file shows these assignments to the IDs: In other words, three different installations of a "wireless keyboard kit", as devices 0, 1 and 2. I canot imagine how a wireless keyboard can even be listed as a "joystick" type device, as it appears to be, let along get three different entries for itself. I assume you don't have three of them on the same, FS, PC? Please can you try running HidScanner for me --: HidScanner and show me the log from that. That may help me see the reason for the above. Then try getting proper IDs assigned to your pedals and yoke, using JoyIDs (as linked in that "fixing joysticks" thread I gave you a link to earlier. I really want to nail this sort of problem, because it should be possible for FSUIPC to handle all this automatically. It's just that I need to find out what is going wrong in cases like yours, which seem very rare. BTW, did you delete your FSUIPC4.INI at some stage, because there are no assignments to any device in the file you pasted here. At the start of the thread you said: so I assume from that you had actualy made some assignments in FSUIPC, yet there's no sign of any now. FSUIPC4 NEVER deletes them. The INI file you've posted looks like a complete default file, no personalised settings whatsoever. Pete

Well it is doing the right things: 163302 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 163302 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 163302 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 163302 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 163302 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 163302 *** EVENT: Cntrl= 65540 (0x00010004), Param= 0 (0x00000000) SELECT_3 163302 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 163302 *** EVENT: Cntrl= 65541 (0x00010005), Param= 0 (0x00000000) SELECT_4 Normally (but for the bug in P3Dv3) it would send just 4 of the TOGGLE_AIRCRAFT_EXIT controls, with parameters 1, 2, 3, and 4. That works in previous versions of P3D as it does in FS. The "SELECT_n" controls are what you get when using the keyboard for the exits. I've done some more tests here, and I've found now that the toggle exit control followed by a Select works ok on its own, but not with several in sequence. However, I have found that if I send just one TOGGLE_AIRCRAFT_EXIT control followed by the 4 SELECT controls, ie no more TOGGLE controls, it works! Crazy. I've no idea what they've managed to do in P3Dv3 to get this odd result, but I'll change FSUIPC to suit. Look out for 4.947f. Pete

Strange. It certainly should do -- 3367 setting does work fine here with the workaround I incorporated. I'd like to know why. Can you enable Event logging, please, and also Monitor 3367 as type U8 (on the right hand side of the logging tab) to the 'normal log', then use your Lua plug-in and show me the log results please? Pete

The PMDG aircraft intercept the Throttle control at a higher level than that which FSUIPC injects it after calibration. So you can assign the throttle in FSUIPC, to the Axis throttle controls, but don't calibrate. This part is well known. But if you were assigning differently (eg using Direct to FSUIPC assignments) or calibrating the throttle in FSUIPC even with FS assignment, then I would have expected you to report erratic behaviour of both throttles all the time. I've never heard of a specific problem with one throttle from cold and dark. Therefore I didn't ask or tell you about the normal problem and how to deal with it. You CAN still use FSUIPC assignments, but your PMDG aircraft Profile should have the throttles assigned to the Axis controls, and not calibrated. Pete

First, have you assigned the same increment or decrement control to both "press" and "release" actions, so you get one inc/dec per click? The Rotaries Lua is just an EXAMPLE, and as set it works with the 4 rotaries on the GoFlight RP48 . As an example it is there to show what can be done. Take a look at some of the other threads on the subject, for instance http://forum.simflight.com/topic/79415-rotarieslua/?hl=rotaries Pete

The bug is actually in P3Dv3 and I've been told by L-M that is will be fixed in the next update. Meanwhile I implemented a work-around in an FSUIPC update. Did you check? Which actual version of FSUIPC do you call "new"? This appears in the Updated Modules thread in Download Links subforum: FSUIPC version 4.947e only, for those with 4.946 or later already installed FSUIPC 4.947e -- Same as 4.947c except for two special fixes for current P3Dv3 shortfalls: -- Makes aircraft exit control work correctly via offset 3367, by splltting into two controls Pete

Sorry, the AVATAR is a new feature in P3Dv3 and I haven't had time to even try it. I don't know why it isn't responding to normal joystick inputs. Have you tried assigning to the standard Axis controls, those FS controls nameed "Axis ...." in the drop downs? Probably they simply haven't made it respond to the older FS controls such as those used by FSUIPC calibration. If they've implemented it completely separately from normal aircraft elevator/aileron/rudder/throttle controls I suspect it would need a separate program to drive it outside of the P3D provisions. Of course, the purpose of FSUIPC is to provide onward compatibility for existing facilities and applications, so there are currently no plans to expand it to cover completely new options. Maybe, when P3Dv3 is sorted out so that it works well enough with control devices I will be able to find time to see if it is an easy addition, or more likely something which can be done via Lua plugins, but really it is a bit like asking for support for submarines and bombs and other non-FS type facilities which a military trainer such as P3D might implement. I'm afraid it isn't on my Agenda. Perhaps you can use FSUIPC to log events (both event logging options in the FSUIPC logging tab), then use the Avatar with P3Dv3 controllers enabled, and show me the log -- just the part where only the Avatar was in use. Maybe it is simply a configuration issue, or different assignments needed. Pete

If FSNAV is set to check for F9 then it presumably would need reconfiguring to check for 'N instead'. Have you checked its documentation to see how to do it? FSNAV isn't one of my programs so I can't really help directly. With FSUIPC you can program a Lua plug-in to look for an 'N' key and send an F9 when it sees one, but why would you want to do such a thing? In fact why do you want to mess with keys when you can use a button? Pete

Isn't SPAD configurable? Sorry, I don't know the program at all. Is there a Forum for it where you can get help? Pete

Okay. That is clearer. It sounds like there's no ID assigned to the device. In that case please do three things: 1. Show me the FSUIPC4.LOG file from the FS Modules folder. 2. Show me the FSUIPC4.INI file from the same place 3. See if using the JoyIDs program to assign and ID will help -- see the FAQ subforum thread Fixing joystick connections not seen by fsuipc Pete

No, sorry, that is not an option for me. It would help move forward if you answered the questions arising in my first reply -- for a start, did you check whether P3D or Windows could see your joystick, or did it die completely for everything? And again, when you say "assignments" do you really mean axis and button assignments in FSUIPC itself, or just calibration? Until you can explain what it is you find is wrong I cannot really help. Pete

I need you to explain what you mean by "FSUIPC does not show up" because I don't understand what that means in relation to FSUIPC. In English "does not show up" means "does not appear" or "does not come". How does that apply here? Profiles are created by YOU, as you wish. There aren't any ready-made ones. What are you expecting? Pete

You cannot "create" LVars unless you are creating an add-on aircraft or gauges for one. LVars are "Local Panel Variables" and are intimately tied into the code of the aircraft gauges. The facilities in FSUIPC for LVars are there to discover them, and read or write their values, but they need to actually exist first. I am amazed that SPAD does not handle offsets. That pretty much eliminates its use for default FS aircraft,and add-ons which just rely on normal FS functions. I think you should double check that fact. Offsets manipulation can be programmed in Lua, of course, but easier most times, you can write values to them, change individual bits in them, and increment or decrement them, by simple button assignments to Offset controls, in the FSUIPC drop-down assignments list. What 'tokens'? The PMDG 737NGX and 777X aircraft provide a method of reading all of their indicator, switch and display settings, and FSUIPC has taken advantage of that to map them all to read-only offsets. Those are documented in separate PDFs installed in the FSUIPC Documents subfolder. But no "tokens". I don't know iFly I'm afraid. Pete

Why not try without that for at least one of your flights? Pete

That looks fine. FSUIPC is working well. There is no reason (excepting the possible different in priority I pointed out) why the program could not connect to FSUIPC. So, sorry, you need to talk to whoever supplied / built the program which is giving the error. No. Changes weren't needed in that module, so it's the same for P3Dv2 and v3. Pete

If there's no log then FSUIPC has never actually run!!! What is that "FSUIPC4.txt" file? I think you are probably misunderstanding the way Windows shows you files. If it thinks it's a text file it is probably the Log. Similarly, FSUIPC has NEVER had an "FSUIPC4.cfg" file. That is probably the FSUIPC4.INI file. I think you are inventing the filetypes based on the Windows file description, not basing it on reality. Please change the Windows Explorer to show you real filenames, not hiding known filetypes, as advised in the FSUIPC4 User Guide! Once upon a time Windows didn't do these silly things! Pete

The error is not from FSUIPC, it is from the program trying to connect to FSUIPC. it appears to simply report that it cannot conmnnect. I've no idea what the rest is about, but possibly it's a consequence of the failure to connect to FSUIPC. If you are running P3D or that program "as administrator" then both need to be -- programs at different priority levels cannot talk to each other by memory sharing, which is what the FSUIPC interface uses. Otherwise, to see why it cannot connect we need first to see the log from FSUIPC -- FSUIPC4.LOG which you'll find in the P3D Modules folder. Make sure you close P3D first, and show the whole log file here please. Do not change any options for now, and do not press "New Log" in FSUIPC's logging tab. If it appears that FSUIPC is loading and running fine, then you'll need support form the author of the program which is failing. Pete

Sounds like you enabled the option in FSUIPC to keep the FS time synchronised with your PCs time, and one of them is running slower than the other. FS reloads things, to get shadows etc correct, if the time changes more than one minute. You can set the sync to only change the seconds, not the minutes, or just turn the option off. It isn't on by default. There's no difference whatsoever between "older freeware" and "newer paid" (except of course any new facilities and fixes added in the newer version). What you insist on calling a "freeware" version is merely an unregistered full version. It just does nothing for users, it is an interface for application programs. Registration enabled the user facilities. The rest doesn't change. Pete

Thanks for the extra information. I found out what is happening. Actually, part of it was obvious from your earlier Log: 9333696 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0 .... 9333852 KEYUP: VK=13, Waiting=0 The key code is logged as 135 for KEYDOWN but 13 for KEYUP. Checking my code I see that the code 135 is actually manufactured by FSUIPC when it sees a Keycode of 13 (=ENTER or RETURN) and the flag indicating "extended key" is set in the data from Windows. It appears that's the only way of distinguishing between the two enter/return keys. The bug is that this is not happening on the KEYUP -- it was left as keycode 13. This meant the Lua interpreter was left thinking the ENTER key was still pressed (not seeing the KEYUP for that keycode) and so wouldn't trigger again unless you had Repeats requested. And of course KEYUP events for code 135 never occurred. It'll be fixed in 4.947e, later today. Thanks for the report! Pete

FSUIPC doesn't know one key from another, it is only getting ad matching the Keycodes. They are just numbers provided in the WM_KEYDOWN and WM_KEYUP Windows messages. If it isn't working for one specific keypress then either it isn't working for any, or something else is happening to the missing ones before fSUIPC sees it. When you say "single shot", what exactly do you mean? How is the Lua plug-in being loaded? I hope this isn't typical of wat you are doing with plug-ins: Killing plug-ins is a rather desperate measure -- better to signal to it that it should terminate. Killing meaning terminating the thread in pretty much random places with possibly unpredictable results. I do my best to tidy everything up, but it's still something to be avoided when there's another way. Anyway, if you tell me a little more about how you are starting it, and whether you picked out the Enter key specifically and haven't tested any others, I can try the same things here and see what is going on. Pete

You need to retrieve them from your SimMarket account. The registration is always with the original name, email address and code originally used. The code for FSUIPC3 (FS9) is not the same as the one for FSUIPC4 (FSX). Pete

Ah, there are many reports of P3Dv3 crashes after long periods. Please see the L-M forum for these. I've not seen any before yours which have FSUIPC specifically identified, but, as I mentioned, the crashes are all pretty deep in the Lua interpreter, which is not actually my code but the freely distributed Lua interpreter used by a large number of games and other applications. The fact that these occur after such a long time indicates that it is likely not a specific bug in FSUIPC or the Lua interpreter -- everything used by all the things you are doing must have been done so many times by then that it has to be something else No, it will not help for the reasons I've given, let alone the size. I suspect that even if you discarded all those add-ons, and even FSUIPC itself, you'd still get the crashes after a length of time. I think it must me down to memory corruption which looks to me the probable cause of the other problems reported with P3Dv3, even with no add-ons whatsoever. Other users appear to be trying to narrow it down. The closest they've come so far it that it might be related to Terrain settings. I recommend you read some of the threads and maybe participate. No. That just lists those Lua files you have in the Modules folder and so are available for assignment. I assume you mean that all those which are installed are actually running (actually 11 after ipcReady), but the only thing which would show that is presumably your ipcReady.Lua file. Also, programs like Linda, and possibly others, may well be loading Lua plug-ins from other folders, those not listed for FSUIPC assignment. You don't actually have any keys or buttons assigned to Lua functions. in fact, and -- this is quite unusual -- you have no button assignments whatsoever in FSUIPC, though you do have axis assignments! nothing wrong with that, it is just that I've never seen anything like that before. Don't you use any buttons on your joysticks? Why not? That would be the best way to prove that it is, after all, a P3Dv3 bug. Pete

I think you are making this too complicated. It is much much simpler than you appear to be imagining. This stuff is neither scripting nor programming. The lines are simply slightly more elaborate versions of the assignment parameters which FSUIPC normally automatically puts into your settings file (FSUIPC4.INI) when you make an assignment. The parameters are simply formatted values from the assignments, and the format is described in the Advanced User's document installed with FSUIPC. See the FSUIPC Documents folder, inside your FS Modules folder. Each parameter line is one parameter, and is free standing. The only "scripting" type of relationship is that FSUIPC executes the lines in order of the parameter number, the one to the left of the first =. If you look at your current FSUIPC4.INI file you will see you already have the basic lines. All the above more complex looking ones have got extra are conditions, the "B66C0=n" parts, which just say "only do this is byte 66C0 equals n". 66C0 is a user offset and can be set and changed by other FSUIPC assigned controls, those in the "Offset byte" area of the drop down lists. Google and YouTube are not likely to be dealing with individual parameter formats for a program. Pete

If this is something you are programming, then you need to read the aircraft position at offsets 0560 and 0568. Pete