abax2000

Ok Pete, understood. Thanks a lot for going through this together.

Pete, thanks again. Could you tell me one or two dll's that get updated to 61637 by Acceleration, so I can do a final check?

I concluded normally a 1.5hr flight with no adverse findings. I checked all the files in root directory one-by-one; all are 61472, except the exe (which was 61637, and now is swapped with the sp2). I don't know of course what other files (besides the exe) are updated by Acceleration to a newer version (newer than sp2). It still beats me how this exe version was found in my installation. It is there for quite some time now, without any visible or persistent problems ! And what is more strange, is that FSUIPC (at least at the latest version) would reveal such problem in other users also, but I see nobody else reporting anything, so I guess this case was one in a million !!! Anyhow, it seems settled. flight_FSUIPC4log.txt

I copied the sp2 exe in the installation folder. Fired up ok and closed. The new thing I see in FSUIPC log is the lines regarding the G3D fix which I think that were not recorded in the past. I'll try a sort flight and report back. sp2_FSUIPC4.txt

Thanks for putting up with this. I just extracted (not installed) the sp2 installer. In there, there is ROOT_fsx.exe, which I suppose that if renamed can be put in its proper place. The strange thing is that the exe in the sp2 installer has a timestamp "12/12/2007 20:30", while the Acc one is "9/26/2007 16:09", meaning that sp2 is later than Acc ?!?!?!?! Anyhow, I will try tomorrow to rename the existing exe and place in the extracted from the sp2 installer (if you do not think that there is anything wrong with such a trial). Of course I will report back.

This is driving me crazy. Acceleration is only available in cd, so there is no way to install it by accident with a download. I cannot figure out what can be possibly wrong. Even if I have installed Acc without realizing it ( :cry:), all the other files should have been version 61637, which they are not (they are all 61472) !!! I suppose that reinstalling sp2, will overwrite a lot of critical files, that due to addons or mods, have been altered. So, this leaves me with two questions: Is there any way to extract the exe file from the sp2 update installer? If I live with this error in FSUIPC, will the rest of its functions (and the friction lua plugin) operate as they should? Thanks for helping out with this.

I remembered that I had noticed way back this issue with fsx.exe version number in my installation. Never had any problems, but I posted a question in fsdeveloper (http://www.fsdeveloper.com/forum/threads/fsx-version.84549/) from which I did not receive any helpful info.

From FSUIPC4Install.log: INSTALLATION FOR FSX: SetupPath="C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\" Checking version of the FSX.EXE: ...Version 10.0.61637.0 (Need at least 10.0.60905.0) I've looked my FSX.exe properties and it is: Product version: 10.0.61637.0 (FSX-Xpack.20070926-1421) Size: 2.61 MB Date modified: 9/26/2007 16:09 If this is Acceleration, this is totally unexplicable. I have the Deluxe version installed, updated to SP2 via the downloadable updates. Never installed Acceleration. Most of the other files in install directory have properties with "Product version; 10.0.61472.0 (fsx-sp2.20071210-2023). Note (regarding previous note) I just mentioned it, because normally there are no such records in FSUIPC4.log, when I just load a flight and then close (no take off). So, this was a "question" if something was ubnormally triggered by the new FSUIPC.dll. But, is probably better to leave this aside for the moment, since it seems that we have a major mystery in our hands, regarding the core issue here.

Here is the new log file. I just loaded a flight and then closed the sim. Note (unrelated to the issue discussed): The log file is full of records related to a lua plugin, which should not be there since the aircraft did not take off. G_Pete_FSUIPC4.txt

okee dokee Pete.

I could not paste for some reason, so I attach it in a txt file. Pete_FSUIPC4log.txt

Pete, I think the sim1.dll in my system is the original one. I have forwarded by email as requested. Thanks for helping out.

FSX sp2. Previous fsuipc version was 4.928. As far as I remember I dont use a hacked sim1. I use the relevant lua plugin. I will check again and report back.

I just installed today 4.929 and then 4.929c. In FSUIPC4.log, gets logged 2652 ### Failed to obtain SIM1 Frictions access: no frictions facilities available! Haven't touched anything else. What this can be?

The vertical speed at touch down is best captured using offset 31A0. Offset 030C (and 02C8 also) seem to contain the vertical speed displayed on the VSI, which has a time lag (as in RL). Try to experiment by capturing all offsets at touchdown moment, and you will see the differences. They can be substantial (with a firm landing and/or steeper glidepaths), or smaller (with a greaser and/or shallow landings).

Mea culpa. There is a logic mistake in my code (in some nested if's). But then again, very useful to come in contact with you; I had forgotten about the Trace/Log facility. Thanks again...and sorry about that.

In a specific case, looked like it was not cancelled, but it is difficult to pinpoint it. I will dig in some further. Thnx Pete.

Can a function be cancelled (with event.cancel) from within the same function (e.g. using an "if" statement, [if ipc.elapsedtime()>T then event.cancel("xxx") end]), or it can only be cancelled from outside (some other point of the lua script containing it) ?

So, trying to sum it up: The range C000-C3FF contains weather data at lan-lon of the aircraft from ground up (not only at a/c height)- at least this is true for cloud layers. The offsets within that range published in latest version of FS-Interrogate2std are not the only ones in this range. For a complete picture, all other offsets in this range must be taken into account. WeatherSet2 is the only "user-friendly" means of getting most (but not all) of the info in this range. I have read (multiple times) the NewWeather Readme.txt contained in your documentation, but that's about it; I could not locate a more detailed doc.

The a/c is on the ground; there is no cloud layer on the ground (the first one is 1001-5000ft). So "at" the a/c there are no clouds.That is why I find reasonable 0E88, but not C288 (which is supposed to report also "at" a/c position; although it reports whatever exists 1000ft higher). Since both are supposed to report at a/c, I would expect 0E88=C288=0 (since a/c is out of any cloud layer). I am studying. That explains it; I use AS2012 at "Standard" mode.

Pete, here is an example about the discrepancies in values I was talking about. The aircraft is on the ground. 0E88 reports 0 (which makes sense since the a/c is below the first layer carrying cloud turbulence). On the other hand, C288 does have a non-zero value. I used also the FSUIPC weather logging facility. For the time I have some problems in decoding METAR strings, but I am working on it. What would be the meaning of a message as this (**** METAR errors: length=1684, spurious layers removed: Wind 21, Temp 22) ?

Pete, thanks you very much for your suggestions and the insight provided.

No thanks, I think that I'll pass :cry: I just asked for a confirmation about "weather at aircraft" because flying low I saw discrepancies between whatever reported as turbulence in the first cloud layer (in WeatherSet) and the value in C288 and 0E88 (I was expecting these all three to coincide, but maybe it is my wrong understanding. I will run a new test flight to visit it again). It is true that I do not have a clear view of the structuring or origin of data available in the various FSUIPC offsets. If there is any document/source that explains in layman's terms the concept and general terms of the mapping of data between FS and FSUIPC, please point to it.

Just a clarification for further testing: offsets C000-C3FF refer to "weather at aircraft" taking into account also the altitude (i.e at the actual point in space where the aircraft is) or just the aircraft lat-lon?

Oh, I think I see what you mean: that relevant data can be fed to the FS, but not read back. Of course offsets 2DC8, 2DD0, 2DD8 do fluctuate while in turbulence (regardless of how this turbulence was induced). The problem is that the task on hand (see note) would require some solid measurement of the induced turbulence, in order to map the behaviour of the weather trigger. So eyeballing, aircraft instruments or (2DC8, 2DD0, 2DD8) for that purpose do verify that turbulence is active but do not tell how much. Is there any possibility that some offsets have been yet unexplored :???: ? Note: What I am trying to do is map the behaviour of the induced turbulence by the weather trigger against wind direction, wind speed and scalar.