Pete Dowson

When I change aircraft, it does re-load the lua like it states but the aircraft goes into a spinning dive if it's already in flight. Is it possible to include when the user aircraft is reloaded? Er ... you are not only quoting that line out of context, it isn't even a sentence, so actually states nothing at all on its own. Please read the whole part. The bit you quote actually starts with By some editing in the INI file, you can arrange for one or more Macros or ... and after that it explains what editing you have to do. So ... have you done it? Have you checked it? Please don't waste both of out time by quoting little parts of the manual which are meaningless out of context. If you have a problem making the [Auto ...] system work for an aircraft, show me what you've done in the INI file. And nothing in FSUIPC itself is going to make an aircraft go into a spinning dive. I think you need to explain why you thing it is anything to do with FSUIPC or a Lua plug-in. Pete

No. Pretty much none of the default gauges are suitable because Microsoft did not use their own Gauges SDK to create them. Are you using FSUIPC4 or FSUIPC3? You don't even say which User Guide you are quoting from. But either way, perhaps you should refer to the paragraph just before the one you quoted. Here it is from the FSUIPC3 user guide (but it is similar in the FSUIPC4 one): Furthermore, in order to work they need to be able to hook into Gauge code which must be structured in the predictable way which results from using the Microsoft FS SDK for building gauges in C or C++. This unfortunately excludes most of Microsoft's own default FS aircraft, as they did not use this technique. Furthermore, many new aircraft made by third parties use the more recent technique of having gauges in XML. Those are also not susceptible to "Mouse Macros". (but they are then more likely to be accessible via "L:Vars", which is a separate and more advanced subject). I have highlit the part relevant to your question. If you can't find this then I can only assume you are using a much older unsupported version and therefore ask you to kindly update before requesting support. Earliest supported versions are 3.99 and 4.70. Regards Pete

There are other possible reasons for that, including needed services not running in Windows (cryptographic, mainly), and security settings in the Registry being wrong. Please see the extensive advice in the relevant thread in the FAQ subforum. One usually less likely reason for a signature check failure is either corruption of the DLL itself, or misreads from disk on some accesses. Now with the high reliability of today's hard disks I would normally say that was a very remote possibility, but considering the fact that every time you run the same, unchanging, program (the Installer) you get different results, there's something very very odd going on with your system, and it could either be disk access problems (i.e. errors created on the data transfers), or perhaps much more likely, faulty memory. The Installer log you pasted is incomplete. It should never end after Installed version is later: it is not overwritten. It should simply carry on and log the places it is looking for the Prepar3D.CFG file, so it can check and modify the DLL.XML file. Can you tell me what happened to stop it? Was this running "as administrator"? If not please run it again, but right-clcik on it and select "run as administrator". This shows there is not even an FSUIPC4.KEY file. So you never actually entered in any of the Registration details at all? Apart from that, the FSUIPC4.LOG shows that FSUIPC4 is correctly installed, that the DLL.XML file was updated, and it is working. So there MUST be a proper completed Install log. There is absolutely nothing in the Installer which would cause it to run differently each time it is run. something is changing in the system which is messing it up, somehow. There is nothing complicated nor advanced in the Installer, it uses standard Windows methods to copy files and locate folders. It has worked on thousands of systems without any of the problems you report. I'd like to know what is so wildly different about your system. Are you sure the Windows installation is healthy, to start with? With different results every time you run the Installer I have no way of even starting to diagnose the problems on your system. You need to be able to run it and get a consistent result, whether that be right or wrong, before I can get further. Regards Pete

Vista and Win7 default that setting in Explorer, which is why I include instructions to change the setting in the FSUIPC Installation guide, under the heading ADDENDUM: IDENTIFYING FILES IN WINDOWS EXPLORER They are simply text files. Just paste their contents into a message. Regards Pete

Of course not. Not if (ALTCAP ~= prevALTCAP) then if (ALTSEL ~= prevALTSEL) then but if (ALTCAP ~= prevALTCAP) or (ALTSEL ~= prevALTSEL) then that's what I meant by " if ALTSEL changed or ALTCAP changed then". ALL YOU HAD TO DO WAS FILL IN THE "CHANGED" TEST!!!# And not only have you put the extra lines in but you forgot they were replacing the line if ALTSEL changed or ALTCAP changed then which of course they replace! That line was merely to show you what to do! It isn't Lua! I told you that already! You must now delete it! Also you need another "end" before "prevALTSEL = ALTSEL". I'm very sorry, but I have to discontinue writing code for you. I hoped you'd be learning, but the more I explain the less you seem to know. I realise i am not a good teacher and so I will not try any more. It seems I make things worse not better. May be someone else can help in future. Regards Pete

Well, yes, but you have to fill in the code, not just write the logic out as I did for you!! That's not Lua! Oh dear. That's how to test "changed" in Lua. I thought you were understanding at least a little bit of all this? I really cannot keep writing all this code for you. I have other things to do. What did you think "changed" meant? :-( Pete

Not flashing when ARM but not CAP., like a Bendix-King A/P? No, sorry, I am now even more confused. If you simply want it ON all the time when ARM or CAP is on, and OFF all the time when neither are on, it is MUCH simpler than the logic I showed you. Just treat ARM and CAP together. i.e. -- inside loop if ARM changed or CAP changed then if ARM or CAP then setlight else clearlight end end How many other combinations of two conditions and one light are there? I think you are exhausting them! Pete

To do what? It isn't simulated in FS. Regards Pete

Does it? Why? Sorry, I don't understand the problem, evidently. Yes. And these are indicated by words like that on the screens. What are you wanting the lights to do? And ...? Do you want ARM to flash the light and CAP to make it set on? What is it doing instead? Sorry, I don't understand that. If I'm right in assuming you want it to flash on ARM and be steady on CAP, but off when both are off, all you want is this logic (this isn't real code, just logic): -- outside loop flashtime = 0 flashlit = 0 -- inside loop if ARM changed or CAP changed then if ARM or CAP then if CAP then setlight else if (timenow - flashtime) > 500 then if flashlit ~= 0 then clearlight else setlight end flashlit = 1 - flashlit flashtime = timenow end end else clearlight end end Regards Pete ]

It is in the modules folder, next to the FSUIPC4.DLL you said you put in there. If FSUIPC4 has ever run there will be a Log file, an INI file, and if registered, a KEY file., all named FSUIPC4 ... There will also be an Install log. Well, that's a first! I need for information for that. This has been occurring more often recently, and is, I think, a result of a change in Windows security measures. It's a damned nuisance. But it certainly should not happen if you ereally have installed FSUIPC4 version 4.714 or later in the real Modules folder. The fact that you can't even find the Log suggests that you aren't actually looking in the right folder, so maybe you didn't put the DLL into the right folder? No, it only refuses to replace a later DLL, it carries on doing everything else. I need to see the Logs which are most certainly there! Regards Pete

I can answer specific questions. You will also find lots of examples in the User Contributions subforum -- you might even find the very thing you are looking for. Also check out the package called "Linda" (see first message in this Forum). You should find it much clearer and more straight-forward than the rather arcane parameters used by GFDisplay. You wouldn't use events in any case for simple responses to assigned controls. Events are for things you want to happen on changes in FS, like lighting indicators when an offset changes. If you only want things to happen when you press keys or buttons or turn switches then straight Lua scripts are fine. Yes. In fact they'll each cause several entries -- Lua <name> to just run the script, LuaDebug <name> to run it with a trace log, and others to kill a looping Lua, send it a flag or a parameter. For button actions, if they are doing completely different functions then it is more efficient, yes, because they have to be loaded, compiled and executed each time you press the related button. However, if you have a group of related functions using similar or common Lua code, then the one larger Lua can be called, just with different parameter values supplied for different functions. Look at the examples by Guenseli in the User Contributions subforum for this sort of thing. A Lua using events will run continuously unless it executes an ipc.exit function call. Or you can simply have a never-ending loop -- but in that case always include an ipc.sleep call to stop it hogging resources. (e.g. sleep 50 msecs for a 20 per second update rate). Events are better because they use less resources, You can update displays from FS values by simply having an event which calls a function when a specific offset changes. The new value of the offset is provided to the function, so all it has to do is display it. Very compact too. It would look like this: function updateXXX(offset, val) gfd.setdisplay (.... ) --using val after formatting end event.offset(0x????, "type", "updateXXX") In the one Lua you can have events for different offsets and functions to process each one. The Lua can either be loaded by naming it "ipcReady.lua", whichl oads when FS is ready to fly, or loaded BY the ipcReady.lua by using the ipc.runlua function. For continuously running Luas for specific aircraft they can be loaded automatically by adding them to [Auto....] sections in the FSUIPC INI file. Functions are just a line saying "function <name>(parameters)" and another saying "end", with Lua code in between. To simply update a display that might be only one line, or at most two if you need to do some computation on the value first. Regards Pete

The FSUIPC settings are saved in a file called FSUIPC4.INI, and nothing changes them unless ou go back into the options and change the settings. Maybe ou are getting miced up with so aircraft-specific or profile settings and generic settings. Maybe the INI file is corrupted, or somehow you have it marked "read only"? Please tell me the actual version number of FSUIPC4 -- this information is always needed. If it isn't at least 4.70 you need to update first. If it is already 4.70 or later you might want to try the very latest update from the Download Links subforum. Then show me both your FSUIPC4.LOG file and the FSUIPC4.INI file. You can paste them into a message here. Make sure you close FSX first. Regards Pete

Sorry, I don't understand much of that if any of it. Can you spell it out in separate lines and keep it simple. I don't understand the way you phrase things. If you want flashing LEDs, as when things are being captured but are not yet captured, you will need to keep account of the time (you can get the time in mSecs using an ipc library function) , and alternate the light setting every, say 500 mSecs. (This is where using a time event would be much tidier). BTW I'm out now till tomorrow, or maybe very late this evening. Pete

No no no! I mean you need "prev ... = -1" at the beginning for ALL values, not just a few, and you should check if the values have changed before doing a setLight or ClearLight!! I get the feeling you don't read what I write. No, what good does that do? Why only loop on a few not all of them? Now NONE of those after the loop ever get executed because the loop never ends! You don't make sense, sorry. It is okay, just less efficient. Events on take processing time when things happen. You don't need to use events, I was just saying it is much easier for Offsets because the routines only get called when the offset changes. With LVars you'd need to read them at intervals, either in a loop as you are doing, or more tidily using event.timer. The main mess in your code is simply that you are sending lots of unnecessary SetLights and ClearLights 20 times a second! THAT is what is wrong! Why don't you just write the new parts like the previous ones? I don't understand why you insist on doing it differently! Pete

I think that most toe brakes on pedals are reversed, in that pressing them makes the input values DECREASE, not INCREASE.Therefore, before calibrating in FSUIPC you need to select the "REV" option, to reverse the action. I see from your INI file that you have not done this. I expect that as it stands you can release the brakes by keeping them both fully pressed all the time! Most folks do actually notice the "IN" values decrease rather than increase as they press the brakes when calibrating, and therefore realise they need to reverse them. Did this not happen in your case? Pete

But with the first few tests you only change lights when the values change. In the later ones you change them every time, 20 times per second. I reckon this could mess up the USB driving of the MCP. yes, I know. That's why, for LVars, I suggested using a Timer event. Did you not see? But because you are not checking whether the 0 and 1 has changed, on every loop, that is 20 times per second, you are sending either a SetLight or a ClearLight to each one! You ONLY need to set or clear a light when it needs to change, not 20 times per second!! Sorry, i don't understand this question. It makes no sense to me. Regards Pete

Sorry, can you re-phrase that? Because I simply do not understand it. BTW two points about your code example: 1. You should not be setting or clearing the lights on every loop, only when they need to change. You need to keep a memory of what the previous value was and only change the lights when the values change. I'm sure you've done all that before. That's what "prev ... = -1" and "if prev ... ~= ... then" is all about. 2. In a continuous loop plug-in, as you are using, you should ALWAYS include a sleep, to regulate the frequency of updates. Without that the loop is executing as rapidly as it can on your PC, maybe 500 times per second or more, wasting performance and maybe filling queues up on the USB drivers. Regulate it to some large fraction of a second, like half, by, e.g. "ipc.sleep(500)" before the "end" of the loop Really it is better to use events. With offset reads you can use event.offset to call functions when an offset changes. With L:Var reads you cannot do that, but you can have an event.timer, to call your L:Var checking routine at intervals, like 250 or 500 mSecs, for instance. Regards Pete

All the new installer does is install what will be almost an identical copy of FSUIPC.DLL into your FS modules folder! There won't be anything else helping! There's nothing else I can do! So it does sound as if you have something else wrong. Can you please post the text from the FSUIPC.LOG file which you will find in the FS Modules folder. Close FS first. I'll see if that Log holds any clues. Please note that if you allowed FS to install in the Windows "Program Files" folders, you will likely have problems with all sorts of add-ons unless you run everything "as administrator", because Win7 protects those folders and presents the user with an alias in Explorer, not the real folder. Maybe when you copied the updated DLL you only put it into the aliassed one. Try doing it again, but when you run Explorer do so by right-clicking it and selecting "run as administrator". you might need to do the dame to get the Log file. Many add-ons need to write to FS's own folders and generally they will not be able to when FS is installed in Program Files. This mess comes about because FS9 was written long before Win7 (or Vista for that matter, which presents the same problems). Regards Pete

The offsets lists are in documents provided in the FSUIPC SDK (="software Development Kit"). They aren't installed with FSUIPC because most FSUIPC user's are not programmers and cannot use them easily. The SDK contains all you need in addition to the stuff FSUIPC installs. Regards Pete

That's probably because, like most PMDG aircraft, and PM, and many other sophisticated add-on aircraft, the iFly 737 implements its own A/T, and probably A/P too. This is always a problem with add-on aircraft and add-on hardware. I thought iFly were bringing out an SDK to help cockpit builders interface their hardware to their aircraft? That should tell you how to sort it. Otherwise it's a case of the usual detective work -- maybe mouse macros, maybe L:Vars? Depends what they've done, how it's written. Regards Pete

Sorry, I don't understand. What do you mean by "read" in relation to commands? Commands are sent TO FS, not read FROM it. Maybe you simply mean detect when the autopilot goes off? For that simply monitor the appropriate offset. If your Lua plug-in is event driven, it is easy -- just have an event.offset for the AP master offset, 0x07BC, and see when that changes from non-zero to zero. If you are using a never-ending loop instead of events you'd need to simply read the offset using the ipc.readUD function and check it that way. Pete

I seem to remember I replied to all this elsewhere? Ah yes: Here Pete

There's no different "registered" and "unregistered" versins. The difference is in the facilities unlocked when you register. There's never any need to delete anything first. Really? I think it might say that if you are updating from a reall really old version to a new version you might need to delete the old INI file in case some things have changed, but really all that does is remove entries which no longer apply which would have no effect in any case except act as dross. And in your case, since you previously weren't even registered, it would do nothing because there'd be nothing but default settings in any case. This sounds like another case of recent Windows updates making Windows even more over-protective. In the past any program with "Setup" or "Install" in the name automatically got "elevated admin privileges" which allowed it to update the Registry. I think some recent update has restricted that to only Microsoft's format of installers (the "msi" types). Very mean of them. There are two ways around this, I think. One it to run the Installer by right-clicking on it and selecting "Run as administrator". The other is to replace the FSUIPC.DLL file in your FS Modules folder with the interim update available in the Download Links subforum above. In that I changed some of the checks to get around the problem. I'll be releasing a complete update with revised installer in a few weeks, but it isn't possible at present due to other outstanding developments. Regards Pete

Good. Glad it wasn't a complete re-formatting job! Pete

Yes, the gfd ("GoFlight Devices") library in the Lua plug-in support, which is incorporated into FSUIPC3, 4 and WideClient. (Check for updates in Download Links subforum). In fact I've just added support for the new GF-WP6 unit, but I'm waiting for one to arrive so I can test it properly before publishing the updates for that officially. The Lua plug-in method is more flexible and powerful, and, I think, easier to understand. I don't even understand any more much of what I did in GFdisplay myself! ;-) Regards Pete