Pete Dowson

Not sure what you mean. With [Auto] 1=Lua DynamicFriction in the INI file, that friction plug-in will operate with all aircraft. If you edit it to [Auto.737NGX] 1=Lua DynamicFriction assuming 737NGX is the name of the profile then it will only operate with that profile. Pete

Well, it must either be a keypress or button, or, if you want to write a program, you could start a Lua by writing the command to an offset. Seems a bit, er, complicated, compared to pressing a key? You would have to write a program to send the request to FSUIPC. Do you really think that would be "tidier" or "more efficient"? I certainly don't. If you just want to develop and test programs which don't use any of the libraries provided by FSUIPC to interact with FS, then there are such development environments available. Have a look on the Lua website, I'm sure you'll find links to them there. I suppose you could put dummy calls in for any FSUIPC Lua library calls you wanted, and try to test the logic separately. But you'd need to be developing really seriously complicated programs to really justify that. Most plug-ins are pretty simple and rarely need any complicated testing at all. Pete

You have a conflict then. If you are assigning in FSUIPC be sure to disable controllers in FS. Also, if the IN value 0 s converting to 86 for OUT, you haven't calibrated it properly at all. Follow the calibration instructions in the User Guide. Pete

To load it just for the NGX, you need to have the NGX configured in an FSUIPC Profile, eg "737NGX", then use [AUTO.737NGX] 1=Lua DynamicFriction Pete

Sorry, I don't have many of the interim versions, and not that one. Best now to stick with the "w" version (not v -- you said that made no difference). Pete

If it's the Lua language itself you are talking about, there are some excellent books on it. Try, in order: "Beginning Lua Programming" by Jung & Brown, pub Wiley 2006 "Programming in Lua" by Ierusalimschy, pub by Lua.org (maybe available on-line?) "Lua Programming Gems" by de Figueiredo, Celes and Ierusalimschy, also Lua.org. Ah, do you mean debugging, as opposed to efficient end results? Two techniques which you can of course mix. One is to program lots of logging into the script in the first place, logging important steps and values, but made conditional on a boolean value being true. Just define, eg "Debug=true" at the beginning, and hen all is working change it to "false". The other is just to use the debug/trace facility built in (see FSUIPC Logging tab). This logs every change to every variable and the line in which it occurs, but it needs enabling BEFORE the subject Lua plug-in starts. If you do actually mean efficiency in execution, then always consider using the event library, with your plug-in preloaded (via an [Auto] macro, or by loading it in the ipcReady.lua plugin) unless the action is infrequently needed and always in response to a keypress or button action. Pete

I need the crash information. With no information I cannot possibly help. Why keep the Event Viewer data to yourself? It is intended to help find the problem! FSUIPC knows nothing about Multiplayer and it doesn't affect it at all. It is more likely something to do with how the B206 is using FSUIPC, assuming it does. No idea what "fix" that is talking about. Any fixes from the past for FSUIPC would have been built into the next update. And I don't recall anyone else reporting a problem with FSUIPC and multiplayer. As well as the Event Viewer details, please also show me the FSUIPC4.LOG file, from the Modules folder, after you get the crash. You can paste the contents of the file into your reply here. Pete

Hmm --- the buttons showing are in the correct place, just not showing the others. Very strange. I really don't know how to help. I would need to reproduce the problem to find out what is going on. Sorry, there's absolutely no other changes, and certainly nothing has ever changed in the actual drawing-on-screen code. Unless we can figure out a way of actually me being able to reproduce it going wrong here, I'm afraid I cannot help. That in itself is mighty odd, as the ONLY change from the 'v' version is that two lines of code, where it checks the width and height of the button and prevents it getting smaller than a size computed from the font size, are commented out. No other difference whatsoever. I've been dragging both borders all over the place and apart from the way the text wraps over button borders when the window is too small, there's no change whatsoever in the layout. Very very strange. Maybe it's a good job you still have an older version? Was there a specific reason you updated? Most all of the changes in the last two years or more have been small changes for mostly specialist reasons, mostly for me, to support automatic Radar Contact plan generation from Project Magenta and later Prosim CDUs. There's been no changes in its Network capabilities or options for many many years. Pete

Okay. My Internet was down until just a couple of hours ago, but I've now managed to test WideClient with your ButtonScreen. I'm afraid I cannot make it fail. You said in one message that "Wideclient opens most of the buttons are missing and what is left are in the wrong place. The rest of the Wideclient window is black.". This certainly happens when the Window opened is smaller than the minimum WideClient likes in order to allow for the text in the boxes. Even when I make the Window large enough to get 17 x 17 buttons showing -- not easy even on a 27" monitor running at 1920 x 1200 it needs to occupy almost all of the screen, and you seem to have a deliberate black area all the way over from line 3 town to line 14 and column 4 to the right edge. Is this your "rest is black"? I've looked at the code and, apart from the minor change to stop button presses being sent for null and single space labelled entries, there's been no changes in the ButtonScreen at all. I'm at a loss to explain what you think is wrong. Are you sure it isn't just because your Windows size it too close to the minimum it can cope with? When that occurs here the arrangement is all messed up and some buttons will be "off screen" (i.e. missing in the usable area). The restriction on the size is just a precaution to ensure that the minimum font size I'm using still fits. Just in case it is this restriction which is affecting your display (maybe the size is just really close to the limit), please try WideClient6999w. All I've done is remove the size check, so the layout is retained even if the Window is much too small -- the text will just overlap the button boundaries and look a right mess. Let me know please. Pete

Sorry, sending "to Lua" how, from where? If it's using the com library, reading from a device, then there will be a buffer. You wouldn't lose anything, just maybe run behind (latency). The logging would slow it a bit, but the actual file output for that is in a different thread. If each input involves interaction with FS then that could take longer in the plug-ins thread, depending on what it is doing.Pete

Please see the FAQ subforum thread "read-this-if-you-lose-your-fsuipc-or-widefs-keys". Pete

Sometimes it's obvious, some need trying and seeing, and the Simconnect SID helps too. Pete

I've implemented many things like this. The problem is latency in the FS/Disconnect/FSUIPC loop. The solution which always worked for me is to update your display at the same time as sending the values to FS. Only update the display from a value received from FS when the last change from the user is more than X mSecs ago -- just experiment with X to find the best value, probably 100-500. Pete

There''s no uninstaller, but nothing related to FSUIPC is ever put anywhere other than into the Modules follder. But there will be an entry for it in your DLL.XML file -- that's how Simconnect knows to load it, along with any other add-in modules. Also, there are some other add-ons which may use the Modules folder. Pete

The events are not accumulated. If the previous event is still being processed in the plug-in when the next change occurs, it is simply flagged and sent when the plugin exits. If there were multiple such events they are made into the one.So, I think you may be misinterpreting some results? Maybe you have multiple events being processed in the same plug-in, and a more frequent one is preventing others from signalling? If so, that would be fixed in the most recent FSUIPC version. On your last question, yes of course your plugin can delete and re-establish events, but be warned: if you delete the last outstanding event, then on exit your plugin closes Pete

It must exist, but because I assume you are using a 64 bit version of Windows, it gets transmuted by the 32 bit interface FS uses into HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft Games\Flight Simulator\10.0 Best to user search facilities when using Regedit, else you can miss things you needed to delete. I suspect now that FSX-SE has installed as side-by-side even though you did not want it to. This can in fact be seen by the fact that both FSX and FSX-SE are found in the first pass of the Installer. It was only the fact that you'd deleted FSX which gave the the failure on that first part of the installation proper. You should have aborted the attempt to install for FSX and let it go through to the part for the side-by-side install for FSX-SE instead. BTW your subject says "Registration Issues", but I don't see those? Pete

And does the FSUIPC log confirm that the G3D patch is applied? Which version of FSX and which of FSUIPC? Pete

Registration is just the FSUIPC.KEY file in your FS modules folder. Just delete it. But I don't know of any reason why that would make any difference, unless the Lua program you were using is very badly written. Pete

Sorry, but I've never actually had a logo. I've never really been publicity minded, only being interested in the technical and programming side of things. Maybe Simmarket / Simflight have one, though probably the first was by Enrico Schiratti, for his "Dowson" page. Pete

But 3G and 4G are phone technologies. I can't use them on my PCs. I need to reproduce the problem to fix it. Give me a few days. Pete

Hmmm. I've been using ButtonScreens ever since I added them (I did them for myself after all ;-) ), and I've never seen such problems. I'm wondering if it's related to the size-- 17 x 17 is huge. Is that on as touch screen? I'll try your config here to see whether I can reproduce it. But it won't be till Thurs, earliest because I've had two power outages in the last 18 hours and my internet connection is currently limited to 3G on my iPad! Pete

Mouse Macros only work if the gauges concerned are written in one specific way, in C or C++ following specific gauge SDK rules. Very few newer aircraft gauges are written that way now -- many are in XML instead. You might find L:Vars more usefulf -- local panel variables. As to what you deleted to lose your settings, I'm afraid I've no idea. Do you have a backup? I also am not at all sure what you mean by "FSUIPC Virtual Button" -- where do you see that? Oh, and sorry but I cannot support Saitek -- you need their support forum for their stuff. Pete

OK, I think I've fixed it. Please download FSUIPC4939s.zip. and try it for me. Thanks Pete

Well, my start-up situation for my Prosim737 is cold and dark, and if I switch to the FSX default 738 it too is cold and dark. But even before that I've never failed to get a cold and dark state and I have ALWAYS started FSX (and FS9 before it) in that state. PMDG uses custom controls. You can asign to <custom control> in FSUIPC, and give it the appropriate number computed from the NGX SDK ".h" document details. Pete

What flight simulator (FSX, FSX-SE or P3D?) and which version? What do you mean " seems to line up with the patch for the g3d.dll file"? Pete