Pete Dowson

I've just used this simple Lua plugin: ipc.writeFLT(0x86B4, 0.0) ipc.writeFLT(0x86B0, 0.0) ipc.writeFLT(0x86AC, 52.0) ipc.writeFLT(0x86A8, -0.47) ipc.writeFLT(0x86A4, -0.37) ipc.writeFLT(0x86A0, 0.5) to set the same values as you cameraData.fDeltaX.Value = 0.50f; cameraData.fDeltaY.Value = -0.37f; cameraData.fDeltaZ.Value = -0.47f; cameraData.fPitchDeg.Value = 52.00f; cameraData.fBankDeg.Value = 0.00f; cameraData.fHeadingDeg.Value = 0.00f; (but note that I wroyr 86A0 last, as that is the "trigger", and it succeeds in making the current view an angled overhead one from quite a way up. Not sure if that's your intetion. It certainly doesn't do "nearly nothing" as you reported. I really don't know what it is supposed to do. What units are those Delta's in, and relative to what? If I set them to 0 I'm looking at the nose wheel for under the aircraft someplace, so I assume they are relative to the aircraft's datum point. Pete

You've never used any of FSUIPC's logging facilities? They are the most important part of the tools provided for debugging. It's all covered in the documentation. Logging tab in FSUIPC options. Monitoring specific offsets is in the table on the right -- up to 4 offsets. Send to "normal log". Log files (along with absolutely everything concerned with FSUIPC) are in the FS Modules folder, of course. Pete

Strange, because previously. It was using completely the wrong offsets! Best monitor the offsets (well the first 4 anyway) and show me the log. When I get a moment I'll try writing to them from FSinterrogate, or maybe a Lua plugin. The code in FSUIPC couldn't really be simpler. The typo just made it use the wrong set of offsets in the Simconnect call -- all parameters would have been zero I think. Pete

Don't ever touch the [LuaFiles] section. that is maintained by FSUIPC. You mean that PMDG got something wrong? Really? I'd re-check that if I were you! ;-) Anyway, wouldn't you be better off asking on the PMDG 737NGX forum? Pete

I was waiting for a test result from you to make sure it worked. Since it evidently didn't, I've just re-checked -- and I had made a silly typo in the code. Apologies. It was a little rushed on the day before I went off to Romania I think. Please try version 4.939t FSUIPC4939t.zip Pete

You can't have both. The original was "Frictions" which applies the friction changes all the time on the ground. I didn't write the dynamic one but I think it replaces the original braking frictions above a certain speed. I don't know though -- have a look inside it and see. There will be comments I expect. Lua files are only ordinary text files. Maybe you should have read about them before trying to use them? You seem to think you need them. I thought they weren't wanted on the PMDG aircraft as they had set things correctly in any case. Pete

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