[ipc.display() forcing focus to P3Dv4.2]

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.

 

[ipc.display() forcing focus to P3Dv4.2]

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.

[ipc.display() forcing focus to P3Dv4.2]

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.

 

[ipc.display() forcing focus to P3Dv4.2]

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)

[ipc.display() forcing focus to P3Dv4.2]

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.

[ipc.display() forcing focus to P3Dv4.2]

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.

[FSUIPC5 not loading]

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

[Lua stutter]

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.

[Lua stutter]

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

[TOPER Tool (Boeing 777) - Updates]

Malwarebytes is blocking s411728.somee.com whenever TOPER is opened. Not a good look.

Is TOPER using a server that malwarebytes considers high risk?

Bryn

[0x6D60 creates [Window] in fsuipc.cfg, and then creates many many lines of this...]

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

[0x6D60 creates [Window] in fsuipc.cfg, and then creates many many lines of this...]

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.

 

 

[0x6D60 creates [Window] in fsuipc.cfg, and then creates many many lines of this...]

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.

[view lua conflicting with some aircraft in Windows 10]

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?

[FSPS: Invert AGL FPS]

Yes, I know about the offsets.  

 

There are two offsets that I could see (we have different understandings of the word 'many' if that is so!)

 

0x78E3 is a toggle, 0x78E7 allows you to choose the setting.  

 

What I think would be really helpful and handy would be two more offsets:

 

- a toggle to switch to unlimited fps (as Accelerator does when it can't get to the desired framerate).  This would be a neat value-add, because there is no FSUIPC offset or simConnect switch to do this (so far as I can see).

 

- an offset that allows users to set the framerate for the chosen setting (so I could change the target frame rate for the lower setting programmatically).  A byte should suffice here, too, I would've thought.

 

Bryn.

[FSPS: Invert AGL FPS]

Or even better (in my case), a toggle to switch to unlimited frame rate (ie, your max fps mode).  

[FSPS: Invert AGL FPS]

Thanks.  What I ended up doing was automating it through FSUIPC.

 

Would it be possible to actually also write the lower and middle targets to an FSUIPC offset rather than just toggling between middle and lower?

 

Bryn/.

[FSPS: Invert AGL FPS]

Hi,

I use tileproxy at high altitude on flights, and am prepared to tolerate lower fps to make the tiles load more quickly.  My preference is therefore to have faster fps closer to the ground when tileproxy is off and slower fps at higher altitude.  This seems to be the inverse of the AGL setup in FSPS (i.e, there it only allows the middle profile at higher altitude).

 

Is there any way for me to do this manually?

 

Alternatively, can you provide some more flexibility in the AG: Altitude Cycle Profiles?

 

Bryn

[Can't stop lua logging]

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.

[Can't stop lua logging]

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.

[Can't stop lua logging]

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.

[Can't stop lua logging]

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.

[3130 (flight number) works for writing if also writing to 0130 (flight plan)]

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

[3130 (flight number) works for writing if also writing to 0130 (flight plan)]

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.

[3130 (flight number) works for writing if also writing to 0130 (flight plan)]

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.