ddawson
-
Posts
37 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by ddawson
-
-
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
-
What Windows version, please? So far, of those who have told me about this, they all all still on XP SP1 or WinXP x64. All my systems are fuly up to date and are SP2 and I cannot reprodcue the problem.
Are you running FSX on the same system? Because FSUIPC4 contains EXACTLY the same certificate checking code.
Regards
Pete
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
-
Hi Doug,
That's the procedure set up by "register_key_event_handler". I use it myself for intercepting and logging events, but I didn't know there was any way to CHANGE or STOP the events it intercepted. How's that done, please? The parameters received by the handler are simply the event and its parameter (not a pointer to them for changing), and the return is void so you cannot indicate acceptance or rejection.
Is is done somehow via the PVOID userdata parameter?
Thanks,
Pete
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
-
-
#define KEY_FIRE_ALL_GUNS (KEY_ID_MIN + 620)
#define KEY_FIRE_PRIMARY_GUNS (KEY_ID_MIN + 621)
#define KEY_FIRE_SECONDARY_GUNS (KEY_ID_MIN + 622)
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
-
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
-
Hi,
My need is to know the values of X - Y - Z accelerations ( offset: 3060 -
3068 - 3070) and Pitch - Roll - Yaw accelerations ( offset: 3078 -
3080 -3088).
I've already read the "Guide for Programmers".doc...
Can I read these offsets flying with Flight Simulator 2004
or I have to use Flight Simulator 2002?
:?:
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
-
Sorry I lost one word, should be3 written!
I know this offsets...
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
Autosave Question
in FSUIPC Support Pete Dowson Modules
Posted
The gauge is in fact watching for the SITUATION_SAVE control. I wasn't aware of any other way to achieve this.
Doug