hsors

Hi Pete, I try to detect in one of my application the Joystick ON/OFF state. Sending the JOYSTICK_CALIBRATE control () via FSUIPC at offset H3110 correctly switches the Joystick from ON to OFF or OFF to ON but I didn't succeed in determining what was the Joystick state before performing this action. (my aim is to reconnect the JS if the user inadvertently disconnected it, not the inverse of course). I also used (in other parts of the program) the specific enabling/disabling facilities you provided through offset H310A but this is, I think, another facility not related to the main "physical" joystick state as set by the "Joystick on/off" key event. Thanks for your help Hervé

Pete, In a previous message you made an allusion to FDSConnection..I had a look to this FSUIPC "clone" and I must say that, as regard FS variables access, FDSConnection is not yet appealing but I'm pretty sure it will improve..a few designers already use it for simple apllications :roll: I understood FDSConnection was able to directly access all FS tokens by their names (tokens.h table) although I didn't test it. I know you already mapped most FS tokens in 1st table but not all of them..Moreover, I'm not sure FSlook and FSlook2 use FSUIPC. My questions are: 1) How does FSlook(1-2) access FS tokens? 2) Do you think FSUIPC could, in the future, provide such a possibility? 3) What is your feeling about the freeware FDSConnection module that shares most of its code and offsets with FSUIPC (not taking into consideration all the extra settings FSUIPC added)? Please feel free not to answer the 3rd question if you wish :wink: Hervé

Hi Speedbirdie, You can calculate aircraft altitude (ft, AMSL) with the following VB code Public Const FtToM as double=0.3048 (in the declaration section of any module) Dim AltLow as long (long at &H570) Dim AltHigh as long (long at &H574) Dim td as as double (temp variable) Dim AltAMSL as double (result, ft) td=CDbl(AltLow)/65536/65536 If td<0 then td=td+1 AltAMSL=(CDbl(AltHigh)+td)/FtToM Hope it will do your job Hervé

Raymond, I already posted the process a few weeks ago since a similar question was asked..may be it could help again Accessing FSUIPC registration status and, if necessary, register a program in VB can be performed with the following code You must first determine if the FSUIPC owner has a registered version ; in such a case you do not have to worry about sending a "key" For that you will have to check the &H330C location ------------------------------------------------------------------------------------- Dim AccessByte as byte Dim IsRegistered as byte Dim tb as boolean 'temp boolean variable If Not FSUIPC_Read(&H330C, 1, VarPtr(AccessByte)) Then GoTo CloseExit 'my new FSUIPC_read routine directly returns TRUE/FALSE for success/failure (without a dwResult ByRef variable) If Not FSUIPC_Process() Then GoTo CloseExit 'same for my new FSUIPC_Process routine IsRegistered = AccessByte AND &H2 'will be 1 if user has a registered FSUIPC version, 0 otherwise ------------------------------------------------------------------------------------- If (and only if) the user doesn't have a registered FSUIPC version, you will have to send the program key and recheck the &H330C byte Here is the code assuming you defined the FSUIPCKey variable as a 12 char string (Pete provided it to you for your freeware applications..be sure to remove all spaces).. ------------------------------------------------------------------------------------- If IsRegistered=0 then tb = FSUIPC_WriteS(&H8001&, Len(FSUIPCKey), FSUIPCKey) 'send the key through a [WriteS] and process ; don't forget the double && in H8001 as Pete pointed out and also discard the function result (dwResult or any other..it's meaningless) tb = FSUIPC_Process ' same here If Not FSUIPC_Read(&H330C, 1, VarPtr(AccessByte)) Then GoTo CloseExit 'reread access byte and process If Not FSUIPC_Process() Then GoTo CloseExit If (AccessByte And &H2) = 0 Then GoTo CloseExit 'still 0, registration key failed..ask Pete End If ------------------------------------------------------------------------------------- Hervé

Hi Andragar Here is the detailed process I use for accessing FSUIPC registration status and register a program if necessary You must first determine if the FSUIPC owner has a registered version ; in such a case you do not have to worry about sending a "key" For that you will have to check &H330C location ------------------------------------------------------------------------------------- Dim AccessByte as byte, Dim IsRegistered as byte Dim tb as boolean 'temp variable If Not FSUIPC_Read(&H330C, 1, VarPtr(AccessByte)) Then GoTo CloseExit 'my new FSUIPC_read routine directly returns TRUE/FALSE for success/failure If Not FSUIPC_Process() Then GoTo CloseExit 'same for my new FSUIPC_Process routine IsRegistered = AccessByte AND &H2 'will be 1 if user has a registered FSUIPC version, 0 otherwise ------------------------------------------------------------------------------------- If (and only if) user do not have a registered FSUIPC version, you will have to send the program key and recheck the &H330C byte Here is the code assuming you defined the FSUIPCKey variable as a 12 char string (Pete provided it to you for your freeware applications..be sure to remove all spaces)..A typical example is FSUIPCKey="IZ2QREOXH4G7" ------------------------------------------------------------------------------------- If IsRegistered=0 then tb = FSUIPC_WriteS(&H8001&, Len(FSUIPCKey), FSUIPCKey) 'send the key through a [WriteS] and process tb = FSUIPC_Process If Not FSUIPC_Read(&H330C, 1, VarPtr(AccessByte)) Then GoTo CloseExit 'reread access byte and process If Not FSUIPC_Process() Then GoTo CloseExit If (AccessByte And &H2) = 0 Then GoTo CloseExit 'still 0, registration key failed..ask Pete ;-) End If ------------------------------------------------------------------------------------- Hope it will helps Hervé

Hi Pete It seems that the dynamic pressure (Q) FSUIPC value at &30D8 has changed in FS2004 As an example, with FS2002 and FSUIPC 2.975, this value is returned as 103.14 lb/ft^2 (at standard pressure altitude of 6,000 ft and TAS of 190.9 kts) and this value (1/2 rho*v^2..with units who are well ;-)) is correct as regard density, altitude and aerodynamical data With FS2004 and FSUIPC 3.03 under same pressure altitude, temperature (standard), and speed conditions, the returned value is 0.00218..Did MS changed the units or do you think it could be a FSUIPC problem I didn't check 3.04 for that but you didn't mention any change about that in your announcement This value is of paramount importance for flight tuning..of course, if missing, it can be calculated from true air density (from static ambiant temperature and pressure altitude) and TAS (I did that before you provided it in previous FS2002 FSUIPC versions) but it's much more comfortable and "safe" to have it directly (so as to be as close as possible..) Thanks Pete for your help Hervé

Jason I don't think there has been much disrespecful posts on this forum (may be some dilletante questioning which, in my opinion, is normal). I noticed that Pete, as a professional in the field, answered all questions, sometimes with "a ready tongue" but always on the best of his knowledge and taking into account the pertinence of the question. Don't think he needs any special help for calming down Regards Hervé

Thanks Right, it's not your job to test everything and I fully understand the compatibility requirements although your statement that it should remain compatible even if it's false (and even if MS corrected it) could be a background discussion ;-)..FS98 is so distant.. BTW, I will perform extensive tests with 3.03 and 3.04 and send you a report privately..I need some time for that but I'm sure you are even more busy than I am Again, thanks for your very quick answers and help Regards Hervé

Pete Thanks for these precisions. However, I still think the EGT problem for prop aicrafts remains unclear and probably will need to be reinvestigated. I always trusted the RECIP_ENGINE1_EGT_DEGR token (which is in degrees Rankine) since its value (after converting it to °F or °C) was concordant with what default MS gauges showed ; also, the value was available from FSUIPC at &H3B70 (for 1st engine) and didn't change in FSUIPC versions from 2.9xx to the latest and also didn't change in FS2004 as compared to FS2002 Comparing it to the integer mapped at &H8BE showed a problem in FS2002 (if assuming here that 16384=860°C). As an example 1524.19°R (from &3B70 - which is 1064.52°F and 573.6°C) was corresponding to an integer of 4545 at &H8BE (which is only 238.5°C)..clearly wrong.. Now it seems that FS2004 changed (corrected?) something that FSUIPC before 3.04 reported at &H8BE but it could have been OK since (using FSUIPC 3.03) both &H3B70 and &H8BE were concordant..An example 1567.71 °R was 11391 (597.8°C and 597.9 respectively..) May be, you reversed back the MS error, because panel designers who initially used the wrong &H8BE were of course far out of their initial FS2002 gauge values with the new value FS2004 provided? But who is right? I will be glad if you could compare both EGT locations (ie &H8BE and &H3B70 only applicable to prop aircrafts) and may be also compare them to some other sources, including published real EGT values in MS default aircrafts which are available in some engine data sheets and/or POH. But may be I'm wrong and missed something..let me know Regards Hervé

Pete >EGT for props. It seems that the units used for this value for props are not the same as those used for Jets. Only the latter appears compatible with FS2002 and before. Until we know more about this, I have derived an approximate conversion formula empirically so that the Prop values, too, are more like their FS2002 values< Could you here clarify..most experienced designers know that EGT, as it is reported for jet aircrafts by FS2002 token (and previous FSUIPC versions) is grossly wrong (a much better approximation from corrected N1 value was provided some time ago by Ian Kerr and Ron Freimuth and I advise all interested designers to have a look to the posts on the subject at http://www.avhistory.org/scripts/MegaBB?forumid=5 We didn't test it yet in FS2K4 due to the necessary test program updates Many "test" applications have used FSUIPC so as to discover and report what MS has programmed too badly..no more but not less..so changing the values FSUIPC will report will surely complicate the process unless we use a non-FSUIPC approach (through XML or gauge C programming) I suppose the "empirical conversion formula" you intoduced in 3.04 was suggested by some panel designers. Is it a simple temperature conversion or a more complex approximation and, if so, could you give us more details? Thanks Pete for the help you could provide on this point, so as to correctly interpret what the future FSUIPC readings mean Hervé Sors