jeehell

You have much better low level knowledge than I have so I can't tell you what's really happening between code/compiler/machine code etc... But, my "research" in P3D V4 on all data formats is that they used double precision floats almost everywhere already, and they kept that. This means most "constant" data (friction, idle fuel flow factor, and probably other stuff) has been moved around (usually "further down"), but all constant data is the same, and packed in memory the same way (double float length). In my own app, I have made it "easy" to switch to another version by storing the entire table and just searching the in-process sim1.dll memory area for the same memory "blob". I actually do not know where the data is, but once my module launches it knows, which is good enough for me. I only had to recompile for 64bits and check I used cross-compiler friendly pointer maths (I can totally see THIS may take a while, particularly if you do many stuff in ASM...). Also, I agree if LM would export more data in their DLL (actually read "export" instead of " export more") this would help a lot... Unfortunately they probably expect people to use their external sim API instead of hacking ground friction tables...

Ok, thanks for the answer. Well then you'll be "happy" (or not...) to know that there seems to be no change whatsoever in air files, the way they are loaded and used in process memory, all aerodynamic computations, as well as ground friction, based on my research so far and also others such as Hervé Sors.

Hello Pete, In the FSUIPC5 announcement you state P3D v4 is handling ground friction in a different way then earlier versions. I have been looking into that myself as I have an application which changes the friction in real-time, and it seems to me there are no differences, except the address in the Sim1.dll. Everything seems to work just as before. I also looked into the SDK and no clue in that direction. Do you have any official information on this different handling?? Regards Jean Luc

Hi, I just upgraded to the new FSUIPC versions (4.60a to 4.70b and 3.98 to 3.99). As you maybe know/remember, I developed a FBW software. Since upgrading, my soft does not want to work correctly under FSX, but it still works correctly in FS9. So I was wondering if you had introduced any change in the handling of any of the following offsets, that might differ under FS9 and FSX: - Elevators $0BB2 - Elevator trim $0BC0 - g-load $11BA (by the way, I just noticed you were off until the 9th, enjoy your holiday!) Regards, Jean Luc

Ok just browsed the two help files: Old version (P)char was equivalent to (P)AnsiChar, whereas new (P)char is equivalent to (P)Widechar. The szname variable was previously declared as AnsiString, so the old code in the new compiler probably lost a byte by transtyping szname to a widechar? (and now I guess that only this szname declaration change was required, but for code cleanliness sake, using the full Pwidechar name is better I suppose) Thanks for your interest, JL

Ok just posted it in user contribution forum. I'm not too sure as those new types (widestring, widechar) are still a bit new to me, but the SendMessageTimeout call in FSUIPC_process function returned a dwerror of 0, when all parameters "looked OK" (meaning the handle to mapped file, message id, atom, etc, were non null). My guess, FSUIPC didn't like the atom naming convention. Since the strings convention changed, the windows API calls from Delphi changed too (or the compiler do not adapt the convention any more?)... Anyway, now it should work! Jean Luc

Hello all Delphi coders, As there were a couple topics on the forums, I post here a 2009/2010/Xe compatible version of the FPCuser.pas file. All the credits still go back to the original author, Pelle F. S. Liljendal, I merely modified a couple lines to adjust it to new delphi unicode conventions. Cheers, JeeHell FPCuser.zip

Hello, I've just switched to the latest Delphi XE IDE, so I've been confronted to that issue as well. Delphi versions prior to delphi 2010 are not unicode compliant. So, in order to make the FPCuser.pas compatible, you simply have to replace all "Pchar" functions to "PwideChar", and all "AnsiString" to "Widestring", it takes 2 minutes... Pete, if you're interested, I can mail you the compatible version, but I'm not too sure about distribution of the modified file? Jean Luc

Actually I tried to get the world axes acceleration from the body axes acceleration, using rotation matrices, but to no avail... Since my maths are pretty rusty now, I probably did it the wrong way though... Another solution would be to actually derive the acceleration from the velocity (in the world axes), but I didn't try this one. If I have time in the upcoming weeks, I will dig further down in my maths books, and if I'm successful, I'll let you know of course. As for the performance issue, you only can tell what is acceptable or not... Regards, JL

It seems that in FSX, as you said, the 11BA offset is indeed accurate. So I decided to go that way, even if it's a little bit less accurate than my previous method. I'm however quite sure that the FSX simconnect data concerning the world Y-axis is corrupted somewhere, it's a real shame. Thanks for your help anyway. JL

Ok I can give you a protocol to see what's wrong with offset x31C8: Keep the wings level and monitor the formula I gave you (G=1+Yaccel/32.2) along with the FS Gforce which you can show inside FS (shift+Z twice) Under FS9, both values should be strictly the same (except for the rounding indeed), when in FSX they do differ a lot, especially when you pull/push the stick fully forward/backward. Thanks for your help.

I use FSX SP2 I had a thought. If I'm correct, FS9 uses a flat Earth model when FSX uses a spherical model, maybe that would be a cause for the little discrepancy? I cannot get good figures because the errors seems to appear only when the actual g load is different from 1g, so on level flight it cannot be observed, and with elevator deflection it's hard to have the same experiment conditions in both simulators... What is weird, is that the sign of the 31C8 offset seems to change (i.e. when it should be negative it becomes positive but stays positive when it should be negative, and sometimes it is however correctly signed??). Regards, JL

That's good to know, I will test it right away. However I can assure you in FS9 it's not even near accurate during level flight coordinated turns, where the total G load would be 1/cos(phi) with phi being the bank angle. that I know, but since I had different results, I thought the unit could have changed and tried the first obvious unit after ft/s/s so the metric m/s/s... Well in my case at least it does not compare... I will do some tests and will try to give you figures to corroborate my experimentations... regards, Jean Luc

Hi Peter, For my A320 FBW, I need to control the vertical flight path through the g-load. Since the usual g force offset is not accurate enough (the documentation clearly states that the unit and all is unknow), I decided to go the physics' way and calculate myself the vertical G load from the Y-axis acceleration in the world axes (offset 31C8). I then use the formula: yGload=1+Yaccel/32.2 to convert ft/s/s to relative g's. This actually works really great under FS9 where I get good results (When I compare to the usual Gload offset, with bank angle=0, I get almost the same value). However under FSX I have had no luck at all!!! Any idea? My first thought was that either in FSX it gets data in another reference axes, or the unit of the data is different (It seems it's not m/s/s would it be the case)... Thanks in advance, JeeHell

I'll repost the code I posted on mycockpit's forums as I know it works.... var dwresult : dword; Lat,Lon : int64; latitude,longitude:extended; begin if (FSUIPC_Read($0560,8, @Lat, dwResult))and(FSUIPC_Read($0568,8, @lon , dwResult)) then if FSUIPC_Process(dwResult) then begin latitude := Lat/ 10001750; latitude := latitude /65536 ; latitude := latitude /65536 ; latitude := latitude *90; //I separate those lines as sometimes it causes stack overflow on my system) longitude := Lon / 65536 ; longitude := longitude /65536 ; longitude := longitude /65536 ; longitude := longitude /65536 ; longitude := longitude *360; showmessage(floattostr(latitude)+' / '+inttostr(Lat) ); showmessage(floattostr(longitude)+' / '+inttostr(Lon) ); end; As I said, in delphi you might raise a stack overflow exception if you do operations such as 360 / (65536.0 * 65536.0 * 65536.0 * 65536.0) in the same line. Also it is a good idea to first divide by the big values ( i.e. 65536.0 * 65536.0 * 65536.0 * 65536.0 or 10001750.0 * 65536.0 * 65536.0 ) then multiply by 360 or 90 (if the integer value you read is just below the maximum size allowed for a 8byte integer, multiplying it will do strange things, like truncating to the 8 bytes allocated...). I also think you should request the FSUIPC offset you want to retrieve then process them in one ifthen operation: if (FSUIPC_Read($0560,8, @Lat, dwResult))and(FSUIPC_Read($0568,8, @lon , dwResult)) then if FSUIPC_Process(dwResult) then begin //code to execute end; instead of: FSUIPC_read($0568,8,@Longitude,dwresult); FSUIPC_read($0560,8,@Latitude,dwresult); if FSUIPC_Process(dwResult)then begin //code to execute end; Hope that helps.