Bryn

Thanks again Pete. I've tested it throughout the day today, and there haven't been any instances of focus stealing. Cheers - I really appreciate your time. Bryn.

Thanks Pete. After a couple of minutes of testing, it appears the simpler text display doesn't cause the behaviour. It's not as pretty, but it does the job, so I'm very happy. I'll put it through a full flight test tomorrow, and confirm the result tomorrow night. Thanks very much. Bryn.

The first post in the thread explains the original problem I was having. This is not a long thread, and the other two posts are basically shoulder shrugs. A difference from the first post that I should have mentioned is that I have updated to version 4.3. I should also have added that I am now using FSUIPC 5.141e. Ctrl F10 is the key sequence I created in FSUIPC to trigger the lua action (though any key sequence would do). The lua file is the standard log lvars.lua, but could be any lua file. When the simconnect window opens, the behaviour begins for about 3 seconds, and then when the simconnect window closes, it begins again for about 3 seconds. When FSUIPC runs these lua files, I get the behaviour I have described, and which I show in the YouTube link. The problem is that P3D steals focus erratically whenever I trigger a lua script that calls ipc.display(). It doesn't steal focus once, it steals focus repeatedly for about 2 to 3 seconds. If I try to focus on any other window during those 2 to 3 seconds, P3D steals the focus again. It's as if a focus call is being repeated for those three seconds. Bryn.

Hi, I'm still getting this problem with lua and ipc.display(). I was hoping FSUIPC would just 'grow out of it' on my computer, but it persists. I can't see anything in the log that would explain why this is happening. Here I've posted a video of what happens when I load the log lvars.lua using Ctrl_F10. When the lua script ends and the simconnect window closes, the same behaviour repeats. I am in fullscreen, so I've pressed the left windows key to bring up the taskbar to show what is happening there after I load the script. If another window is in focus when the script is loaded, the prepar3d window steals the focus. video of the effect (YouTube)

Thanks - I feared you would say that. I'll search on. It turns out not to be ipc.display that causes the problem, but it seems any lua file triggered causes the behaviour.

Hi, I'm using FSUIPC 5.131a on Prepar3d v4.2. Lately, I've noticed that whenever I execute ipc.display() from a lua file, the window title on the taskbar flashes (very fast and repetitively, like it would if I created an ahk file with a loop of 'activate window' commands), trying to draw the window focus back to P3D. This doesn't seem to happen if I send the message through 0x3380. Here is a simple lua I'm triggering at the moment (via 0x0D70 normally, but I've also tested it through the key assignments tab of FSUIPC): ipc.display("OEMA 211700Z 31013KT 9999 SCT045 SCT100 42/M06 Q1010 NOSIG\n\nSTAND: GATE 132\n| DEP:0 ARR:0 | ") ipc.sleep(30000) This is a minor nuisance, as it will draw the focus back to P3D when I might be trying to type in the vPilot window, or checking a chart. Is it a bug, or just me? Cheers, Bryn.

I've been having a similar problem with 5.123c - I can't access the FSUIPC menu.

Pete, Thank you for such a detailed response. Using the event system was new to me. I tried it, and it worked well, eliminating the stutter. The empty file was causing a stutter on subsequent loads, and caching is on. I had tried setting my LuaAffinityMask away from processor 0 (which consistently runs at 100% when P3D is running). Perhaps it was a windows defender or virus protection issue. But not to worry - the event system worked; I learnt something new; and I have ideas about different implementations for other things I have as well now! :) Thanks very much, Bryn.

Hi. Whenever I trigger a lua file, I get a small pause in the sim - maybe about half a second. This happens even if the lua file is precompiled. I am using: UpdatedByVersion=5121b FSVersionUsed="Lockheed Martin® Prepar3D® v4",4.1.7.22841 SimConnectUsed=4.1.0.0 The size of the lua file doesn't matter. Even an empty file will give a short stutter. My FSUIPC5.ini is attached. Grateful for any thoughts or suggestions. Cheers, Bryn. FSUIPC5.ini

Yes, indeed 32FA... my adamant insistence was misplaced!

Thanks Pete. Sorry, I mean't fsuipc.ini. My version is 4.959. Adding a zero to the end of my string seems to have fixed the problem. The program is not writing [Window] entries every time I write to 3380/32FA now. It still writes a [Window] entry on the first write to 3380, though. (3380, not 6D60). Bryn.

Hi, I decided it would be neat to rename the message window for each flight, so I set 0x6D60 once at the start of the flight to be something corny like "ATTN: EIN203 EI-CVB" and then send messages the standard way through 0x3380. However, now whenever a message is sent, a line is added to my fsuipc.cfg each time the message is sent to 0x3380. [Window.ATTN: EIN203 EI-CVB] !1=] Docked=0, 0, 0, 0 [Window.ATTN: EIN203 EI-CVB] !2=] Docked=0, 0, 0, 0 [Window.ATTN: EIN203 EI-CVB] !3=] Docked=0, 0, 0, 0 [Window.ATTN: EIN203 EI-CVB] !4=] Docked=0, 0, 0, 0 etc... etc... etc... Is this a feature, or something I'm setting incorrectly somewhere? My fsuipc.cfg consequently gets quite large after a few flights, because I send stacks of msgs to the window. Thanks very much, Bryn.

Hi, I have a small lua file that I assign to my hat switch, so that it sets the zoom based on the view I'm using: z = ipc.readUB("8320") if z == 1 then ipc.control(65701, 33) end It fires continuously whenever the hatswitch is being used. This all worked fine in Windows 7. However, in Windows 10, this is causing 3-4 second long pauses whenever I trigger it while using Level-D 767, Eaglesoft Citation and the Digital Aviation Fokker. Other aircraft are ok so far (PMDG, Wilco, Feelthere). Any thoughts?

Thanks Pete. As usual, it's all my own fault. For some reason (which doesn't look to have been terribly sensible), I had these lines in the fsuipc.ini: LogLua=No DebugLua=Yes Removing them stopped the logging. Cheers, Bryn.

Perhaps this is also a bit revealing. All the bits in LogOptions are zero, except the last one, which turns logging on (I think I'm reading that right). 15195730 LogOptions changed, now 00000000 00000001 15196370 LUA.0: c:\fsx\Modules\DynamicFriction.lua:52 15196370 LUA.0: c:\fsx\Modules\DynamicFriction.lua:53 15196370 LUA.0: Global: GS_ipc = 19388886 If that's the case, why is LUA getting logged? Bryn.

Thanks for your thoughts - I bet that was a painful debugging session to work that out! Alas, so far as I can see, Offset 3400 is not being used in my setup. I did notice one more odd thing, though. If I tick the box for debug/trace lua plugins in the FSUIPC UI, and then click 'stop' it doesn't untick the box. That is different behaviour to all of the other logging options. Bryn.

Hi, Despite turning off lua logging and not having anything in my fsuipc that would enable it, my FSUIPC keeps on logging LUA events over and over. The consequence is that I have a file that keeps growing in size through the flight to a rather large size. Here's an example of what it keeps logging: 5823362 LUA.0: c:\fsx\Modules\DynamicFriction.lua:61 5823362 LUA.0: c:\fsx\Modules\DynamicFriction.lua:91 5824376 LUA.0: c:\fsx\Modules\DynamicFriction.lua:52 5824376 LUA.0: c:\fsx\Modules\DynamicFriction.lua:53 etc, etc Is there something I've missed that would turn all that off? Bryn.

Woops, a is the flightplan, and fn the flight number.

FSUIPC_Write(0x3130, 12, fn, &dwResult); FSUIPC_Write(0x0130, 256, a, &dwResult); FSUIPC_Process(&dwResult); where fn is a pointer to the flightplan, and a is a pointer to the flight number.

Hi, The documentation says that 0x3130 doesn't work for writing in FSX. However, I just stumbled on having this work for writing when I also wrote a new flightplan to the sim via 0130. Anyway, that's that, for verification. Cheers, Bryn.

Thanks for the response. It is FS9 and FSUIPC3. I understand the position on FSUIPC3 (though I reckon FS9 is a far more reliable and enjoyable platform than FSX). A question then: When I set the minimum altitude to zero, the form says that it graduates from the top of the layer. Am I right that that is the top of the global layer, or does it take a local layer? With that answer, I should be able to manipulate the NWI for my purposes. Painful as that is. Cheers, Bryn.

G'day, Curious about whether there is an offset for the graduated visibility altitude options. I haven't been able to find one in the manuals. If there isn't one, could one be added? It would be handy for me to make the graduated visibility a bit more precise around the cloud layers, without having to get into the messiness of NWI writes (that's with me presuming the minimum altitude in the graduated visibility options is the GLOB visibility maxAlt?). Anyway, heaps easier (for me, at least) if they were available is a simple writeable offset. Cheers, Bryn. PS. Also still wishing for some more writeable AI controls for FS9, like runway selection, and active runways. ;-)

Hi, I'd like to play a wav on a lua event (say a keypress or, indeed, any other possible lua event), but I can't find a library function to do that. Is this something that can be included in the FSUIPC Lua implementation? Cheers, Bryn.

Pete, thanks for getting back to me. My alternative is to try and learn how to do this myself. I've been looking at memory addressing and dll structures and so forth, but (as with many things), the challenge is interpreting general principles for a specific problem. Could you describe the methodology you would use if you were tackling the 1st 'wish' - AI runway allocation. That would be a tremendous help to me (and, I suspect, other programmers like me). Cheers, Bryn.

I have two huge wishes for FSUIPC in 2010. 1. Hooks into the FS9 AI sub-system to control runway selection. I would like FSUIPC to intercept the call to allocate an AI a departure or arrival runway and then send it to me so that I can change it to whatever runway I decide before it is adopted by the AI aircraft. I could then create a program that distributes traffic across any or all runways at an airport. If this feature were implemented in FSUIPC, my plan would be to write a program that checks a simple text file for runway allocation rules for any airport an end-user wants to affect and then allocate AI when they internally choose their runway. AFCADs with the star method can open up crossing runways, and different length runways can affect the size of aircraft allocated to takeoff, but that's it. Only a pure intercept of the function to allocate the AI a runway can distribute traffic according to whatever criteria a user might want to set. (for example, spreading some arrivals to inner runways (eg, ZBBB, KATL, KLAX, LFPG), or sending arrivals to the furthest runway from the direction the aircraft are arriving from, or sending departures to distant runways (eg, EHAM, YSSY)) Thinking about the possibilities this would open up for the simulator keeps me awake at night! 2. Writeable offset for the callsign of a user aircraft. I would like to be able to change the callsign of my aircraft without entering the Aircraft menu because entering the aircraft menu and changing the callsign resets the panel of the aircraft. If I am doing a simulated multi-stage flight (like regional airline hops), I would love to be able to change my callsign while leaving the aircraft untouched. Cheers, Bryn.