Disabling simrate change

[Raymond van Laake]

Hi Pete,

One of the things my program must always do is check that a pilot doesn't change simrate from 1 to something else. Basically my program is a loop, and during each loop I check it.

One pilot managed to assign "change simrate" to a knob on his flightstick and set simrate to 2 and then back to 1 for such a short time that it went unnoticed by my program. Bugger.

Question: would it be possible to have FSUIPC handle this? I imagine that FSUIPC can't prevent it, but as soon as it detects simrate<>1 reset it back to 1, and set a bit (or increment a counter) so my program can see that a simrate change had occured.

I realize that another option for me would be to lookup if a key or button is assigned to "simrate change" and disable it (changing simrate on the panel with the mouse and then back again can't be done so fast that my program won't detect it); still a solution asked above would make life easier.... yes I'm lazy :lol:

Raymond van Laake

[Pete Dowson]

One pilot managed to assign "change simrate" to a knob on his flightstick and set simrate to 2 and then back to 1 for such a short time that it went unnoticed by my program. Bugger.

But if it is for such a short time, would it matter?

Question: would it be possible to have FSUIPC handle this?

If it is on a joystick input, or asigned through FSUIPC as an FS control, FSUIPC can intercept it, but if it is a keyboard assignment in FS, I don't see it. I could do the same as you, watch it and set it back to 1 if it changes, and of course FSUIPC would be faster, but as you should be able to do it within milliseconds anyway I don't really see that it is needed in FSUIPC.

Can you clarify more on the timing? Maybe your loop is fast enough for your other things, but not for checks like this. Maybe you should put all such checks into a faster loop, say every 110 or 220 mSecs (2 or 4 Windows TIMER ticks)? I'd really rather not 'clutter' FSUIPC with such odd things unnecessarily.

Regards,

Pete

[jcboliveira]

It's possible:This is done in a timer callback with 3s.

FSUIPC_Read(0xc1a, 2, &Rate, &DwResult);

FSUIPC_Process(&DwResult);

if (Rate!=256&&NoRate) {

Rate=256;

FSUIPC_Write(0xc1a, 2,&Rate,&DwResult);

if (FSUIPC_Process(&DwResult)!=TRUE)

return;

} else {

if (Rate==256&&OnRate!=1) {

OnRate=1;

FSTime ( &hour,&minute);

message=(char*)calloc (200,1);

lenght=sprintf ((char*)message,"%02d:%02d Simulation Rate 1x\n",hour,minute);

MainWnd->SendMessageDialog(TEXT1, message);

free (message);

}

if (Rate==512&&OnRate!=2) {

OnRate=2;

FSTime ( &hour,&minute);

message=(char*)calloc (200,1);

lenght=sprintf ((char*)message,"%02d:%02d Simulation Rate2x\n",hour,minute);

MainWnd->SendMessageDialog(TEXT1, message);

free (message);

}

if (Rate==4*256&&OnRate!=4) {

OnRate=4;

FSTime ( &hour,&minute);

message=(char*)calloc (200,1);

lenght=sprintf ((char*)message,"%02d:%02d Simulation Rate 4x\n",hour,minute);

MainWnd->SendMessageDialog(TEXT1, message);

free (message);

}

if (Rate==8*256&&OnRate!=8) {

OnRate=8;

FSTime ( &hour,&minute);

message=(char*)calloc (200,1);

lenght=sprintf ((char*)message,"%02d:%02d Simulation Rate 8x\n",hour,minute);

MainWnd->SendMessageDialog(TEXT1, message);

free (message);

}

if (Rate==16*256&&OnRate!=16) {

OnRate=16;

FSTime ( &hour,&minute);

lenght=sprintf ((char*)message,"%02d:%02d Simulation Rate 16x\n",hour,minute);

MainWnd->SendMessageDialog(TEXT1, message);

free (message);

}

[Raymond van Laake]

Hi Pete & others,

To the question if it matters: yes. Not so much for me, but for all the pilots that use my software, which is a race and where an illegally gained second can make the difference between the #1 and #2 position.

Having FSUIPC checking simrate as I described before is certainly not a "must" for me, but I thought if it was pretty easy, why not. If it 'clutters' FSUIPC and/or degrade its performance I would even vote against it.

I came across this problem last year, and am now rewriting my software. When finished I'll do some tests to see how long a loop takes to complete. If necessary I can check the simrate two or three times during a loop. My software doesn't use timers by the way; as I understand they are very processor-time demanding so if only to keep the framerate as best as possible I avoid using them.

One last thing that's a bit alike: slewing is also a problem. It can never be prevented because a program like FSNavigator can always let a pilot slew. I've got some routines checking if a slew has occured, but wouldn't it make life easier if FS itself realizes a slew had taken place and tell me through FSUIPC.... but I doubt that this is possible.

Thanks,

Ray

[Pete Dowson]

Having FSUIPC checking simrate as I described before is certainly not a "must" for me, but I thought if it was pretty easy, why not. If it 'clutters' FSUIPC and/or degrade its performance I would even vote against it.

It's just that if FSUIPC does all these "little" things, it will be huge and slow. I have to resist them, I give in to too many as it is. When something is so easily possible without a fiddle in FSUIPC, then I resist more strongly. This is one such.

If an external autopilot can control FS precisely, split second by split second, it must be very easy to "fix" any change in Sim Rate. If your users are getting away with it for a whple second, or even a significant proportion of one, your timing is too lax.

If necessary I can check the simrate two or three times during a loop.

I don't know what you mean exactly by a loop, but I would certainly implement it all as a TimerProc, entered very frequently (even up to 55 mSecs -- one timer tick), counting entries, and doing different things at different intervals, eg "AND" the count with 3 for something repeated every 220 mSecs, and so on.

My software doesn't use timers by the way; as I understand they are very processor-time demanding

Where did you learn that? There are (or used to be) a limited number of timers, but FS works on timers, quite fundamentally. All you need is one SetTimer specifying a TimerProc, then base all your other actions on multiples of the entries to that Procedure, i.e a count.

Sorry if this is in C terms and you use VB or Delphi, but I'm sure the facilities are the same.

One last thing that's a bit alike: slewing is also a problem. It can never be prevented because a program like FSNavigator can always let a pilot slew.

You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly. Checking for a sudden change of location (not by slew but by direct placement) is another matter. I'm sure you can do that too -- if you check position every 10 mSecs or so and compare positions you should be able to calculate an impossible speed. Just calculate the distance between them and allow a maximum speed. There's no other way.

Regards,

Pete

[Raymond van Laake]

Hi Pete,

I don't know what you mean exactly by a loop

It's pretty simple actually, something like:

blnFlightEnded = False

While Not blnFlightEnded

:

:

If Then

blnFlightEnded = True

End If

Wend

You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly.

Yes, provided slew is done within FS by pressing the (default) Y key

Checking for a sudden change of location (not by slew but by direct placement) is another matter....

What you say is just about exactly what I do. But in FS2004 I noticed, when I even do a absolutely minimal slew FS reloads scenery. In other words, FS detects that sudden change of location. It would be wonderful if FSUIPC would notice that and set a bit when it happened.

Again, I don't mean to clutter FSUIPC with trivial things, it's just a thought.

Thanks,

Ray

[Raymond van Laake]

Little correction...

When I wrote:

What you say is just about exactly what I do. But in FS2004 I noticed, when I even do a absolutely minimal slew FS reloads scenery.

I meant:

What you say is just about exactly what I do. But in FS2004 I noticed, when I even do a absolutely minimal direct placement with FSNavigator, FS reloads scenery.

[Pete Dowson]

It's pretty simple actually, something like:

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I though a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread?

You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly.

Yes, provided slew is done within FS by pressing the (default) Y key

What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset. You seem to be trying to make it difficult for yourself :)

Regards,

Pete

[Pete Dowson]

It's pretty simple actually, something like:

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I thought a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread?

You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly.

Yes, provided slew is done within FS by pressing the (default) Y key

What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset.

Regards,

Pete

[Raymond van Laake]

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)?

Yes I do, with the VB statement DoEvents() which processes Windows messages. This statement is placed in the loop.

What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset.

Indeed that's what I do. "Pressing the Y key" was a bad choice of words. What I meant was that pressing the Y key or using the FS menu sets slew, which you can detect at the appropriate offset and reset it, or what I do terminate the flight. But a direct placement for example with FSNavigator is not detected this way, but must be calculated.