Pete Dowson

Yes, the Installer has nothing else to do. What do you expect it to do once the installation is finished? Pete

Most FSUIPC offsets contain data (and set data) for the basic FS simulation engine. Sophisticated aircraft such as those made by PMDG are written with their own subsystems and the underlying simulation is overridden or avoided in many areas. The "?" means that, although it is implemented, it isn't known whether it works. I normally confirm it one way or the other based on feedback, but folks interested in such detail tend to be using add-ons like PMDG's, so it hasn't happened. Many of the offset data and its operation derived originally from hacking into FS98, FS2000, FS2002 and FS2004, then being implemented in SimConnect in FSX after MS finally realised that folks wanted more flexibility in the interfaces. For the PMDG aircraft you might find something you can use in the data provided by the PMDG code itself, which FSUIPC maps into a different set of offsets. There's a document listing those in your FSUIPC documents folder. But those are only read-outs, you can't write to them to change them. The header (.h) file in the aircraft's SDK folder lists special "custom controls" to actually operate things. Really, in order to try to fix the failures (which surely you can stop anyway if you don't want them?) you'd probably need to know all the symptoms or results, in the values read, and try to do something about them. But that seems unlikely to be possible knowing how much PMDG likes realism. Pete

Good. Please do let me know if you suddenly get the macros doing the wrong thing, as it seems that the rectngle numbers (that hex number after the RX) can change, depending, we think, on what happened before in the same session. If you always load the aircraft first, or as default, it will probably stay ok. I'm hoping L-M will respond to our reports about this. Pete

I'm really confused by this. Those two parts seem self-contradictory. What is this about plugging throttles back in? Are you actually removing them? Are you saying you want the throttle levers to control the throttles, or your plug-in, or is it that you want to switch between? For complete control, instead of assigning to the throttles, you'd need to assign your throttle lever to the running Lua plug-in as LuaValue <name>, then detect this and the value of the lever by event.param. That way you can do what you wish with the value -- send it as a Throttle control after all, or discard it, or process it some other way. But to deal with multiple throttle levers would need a separate plug-in for each. Or, and maybe best, read the axis values which would otherwise have been applied from the offsets provided for this. These are in final units (i.e 0-16383), post calibration. Please do see the full description in the details for offset 310A. You could use event.offset. Pete

Sorry. It was the statement above which confused me. I now assume you mean with other aircraft, not this one? Yes, they should do. But bear in mind the current limitations, which I'm trying to resolve with L-M. Pete

The mouse macro isn't capturing buttons switches or levers! It captures the mouse actions! That gives you assignable controls. So you don't need mouse macros? You can already control it via button assignments? I think you may be asking the wrong questions altogether! Are you really asking how to assign button events to an axis? Pete

So, your program isn't doing what you want? The differences between yo IN and OUT values are too small to have any real affect. I'm not sure, but Ithink the Sim only uses differences or 256 or more! Certainly you'd not notice those differences. And those values are close to idle. Pete

NO! It is the ground altitude. The altitude of the GROUND. The stuff you can walk on! I don't understand what isn't clear? Pete

Didn't you read it? Poster 767300 had a bad hardware card and replaced it and then calibrated flaps successfully. Is that your problemm a bad piece of hardware you need to replace? Pete

Instead of doing ipc.display for the values, why not do ipc.log so that you can show me the values?

It is as it says, the elevation of the ground -- that is the elevation you'd experience on the ground! It won't tell you the elevation of, say, a skyscraper in the scenery below you! Pete

In that case you should be able to use Mouse Macros, as the easiest way. There is a problem we're investigating at present which can make a mouse macro invalid on a subsequent reload of P3D4. I think it's a P3D4 problem and have reported it to L-M. If you always load the same aircraft as the main and first one I think it is okay though. Pete

Check the documentation for "mouse Macros". If they don't work with this aircraft (is it on FSX/P3D1-3, or P3D4?) the only other possible recourse is accessing L:Vars. Do a bit of research with the documentation and you'll find such details. Pete

Yes, the NWI interface I already pointed you to supports weather settings, or oyu can use METAR strings. Rain and snow are part of the weather. It is all one interface, eventually via Simconnect into FS. I don't have any specific samples apart from the old ones in the SDK. If you are new to programming you'd probably be better off using .NET and Paul Henty's excellent DLL (see the special Subforum about this, above). Pete

You look in the List of controls document supplied for you along with all the other FSUIPC documnetation! Unless you assign to an offset control (i.e. one designed to write to an offset) all controls you can assign to are controls, also called Events in FS. 65820 is "Throttle1 Set" and is th very same control used for the separate throttles in FSUIPC which you already said don't work with your aircraft! Use the Axis throttle controls as I instructed way back. Pete

It works assigning to the Axis Thottle controls in FSUIPC, the FS controls not the "direct" controls. Those are the same as those you can assign in the Sim itelf. But you csn't calibrate in FSUIPC. The problem is that most PMDG aircraft read these values "off the top" of the SimConnect pile, whereas, so FSUIPC can calibrate them first, it feeds calibrated controls at a lower level. it has no option. It isn't an "offset" but a "control". Offsets are values you can read and maybe write. Yes, there are throttle offsets, but those would bypass the PMDG mechanism. You can send controls to the Sim using the Lua library function ipc.control. Just look up the number for the Axi throttle controls in the list of controls supplied, and supply the throttle value as parameter. Pete

Please try 4.861, now uploaded. I didn't manage to reproduce the problem but I did see a flaw in part of my logic, and that's now corrected. It does delete the MakeRwys_scenery.cfg file before getting a new one created, so it should be evident from the first few lines of Runways.txt (the log) if it went wrong. I don't see how it can here, assuming the Lorby program works. Pete

Very strange. I'll experiment here. No need for TV. Pete

I just looked on the PA/X forum, and you only posted there recently. I'm pretty sure the folks there have day jobs (not retired like me). It is far too early to say you can't get an answer there! Also I suspect similar questions have been asked and answered many times before -- worth a search through previous threads. Pete

Yes you are. ProATC/X. I'm pretty sure doesn't use FSUIPC or WideFS. If the ProATC/X folks won't help (which is unusual as they've always been very helpful to my observation0, you'd probably be better off in the FSX Forum on AVSIM Depends on versions. There are three FSX versions. most programs will want the last one (SP2/ACC) but that's not guaranteed. You'd need to state that folder and then give ProATC the full network path to the share, something like \\computer name\share name. What SDKs? Sorry, I've no idea. Pete

Which version of FSUIPC are you using? For FSUIPC5 it starts on page 43. It has the explanatory title CALIBRATING FLAPS WITH SPECIFIC DÉTENTES and it is also listed in the Contents, which is on the second page. Please do use the actual facilities available to find these things. For other versions of FSUIPC the section will be on a different page, but the Contents will help -- that's what it is for. another way is to simply search for a keyword, like flaps or detentes. All PDF readers that I know of have search facilities. No link provided. I see no threads originating on Feb 5th, and it really isn't possible to find all messages with that date within threads. There might be a way of searching for all messages by a user name, but I can't find one. If you can locate the thread just select it so it is showing, then copy the actual link which will be in the selection bar at the top of your browser, probably beginning with https:// Pete

Ouch. Okay, then. I'll have to track through the code to see where I can get through with a zero VID -- but always a non-zero PID. I could probably "fiddle" that okay. But obviously I can't test here so please send me an email (petedowson@btconnect.com) and I can send you a link to download a test version of FSUIPC5 when I think I've done. Also, it is interesting that in the Registry they do have names: Pete

Just a clarification, please. Are these log entries when using your original macro, the one you said was looping, repeating the FS control? Because, if so, I don't understand why there's only a second or so between each switch chnage being seen and logged. Do you have the FSUIPC Event logging covering this period (less than 9 seconds)? If not could you reproduce the events like this? I'd like to see what happens on the change -- i.e. do the repeats just continue forever or until thenext change to the same switch? One other useful bit of logging would be to first set LogMacroNames=Yes, because the macro is executed by using offset 0xD70 in FSUIPC, and there's only one place in PFCHid64 where that's done -- just after logging the Macro name. I want to see if it is looping in PFCHid or in FSUIPC, because I simply cannot see any way it repeats in PFCHid unless the hardware is repeatedly sending the report that the switch has changed "to the same position", which the Decode log (snippet above) didn't show. In other words, it is not making sense at present. BTW if I cannot solve this strange problem with PFCHid, or it simply takes too much time, your needs could probably be met with a Lua plug-in: You would use event.intercept to get notification of the write to 0x3880 (Engine 1 Tank Selector) and if the "UD" type value is 0 write 0, if 1 write 2, if 14 write 3. This would actually be more efficient than using macro file execution. Pete

It isn't created here. i think it only gets created as a default if no filename is given wqhen it is run. MakeRwys runs it WITH a command line parameter giving the locationand name for the CFG file it uses. If you have that default file it is because you ran LorbySceneryExport.exe separately, and with no parameter to tell it otherwise. Ah! That shouldn't be so. It is supposed to give time to allow the file to be created. This has always been the case, even before this new method, and yours if the first report of that not working. I shall extend the time. Perhaps your disk or processor is rather slower than others. [LATER] Just checked. It allows up to 20 seconds for the Lorby program to do its job. I'll extend that to 40 seconds, Surely that will be enough? I'll also delete the previous file before executing the Lorby program, so you'll know it isn't the wrong one. If it still fails, the log will show that it used the main SCENERY.CFG file. Pete

No. I think that won't be a difference in PID, if the devices are the same. In HIDDEMO it is the Device number which needs incrementing. Well, the values I can read are those shown in the HIDscanner output. Are you sure those names are not just in the Registry, maaybe installed by a driver? What does the FSUIPC5.LOG show? Try the "" string values first,. Pete