Pete Dowson

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

Sorry, I can't seem to do anything with your attached file. Couldn't you simply copy and paste the details? The only relevant parts are Module Name, Module Offset and Error Code,. If the Module name quoted is FSUIPC I can look into it with that data. If it is something else then it is unlikely. I'll see if I can adapt the Lua code to run here so I can test on my system. I don't have EZCA but you say it happens in any case without EZCA running? Pete

Sorry, now home and reading this properly: The light assignments I use in Prosim do not include Cabin Lights. I don't think they work for me in the Prosim 738 model. This thread, which does imply that they should or may work, from the model's Prosim Forum is relevant: http://prosim-ar.com/forum/viewtopic.php?f=88&t=9561&p=70945&hilit=cabin#p70945 I've never really been bothered with cabin lights as (a) my cockpit has no such switch. They are controlled, I think, by the non-pilot crew, and (b) I'm rarely looking at the aircraft from outside, and especially not at night, so never really notice this deficiency. Pete

Weird! Glad you managed to nail it. Pete

Sorry, but I've never known an Elite system to work correctly, if at all, with FS except with Elite drivers. I don't even think the protocol switch works to give the later PFC protocols I know and programmed for, but some older version. The only folks I think you can get help from would be PFC or Elite, unless you are a programmer and can use the appropriate monitoring tools to see that signal formats you get and write to decode them appropriately. That's what I'd do as I enjoy it, but I always had the hardware attached in order to be able to do it. I programmed the PFC stuff I had like that (and FlightLink EPIC-based stuff before it). Pete

Program both "press" and "release" for the same controls. That's the most you can do. Each click is either a press or a release. The default poll interval should be sufficient. Any other delay is down to the processing in the gauges, or whatever is processing the controls. Pete

The first part, the [LuaFiles] section, is entirely automatic, and is not relevant. The [Auto] section loads the plug-in for the entire session. Only profile-specific Auto sections will load and kill plug-ins according to the aircraft loaded. Were you expecting your plug-in to close and reopen across each aircraft reload? Windows crashes are recorded in the Windows error logs. That is the information needed. There is no way I can help without that. Go to the START menu in Windows and enter "Event Viewer", then find your crash. The way you are starting the plug-in is universal, it is meant to continue for the entire session. There is something else causing the crash when changing aircraft. I have many plug-ins running for whole sessions. No, the whole plug-in is still running. There is nothing about changing aircraft which would influence it. It is much more likely to do with your view options. But I can't tell anything with no crash data. Pete

Wow! 17 months later? I'm away from my system at present. Please post again on Monday, or later, when I am back. Pete