Pete Dowson

Use FSUIPC 4.946, the first version for P3D v3. Pete

i tried to, but every beta release, every update, changes things FSUIPC depends upon! Mostly 4.945a would have worked, but some crucial things changed. It was lucky I was working with the Betas because I only just got back and had a few hours work to do to release 4.946, now available! Pete

Where did you get P3Dv4 from? V3 only jsut got released! You should have had a warning telling you that FSUIPC was the wrong version and didn't know the version of P3D you were using. If you had then just acknowledged it, it would have carried on and let you Register. However, it won't work properly in version 3 or 4! The version of FSUIPC for P3Dv3 is 4.946, released today! Pete

Why have you just installed such an old version of P3D? The updates all the way to version 2.5 are free. Try getting up to date. Pete

Registration is part of the Installer, not in FSUIPC itself! 4.944 was nowhere near compatible with P3Dv3 -- it was out of date weeks ago. 4.945a was the most recent, but the only version at present which works correctly with P3D v3 is 4.946! Pete

Yes. They are all in the FSUIPC4.INI file (and Profiles subfolder if you are using Profile files), so just copy those into the new Modules folder. Pete

Depends entirely on the aircraft. some support Mouse Macros, some have keyboard shortcuts you can assign to, some have local panel variables you can write to (L:Vars). And unfortunately some have no option other than to use the mouse. First off, search the User Contributions subforum here for your aircraft. Maybe someone's already solved it. Pete

I would need specific information to help, I'm afraid. "Do not respond correctly" isn't much to go on. Are you assigning in FSUIPC or in FS? If in FS are all controllers properly disabled in FS? Are you using Profiles or Aircraft-specific assignments and perhaps are selecting different aircraft? Maybe some description of exactly what the problem is would be useful, as well as a sight of your Settings (i.e. the FSUIPC.INI file, in your FS modules folder). You can paste its contents in a message. Pete

Yes, P3D v3 was not supported until FSUIPC 4.946, released today. Perhaps you didn't notice that I announced I was away till today? Pete

This is ALWAYs due to a bad joystick driver, probably installed for a joystick no longer installed. The freeze is happening inside the Windows driver, not in FS or FSUIPC. Use the Windows Device Manager to disable and then uninstall anything you no longer actually have connected. Pete

Assignments in FSUIPC won't change. The joystick axes must be changing. Make a note of not only joystick number but also the axis letter. Then check next time it seems to change. If the joystick axes change in the card, it is a fault in the card's software. You need Leo's support then. Pete

You can ALWAYS his "Reset" and the "Set" again to re-calibrate. But if the numbers don't change, it is not assigned to that control. With multiple USB connected joysticks, their numbering depends on where you plug them in, and in which order. To avoid prtoblems with disconnecting and reconnecting you should use the facility for assigning letters instead of numbers. There's a chapter about it in the User Guide. Pete

FSUIPC settings are all included in the FSUIPC4.INI file in the Modules folder. But if you hadn't opted to use Joystick Letters, as advised in the documentation, the joystick numbers might be all different after a Windows re-install. The settings will all be there but maybe attributed to the wrong controller. Pete

Pardon? If FSUIPC doesn't recognise your joystick please see the FAQ subforum thread about this very subject. Pete

Assuming you are having a continually running gear handle monitor, this would suit. Load it in ipcReady, or via [Auto], or once by key or button assignment: function geardown(off, val) if val == 0 then msg = " up " else msg = " down " end ipc.display ( "gear"..msg, 5) end event.offset(0x0BE8, "UW", "geardown") The display lasts 5 seconds. if you want a permanent display, remove the ", 5" in the display call. Pete

Something like that. not sure why yet. I'll find out when I get back. Meanwhile, if you are starting it from ipcReady or an [Auto] section, you don't need or want any "event.cancel". If you were just using a key assignment to test it, I'm not sure why you used cancel anyway. Why was that? If you try to run the same plug-in again, eg, via a keypress or button, the former incarnation is killed ruthlessly in any case. Or you could assign another key to "Luakill test" which does the same thing.. Anyway, I'll look at fixing the real problem, no ,atter how iIllogical it might be, when I get back. So thanks for reporting it. Pete

Well, the Windows crash data wasn't of use because you forgot to update to the current FSUIPC version as I asked -- you are still using 4.942! But there is an error somewher in the ewvent processing in the Lua package. I won't have time to work it out until after I return from holiday, on October 5th. But the reason seems somrthing to do with the fact that the event has already been triggered when you cancel it. The cancellation removes the function from the list of callable functions, and the pending event gets rubbish. I don't know why, but I will find out. The reason the "ipc.exit" stopped it is simply that this kills the plug-in completely, whereas just ending the function allows the next pending event to be processed. However, this sort of thing would not occur in normal practice. The plug-in is being initiated by a button press. This will immediately, without any change in the offset 0BE8, action the function with the current value of the offset -- the event function is designed to do this, to always call the function initially, with the current value. So the same effect could be achieved without using events at all. Just: msg = "" val = ipc.readUW(0x0BE8) if val == 0 then msg = " up " else msg = " down " end ipc.display ( "gear"..msg) would be more appropriate. I'm not sure why you'd want the thing started by a key press and ended immediately (by the event.cancel -- cancelling the only event would / should terminate the plug-in (and this will probably be part of the 'fix')). I don't understand the relevance of your last post, with a revised version of your test.lua.. BTW the offset you are using doesn't give you the state of the Gear, only the state of the gear handle. You know that, don't you? Pete

ProSim? I thought Prosim was cockpit software? That's what I use -- Prosim737. I've never heard of them doing hardware. Sorry, I don't know what OC4BA means. I assume this is specific to the OC cards? Almost none of the normal controls work with PMDG. PMDG aircraft are probably the worst choice for anyone building a cockpit because thery implement all of their own subsystems, not using many of the default systems at all. The additional PMDG 737NG offsets supported in FSUIPC are READ ONLY, -- they are for switch states, readouts and so on. All of PMDGs controls are custom controls. I think they provide a list in the .h document in their 737NGX SDK. Mind you, flaps should be controllable by an axis. Does it work assigning in FSX itself? 65758 is FLAPS INC. Seems you have another assignment as well as the flaps axis one. If not in FSUIPC, then in FSX (if assigning in FSUIPC you MUST disable all controllers in FS), or maybe in some other software drivers you are using -- maybe to do with those OC cards or whatever software comes with the quadrant? No. You are mixed up. Offsets reflect changes in FS. The goal is to change things in FS. Offsets are local to FSUIPC. When you write to an offset, FSUIPC communicates the change to FS by whatever means is needed, by control or some other way. If something else changes values in FS, FSUIPC reflects those changes in the offsets so programs can read them. Oh dear. Axes are the joystick levers, the things which prtvide varying input data to FS. You assign axes to controls. Controls are just messages or events which change things (i.e. control things) in FS. Axis controls are controls which have a parameter which is normally the input axis value (maybe after calibration). Many other controls, like FLAPS INC, just do something without a parameter. PAUSE TOGGLE for instance is a control which pauses the sim, or releases the pause when on. In FS controls are also called EVENTS, or KEY EVENTS. You assign to them in FS or in FSUIPC. You are wrong. FS natively does not support reversers on an Axis. That's a facility provided by FSUIPC, and it uses the negative values for the old FS98-style axis controls "ThrottleN_Set". Those controls still exist in FSX but not assignable in FSX, only in FSUIPC. They are the only way to get a proper reverser axis action. Otherwise you have to use repeated "throttleN decr" controls (which is what most if not all PMDG 737NGX users do I think). But PMDG throttles cannot be controlled by the sorts of axis controls FSUIPC has to use to provide reversers. You cannot even calibrate throttles in FSUIPC and have success with the PMDG 737NGX, because they do things completely differently. I really doubt you'll ever have success with a lovely motorised throttle quadrant with the PMDG 737NGX. It really is not suited in any way. 66162 = COWLFLAP1 SET. I've no idea why PMDG use these contorls. You'd need to ask them. I'm pretty sure they are PMDG custom controls. You can find them all in the PMDG 737NGX SDK document, the one with a .h filetype. FSUIPC allows custom controls to be assigned to, by number. Pete

Your second message crossed with my first reply. in addition to what I asked there, could you make sure logging is going to the FSUIPC4.LOG file (not the separate Lua file option), and enable -- button logging -- event logging -- monitor 0BE8 (on the right hand side) as type U16. That way I can see the relative timing of the things happening in relation to the Lua execution. This is with your original code, for now (which i still think is, er, rather odd ... ;-) ). Back about 5pm UK ... Pete

How are you starting this Lua plug-in? Just by button press? If so you should not use the event system at all. That's for keeping plug-ins running looking for events. You program is more suited to loading once at the start of FS (eg via ipcReady, or using an [Auto] section in the INI file). That way you wouldn't cancel the event in any case. Does the same button press also operate the gear? If so, there's a timing element too. Are you using the current version of FSUIPC, 4.945a? If not please try again with that -- not that it will change things, it is jst that the error data I need will then releate to the current state. Can you then please provide the crash details from Windows? I need the error code, module name and offset. If you can't get it displayed on screen, check the Windows event viewer. I've got to go out for a couple of hours or so. I'll check further when I return, trying things here as well -- once I know how you are starting it, because it doesn't appear to make proper sense as a one-shot. Pete

FSUIPC cannot lose assignments. They are stored in the FSUIPC4.INI file and, as you see, reloaded each time. Are you using Profiles? Perhaps you are using more than one livery for the aircraft and have not used the same profile for all? You can use FSUIPC's logging (button logging, event logging) to see what happens in FSUIPC when you operate the buttons. If you need more help I'll need to see your FSUIPC4.INI file, and if necessary the result of the logging. You also need to be sure that those switches are working in the aircraft model. Note that after today I'm away till October 4th. Pete

I think the Saitek Switch Panel only works with its own driver. I'm pretty sure it isn't a standard joystick device.and so cannot be recognised by FSUIPC. You could probably write a Lua plug-in to read it, using the com HID functions. Or maybe use the utility "SPAD", which I think was designed for it. Pete

0330 works fine. How are you reading it? Here's an example from P3D 2.5, using the FSUIPC Monitor facility (right-hand side on Logging tab) with 0330 selected as type U16 (i.e. unsigned word), with some increments and decrements using the Kohlsman control: 313047 Monitor IPC:0330 (U16) = 16322 313047 SimRead: 0330="KOHLSMAN SETTING MB" FLT64: 1020.11390018 314545 Monitor IPC:0330 (U16) = 16327 314545 SimRead: 0330="KOHLSMAN SETTING MB" FLT64: 1020.42640018 315855 Monitor IPC:0330 (U16) = 16332 315855 SimRead: 0330="KOHLSMAN SETTING MB" FLT64: 1020.73890018 320520 Monitor IPC:0330 (U16) = 16327 320520 SimRead: 0330="KOHLSMAN SETTING MB" FLT64: 1020.42640018 321128 Monitor IPC:0330 (U16) = 16322 321128 SimRead: 0330="KOHLSMAN SETTING MB" FLT64: 1020.11390018 321799 Monitor IPC:0330 (U16) = 16317 321799 SimRead: 0330="KOHLSMAN SETTING MB" There's really nothing to go wrong with it, and it certainly hasn't changed since FS98 days! The latest is 4.945 (actually 4.945a now). Pete

I think you must be looking for the wrong thing. In Task Manager the task will be FSX.EXE, not FSUIPC. FSUIPC is just a module, part of FS, it is NOT a task or a process! Pete

What is sending the control with the parameter? The log merely shows what the parameter value sent is set to -- that depends who has set it. I can assign a keypress or button to send it with a parameter of 12345, but it won't change the toggle action. The parameter is ignored except for those controls which use it! The ipc.control function does not have a value, so you cannot test it. That code is meaningless. The parameter there (you have 0) will be logged. It could be any number. It will be logged. But for this control it does nothing, as i keep telling you! No, because many controls do things which don't change any data which is readable. Think about it for a while. Pause Toggle wiil change the pause state, which you can read in an offset, but "ATC MENU 3" just selects something in a menu, "Capture screenshoot" captures a screenshot, "exit" closes FS. What do you expect to read from such events? Events are things that happen, and controls trigger events. Some events change values somewhere, some don't. Many, but not all, values can be read from offsets. I try to cover all the needs, but some escape. Regards Pete