Raymond van Laake

Hi Pete & visitors to this forum, Happy 100th birthday to all of us! And now we're at it: MERRY CHRISTMAS & HAPPY NEW YEAR!

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

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

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. Indeed, it is not full-proof. By the way, "speed" was just an example, I can imagine other "challenges" for the pilots. 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. 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

Thanks for your reply Pete, unfortunately there's no easy answer here I realize. 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

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

It works very fine, thanks a lot! About the bumping... that seems to be a problem yes. I remember having the same thing years ago when I used Fs98Class.Dll (which was an interface between VB and Fsuipc) and used the same way of solving the problem you have: let the pilot start a flight, and then initiate the program. Thanks again, Ray

Thanks mate, I'll try it out asap, and let you know about the bouncing Ray

Hi VB programmer, I can't seem to set my aircraft to a certain lat/lon.... Example: when I read the aircraft's position, I get: LAT=41.5096398176553, LON=9.10810299276619 Then I reposition the aircraft. Then when I try to set it back with my VB program to the coordinates above, I land on the northpole.... no fun there! Does anyone have a routine to share to help me out? I use this: Public Function Lat_SET(AcLat As Double) As Boolean Lat_SET = CURRENCY_SET(&H560, AcLat / 90# * (10001750# * 65536# * 65536#) / 10000#) End Function Public Function Lon_SET(AcLon As Double) As Boolean Lon_SET = CURRENCY_SET(&H568, AcLon / 360# * (65536# * 65536# * 65536# * 65536#) / 10000#) End Function Public Function CURRENCY_SET(address As Long, varDouble As Double) As Boolean If FSUIPC_Write(address, 8, VarPtr(varDouble), dwResult) Then CURRENCY_SET = FSUIPC_Process(dwResult) Else CURRENCY_SET = False RWError = ResultText(dwResult) End Function Thanks! Ray

Just a thought.... somewhere in the fsuipc sdk there's a VB example how to get the LAT of an aircraft with one 64 bit variable: currency. Maybe that can be used for this as well Ray

Yes I do, with the VB statement DoEvents() which processes Windows messages. This statement is placed in the loop. 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.

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.

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

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

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

I see what you mean, and can't help but say you're right. I took my part in forfilling your hopes and ordered a full key thru simmarket just now. Thanks for all, you've been a great help in the past and I'm sure you'll continue to be that in the future! Raymond

I feel like a stupid fart.... but it's working now, thanks Pete!! I do have one more question: it works ok if I compile my stuff and then run it. But I can't run my program from VB6 in uncompiled mode, because then understandably I get this error: 112078 Client Application: "vb6" (Id=536) 112078 F:\Program Files\Microsoft Visual Studio\VB98\vb6.exe 112078 Product="Visual Basic" 112078 Company="Microsoft Corporation" 112234 Illegal read attempt: offset 320C, size 4 112234Program not accredited for use with this unregistered FSUIPC Do you also have a VB6 developers accesss key? Raymond

Still no luck.... Pete can it be that the access key ain't right? 1) I disabled all registration stuff in my code and checked that the program works correctly with FSUIPC 2.97 2) I put FSUIPC.DLL 3.1.1.0 back, rebooted, loaded FS2002, hit Modules | FSUIPC | "register an application program". I entered "BOTA" (without the double quotes) & the access key, pressed OK, got the message to restart the calling app, pressed Confirm. 3) Started BOTA.EXE and problem remains; see log: 100000 Client Application: "BOTA" (Id=864) 100000 F:\BOTA\BOTA2004\DataProg\BOTA.exe 100000 Product="BOTA" 100000 Company="Battle of the Airlines Trophy" 100125 Illegal read attempt: offset 320C, size 4 100125Program not accredited for use with this unregistered FSUIPC So even if I enter the 12 digit accesscode manually BOTA won't run... I copy & pasted the key from your email, so there's no typing error. Or should I download a special version of FSUIPC.DLL? I got version 3.1.1.0 from http://www.schiratti.com/files/dowson/FSUIPC.ZIP. Thanks, by the way this messageboard is GREAT! Raymond

Hi, FSUIPC: 3.1.1.0 FS: 2002 OS: Win2000 SP3 I just received my program access key, and want to write it to offset 0x8001. This is the VB code (in which ABCDEFGHIJKL is my key) : text = "ABCDEFGHIJKL" & Chr$(0) If FSUIPC_WriteS(&H8001, Len(text), text, dwResult) Then If FSUIPC_Process(dwResult) Then If FSUIPC_Write(&H8001, 2, VarPtr(mode), dwResult) Then FSUIPC_Process (dwResult) End If End If End If When running my app, I get an error about not being regsitered. When I look at FSUIPC.LOG I read: 99922 Client Application: "BOTA" (Id=1972) 99922 F:\BOTA\BOTA2004\DataProg\BOTA.exe 99922 Product="BOTA" 99922 Company="Battle of the Airlines Trophy" 100047 Illegal write attempt: offset F8001, size 13 100047Program not accredited for use with this unregistered FSUIPC Looks like I need to register the access key, before I can write it to F8001?? Or is something wrong with my data/key? I haven't entered my access key manually on purpose to simulate how my program would run on a machine of someone else. Thanks, Raymond

Hi Greg, What I do is this: have the flight loaded, and then read the lat/lon of the aircraft. Once that readout matches what it should be I continue. It never gave any problems. Of course you need to know where the aircraft should be after loading the flight for this to work. Ray

Hi boe1iz, What you ask can't be done afaik. I had contact with Pete when he worked on the disable-menu routines, and as I recall he had good reasons to do it the way he has done. I also wanted to disable parts of the menu and his solution was exactly what I needed; if you need more, well maybe Pete can implement it after all.... lets wait until he gets back (today?) Raymond