ddawson

The gauge is in fact watching for the SITUATION_SAVE control. I wasn't aware of any other way to achieve this. Doug

I don't recall the exact offset address, but check in the 3050 - 3090 range. The speed values in that range are the one's you need to set. Doug Dawson

This article from Microsoft will explain why, and what you can do about it: http://www.fsinsider.com/Community/NewsOr-Not.htm Doug

********* FSUIPC, Version 3.715 by Pete Dowson ********* Verifying Certificate for "D:\fs2004\MODULES\FSUIPC.dll" now ... SUCCESS! Signature verifies okay! Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL) User Name="Doug Dawson" User Addr="douglassdawson@netscape.net" FSUIPC Key is provided WIDEFS not user registered, or expired Module base=61000000 ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E WeatherOptions(Orig)=40003605[40003605] InitDelay: 0 seconds WeatherReadInterval=4 LogOptions=0000000D DebugStatus=15 Doug

Yes, running FSUIPC4, v4.064 - seems to be working OK. I'm running WinXP, SP2. It's a reasonably fresh install. Just checked with Windows Update - it's not showing any critical updates that I need. Doug

Pete, With 3.714, I am getting this: ********* FSUIPC, Version 3.714 by Pete Dowson ********* Verifying Certificate for "D:\fs2004\MODULES\FSUIPC.dll" now ... FAILURE! "WinVerifyTrustEx" error 0x80092003: This return is non-standard, possibly specific to trust provider Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL) User Name="Doug Dawson" User Addr="douglassdawson@netscape.net" FSUIPC Key is provided WIDEFS not user registered, or expired Module base=61000000 ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E WeatherOptions(Orig)=40003605[40003605] InitDelay: 0 seconds WeatherReadInterval=4 LogOptions=00000001 DebugStatus=15 WINTRUST.DLL is version 5.131.2600.2180, dated Aug 4, 2004. Despite FSUIPC reporting in the log that it is registered, it runs in the game as unregistered. I had previously clicked on the FSUIPC certificate to install it in the certificate store. Doug Dawson

Pete, When the event being controlled is detected, measure the current position of the related control surface. Then issue an Axis Set command with the current position as the parameter. Also set a user declared control variable to allow this responding command to bypass the test. The original command will go through, but have no effect. Doug

Bob, Have a look at the GAUGE_KEY_EVENT_HANDLER function in gauges.h. The reaction to an FS control by this function is immediate. You can use it to completely inhibit user control over the flaps (or any other control surface for that matter.) Drop me a PM or e-mail if you want help with it. Doug Dawson

Keep in mind that FS will continually try to "correct" the values you are writing. Your results would seem to indicate that this process continues even when the sim is paused. Try writing the required value immediately before releasing pause. If pause is to be released by the user, you will likely have to write the values on a continuous basis as long as the sim is paused. Doug

Second "announcement" at the top of this forum... http://forums.simflight.com/viewtopic.php?t=55488 Doug

http://library.avsim.net/search.php?Sea&Go=Search Doug

They are holdovers from CFS. I think they are still active in FS9, but of course they won't do anything... Doug

Luke, XML itself is not capable of what you are after - it requires a C gauge or module as a shim. The gauge you mentioned writes values to FSUIPC offsets based on instructions from an XML gauge. If you have specific requirements in mind, drop me a note and I can let you know what can be done. Doug

Björn Have a look at the log, but I suspect that when you specify the size of the block of memory to be read, thus: sizeof(TCAS_ARR), what you are getting is the size of the pointer itself, not the size of the block of memory it points to. Also, if you read in the entire TCAS block on every gauge update, you will likely notice a bit of a frame rate hit. FSUIPC provides an array of byte elements at 0xf008 which get incremented when the relevant TCAS slot is updated. You can use these counters to determine if you need to re-read the data for a particular slot. This approach greatly reduces the amount of data that you need to request from FSUIPC. I did it like this: int j; _TCAS_DATA airborne[100]; _TCAS_DATA2 airborne2[100]; BYTE Mem[4100]; BYTE slots_changed[100]; BYTE slots_now[100]; BYTE slots_then[100]; CopyMemory( &slots_then[0], &slots_now[0], 96 ); FSUIPC_Read ( 0xf008, 96, &slots_now[0], &Result ); FSUIPC_Process(&Result); j = 0; while ( j < 96 ) { slots_changed[j] = slots_now[j] - slots_then[j]; if ( slots_changed[j] != 0 ) { FSUIPC_Read ( 0xf080 + (j * 40), 40, &airborne[j], &Result ); FSUIPC_Read ( 0xd840 + (j * 20), 20, &airborne2[j], &Result ); FSUIPC_Process(&Result); } j++; } Doug

I am one of the authors of the package in question. It was released at the beginning of January 2005. The version of FSUIPC included in the package is 3.44 and the documentation advises that the user can always obtain the current version at http://www.schiratti.com/dowson.html I have checked and none of the files in the archive are flagged as read-only. There is nothing in the archive which requires a password. My e-mail address, and that of Rob Barendregt, the co-author, are both included in the documentation if the original poster requires any further assistance. Doug Dawson

You probably need to keep track of the previous value you read. A sudden change from one update to the next will be your indication that the aircraft has hit the ground - even if the aircraft has bounced back up into the air before the Sim On Ground variable has become True. Doug

The TCAS_DATA structure is 40 bytes in size. You are attempting to read a data block consisting of of 96 of these structures - that's 3840 bytes for each of each of the FSUIPC reads. You have only allocated 1024 bytes for FSUIPC to work with. Increase the allocation accordingly. Doug

Your problem isn't with F16.gau. It is here: 24391 Client Application: "fs9" (Id=136) 24391 C:\FS2k4\fs9.exe 24391 Product="Microsoft Flight Simulator 2004 - A Century of Flight" 24391 Company="Microsoft Corporation" 24391 Illegal read attempt: offset 0B78, size 4 [P136] 24391Program or module not accredited for use with this unregistered FSUIPC Have a look at Pete's explanation in this thread: http://forums.simflight.com/viewtopic.pess+method Doug

Have another look in the .log file. You will see lines that look something like this: 97625 Module [M3] identified = "dsd_ipc2xml.GAU" 97625 READ0 [M3] 3304, 4 bytes: 00 00 00 35 97625 READ0 [M3] 3308, 4 bytes: 07 00 DE FA 97625 WRITE0 [M3] (failed, read-only!) 330A, 2 bytes: B0 04 100015 Illegal write attempt: offset 6D40, size 32 [M3] 100015Program or module not accredited for use with this unregistered FSUIPC 101406 ### IPC Message processed in 1391mSecs ### In this example, my gauge dsd_ipc2xml.gau, which does not have FSUIPC accreditation, opened communications with FSUIPC at timestamp 97625, and was identified as module [M3]. At timestamp 100015, the gauge attempted an FSUIPC write, which FSUIPC refused. You can see that the offending module is identified by the number assigned by FSUIPC - [M3]. In your log file, look for the illegal read or write attempt and find the number of the program or module making the call. If the offender is a gauge or FS module, the number will be in the form [Mx]. If the offender is an external program, the number will be in the form [Px]. Now have a look further up to find where that program or module is listed as opening communication with FSUIPC. It will be there. Doug

I think the code provided in this file will give you what you need: http://library.avsim.net/esearch.php?DLCatID=root Doug Dawson

This is not an FSUIPC issue. I was, however, able to duplicate your error. The gauge dsd_xml_sound.gau, used in this panel, requires the presence of gaugesound.dll in the main FS folder. I have attached that .dll to this post. Also, the sound files distributed with the panel must be in the main FS Sound folder. Their absence will also cause the panel to crash. Doug Dawson GaugeSound.zip

The gauge in question is TC.FuelStatusCG.gau. It does indeed date back to the days of FS98. While it does seem to work with a registered version of FSUIPC, it will of course not support the fuel tanks which have been defined in newer versions of FS. Doug

Yes, these offsets are available in FS2004. Doug Dawson

Alvaro, The controls you will want for use through offset 3110 are: KEY_PANEL_ID_TOGGLE 66506 KEY_PANEL_ID_OPEN 66507 KEY_PANEL_ID_CLOSE 66508 Each takes, as a parameter, the ID number of the panel window you wish to control. There is a function defined in GAUGES.H to determine if a panel window is visible or not, but it is just that - a function, not an FS Key Event. Doug Dawson

The offsets quoted above are correct, and they do work. Keep in mind you need to write 4 bytes. For the center tank, you need something like: FSUIPC_Write ( 0x0B74, 4, &Your_UINT32_Variable, &Result ); Doug Dawson