Paused when in menus?

[StuartWhelan]

Hello Pete,

Is there anyway to tell when the simulation has been paused for menu access?

I know the pause state does not change, and all the obvious counters I can think of continue to count.

I guess I could watch the seconds value, but its not really granular enough for me.

I could watch the fuel consumption, but only when the engines are running...

Any ideas would be most welcome!

[Pete Dowson]

Is there anyway to tell when the simulation has been paused for menu access?

Did you not read the Notes for the most recent FSUIPC Release (3.202), viz:

"A flag is provided in the byte at offset 3365 which indicates when FS is effectively frozen because of menu access or modal dialogue action. Full details can be provided to those who need to use this before the next SDK update."

Regards,

Pete

[StuartWhelan]

Did you not read the Notes for the most recent FSUIPC Release (3.202), viz:

Guilty as charged. :)

I read through the SDK very carefully, but not the FSUIPC release notes.

I shall do so now. :oops:

Can I request full details here? :)

Many thanks!

[Pete Dowson]

I read through the SDK very carefully, but not the FSUIPC release notes.

Ah, sorry. The facility was only added in 3.202 and the SDK isn't updated yet.

Here's the proposed entry for offset 3365:

3365

1

"In Menu or Dialog" flag. This byte is non-zero when FS is effectively

paused because the user accessed the Menu, or is in a dialogue resulting

from menu or other selection activity.

The non-zero values are:

1 = FS frozen because of menu activity

2 = FS frozen because of modal dialogue

Both bits may be set in dialogues accessed through the menu. Note that the

2 bit may flicker a little on exit from the dialogue, due to the way it is detected.

In FS2004 the byte at 3364 should also be considered when using this

flag-there are some conditions, like reloading scenery or aircraft or

flights, which effectively freeze the sim in ways not detectable except by

the method used for the "ready to fly" indicator.

Ok

Ok

Regards,

Pete

[StuartWhelan]

Hi Pete,

Sorry to bring this one up again, I have been looking at using this value today.

What I have noticed is this, my tests were done using FS8 and FSUIPC 2.02 on Windows XP:

When in a menu or dialog, the value is always 3.

When you are not in a menu or dialog, and FS is running normal, AND it is the active application, it is 0.

If you move focus to another application, the number changes. Sometimes it is 0, sometimes is a 2, ocassionally it is 3... But FS is still running and the plane is still moving.. Eventually it seems to settle at 2.

Does this make any sense?

[DocNZ]

Hi.

Sometime back I asked Pete about this, and he came up with the above solution at offset 3365. While I was working with windows message techniques myself, Pete being the brilliant programmer he is, came to solution alot quicker than I.

While I was working out my own technique I discovered this little trick, which will determine if FS is pause on menu select, or modal dialog. I use this technique now personally.

Its ugly, to fast, but works..

Gobal variables A,B.

Set A=0 on application initiation

within a timer (500ms)

//======================================

if FSUIPC_Read($0314,4,@FTimer,dwResult) then

begin

if FSUIPC_Process(dwResult) then

begin

B:=FTimer;

if (A=B) then

begin

//FS Paused

end else

begin

//FS Not Paused

A=B;

end;

end

else DoCantConnect(dwResult);

end;

//================================

I discovered that the value at 0314 stops on menu or modal pause.

[Pete Dowson]

When in a menu or dialog, the value is always 3.

If the dialogue is entered via a Menu, yes, because the 1 bit is set only by the MENUSELECT message from Windows.

If you move focus to another application, the number changes. Sometimes it is 0, sometimes is a 2, ocassionally it is 3... But FS is still running and the plane is still moving.. Eventually it seems to settle at 2.

Does this make any sense?

No, none at all. Though I must admit I don't know exactly what causes the "ENTERIDLE" message -- it is this which sets the 2 bit. I don't see how the value could ever be 3 in that circumstance, because that would definitely mean that FS receieved a MENUSELECT message. Maybe you are using the ALT key to swap processes? That may give a temporary 1 bit because ALT is the MENU key.

The bits are cleared whenever FS sends FSUIPC a "frame rate" call. The only time I know, when FS doesn't have the focus, that no frame rate calls are sent, is when FS is minimized. In older versions of FSUIPC it would effectively stop doing anything when FS is minimised -- the returns you got would be the values frozen at the time it was minimized. Mostly that is still true, I just keep enough going to prevent WideClient's timing out.

If you are minimising FS then I wouldn't be surprised if the value goes to 2. If you do it with the ALT key it may even get stuck with the 1 bit too. I've not really got any solution to that at present -- others seem to regard a minimised FS as a pretty well stopped one in any case, though it does carry on at a very low frame rate I think.

If anyone has a better idea of how to decide on these signals, I'd be glad to consider it.

Regards,

Pete

[StuartWhelan]

Hi Pete,

I have done some more checking on this...

I was unable to re-create the 'stuck on 3' behavour, so lets write that off as user error..

Reading 0x3365 will reliably set bits 1 & 2 when in any menu, model or dialog, which is good.

In Fs2002, with pause on task switch turned off, Bit 2 will sometimes stick when task switching, and may or may not get reset back to 0 at some point later on. It always resets back to 0 when FS2002 gets focus again. I did not see this behavour with FS2004.

The 8 byte timer at 0x0310 as described above by DocNZ (Thanks for the reply Doc!) pauses perfectly for all menu and modal dialogs, EXCEPT for the FSUIPC configuration screen, in which it continues running.

Hope this helps,

Stuart.

[Pete Dowson]

In Fs2002, with pause on task switch turned off, Bit 2 will sometimes stick when task switching, and may or may not get reset back to 0 at some point later on. It always resets back to 0 when FS2002 gets focus again. I did not see this behavour with FS2004.

I'll check that, but it sounds very off, as I clear the byte altogether when getting "frame rate" calls from FS. This would imply I get none in FS2002 when it has no focus -- which would effectively stop some of FSUIPC's variable updating in any case. Ugh.

The 8 byte timer at 0x0310 as described above by DocNZ (Thanks for the reply Doc!) pauses perfectly for all menu and modal dialogs, EXCEPT for the FSUIPC configuration screen, in which it continues running.

Hmmm. Strange.

Regards,

Pete