Freeware aplication key problem :(

[^COOLER^]

Hi everybody!

I've got free key for some gauge from Pete.

Filename of gauge is: "154_B2_APU_1_3.gau"

KEY = B2AO ZMKV 9W9Y

Now, in flight sim, i choose Register an application program and enter there filename and key. Then i press confirm and ok. But, when i start my gauge i recieve message - Program or module not accredited for use with this unregistered FSUIPC. What i am doing wrong?

Thanks!

Project Tupolev Team - http://tu154.avsim.ru

[^COOLER^]

Can this problem be because of different file verison information?

Look here:

Upper file version is 1.3.0.5 but another - 1.3.5. And product version is 1.3.5.

When i sent information about gauge to Pete, i wrote, that our version is 1.3.5..

[ddawson]

The file version information is not used by FSUIPC - you may change this value to what ever you like. Keep in mind that when you are entering the registration information there are no spaces in the registration key. It would be entered as:

B2AOZMKV9W9Y

Also, as far as I recall, you need to specify the file extension (.gau) when you enter the filename and you should not be using quotes.

Doug Dawson

[Cooler2k]

Yes, i am entering key wihout any spaces.. And full gauge filename..

and still recieving "Program or module not accredited for use with this unregistered FSUIPC. " message.. :(

[Jamie Fox]

Are you using FSUIPC_Open or FSUIPC_Open2? Using the external interface (FSUIPC_Open) from a gauge is a very bad idea, for reasons described in the SDK.

Keys will only work if you use the correct access method: FSUIPC_Open2 for an internal module or gauge. You can use the box in FSUIPC if you wish, and you need to enter the full filename INCLUDING .gau, with your key. However, a better way is to write "B2AOZMKV9W9Y154_B2_APU_1_3.gau" to offset 0x8001 immediately after opening the link to FSUIPC. This saves your users the trouble of entering the key manually.

[Pete Dowson]

Yes, i am entering key wihout any spaces.. And full gauge filename..

and still recieving "Program or module not accredited for use with this unregistered FSUIPC. " message.. :(

If you haven't resolved this yet, please send an FSUIPC.LOG showing the problem, to petedowson@btconnect.com. ZIP it please.

Regards,

Pete

[Pete Dowson]

Filename of gauge is: "154_B2_APU_1_3.gau"

KEY = B2AO ZMKV 9W9Y

Now, in flight sim, i choose Register an application program and enter there filename and key. Then i press confirm and ok. But, when i start my gauge i recieve message - Program or module not accredited for use with this unregistered FSUIPC. What i am doing wrong?

Okay, it is obvious from the log you sent. This part:

167601 Client Application: "fs9" (Id=392)

167601 E:\FS2004\fs9.exe

167601 Product="Microsoft Flight Simulator 2004 - A Century of Flight"

167601 Company="Microsoft Corporation"

176404 Illegal read attempt: offset 0B74, size 4

176404Program or module not accredited for use with this unregistered FSUIPC

indicates that your gauge is using the External program method of interfacing to FSUIPC. This is most inefficient and is not supported for Gauges and internal modules. You need to use the Module User's library and the FSUIPC_Open2() call. Please see inside the SDK, there is a separate ZIP with what you need.

Regards,

Pete

[Andrey Novikov]

Hi, I'm the author of this gauge. It turned out that I've realy used FSUIPC_Open in my code. But when I changed it to FSUIPC_Open2 the code stoped working at all (I've tested it with a "user registration" also).

The part of the code looks as follows (I comment one of two strings by turn):

static char chOurKey[] = "B2AOZMKV9W9Y154_B2_APU_1_3.gau";
...
fsuipc_ok = FSUIPC_Open(SIM_ANY, &dwResult);
//fsuipc_ok = FSUIPC_Open2(SIM_ANY, &dwResult, NULL, 0);
if (fsuipc_ok)
{
     if (FSUIPC_Write(0x8001, 30, chOurKey, &dwResult))
          FSUIPC_Process(&dwResult);
}

But when I use FSUIPC_Open2 it always returns FALSE. So I think that the case is not in the registration key.

Has anyone clue why it's happening?

[Pete Dowson]

Hi, I'm the author of this gauge. It turned out that I've realy used FSUIPC_Open in my code. But when I changed it to FSUIPC_Open2 the code stoped working at all (I've tested it with a "user registration" also).

The part of the code looks as follows (I comment one of two strings by turn):

static char chOurKey[] = "B2AOZMKV9W9Y154_B2_APU_1_3.gau";

...

fsuipc_ok = FSUIPC_Open(SIM_ANY, &dwResult);

//fsuipc_ok = FSUIPC_Open2(SIM_ANY, &dwResult, NULL, 0);

FSUIPC_Open2() needs a memory pointer and the size of the memory, which YOU provide in your program. You are supplying a NULL pointer for the memory and zero size. Nothing can be sent and received in such memory!

Regards,

Pete

[Andrey Novikov]

So I don't understand it at all. What is that memory for? How much memory I have to allocate? Do I need to repudiate FSUIPC_Write and FSUIPC_Read? There is too little on this in documentation. :(

[Pete Dowson]

So I don't understand it at all. What is that memory for? How much memory I have to allocate?

When you use the standard EXTERNAL interface to FSUIPC, there is a block of memory obtained and marked as a memory-mapped file. By default this is the maximum supported memory (31k I think). It is this memory which is passed back and forth between your program and FSUIPC using Windows memory sharing system by file-mapping.

The Read and Write calls do nothing except add requests to that memory. If you add too many and overfill the memory, they report a failure. Only the Process call actually does anything as far as FSUIPC is concerned.

In modules and gauges which are running inside FS, using memory mapping is horrendously inefficient and wasteful, so the interface is just a little different. The ONLY difference is that the memory has to be part of the caller's global or allocated memory. Since only the caller knows how much it might need and how it wants to allocate it, this is left to it, and you simply pass the details in the Open2() call. It would be wasteful to assume 31k when you only need 1k, for instance, and every caller needs its own separate memory, so it is more efficient for it to own this.

As to how much, you just need enough for the maximum number of simultaneous Reads and Writes you will make per Process call, plus the red-tape overhead of about 16 bytes per call., plus a little more. All as clearly explained in the package. How did you miss it?

Do I need to repudiate FSUIPC_Write and FSUIPC_Read?

Sorry, what does that mean?

There is too little on this in documentation. :(

Really? You've not even read the little there is! It seems like you've not made any use of the documentation I have provided -- please look again into the internal users ZIP and find the "FSUIPC Internal Access" text file.

This method has been in existence and used without such problems arising for over four years now. Most gauge and module writers evidently seem to find it enough. I took a lot of trouble to make sure there was very little change to make to move to this interface. Would you rather it was all completely different? :cry:

Regards,

Pete