Pete Dowson

No, should be a "use" there. Sorry. i.re. event.key or event.button. Yes. I think it's 127. Of course you don't list them -- that's automatic -- but the internal encoding of assignments has only 7 bits for the refernce to the LuaFiles list. Pete

If they are called individually, by different assignments, as you say, it is probably slightly more efficient to leave it the way it is. In fact, if you are likely to use 2 of the 12 very closely to each other, that would work better in any case, because when one is completed there's a bit of a delay before the thread and its resources get removed. If you re-use the same plug-in before that's done it has to wait to reload. I only allow one instance of each plug-in to run at a time. And, yes, they are recompiled each time, but only to an intermediate language, not to processor machine code -- then that is interpreted. The is a Lua compiler available on the Lua website, and FSUIPC will accept pre-compiled Lua programs the same as source ones -- but really for small programs it's not worth it as you wouldn't notice. Event-driven plug-ins are the most efficient, because they are loaded and compiled once (eg via [Auto] sections in the INI file, and then act on events as they occur. For this you'd be better off with one larger plug-in interpreting what you want done by the parameter, as you suggest. You would then assign via LuaValue instead of the straight run Lua control, and interpret the ipcPARAM value passed to the plug-in. (event.param). Or, if the assignments are fixed to specific keypresses or buttons then you could just the events for those instead of assigning at all. Pete

Oh, I thought I told you that? .... It is because you enabled Extras logging. That adds quite a lot more information to the log, and data such as why a couple of extra optional hardware drivers (other programs of mine) did not load would be useful to someone who needs to use them because of the specific hardware they are using with FS. PFCFSX is my driver for the serial port PFC devices, made by PFC in Sacramento, and the EpicLink one is for EPIC based devices including those made by FlightLink. EPIC is, or was maybe, an interface card system for inputs and outputs, much like you might have a driver for Saitek and GoFlight devices. And you surely don't need to be a programmer to understand words like "could not be found"? And as for not knowing what a "DLL" is: well, FSUIPC is one of those but you appear to be using it. So you don't need to know to use them, obviously! If you don't understand logging, why are you looking at the file? It is mainly produced to help me help folks with problems. What problems exactly do you have with FSUIPC? Why not post about those instead? Pete

As Mario says, the meaning is there in the message, where it says the DLLs which it would load if they were there are not there (that's why they are "not found", as it says), so they won't be loaded! :-) You have "EXTRAS" logging enabled in the Logging tab, so you get extra information logged telling you things you may or may not wish to know -- and in this case, they are not in ant sort of mysterious code form, but in English and surely self-explanatory? Pete

No, just different. It count cycle around once the value reaches capacity. The only thing to see is that is is changing. If it isn't for a while, the connection isn't currently operative (though of course it may reconnect). Pete

Each assignable axis can be revered in the Assignments -- it just means adding a few characters to the assignments line in the FSUIPC4. INI file. Did you not read this in a message just a little earlier than yours: So, please see the Advanced Users guide for FSUIPC, the section "Additional parameters ..." it refers to is now on page 45. Is that why you didn't find it? Just use a sequence like *-1,-16383 The *-1 changes is to 0 to 16383, and the -16383 changes it to -16383 to 0. Pete

Well, it can, as I've done it today both in FSX and P3D. No, I'm using FSX-SE too. I don't have FSX installed any more. Pete

It works fine here with the normal keyboard numpad keys assigned to those ATC_Menu controls. Have you checked that you have Num Lock set the same each time, as when you assigned? For instance, the 1 key is assigned as "Num1" when NumLock is engaged, but as "End" otherwise. If you want it to be independent of Num Lock you'd need to assign both the to same control. Also, can you confirm that it is FSX or FSX-SE you are using? I think some versions of P3D are buggy with those controls and the SELECT_1 tc controls too, though the ATC ones definitely work in P3D3.3.5 Pete

Well the transparent undockable type window doesn't provide for user input, though you could use it for menu selection and so on by checking for key or button responses., like the built-in FS program menu windows used by GSX and so on. If you want the user to be able to type longer text entries you need to use ipc.ask, as I said. The ipc.ask facility window is different. Why not try it? Pete

Take a look at offset 337E. You'd need to check that it changes over a reasonable period. Sometimes FS being totally busy looks the same as a crash or hang. Pete

Do you mean for the User to enter data on the FS screen, from the keyboard? If so you use ipc.ask. Otherwise, do you mean a transparent (and undockable) window on the FS screen, or a separate Window external to FS? Pete

Why are you using Keystrokes? The problem most likely is that the button press is resulting in a keystroke which is beng looked up to find the action assigned to that, all via Wndows messages which queue. Are the keystrokes, rather than the buttons, repeating? You can use the FSUIPC Key/Button logging to check. The PMDG aircraft do have individual controls you can assign, via <custom control> assignment. You get the numbers for them from their SDK .h file, towards the end. I think they would be more reliable than keystrokes. Pete

I don't know, I don't think so. Did you check the Logs for error reports? Pete

Version 4.955d is now available. Pete

Mine says: RunIF7=AM=xC0,KILL,"C:\Program Files (x86)\HiFi\AS16_FSX\AS16.exe" because my AS16 is installed where it wanted to go, and I set different Affinity Masks (AM) for each program I load, to try to stop extra processes interfering with FSX's use of processors. I also am a lttle more ruthless, using "KILL" instead of "CLOSE" so it does always disappear! Pete

Found the reason for this. With this way of changing the weather (i.e. using the old FS98-style weather offsets), FSUIPC deliberately does not send a "NewSet" request if it sees no change from what was last written. This is because it uses the same action for doing the continuous filtering actions, and it cannot simply compare the weather to be written with the actual current weather, to see if it different, because it pretty much always will be -- the SimConnect weather actually set is very rarely 100% what is originally requested, and on top of that it is generally dynamically changing in any case. However, I've added more code to override this check when the reason for trying to "NewSet" is an actual write to any of those offsets This will be in interim update 4.955d, which I shall release in the Download Links subforum some time tomorrow (Tuesday), after more testing. Pete

I'm looking at this now. I've found that if you write a different value to 0F72, not just 15 all the time, then it works. Evidently something in the code thinks it isn't changing so doesn't send the weather request to SimConnect (the lines beginning ">NewSet:" in the Log). I'm not sure why this is. It isn't anything to do with Lua -- you can get exactly the same effect by simply assigning a keypress to "Offset word set" in FSUIPC assignments. The code here is very complex and actually dates back for before FS9 even. (except for the result being sent to SimConnect instead of using a direct call into FS innards). I am looking at it and if I see the reason I'll let you know -- maybe it's intentional for some reason. If not I'll see if I can fix it, but no guarantees at present. Meanwhile, if it is important for you to get that working, just try changing the value you are trying to set. It doesn't need to be a lot different. 1 knot should do it. Pete

Ok. So that's why I still don't understand your question. Pete

So where does assignment in FSUIPC come into it? Pete

Sorry, how do you mean "won't be recognised"? Are the switches operating as standard joystick buttons, for assignment? Is your overhead looking like a lot of joystick buttons? Pete

AS16 should certainly not still show "connected" after FSX is terminated. It is working fine here, and has been for a while (I was lucky enoough to get the final Beta to test). There is no interaction between FSUIPC and ASN itself. FSUIPC does detect if the as_btstrp DLL is running so it can take steps to avoid hooking the same places in FSX's Weather.DLL for Wind Smoothing (you only get one or the other doing that). That's unchanged for AS16. There is a little more interaction, again through the DLL, if you use the FSUIPC WX radar facilities -- which are again unchanged. There is certainly nothing on the FSUIPC side which could cause all sorts of different crashes in different FSX modules. You will have to talk to HiFi support about this. I expect you will need ot go thjrough some process of elimination. You could also try starting and stopping the AS16 exe using an entry in FSUIPC's Programs section. That works quite well for me, as it did for ASN. Imn fact most external apps seem to operate better in termas of shutting down if they are only started when FSX is running, and closed before it closes. Pete

P.S. I assume you've checked the WideClient and WideServer log files to see if any errors are occurring? If not, best do that first. Pete

By "closing WideFS" do you mean terminating the WideClient application on the Client, or disabling WideFS in the FSUIPC options dialogue? Is Project Magenta running on two Client PCs, or partly on the Client and partly on the Server? I e. do you mean 3 PCs or 2? Normally a slow down over time is due to memory running short forcing Windows to move things more and more onto page tables on disc. If the Networking is doing this it probably means there's something wrong with your Network settings or drivers, or even, possibly, with the Networking hardware. I once had a similar thing happening and it was due to a failing Networking chip or circuitry on the motherboard, and purchasing a separate Network card fixed it. You talk about 50 fps, but what is the FPS for WideClient (shown optionally in its title bar, and also logged when it closes -- in fact logged by WideServer too)? It shouldn't be much more than 30. Really, for best and most consistent performance and smooth operation you should limit FS's own frame rate to around 30. When the frame rate on FS deteriorates, what happens to the frame rate on the Client? Does it stay at 30 or so whilst the FS rate descreases from 50 to 30, or does is decrease proportionately? One thing which can improve performance is choosing UDP instead of TCP protocol. This has less red-tape error checking, and won't do retries in the event of bad packets. If that fixes it completely then you'll know something is wrong with the Network and it is retrying too often, causing a build-up. The only disadvantage with UDP is that it doesn't guarantee delivery, nor does it guarantee that packets arrive in the order sent. If performance and reliability on the Network is good, this shouldn't really matter, but if there is any problem it can make PM's actions go wrong because certain things needed in sequence don't operate in that sequence. That said, I have been using PM on an 8 Client Network with UDP (and Broadcasts enabled for even more efficiency) for years with no problems then -- nor since, after changing over to Prosim737. (Note that the Broadcasting option simply makes the Server send the same data out once, with all Clients getting all the data whether they requested it or not. This is instead of only sending the data requested by each client, individually. So it wouldn't be of any advantage on a single client setup). Pete

I need more information really. For example, what's the difference betrween what you expect and what you get? Have you tried using any of the Logging to see what is happening? It would also help if you pasted your Lua script into your message, as I've no idea what it looks like. By invoking it each time you are loading and recompiling the source for each press and release. Not that this takes as long as your press, but still. It is inefficient. And FSUIPC will impose a delay before reinvoking the same plugin if the current one is still closing and freeing resources. You could see if that is causing your problem, whatever it is, by making two copies, one each handling the separate event (press or release). BTW a much better and more efficient technique for plug-ins would be to use Events -- have the plug-in loading automatically at the start, then just program your keystrokes to send it parameters, or more simply having it detect the keypresses itself using key events, saving you even the assignments. Pete

By changing your Joystick number to one matching my SideWinder, I can use the hat and see the keypresses being sent. The "PRE_FLIGHT BRIEFING" is displayed okay, and throughout I can change aircraft with no problems, no crashing occurring. This is with both P3D3.3. and FSX-SE. So I think it is some sort of interaction with something else on your setup. There is certainly no reason for such a simple Lua program thread crashing the sim -- far more complex ones that that are running continuously on my cockpoit, and many others (thanks to LINDA, on the whole). If you do want the plug-in to terminate and restart of changing aircraft the best way is to have it loaded in a Profile dependent manner. If you wish it to just terminate you can use the ipc.exit function, making it dependent on a change in the Aircraft title offset (3D00), or, to do it on simple aircraft reloads too, the aircraft change count at 32FC. Pete