Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Mister Dawson,

Very recently, you have added into your published list of freeware key code, a key for my gauge "ACS.Zulu-MD11.GAU", on the request of an user. Then you have removed this key, soon after, because this user told you that this key wasn't working.

Where I recognize you perfectly, it is in the fact that you immediately said to this user that it was my fault, that probably, I was not acceeding your module in a clean way.

Sorry, Mr Dawson, but I am not the guilty. It is your module which do not support all possible legal file names. In this particular case, your system actually do not support executable file name which contain several dots characters.

So now, we will see if you are respecting your engagements (freeware users must not be obliged to pay a licence), by correcting this obvious fault in your module and publish again a new key which will work.

It is quite clear here, that it not to me to change the name structure for my gauges, a structure which I use for many years now and moreover, which I am not the only developper to use.

Regards,

Alain Capt

ACSoft Productions

Posted

Sorry, Mr Dawson ...

It is Dowson.

... , but I am not the guilty. It is your module which do not support all possible legal file names. In this particular case, your system actually do not support executable file name which contain several dots characters.

This is not actually true. Certainly there is a bug in the current version which terminates the name at the first dot, when input via the Application Registration dialogue. However, the entry can be made manually into the KEY file.

It is certainly also true that older versions failed to self-register (via the method of writing to offset 8001) a GAUge or DLL if the filename contained more than one dot. That problem came to light on the first such gauge encountered, some time last year, and was fixed then.

The ACS gauge was the first with such a filename which, because it did not contain the code to write the Key, had to be manually registered, and this was reported in the last day or two, when I was asked for a Key for it. I have corrected the Registration code in version 3.22 of FSUIPC, which is due to be released tomorrow (Friday) some time.

Not being in possession of your gauge, I am unable to test this, but one of your users did do some test and recently informed me that it was solved, even before I have made this release. I could have provided the manual way (editing the .KEY file) in the Freeware Keys thread, but I felt this was possibly confusing to users and, after all, I am releasing a revised FSUIPC within a day or so of producing the Key in the first place, so there was no inordinate need.

I really do not see how I could have provided better support in this case. Please ask your own user for confirmation of this.

Pete

Posted

You are both very active developers for FS community, especially for freeware outstanding works to enhance our flight simming experience.

I don't have any idea of what consequence could happen if ACS changed his gauge name, nor i don't know how long it would be to enable such a gauge name in FSUIPC.

Pete Dowson seems to spend a lot of time with developers, more than with his customers, and he accredited many freewares to access FSUIPC with free keys. But i guess those freewares developers respected the FSUIPC development SDK to fit the requirements. And Pete on his side, tried to enhance his module when something was not working, bugging or whatever with a third party program.

If I understood, the fact that FSUIPC doesn't accept mutliple dots in gauge name was not known, and not written somewhere nor in FSUIPC SDK. In this way Alain Capt couldn't guess it doesn't work with his gauge.

I'm sure as professionnals and experienced developers, you'll find the way to the solution through the dialog, maybe discussing what would be the longer and harder : working on the gauge, or working on FSUIPC. I don't know, i would say this is your part of discussing, not mine anymore. Then the whole FS community will welcome another freeware enhanced by FSUIPC features, like many others already available. 8)

Posted

It is Dowson.

Sorry Mr. Dowson, for this misspelling of your name.

This is not actually true. Certainly there is a bug in the current version which terminates the name at the first dot, when input via the Application Registration dialogue. However, the entry can be made manually into the KEY file.

Yes, I used this option, along with gauge rename, with the Key the user sent to me, to investigate the case. But you should know that with this key, NONE of the manual correction into the KEY file was working, unless I rename my gauge.

It is certainly also true that older versions failed to self-register (via the method of writing to offset 8001) a GAUge or DLL if the filename contained more than one dot. That problem came to light on the first such gauge encountered, some time last year, and was fixed then.

For your information, even with a renamed gauge which work with the manual registration method, I was not able to make working the auto-registration method which I also tryed by curiosity. The code into gauge is EXACTLY like into your sample, except, of course it use Open2() instead of Open(). Is it that the auto-registration use an other key ? I don't know.

The ACS gauge was the first with such a filename which, because it did not contain the code to write the Key, had to be manually registered, and this was reported in the last day or two, when I was asked for a Key for it. I have corrected the Registration code in version 3.22 of FSUIPC, which is due to be released tomorrow (Friday) some time.

Not being in possession of your gauge, I am unable to test this, but one of your users did do some test and recently informed me that it was solved, even before I have made this release. I could have provided the manual way (editing the .KEY file) in the Freeware Keys thread, but I felt this was possibly confusing to users and, after all, I am releasing a revised FSUIPC within a day or so of producing the Key in the first place, so there was no inordinate need.

This user missunderstand me. I simply told to him that I was able to make it work, but for that, I had to make an abnormal modification on my side.

I would greatly prefer to implement the auto-registration method, to avoid installation, documentation, support complications.

If you are on the way to issue a new version with correction in the aera, please use me to check all that. If you send me your beta, along with the key which is supposed to work with auto-registration method, I will test all this asap (this afternoon already) and report here.

Regards,

Alain

Posted

Yes, I used this option, along with gauge rename, with the Key the user sent to me, to investigate the case. But you should know that with this key, NONE of the manual correction into the KEY file was working, unless I rename my gauge.

I was unable to perform any tests because your user refused to send me the Gauge to try without your permission. All I can suggest is that you re-test with FSUIPC 3.22, being released today. The FSUIPC code is being developed al the time, mostly in response to user requests.

I was not able to make working the auto-registration method which I also tryed by curiosity.

Well it sounds like you may actually have an error someplace, as there are plenty of gauges which are working fine with multiple '.' characters and auto-registration. There was only this problem with the manual method. If you think there is still a problem with the automatic method I would need a log with IPCreads and writes enabled. Be sure to use 3.22 though as I don't want to test old code -- and there are some improvements to the logging in this newer version. Forward only!

If you send me your beta, along with the key which is supposed to work with auto-registration method

It is too late for a Beta or other changes for 3.22, as I told your user. I had a deadline of today. Any further changes will await the next version. Oh, and the key is as already issued to your user.

Pete

Posted

Mr Dowson,

I redo all the test with your very last version 3.212, with my gauge renamed in "ACS-Zulu-MD11.gau" instead of "ACS.Zulu-MD11.gau". here are the results:

Auto-registration method:

the code used:

if(FSUIPC_INIT && !FSUIPC)

{

DWORD dwResult;

FSUIPC_INIT--;

if(FSUIPC=FSUIPC_Open2(SIM_ANY,&dwResult,FSUIPC_buf,sizeof(FSUIPC_buf))==TRUE)

{

WORD FS_year;

static char chMyKey[]="EHTMOBYEXWXI"; // As obtained from Pete Dowson

if (FSUIPC_Write(0x8001,12,chMyKey,&dwResult)) // register my key

FSUIPC_Process(&dwResult);

// read FS year offset, to check if FSUIPC is really operational

if (!FSUIPC_Read(0x0240,2,&FS_year,&dwResult) || !FSUIPC_Process(&dwResult))

FSUIPC=FALSE;

else

{

This code is located into the "update()" part of the gauge and executed a maximum of 18 times in 1 second (FSUIPC_INIT counter) to insure your module has the time to be operational (this feature is required).

Result of the test: failure, no registration.

Manual registration method:

Content of your file FSUIPC.key:

[Programs]

ACSZuluMD11.gau=EHTMOBYEXWXI

Content of your file FSUIPC.log:

********* FSUIPC, Version 3.212 by Pete Dowson *********

User Name=""

User Addr=""

FSUIPC not user registered

WIDEFS not user registered, or expired

Module base=61000000

ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E

WeatherOptions(Orig)=0000B027[0000B027]

InitDelay: 0 seconds

WeatherReadInterval=4

LogOptions=00000001

DebugStatus=0

1485 System time = 15:08:58

1485 \\PC-ALAIN\F\FS2004\

1485 System time = 15:08:58, FS2004 time = 12:00:00 (00:00Z)

2485 D:\Documents\Flight Simulator Files\ACS MD11 - default flight.flt

2516 AIRCRAFT\iFDG_MD11-PW-PAX-3C\MD-11_acs.air

2516 Aircraft="iFDG MD11 Swissair"

6610 Advanced Weather Interface Enabled

32516 D:\Documents\Flight Simulator Files\UI generated flight.flt

32813 Clear All Weather requested: external weather discarded

33125 Module identified = "ACS-zulu-MD11.GAU"

33125 ModuleOK="ACS-zulu-MD11.GAU"

43500 Traffic File #14 = "scenery\world\scenery\traffic030528"

59828 System time = 15:09:57, FS2004 time = 15:09:16 (13:09Z)

59828 *** FSUIPC log file being closed

Memory managed: 2 Allocs, 1124 Freed

********* FSUIPC Log file closed ****

Result of the test: success of registration

With the hope this might help you.

Regards,

Alain Capt

ACSoft Productions

Posted

Mr Dowson,

Hoops, we crossed our messages !

Can you give me the key, I am not in contact actually with the user. I will redo the test with your 3.22 which I suppose is already downloadable.

Thanks in forward,

Alain

Posted

I redo all the test with your very last version 3.212, with my gauge renamed in "ACS-Zulu-MD11.gau" instead of "ACS.Zulu-MD11.gau". here are the results:

No, please test with 3.22, being released today, as I asked. Information for old versions is really not a great deal of use to me. As I said, FSUIPC is changing all the time. Besides which, as I also said, there is better logging in the new version.

Please check the announcements at the top of this forum. The new version has been released and will no doubt be up on the usual sites within a few hours or so.

There is no big rush in any case. From now until Monday I am tied up with family matters. It is my Father's 90th birthday and we have relations converging on us from all over.

One observation, however:

if (FSUIPC_Write(0x8001,12,chMyKey,&dwResult)) // register my key

This is completely wrong. For gauges and DLLs the data written is the 12-byte Key followed by the complete Gauge or DLL name, zero terminated. This is clearly documented in the Access Registration document in section 4. Please check.

There is NO NEED to rename your gauge. Please do not.

If you still have problems with 3.22 and/or the correct auto-registration code, please use the logging, as I asked.

Pete

Posted

Hoops, we crossed our messages !

And again toobut at least I saw the error in your program! Please check the instructions for auto-registering DLLs and GAUs in the FSUIPC SDK Access Registration document. If you fix that I am convinced it will work fine, with the original name of the Gauge, in all versions of FSUIPC made this year at least.

Can you give me the key, I am not in contact actually with the user. I will redo the test with your 3.22 which I suppose is already downloadable.

You have the key, it is even in your message above. 3.22 should be downloadable soon, but it appears Enrico is out this afternoon.

Pete

Posted

No, please test with 3.22, being released today, as I asked. Information for old versions is really not a great deal of use to me. As I said, FSUIPC is changing all the time. Besides which, as I also said, there is better logging in the new version.

Please check the announcements at the top of this forum. The new version has been released and will no doubt be up on the usual sites within a few hours or so.

I just got the 3.22 and tested. Nice, now the manual registration method work perfectly with the "official" name of my gauge.

There is no big rush in any case. From now until Monday I am tied up with family matters. It is my Father's 90th birthday and we have relations converging on us from all over.

What a beautiful age ! Please, transmit my very warm and sincere "happy birthday wishes" to your father, from the Swiss developper who is always "fighting" with you ! :wink:

One observation, however:

if (FSUIPC_Write(0x8001,12,chMyKey,&dwResult)) // register my key

This is completely wrong. For gauges and DLLs the data written is the 12-byte Key followed by the complete Gauge or DLL name, zero terminated. This is clearly documented in the Access Registration document in section 4. Please check.

One point for England !

But like I said, I tested that quickly by curiosity, with the straight forward natural developper reflex, to refer to the sample code you give.

May I suggest that you add into this basic sample code:

"Attention, the method is different for gauge or dll, please refer to..."

But thank anyway to have pointed out the problem, this has probably saved me from some fastidious documentation readings & researches.

I will now make the code correct and test again and I am sure it will work. I wish to you a nice week-end and fest with your family.

Regards,

Alain Capt

Posted

Mr Dowson,

I have modified the code mentionned in a previous message this way and tested with you brand new version 3.22:

static char chMyKey[]="EHTMOBYEXWXIACSZuluMD11.gau";

if (FSUIPC_Write(0x8001,strlen(chMyKey),chMyKey,&dwResult))

FSUIPC_Process(&dwResult);

But it does not work.

Just to see, I tryed also to rename the gauge, but also without success.

Please give me advises, because now, I positively don't know what to do.

Regards,

Alain

Posted

Mr Dowson,

I am terribly sorry, but you still have a problem on you side. I prove it:

With your last version 3.22 I have build my gauge using the name "A320.gau" everywhere and used the key "VSB54OK5UVWNA320.gau" in the code of my gauge (code as printed in previous messages).

Result: auto registration work perfectly

Here is the log with read/write enabled:

********* FSUIPC, Version 3.22 by Pete Dowson *********

User Name=""

User Addr=""

FSUIPC not user registered

WIDEFS not user registered, or expired

Module base=61000000

ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E

WeatherOptions(Orig)=0000B027[0000B027]

InitDelay: 0 seconds

WeatherReadInterval=4

LogOptions=0000000D

DebugStatus=0

1454 System time = 21:16:53

1454 \\PC-ALAIN\F\FS2004\

1469 System time = 21:16:53, FS2004 time = 12:00:00 (00:00Z)

2454 D:\Documents\Flight Simulator Files\ACS MD11 - default flight.flt

2485 AIRCRAFT\iFDG_MD11-PW-PAX-3C\MD-11_acs.air

2485 Aircraft="iFDG MD11 Swissair"

6610 Advanced Weather Interface Enabled

7375 D:\Documents\Flight Simulator Files\UI generated flight.flt

7672 Clear All Weather requested: external weather discarded

8172 Module identified = "A320.GAU"

8172 READ0 3304, 4 bytes: 00 00 20 32

8172 READ0 3308, 4 bytes: 07 00 DE FA

8172 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

8172 WRITE0 8001, 20 bytes: 56 53 42 35 34 4F 4B 35 55 56 57 4E 41 33 32 30

8172 2E 67 61 75

8172 ModuleOK="A320.gau"

8172 READ0 0240, 2 bytes: D4 07

8172 READ0 F000, 2 bytes: 00 00

8172 READ0 F002, 2 bytes: 00 00

20610 Traffic File #14 = "scenery\world\scenery\traffic030528"

20625 READ0 3304, 4 bytes: 00 00 20 32

20625 READ0 3308, 4 bytes: 07 00 DE FA

20625 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

20625 WRITE0 8001, 20 bytes: 56 53 42 35 34 4F 4B 35 55 56 57 4E 41 33 32 30

20625 2E 67 61 75

20625 READ0 0240, 2 bytes: D4 07

20625 READ0 F000, 2 bytes: 28 00

20625 READ0 F002, 2 bytes: 60 00

21485 READ0 F006, 2 bytes: 03 00

21485 READ0 F004, 2 bytes: 03 00

... and here dialog with FSUIPC start and work normally.

But using my "official" gauge name and EXACLTY the same code, it does not work.

Here is the log with read/write enabled:

********* FSUIPC, Version 3.22 by Pete Dowson *********

User Name=""

User Addr=""

FSUIPC not user registered

WIDEFS not user registered, or expired

Module base=61000000

ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E

WeatherOptions(Orig)=0000B027[0000B027]

InitDelay: 0 seconds

WeatherReadInterval=4

LogOptions=0000000D

DebugStatus=0

1453 System time = 21:24:59

1453 \\PC-ALAIN\F\FS2004\

1469 System time = 21:24:59, FS2004 time = 12:00:00 (00:00Z)

2453 D:\Documents\Flight Simulator Files\ACS MD11 - default flight.flt

2484 AIRCRAFT\iFDG_MD11-PW-PAX-3C\MD-11_acs.air

2484 Aircraft="iFDG MD11 Swissair"

6609 Advanced Weather Interface Enabled

7781 D:\Documents\Flight Simulator Files\UI generated flight.flt

8063 Clear All Weather requested: external weather discarded

8391 Module identified = "ACS.zulu-MD11.GAU"

8391 READ0 3304, 4 bytes: 00 00 20 32

8391 READ0 3308, 4 bytes: 07 00 DE FA

8391 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

8391 WRITE0 8001, 27 bytes: 45 48 54 4D 4F 42 59 45 58 57 58 49 41 43 53 5A

8391 75 6C 75 4D 44 31 31 2E 67 61 75

8391 Illegal read attempt: offset 0240, size 2

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

9703 ### IPC Message processed in 1312mSecs ###

18906 Traffic File #14 = "scenery\world\scenery\traffic030528"

18922 Module identified = "ACS.zulu-MD11.GAU"

18922 READ0 3304, 4 bytes: 00 00 20 32

18922 READ0 3308, 4 bytes: 07 00 DE FA

18922 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

18922 WRITE0 8001, 27 bytes: 45 48 54 4D 4F 42 59 45 58 57 58 49 41 43 53 5A

18922 75 6C 75 4D 44 31 31 2E 67 61 75

18922 Illegal read attempt: offset 0240, size 2

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

18922 READ0 3304, 4 bytes: 00 00 20 32

18922 READ0 3308, 4 bytes: 07 00 DE FA

18922 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

18922 WRITE0 8001, 27 bytes: 45 48 54 4D 4F 42 59 45 58 57 58 49 41 43 53 5A

18922 75 6C 75 4D 44 31 31 2E 67 61 75

18922 Illegal read attempt: offset 0240, size 2

18922 READ0 3304, 4 bytes: 00 00 20 32

18922 READ0 3308, 4 bytes: 07 00 DE FA

18922 WRITE0 (failed, read-only!) 330A, 2 bytes: 4C 04

18922 WRITE0 8001, 27 bytes: 45 48 54 4D 4F 42 59 45 58 57 58 49 41 43 53 5A

18922 75 6C 75 4D 44 31 31 2E 67 61 75

18922 Illegal read attempt: offset 0240, size 2

etc..., until all 18 attempts are done.

For your information and help, I have also tryed with my key, but with different gauge name:

With: "ACS.ZuluMD11.gau" it does not work

With: "ACSZulu-MD11.gau" it does not work

With: "ACSZuluMD11.gau" IT WORK

You obviously still have some "salad" in the way you handle spécial characters.

So, I am waiting you correct the problem on your side.

By the way:

Switzerland: 1 point.

Regards,

Alain Capt

Posted

I have modified the code mentionned in a previous message this way and tested with you brand new version 3.22:

static char chMyKey[]="EHTMOBYEXWXIACSZuluMD11.gau";

Is your gauge really named "ACSZuluMD11.gau". If not, use the real name, please. FSUIPC need the REAL name.

if (FSUIPC_Write(0x8001,strlen(chMyKey),chMyKey,&dwResult))

FSUIPC_Process(&dwResult);

But it does not work.

You need to add 1 to the length, otherwise the zero terminator, as specified in the interface, and as mentioned in my message, is not included!

Pete

Posted

I am terribly sorry, but you still have a problem on you side. I prove it:

Add 1 to the length so that your writes to 8001 end with the correct zero, as specified. THEN show me logs. Not before.

You obviously still have some "salad" in the way you handle spécial characters.

Please refrain from trying to be so insulting, and obey the specification first. Then I will look at it. but it will certainly not be till Monday now!

Pete

Posted

Please refrain from trying to be so insulting, and obey the specification first. Then I will look at it. but it will certainly not be till Monday now!

Shall I say now "yes Sir yes" my Colonel and clap my heels ?

No, because now I have definitively ENOUGH OF YOU.

There is nothing insulting in that expression.

I don't care about when you look at your problems.

I simply recommend you a bit more humility, because if your documentation was a bit more precise, we would know if the zero character should be included or not. Your text is very ambigous on that point. What about special characters ? Shall we omit them like it is the case into the file FSUIPC.key ? Simply not one word on that matter.

What do you think, your are the only clever man on this planet ? Of course, I have tested with or without the zero terminator and this make no difference at all.

Moreover, I tell you that it work in two cases WITHOUT, tell me why in this case ?

Alain Capt

Posted

Hep Hep calm down :lol:

I guess developing gauges for FS is exactly as crazy as any programming activity. You want to manage, it's hard, you don't understand, you think hours and hours getting tired and nervous and finally you find what can make the trick. pfffuu wonderful.

I hope the misunderstood words of tired developers won't cut the flight simmers to get a finalized weather radar gauge in Alain Capt's MD 11 panel. Remember how started the day this morning with the dialog method, it was comprehensive and progressing and the food had nothing to do with this :wink:

Now I think Pete is away until monday, and Alain you have the time to look closely at your code issues. Take your time, and some distance. Maybe the solution is near and you don't see it because you worked too much today. You will manage another day, no hurry needed. Remember you have in your have in your hands the first freeware weather radar gauge for FS ever ! 8) And this won't maintain the dialog method to write what you think when you are nervous because of the programming activity. Please write only what you need for the code issues, this will help. Pete on his side won't take care of the above if you both keep the dialog method on code issues, not food ones :idea:

Posted

No, because now I have definitively ENOUGH OF YOU.

Oh dear, this is always the same with you. You tend to become rude and unbearable so quickly, as before in private email. Why do you think my email address is blocked to you?

if your documentation was a bit more precise, we would know if the zero character should be included or not. Your text is very ambigous on that point.

Excuse me, what is in any way ambiguous about the text in the documentation I supply and you seem not to want to read (as you even implied in an earlier message). This is the relevant paragraph:

The Key is provided, once agreement is reached, based only on this module name. No company name or product title is needed, as it is not expected that Gauges and Modules are all to be equipped with Version Information resources. You write the above data to offset 0x8001 with no space or zero between the Key and module name, but a terminating zero at the end of the latter.

Don't you see that part"but a terminating zero at the end of the latter."?

I don't mind the fact that you missed this point, but you don't have to be so nasty about it, as if it is all my fault that you don't read the details correctly. How did you ever learn to program if you don't notice details?

What about special characters ? Shall we omit them like it is the case into the file FSUIPC.key ? Simply not one word on that matter.

No, there is no need to omit anything. There is no need for any word on that matter because it is all handled in FSUIPC. Special characters are not a problem. You are not supposed to edit the KEY file in any case, there are no instructions so to do.

Please be reasonable, you are reacting quite irrationally. It is because you shoot off half-cocked like this that we stopped communicating before. Aren't you ashamed of doing the same in public?

What do you think, your are the only clever man on this planet ?

What is that supposed to mean? That you are clever? You are not showing it at present. It is not clever to post such foolish unconstructive messages.

Of course, I have tested with or without the zero terminator and this make no difference at all.

In that case I need at least the log file showing it. You seem to be the only developer to have such problems, yet you react as if I've never helped at all. I will fix things if they need fixing, but I need data to work with. Perhaps, if you had given permission for your user to send me your very worthwhile gauge in the first place this would all have been resolved by now. As it is you seem to be climbing up some wall with no good reason and without any appreciation of what is needed for correct resolution of a problem.

Moreover, I tell you that it work in two cases WITHOUT, tell me why in this case ?

The data in the memory you are writing to will vary. If it happens to be zero where a zero should be written you are lucky, of not you are not.

If you are prepared to be more reasonable in your messages, let us continue. If you are not, please desist.

I may not be responding so fast over this wekend due to family commitments, as I said earlier.

Pete

Posted

I don't mind the fact that you missed this point, but you don't have to be so nasty about it, as if it is all my fault that you don't read the details correctly. How did you ever learn to program if you don't notice details?

Is it possible for you to imagine that somebody which is not speaking English as is mother language may have more difficulties to understand some kind of redaction ?

Is it possible for you to imagine that to say "How did you ever learn to program if you don't notice details?" is almost equally insultant than my remark about the "salad" ?

No, there is no need to omit anything. There is no need for any word on that matter because it is all handled in FSUIPC. Special characters are not a problem. You are not supposed to edit the KEY file in any case, there are no instructions so to do.

And, of course, we are supposed to know that "it is all handled in FSUIPC", even if this is not mentionned in the doc.

Please be reasonable, you are reacting quite irrationally. It is because you shoot off half-cocked like this that we stopped communicating before. Aren't you ashamed of doing the same in public?

I am not ashmed of nothing. Public will judge.

Public will judge who is always disparaging other.

Public will judge who tryed to bring peace by writing kind words about your father birthday and wish to you a nice week-end.

Public will judge who simply do not say the smallest thanks for these wishes nor returned them.

Public will judge who started first to be disagreeable for nothing in this thread.

Now you can continue alone to give lesson to me or to others, if you want, apparently you seem to found that delightful. But note that I will never come back in this forum. So if you do it, everybody will understand you need to justify yourself.

All this effort, to make this gauge auto-registrable, I do it exclusively for the simmer community, not for me. I don't need it.

In the bible it is written:

"You see the straw which is in the eye of your neighbour, but you don't see the beam which is in yours".

Thanks anyway to have respected your engagement by building a key for my gauge and may God bless you.

Alain Capt

ACSoft Productions

leaving this forum and this thread for ever.

  • 2 years later...
Posted

Whew! Alain's been doing some marvellous add-ons for the Orbiter Space Flight Simulator, notable the AMSO Apollo mission simulator, and he's been known to be somewhat protective of his work, which is understandable, but until I read this thread, I never fully realized the tremendious amount of work involved in the develpment of flight simulation software.

I admit that I was mildly amused by the ongoing furball between two experienced software programmers, each defending his own area of expertese, but I also respected the knowledgable and intelligent reparte as a means to an end, namely the solving of a difficult technical problem.

I was about to suggest to both parties that they collaberate on linking FSUIPC to Orbiter for Multiplayer and external applications, but it seems that opportunity has passed quickly. Anyway, just my 2 pence worth.

  • 1 month later...
Posted

It is your module which do not support all possible legal file names. In this particular case, your system actually do not support executable file name which contain several dots characters.

This is of only a personal view.....

Under the windows / ms dos operation systems it would seem

"Logical" not to use more then one "Decimal" in anyfile name

considering the usual method is the "Decimal" determains the starting point of a "extension" of the file.... maybe reads last decimal but..... ( certain applications save from the first decimal and others from the end and a few just anywhere in the middle...... (Comes down to the developer/code)....

If your methods have been working for years then your methods seem to not follow along reconised guide lines for such "Problems" that can arrise....

You maybe able to code something to work with "The Last Decimal" as the starting point for an extension or any other use..... But would'nt it make sense just to stick to guide lines....???

Make it compatible & expandable

----- My Personal View ----

Posted
You maybe able to code something to work with "The Last Decimal" as the starting point for an extension or any other use..... But would'nt it make sense just to stick to guide lines....???

What are these "guidelines" that you speak of? :)

It might make things easier for misbehaving software, yes. But when it comes to filenames, there are no "guidelines". Either the filename is valid, or it is not - and if it is valid it is expected that it is supported.

(Please note that I have not read the above thread in years, and am not commenting on anything beyond your post.)

Cheers!

Luke

  • 2 weeks later...
Posted

If your replies are for Alain, I would not count on him returning to read them. He is currently working on projects for Orbiter Space Flight Simulator, notably the AMSO Apollo program series, which I have been beta testing for him.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.