Pete Dowson

There's no PollInterval parameter by default --- when omitted it defaults to 25. The parameter is described in the Advanced Users manual. You will see that there are lots of parameters which don't appear when defaulted -- you ADD them when you want to change default values. The ButtonRepeat parameters don't change button or axis scanning/polling rates, only how often the button action is repeated when it is held. Pete

D008 never stays fixed for more than a few seconds. I added code to do that many versions ago. So either you are very much out of date with your FSUIPC (you don't say), or something stopped RC long enough for it to fall foul of one of its timeouts. I did suggest years ago that RC could simply continue. It isn't a disastrous error and shouldn't result in the program stopping. On a very busy system he can (and evidently does) miss the signal. A longer timeout or more retries would work, as would simply logging the error and continuing. Sometimes it might mean he doesn't determine the runways in use by AI so quickly, or doesn't get the identity of an AI aircraft which just appeared, but that's all D008 is involved in, and carrying on would never be as disastrous as stopping. Reinstalling FSUIPC never ever changes anything whatsoever because the code doesn't change. Updating to a more recent, supported, version (3.98 and 4.60 are the earliest supported versions in any case) might, but the real problem is in RC's treatment of a transient timing glitch related to AI ancillary information requests. Performance, performance, performance. Something is getting overloaded. There's no other cause that I can think of at all. It's something stopping something from happening for too long, that's all. You don't mention WideFS, so I assume all those things are running on one PC. That's a large load for one PC. Maybe manipulating priorities of programs would help. Or reducing the FSX settings (especially AI traffic levels). Or limiting its frame rate more. Or switching to DX10 instead of DX9. Or updating to a more efficient video driver. Or overclocking your PC. Or not running so many add-ons. Or using a simpler aircraft .... In other words, anything which reduces the loading could help. But the correct fix would have been in RC. I hope JD took enough notice of my suggestions to sort this out in RCV5, but as yet there appears to be no end date for that. Regards Pete

Okay, but don't discard your code above yet, as I've looked at my code for the "key" events and I think I can accommodate a "repeat" option quite easily. If I do you can try both ways and see which operates better for you. I'll post again when and if I have anything for you to try. Regards Pete

Okay. i see why you want the event to repeat with keypress repetition. I could consider adding such a facility. I'll think about it and let you know. But meanwhile there are at least two ways of doing it. First there is the more usual way to do it, without events, just using normal Lua assignments. Use a free user FSUIPC offset, like 0x66C0, for your "select" variable. Assign the keypress to increment that cyclically, or whatever (or use two variables, 0x66C0 and 0x66C1). Use Offset Byte Cyclic Increment, for example. you'll find this is the FSUIPC drop-down assignments list. Then each of the inc/dec routines is replaced by a Lua program like this example (say "WholeInc.lua"): select = ipc.readUB(0x66C0) if select == 0 then ipc.control(65641, 0) end --NAV1 RADIO WHOLE INC if select == 1 then ipc.control(65645, 0) end --NAV2 RADIO WHOLE INC if select == 2 then ipc.control(65637, 0) end -- COM1 RADIO WHOLE INC if select == 3 then ipc.control(66437, 0) end -- COM2 RADIO WHOLE INC Assign the WholeInc key press to "Lua WholeInc", which will then appear in the drop-down assignments list (use the RELOAD button after saving the new Lua programs). And so on. The repeating key action is then automatically taken care of. The other way, still using events, is more complicated. You'd still have the separate Lua's like "WholeInc.lua" but now they'd be called by the event processing Lua thus: function whole_inc(keycode, shifts) ipc.runlua("WholeInc", select) end and the "WholeInc.lua" program would loop forever: select = ipcPARAM while true do if select == 0 then ipc.control(65641, 0) end --NAV1 RADIO WHOLE INC if select == 1 then ipc.control(65645, 0) end --NAV2 RADIO WHOLE INC if select == 2 then ipc.control(65637, 0) end -- COM1 RADIO WHOLE INC if select == 3 then ipc.control(66437, 0) end -- COM2 RADIO WHOLE INC ipc.sleep(100) -- this is 10 incs per sec. Adjust to taste end You'd then need to process the keyup events too (downup = 2), calling a function to execute ipc.macro("Luakill ....") to kill the repeating Lua. The first solution is better and doesn't involve any complication or permanently loaded Lua programs. The small programs just run when you press the keys. I will look into the possibility of a "downup" parameter for event.key which specifies repeats required too, but I can't promise anything. I do feel you've made it rather more complicated than you need to. Feel free to ask further questions if anything isn't clear. Regards Pete

Not sure why you want to program this as a Lua plug-in. Wouldn't direct assignment to those functions be better, easier? Quite honestly, if this is all you want to do and you really do want it in Lua, I would simply assign the keypress to run the Lua program. Why use the event library? If you really want to use the event library I think it might need two Lua plug-ins, one to process the events and the other to operate the inc/dec. Regards Pete

Why not just detect the press, detect the release, and repeat whatever it is you want to repeat yourself, at your desired rate? That's a more elegant and controllable way, don't you think? If FSUIPC tried to pass them on it would either have to queue them, waiting for the event processing to finish, or forcibly restart it to re-enter it. Neither of those ways is very nice, and any other way could give an irregular or unwanted repeat rate out of your control. In other words, the reason I designed it so that repeats don't result in events is because it is not necessary to depend on the standard Windows or keyboard auto-repeat when you can do it with more control yourself. (It's the same for button pressing of course). Regards Pete

The name needs to be the same, but in all currently supported releases you can enter a different email for WideFS. Use the Installer to register. Earliest supported releases are 3.98 and 4.60. Regards Pete

Go through all the assignments in FSX and unassign them. It just occurred to me that there is one other thing you can try first. Increase FSUIPC's joystick polling rate. I have doubts that it would help as its polling rate is already higher than FS's, but still. To try that set the PollInterval parameter in your FSUIPC.INI's [buttons] section to something less than the default interval of 25. If you set it too low it may impinge upon FS performance, but you could try 15 or 10. Pete

I don't think IVAP uses FSUIPC offsets, does it? Regards Pete

As I said, if you want to assign just the Pan View in FS, do so. Everything else in FSUIPC can be left as is. Just be sure that nothing assigned in FSUIPC is also assigned in FS. That's the only thing which will cause problems -- the same axes or buttons assigned in two different places will both activate and cause confusion at the very least! Regards Pete

You mean the "List of FSxxx controls" document, installed alongside all the other documents and Lua stuff when you installed FSUIPC? That lists all of the FS controls that exist. The additional ones added by FSUIPC are listed in the FSUIPC Advanced User's document. There isn't one. FS has never simulated any of the transponder selector switch settings. If you are using Squawkbox or FSInn the FSUIPC added transponder standby/on controls will work (you'll need to update the FS version to the most recent version -- see the Updates and other goodies announcement near the top of this forum). Regards Pete

66C0 - 66FF are free for personal use. If you are writing software for others to use you need to work out how many bytes you need (I normally allocate in blocks of 16) and apply for a private assignment. Write to me at petedowson@btconnect.com when you've worked it out. Regards Pete

Okayyou don't need the VRi MCP to reflect the MCP values as well? It sounds like you've got some VRi device command wrecking your code. The only way to find out what is going on is to use the logging. Unse the VRi logging additions ot the FSUIPC INI file (Debug=Please and LogExtras=x4) and see what exchanges are truly happening. My bet is you are getting a HDG string which has no number -- maybe a hdg command other than a value. Your lines: hdg = tonumber(string.match(str, "HDG(%d%d%d)")) ipc.writeUD(0x5408, hdg) have no check that there is indeed a result, so a zero is quite possible. If you check my example, for Speed, I included a check like if speed ~= nil then ... before writing an offset with the result. Regards Pete

Why would you want that? You'd have to make adjustments for navigation, for runway and ILS headings, etc. I was talking about options in those otherwise apparently buggy programs you are using. Pete

well in that case I don't know how you find it so unacceptable. It seems pretty good to me, though of ocurse it will depend on FSX frame rates. Maybe you have got really bad FSX performance? Yes, just don't assign any of the FSUIPC controls in FSX (unassign any that you have). As long as you don't assign in both places, you can mix and match as you wish. Pete

No. you have to get the Lua program to re-run. To do that simply assign any keypress or joystick button to that Lua program, so you can re-run it any time by pressing the button or keypress! All Lua programs show up as assignable in the FSUIPC assignment drop downs -- that's the whole point, and the normal way they are ryun! Thats what i trying to do. So what is stopping you? There's no editor in FSUIPC. The plug-ins can only run in FSUIPC. Only FSUIPC can start them. I really don't understand how you have become so confused. Of course you can keep your editor open whilst you test, but there is no editor which sends a keypress or button press to FSUIPC!! Pete

How? you cannot do that! It is entirely dependent upon FSUIPC and FS data! Because you've not used those additional Lua lines I pointed out, the ones already in the VRI_SetMach example? You only had to change the COM port numbers to match those you are using. You can't. Just assign a button or keypress to run it, and use that to rerun it after each change. There's no need to keep restarting FS! I did explain all this a while back in this thread -- did you miss it? Pete

What, to make a program display magnetic instead of true heading? No, not really. There is a fiddle available to "spoof" values (make them read differently, mainly to emulate equipment failures), but that would make everything reading the value incorrect. Assuming the program was intending to show magnetic but instead it is showing true, then it is an out-and-out programming error. However, maybe it is deliberate? Maybe it is an option someplace in the program? I find it hard to believe that anyone would make such an obvious error and not notice it, even if they only flew in the UK where the Mag Var is quite low -- it is still noticeable. Regards Pete

Yes, but you also want an event for each offset which you want to update your displays with. See the "VRI_Setmach" plug-in example. There are events there for all the FS offsets which affect the speed display. You'd need to change those for PM and add ones for heading, altitude, and V/S. Yes, and 540E for Mach. The mach or IAS mode would have to be read from PM too. Not sure where off-hand. These offset would be for setting the values (i.e. writing to PM). For reading the values in order to update the MCP display you need to read 04E0, 04E2 etc, as documented in the PM list. So, for Events to update your displays you use the 04xx values, for setting the MCP you use the 54xx values. Also, though it doesn't say so against 540A, I think the altitude is in 100's of feet as it is for 04E4 (and the V/S, in 04E6 and 540C). No, not 5406, 0x5406. All the offsets listed in the PM document are hexadecimal, as they are in my lists. Regards Pete

How are you assigning the hat? It should be assigned, in the axis assignments, to "PAN VIEW". You can assign it as 8 buttons instead, but that is really more suited to view changing rather than panning. FSX doesn't have to go through SimConnect, it can operate things directly. However, the pan view command from the axis assignment works pretty well as far as I can see. If it is unacceptable to you, please assign it in FSX instead. Regards Pete

If it is incorrect it will be an error in those programs. Where are you when seeing this 2.5 degree difference? Are you sure it isn't the magnetic variation? Possibly you are comparing magnetic heading with true heading? Try at Seattle (KSEA). The variation there is about 20 degrees. See if the difference matches. FS frame rates limit update rates. I don't know about the programs you are using -- their update rate is up to them -- but the WideFS data rate should approximate the FS frame rate, within reason. I run 7 client PCs on my FSX system and they all have a WideClient data rate just below the FS frame rate. You can check performance of WideFS by stats written to the WideServer and WideClient logs when the programs are closed. Regards Pete

The one Lua. There are no facilities to have more than one automatically run from each [VRInsight ...] device section, though the Lua being run could start other Lua plugins if it needed to -- but i don't see the point. They wouldn't inherit access to the COM devices. No. You cannot do it. surely you must have tried it and found this out? Just do everything in the one Lua program. Incidentally, the FSUIPC INI file is like all Windows INI and CFG files -- each parameter line has a unique identifier left of the "=". I don't know what Windows does when there are more -- it might ignore the later ones, or the later ones might override the earlier ones. The FS CFG files have the same restriction. Regards Pete

Yes, that's where the latest official user versions are. But it isn't my page, but instead run by Enrico Schiratti, and I cannot get it updated as easily and freely as I can this Forum. So I supply updates to Enrico as and when I've got a fully documented new release and wish to discontinue support for previous versions. Meanwhile I can add lots of little goodies, possibly adding up eventually into a worthwhile new release, in this Forum. Actually, the list of enhancements since 4.60 and 3.98 is getting quite significant, so i am planning to get to work on the documentation again soon, and then make a full new release. But it will probably be October or November by then It's a shame I cannot make the Announcements here stand-out more, become more prominent. They do look like just other threads despite the separate heading. Regards Pete

That was dealt with a while back by using the SimConnect ClientData which SB4 creates. In fact I added new FS controls to handle it so it would be compatible across SB3 and SB4. The place to look for updates is always the Updates and other goodies Announcement near the top of the forum. Since 4.60 was released in March there have been 22 updates. The list of changes is provided there too, and you will find the matter dealt with. It was within days, probably hours, of the thread you refer to. The Beta mentioned in the thread you referred to has probably been superseded by several others since then, which is why the link is no longer valid. It often surprises me how many folks come to this forum and never seem to see the Announcements, where most of my assistance and extras are provided. How does this happen? Aren't they visible on your browser? Regards Pete

It is only FSUIPC offsets hacked from PMDG aircraft gauges while I feel unable to publish because PMDG hold them as confidential and, in fact, deliberately attempted to obscure them to prevent folks, as they thought, taking advantage of all their hard work. Although I disagree with that point of view I have to respect it, especially because the use of FSUIPC offsets by applications is a private and trusted arrangement between them and me. PMDG aircraft only use FSUIPC offsets on FS9. Their FSX versions use SimConnect and, to some extent, FS "L:Vars" (named local gauge variables). I see nothing wrong with determining the functions of L:Vars and making use of these where they do prove useful, so I am not particularly averse to publication of such findings here. Good luck! Regards Pete