abax2000
-
Posts
79 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by abax2000
-
-
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.
-
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.
-
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.
-
okee dokee Pete.
-
-
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.
-
What's wrong with that? C288 is the first cloud layer entry (out of 16) in the weather table "at the aircraft". Your aircraft is on the ground. Is the cloud layer on the ground? You are making no sense!
0E88 is in fact derived in FSUIPC by it scanning the cloud layers to see if the aircraft is in one and if so that shows its turbulence value. So 0E88 will only reflect the layer you are in. Why is that a "discrepancy"?
I get the feeling you completely misunderstand something here. There is only one source for all these values, the METAR string read from SimConnect, which you can easily monitor yourself. The weather tables and all the weather offsets, EXCEPT the X/Y/Z wind components at the aircraft, are derived from that one source. Why do you think this results in "discrepancies"??? :sad:
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).
They are not standard METARs. You need the SDK reference.
I am studying.
These sorts of rubbishy METARs settings don't normally occur if you are using default weather sources, but they do get generated, and get worse and worse, when using external weather programs -- unless those programs use the only really safe weather setting mode, "Global". The spurious layers generate because of bugs in the FSX weather interface.
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.
-
You'd need to measure the frequency and amplitude of the fluctuations to determine the strength of the turbulence. I really can't think of any other way. Perhaps start by measuring the peaks and their frequency.
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).
I see you misunderstand. Not since FS98 days have the offsets actually mapped into real FS variables. All of them in FSUIPC4 are part of a data area inside FSUIPC which is populated by reading SimConnect variables plus a lot of derived values computed for compatibility with previous FS versions.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?
-
Yes, but no facility to read those settings at all. I expect you can only read the result, which is most likley in those wind elements I mentioned.
Oh, I think I see what you mean: that relevant data can be fed to the FS, but not read back.
I think you are wrong there. Certainly it would not manifest in the prevailing wind data at all, but I'm talking about the active wind X Y Z components at the aircraft -- it is those which makes the aircraft shake in the different directions. These are simulation values not weather values.
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.
Friction access lost with 4.929
in FSUIPC Support Pete Dowson Modules
Posted
Ok Pete, understood.
Thanks a lot for going through this together.