Is another application accessing FSUIPC at this moment?

[Raymond van Laake]

Hi Pete,

Situation: In my application I disable a gauge, for example speed. Now the pilot must estimate his speed, at a point where there is a speed limit. The challenge is to fly as fast as possible without getting penalized for going faster than the speedlimit.

Problem: the pilot writes his own application that reads and displays the ac's speed, and runs it next to mine.

The only solution to this, I think, is to be able to check if any other program is accessing FSUIPC. Is this possible?

Thanks,

Ray

[Pete Dowson]

The only solution to this, I think, is to be able to check if any other program is accessing FSUIPC. Is this possible?

Not really. As far as FSUIPC is concerned each access is a unique event. It can, for the purposes of accreditation checking, investigate each and every access, but it only does this by the process ID after the first access otherwise it would slow things down too much.

Between accesses nothing is known about any program. The communication is all from the application to FSUIPC. So most of the time FS is running there are effectively no FSUIPC users (else only FSUIPC would be running and FS would stop, if you see what I mean).

In any case there are several other programs which can and do access data such as airspeed without using FSUIPC. As well as FSConnect there is the GoFlight stuff for instance.

Anyway, when you actually fail the ASI, doesn't the airspeed read from FSUIPC also fail? I'm sure, for instance, that when the pitot heat if off and the pitot tube freezes up programs like Project Magenta also show zero airspeed, and PM definitely reads it through FSUIPC.

Of course, there's also Ground Speed which effectively by-passes the ASI and can be read in things like PM (thanks really to the INS available in airliners) and of course FS's own GPS gauges, and then there are the cruder estimates of speed available through DME read-outs if you are travelling to or from a VOR/DME.

Regards,

Pete

[Raymond van Laake]

Thanks for your reply Pete, unfortunately there's no easy answer here I realize.

It can, for the purposes of accreditation checking, investigate each and every access, but it only does this by the process ID after the first access otherwise it would slow things down too much.

Brainstorming.... if I read this right, it would be possible for fsuipc to increment a counter each time a "first access" occurs, which wouldn't slow down things. I'm sure I could use this info to some extent, by allowing my program to continue only if it is the only fsuipc-accessing program running. Or if there is one other program accessing fsuipc, check if for example that is WideFS which would be allowed as well.

Well, it's no showstopper for me if you wouldn't, but if you would consider introducing this "access counter" I'd use it.

Thanks,

Ray

[Pete Dowson]

Brainstorming.... if I read this right, it would be possible for fsuipc to increment a counter each time a "first access" occurs, which wouldn't slow down things. I'm sure I could use this info to some extent, by allowing my program to continue only if it is the only fsuipc-accessing program running.

But what if it is your program, restarted for some reason? Each fresh process ID looks like a fresh program. Also, I only keep memories of so many then they look fresh again.

And as I said, there are other ways of getting the speed -- FS's own GPS for one, Goflight displays another, programs using the other IPC type interfaces, etc etc.

Or if there is one other program accessing fsuipc, check if for example that is WideFS which would be allowed as well.

WideFs doesn't look like a program to FSUIPC, it is an extension to itself. But if WideFS is running there will be Clients, and any client can read information and FSUIPC has no knowledge at all about Wideclient applications.

Well, it's no showstopper for me if you wouldn't, but if you would consider introducing this "access counter" I'd use it.

Do you really think there's any point? If I implemented something like that it would only ever increment, never decrement -- I don't know when a program has finished accessing FSUIPC. How would you interpret it?

Pete

[Raymond van Laake]

But what if it is your program, restarted for some reason? Each fresh process ID looks like a fresh program. Also, I only keep memories of so many then they look fresh again.

In my particular case a restart wouldn't be a problem: my program requires FS to be NOT running, and starts FS automatically (with a parameter which flight to start with). So, if for any reason my program quits and needs restarting FS needs restarting too.

And as I said, there are other ways of getting the speed -- FS's own GPS for one, Goflight displays another, programs using the other IPC type interfaces, etc etc.

Indeed, it is not full-proof. By the way, "speed" was just an example, I can imagine other "challenges" for the pilots.

WideFs doesn't look like a program to FSUIPC, it is an extension to itself.

Yes, but with VB you can get a list of programs that are currently running, so I assume it's possible to detect WideFS, GoFlight etc. Not sure though because I don't know/have these programs.

Do you really think there's any point? If I implemented something like that it would only ever increment, never decrement -- I don't know when a program has finished accessing FSUIPC. How would you interpret it?

My first idea was along these lines. My program starts FS, once it has loaded the counter will be 1 (= my program). As long as this counter stays at 1, I can be sure no other "fsuipc-application" is helping the pilot.

If the counter changes to 2, then another "fsuipc-application" is running. Assuming I can detect WideFS is running as well, or any other program that is regarded by my program as "legal", the pilot can continue. If none of such "legal" programs is running, then I would check how well the pilot is doing.... if he does a fantastic job (for example for a long time stay at 249kts when the max speed is 250kts) I can assume he is getting help from another program.

I'm not sure if this idea is feasible, but it would be certainly something I would dive into if the counter was implemented into fsuipc. Again, no big deal for me if you wouldn't implement.

Thanks,

raymond

[Pete Dowson]

Yes, but with VB you can get a list of programs that are currently running, so I assume it's possible to detect WideFS, GoFlight etc. Not sure though because I don't know/have these programs.

They are not separate programs, but modules inside FS just like FSUIPC.

My first idea was along these lines. My program starts FS, once it has loaded the counter will be 1 (= my program). As long as this counter stays at 1, I can be sure no other "fsuipc-application" is helping the pilot.

I can certainly do that. But I cannot count programs using WideFS and running in a separate PC.

Assuming I can detect WideFS is running as well, or any other program that is regarded by my program as "legal", the pilot can continue.

WideFS won't be counted as a program as it isn't, it's an extension to FSUIPC as I said. And what if your "cheat" is running his helpful applications on client PCs? For install, all my instrumentation is running on PCs other than the FS PC. I don't even use an FS panel at all.

I'm not sure if this idea is feasible, but it would be certainly something I would dive into if the counter was implemented into fsuipc. Again, no big deal for me if you wouldn't implement.

It really isn't a problem, and I can add it in the next release (certainly this side of Christmas) but I really don't see how it would help a lot.

Maybe you should refuse to let him use WideFS too? You'd be able to detect it in any case through FSUIPC offsets, you don't need to list all the modules in FS -- bit 2^1 at offset 333C indicates whether any clients are connected. You don't have to force him to uninstall WideFS, just assume he's cheating if there are clients connected.

What about add-ins like Gauges and DLLs (GoFlight is but one -- there's my own EPICINFO and several others designed to get data already). These can of course interface to FSUIPC, and some do, but they can equally and more usually get their data direct from FS?

Regards,

Pete

[Raymond van Laake]

Hi Pete,

Thanks again for the prompt reply. Obviously there's a lot more to it than I initially thought... bummer.

I think with a lot of work the "counter" could help prevent some cheating from happening, with still a lot of holes that pilots who happen to have a certain program, or certain knowledge can use to cheat anyhow... meaning that not the best pilot but the best cheater would get the best ranking. Meaning: I must change or skip this "challenge".

Thanks for joining this brainstorming session, it was interesting!

By the way, it may seem that I see in every pilot a potential cheater. From experience with my races I know that 99.9% of the pilots rather loose honestly than win dishonestly. But that one in thousand persons who does want to win with cheating can spoil the race for the other 999 pilots, that's why I'm so determined to close every security hole possible, or if not possible skip/change challenges as we discussed in this thread.

Thanks again,

Raymond

[Pete Dowson]

I think with a lot of work the "counter" could help prevent some cheating from happening

I'll add it in the next Release. You've already got the ability to see if there are any WideClients connected, if you want to exclude those (or at least flag a 'warning' in your results). I suppose the same could go for add-in modules and gauges -- you can list those that are running and look for suspects. :)

Pete

[Raymond van Laake]

OK, thanx in advance.... I'll let you know what use I put to it!

I have another bright idea.... I'll let you know who was caught cheating so you can inhibit them from using fsuipc ever again :twisted: :twisted: :twisted:

Raymond