Pete Dowson

You need to refer to the Lua library documentation! Both sound.query and sound.stop need the REFERENCE to the current sound you started, not the wave path! i.e. in your case PumpSound. Pete

Is FSUIPC getting the 737NGX data? Check something more obvious, such as the Flight Number string at offset 6614. Read that via ipc.readSTR. If that and other data is ok, then the Annunciator indications problem becomes a question for PMDG. There are parameters in the FSUIPC5.INI file to enable/disable the various PMDG offset reading. Check that this is not set to disable them. They should be enabled by default -- either PMDG737offsets=Auto or PMDG737offsets=Yes Pete

Why? The FSUIPC INstaller does that for you. I've always had the Tools and AddOns menu running with no problems. I don't understand why you are manually editing the XML file. You can use SimConnect logging to see what DLLs and EXEs are being loaded by SimConnect from the XML files, and it also logs the error number/message if one it sees does not load. Check that. SimConnect logging is enabled with entries in a Simconnect.ini file in your FS Documents folder. See the FAQ subforum for a thread on that. Pete

Strange. The .PLN is only supposed to be added when SimConnect supplies the filename without. Is this a plan being loaded by the flight file? If so please show me or attach the FLT file (C:\Users\DBT\Documents\Flight Simulator X Files\FSX Startup for Complex Aircraft.FLT). Or are you loading it explicitly? It doesn't rename any files, it is a correction to a bug in SimConnect for the facility which provides FSUIPC (and other interested parties, like ActiveSky) a copy of the flight plan path when on is loaded. FSUIPC only uses it to populate an offset so other applications can use it. ActiveSky uses it to tailor its weather updates better for your planned route. It was added as a result of reports of this weird SimConnect bug which i think was to do with plan files with an extra "." in them. Please see this thread: I'll check here to see how .PLN.PLN can arise. Maybe the original didn't actually end correctly as ".PLN" and so FSUIPC added the cirre ending. i'll make sure it checks properly for an existing .PLN earlier, if that is the case. Pete

If the bitmap is being produced then it indicates FSUIPC is receiving data from Active Sky, and using it. It may be that the Active Sky parts aren't working properly, or that the parameters you are using to request the weather are not set correctly -- eg using a downward tilt angle whilst on the ground, or setting a silly range. The parameters are set by FSUIPC offsets as documented. You can check thse by using FSUIPC's Monitor facilities on the Logging tab. Try slewing up and placing yourself in the middle of the rain cloud layer. Pete

Sorry, I've no ideas how this relates to anything. The last i saw from you was this: So what are you talking about now? That depends entirely on how fast your FS is running, and how much degradation you are will ing to make it suffer. But 5 Hz is only one poll every 50 mSecs, which is normal for an FS frame rate of 20 fps. Relatively slow. But there's no way of guaranteeing a "constant" ratre. It is bound to vary a bit according to what FS is doing. just read the elapsed time offset too (it is in milliseconds) so just can adjust for any unevenness. Pete

I'm sorry, but you will need to provide more details. What controls or key presses or whatever do you need to send for your APU? And is this a button with a momentary action -- i.e. "on" when you press it, "off" when you release it? Pete

FSUIPC does not run Lua plug-ins at the sort of speed a dedicated separate program, DLL or FSUIPC application will tun. This is deliberate because the plug-ins are running in-process, and there can be very many of them. They are excellent for prototyping a design before code is written, and doing things like updating dispays, and I have supplied demos even synchronizing two copies of FS across a Network. but really they are unsuitable for fine control and will never manage speeds much higher than the FS frame rate. many internal processes in FS operate at higher rates. When FSUIPC used to do direct wind control (at the aircraft) it did this by hooking directly into the FS code, it didn't use SimConnect. Thanks for the info relating to C:SIMVARS. I may look at that when I get some time. Pete

Sorry, what were you logging and expecting to see? According to the notes on this variable in my code, it accepted writes to it without error. And this is confirmed in the Simconnect reference, here: TURB ENG CORRECTED FF:index Corrected fuel flow Pounds per hour Y - That is the variable represented in offset 2020, with index set to 1. The 'Y' in the 4th column means "Settable" according to the column heading, so it should be working. I really can't do any more than use the facilities available and assume they work as documented. Maybe the rest of the simulating engine is working so much faster and so overwriting it. How frequently was the "(>C:SIMVARS:TURB ENG CORRECTED FF:1, pounds per hour) through the XMLTools.dll interface" action being performed? BTW I'm interested in that "C:SIMVARS:" way of accessing SimVars. Do you have the XML source for that? I'd like to know how it interfaces to P3D. It might be something I could add to FSUIPC5 in the future. Pete

I don't have anything using that particular window type. I could write a small Lua program to emulate RC's use of it, but meanwhile, in P3Dv3, did the show/hide facility work without any changes being made in the text itself? And did the display automatically reappear if the text changed -- or not? I would like to emulate the original behaviour but I don't even though I did use RC up till 3 years ago I don't recall how it operated because I never used it with its menus on the FS screen. I always used the facilities I added via WideFS and Lua to move the display to a small screen in my cockpit where it is controlled by local buttons. (I did the same with Simconnect menu windows, such as those from GSX, as well. Sadly, I'm still waiting for some L-M-promised facilities in P3D4 for that at present). Pete

The facilities used in FSX and P3D3 aren't available in P3D4. They were implemented by a hack into the Window module in the sim. Instead, in P3D4, FSUIPC uses the normal SimConnect Text window provisions. Those windows are closed when the text in them is cleared. Are those facilities still displayed in FSUIPC options? I might need to change that. Here the displays certainly close when the Window is cleared, but i suspect that needs to be done by the program for which FSUIPC is displaying it. For example, ProATC/X (which I use now instead of RC) has keypress options to bring up or close the menu. If RC is relying on simply using the FSUIPC shortcut, and not actually sending a blank text to clear it, then that may explain your problem. I'd need to look at the possibility of imposing blank text automatically. The trouble then is losing the display if RC doesn't re-send it until it wants it changed. That makes it more complex -- I'd have to look at saving the text so it can be re-drawn, and updating that if the offset RC is using changes. I will look to see what I can do, but it won't be till later in November. I'm away till the 15th. Pete

So EZDOK is not yet compatible with P3D4.1? Pete

Yes, of course. One byte is 8 bits. 8 x 4 is 32. Correct. You re reading it there as a float, a 32-bit floating point number. That's what you need to get SIOC to do, if it can. Yes, length 4 is correct, but it is evidently reading it as an INT, not a float. Yes, again. Exactly as I originally said. But it isn't the legth you have wrong, it's the type of number. I see Luke has also answered saying the same. And yes, in case you ask for a 4th time, even though I answered it in my previous response before you asked another 3 times, a float it 32 bits = 4 bytes. (A double is 64-bits = 8 bytes). One byte is 8 bits! Pete

Ah, well, then FSUIPC is not likely to see it either. Both are using the same DirectInput HID functions. Seems those "buttons" aren't true HID buttons. Does anything see them? Are you sure they are buttons and not just safety stops? Pete

That's a function of the aircraft visual modelling. It isn't necessarilty related to the actual simulation mechanisms. That's more a question for L-M. Sorry. Pete

Er, oh dear. Rudder trim is NOT a steering control!!! Even if you used it okay before, You should NOT. It is what it says, a trim control, for trimming the rudder, for correctly an out of trim rudder, or, for example, so that flying in the air is made easier if you have an engine failure and have to fly permanently pushing the rudder. In other words the same sort of use as elevator trim to relieve pressure on the yoke. For steering you can use STEERING SET, as described earlier in this thread (did you not read it before adding to it?), or RUDDER. You can assign to AXIS RUDDER SET in the FS control list, or RUDDER in the "direct to FSUIPC calibration" list. If you want gradual transfer from steering tiller to pedals you use FSUIPC's "direct to" Rudder for both controls, and calibrate both. But P3D supports Steering directly with Steering Set, so there's really no need. You should also make sure that the auto-rudder option is disabled in P3D's options. Pete

If it is a 32-bit floating point number, it needs no handling whatsoever. You have to treat it just as a 32 bit floating point number! You are thinking of an integer, with fractions built into its value. And in any case 65536 * 65536 is over the maximum value a 32-bit value can take, so dividing it into any 32-bit value will give zero. In fact if your "SIOC" is using 32-bit integers in any case, 65536*65536 is already zero, so you should get an error using it as a divisor. So treat floating point numbers as floating point numbers. They are NOT integers. They have a sign bit, and exponent and a mantissa. 3 parts within the 32-bits. Look up "floating point" if you don't understand. Intel processors support two formats of floating point: 64-bit and 32-bit. In C/C++ 64-bit ones are called "double" and 32-bit ones "float". I don't know anything about SIOC, and other langiuages have different names for them. Pete

The instructions seem clear enough. What are you confused about? Active Sky Next won't work properly with P3D 4.1. You need the new Active Sky for P3D4! So you need to change the computer name "PMcomputer" to "CDU". What's the problem with that? BTW what is wrong with PM support? Don't they have a support forum now? Pete

So it isn't related to the subject of this thread. you are really in the wrong place. Is this relevant in some way? You answered several things which i didn't ask, details which you gave in your first post, but there are still three relevant questions you haven't answered at all! i.e. Are you assigning in P3D or FSUIPC?What control are you assigning to?Are you calibrating in FSUIPC? Pete

Yes, interchangeable both ways. You'd need to have it renamed correctly -- FSUIPC4.INI for FSUIPC4, FSUIPC5.INI for FSUIPC5. Facilities not supported, if any, will simply have their parameters ignored. Pete

Is it a button seen by the Sim, and/or by Windows' Game Controllers? If so, is the number over 32? FSUIPC can only handle button numbers 1-32 (which it knows as 0-31). I know the Saitek quadrant has a normal button in the full reverse position, but I didn't know the CH one did. You need to check if the button works at all, and if so what number it is recognised as. Does the CH quadrant only have one throttle lever? If not, do the others have a button there? If so, are they recognised, what numbers are they? Pete

Thanks. But that could be even simpler, just this one line: ipc.writeLvar("L:OHD_EXT_LT_ACOL_SW", ipcPARAM) That does exactly the same. Pete

I'm afraid you give zero information from which to help you! This is with the FSL A320? How is it similar? Are you assigning in P3D or FSUIPC? What control are you assigning to? Are you calibrating in FSUIPC? Does it work (to steer) using default aircraft? Pete

MOVED FROM "ANNOUNCEMENTS" SUBFORUM! Why post a support question to an "Announcements" subforum? It is in no way any sort of Announcement! Sorry, I don't really understand the question. Are you asking which? Which of what controls, by name? There are actually none to do with INS or aligning it. FSX/P3D itself doesn't support any IRS system internally. If you are dealing with a working IRS system in an add-on panel or aircraft than you'll need to ascertain whether that has such controls, possibly accessible by keyboard shortcut or local panel variable (L:Var) which you can program. Pete

Very good. Could you show your final working result please? Might help others who'll refer to this thread. Thanks,Pete