Jump to content
The simFlight Network Forums

StuartWhelan

Members
  • Posts

    48
  • Joined

  • Last visited

Posts posted by StuartWhelan

  1. I have an FSUIPC accredited flight sim DLL is using the internal method to access an unregisted FSUIPC.

    Which one is that, please? I can see here if it has been given a Key. Does it register itself, or did you register it manually?

    Thanks Pete, email sent with DLL and answers to all but one of the above questions, which I forgot to answer:

    The DLL is self registering by writing to 8001.

  2. Hi Pete,

    This is one me confused for a while, here is what I believe I am seeing. :)

    I have an FSUIPC accredited flight sim DLL is using the internal method to access an unregisted FSUIPC.

    If I start up FS with my A/C set to my 767, the number of engines offset (0xAEC) reads 2. Enabling IPC Read logging shows it being read as 2, everything is fine. I then stop the IPC Read Logging.

    I then switch to a A/c with no engines, for example the default sailplane.

    FSUIPC Log shows no problems, everthing appears to be working okay..

    If you then enable IPC Reads, you get instantly get the 'One or more of the programs you are using are not accredited.' message.

    The log contains (among other things):

    Illegal read attempt: offset 0AEC, size 2

    The internal program can no longer access any FSUIPC variables.

    Changing A/C back to a powered A/c does not fix the problem...

    External programs are not effected.

    I have a log file for the session if you want to see it...

    EDIT:

    If you do not turn on IPC Read logging, you never get an error, but the internal DLL always reads 0's for the number of engines from the moment it tries to read 0xAEC on the sailplane, regardless of what plane you switch to afterwards.

  3. Hi Pete,

    I have done some more checking on this...

    I was unable to re-create the 'stuck on 3' behavour, so lets write that off as user error..

    Reading 0x3365 will reliably set bits 1 & 2 when in any menu, model or dialog, which is good.

    In Fs2002, with pause on task switch turned off, Bit 2 will sometimes stick when task switching, and may or may not get reset back to 0 at some point later on. It always resets back to 0 when FS2002 gets focus again. I did not see this behavour with FS2004.

    The 8 byte timer at 0x0310 as described above by DocNZ (Thanks for the reply Doc!) pauses perfectly for all menu and modal dialogs, EXCEPT for the FSUIPC configuration screen, in which it continues running.

    Hope this helps,

    Stuart.

  4. Hi Pete,

    Sorry to bring this one up again, I have been looking at using this value today.

    What I have noticed is this, my tests were done using FS8 and FSUIPC 2.02 on Windows XP:

    When in a menu or dialog, the value is always 3.

    When you are not in a menu or dialog, and FS is running normal, AND it is the active application, it is 0.

    If you move focus to another application, the number changes. Sometimes it is 0, sometimes is a 2, ocassionally it is 3... But FS is still running and the plane is still moving.. Eventually it seems to settle at 2.

    Does this make any sense?

  5. Hello Pete,

    Is there anyway to tell when the simulation has been paused for menu access?

    I know the pause state does not change, and all the obvious counters I can think of continue to count.

    I guess I could watch the seconds value, but its not really granular enough for me.

    I could watch the fuel consumption, but only when the engines are running...

    Any ideas would be most welcome!

  6. Odd then that there's no gauge tokens defined for anything but "Left Flaps" and "Right Flaps". I wonder how the panels manage to show these things correctly?

    My guess would be by using timings. :) Thats how I did it in the meantime. Ie, it takes 2.5 seconds to go from Flap 0 to Flap 1, etc etc.

    I've just found these variables in FS2002's SIM1.DLL

    TRAILING EDGE FLAPS0 LEFT PERCENT

    TRAILING EDGE FLAPS0 RIGHT PERCENT

    TRAILING EDGE FLAPS1 LEFT PERCENT

    TRAILING EDGE FLAPS1 RIGHT PERCENT

    LEADING EDGE FLAPS0 LEFT PERCENT

    LEADING EDGE FLAPS0 RIGHT PERCENT

    LEADING EDGE FLAPS1 LEFT PERCENT

    LEADING EDGE FLAPS1 RIGHT PERCENT

    TRAILING EDGE FLAPS0 LEFT ANGLE

    TRAILING EDGE FLAPS0 RIGHT ANGLE

    TRAILING EDGE FLAPS1 LEFT ANGLE

    TRAILING EDGE FLAPS1 RIGHT ANGLE

    LEADING EDGE FLAPS0 LEFT ANGLE

    LEADING EDGE FLAPS0 RIGHT ANGLE

    LEADING EDGE FLAPS1 LEFT ANGLE

    LEADING EDGE FLAPS1 RIGHT ANGLE

    and there are similar ones in FS2004. I can try to map these into FSUIPC's address space and see what they provide. I assume the 0 and 1 sets are inboard and outboard? If not, what?

    Yes, I would also presume that the 0 and 1 and inboard and outboard.

    Alternatively, I could try to interfere with the value going to offsets 0BE0 and 0BE4 -- "correct" them according to these other values. Though I'm really not sure how I should combine them all. Currently the offsets 0BE0 and 0BE4 are actually two of the very few still in GLOBALS.DLL and still updated directly by FS, no FSUIPC involvement.

    Hmm, this might be a bad move, I can not think how the current offsets could be corrected without possibly breaking them for other apps (if that is a consideration). The only way i can think of combining them is to do what I started to do, and read the current aircraft.cfg setting to get the resulting flap setting from each detent, and then reporting the flap pos as a detent as opposed to a single angle?

    I think it would be much easier to just make each flap variable available, and leave stitching them together as an excercise for the reader? :)

    This is applicable to FS2002 as well, so how come the first request comes two years late? Very strange.

    It is possible that most people assumed as we first did, that flaps detent 1, ie flaps 1, should result in 1 degree of flaps and the 0 in the cfg file was a error.

    It wasn't until I happened to be zoomed in on an outside view that I noticed the leading edge graphic moving and decided to investigate further.

    I tried to monitor those (2a98, 2aa8) locations, they always returned 0's, but I thought the locations might have been overridden by the 224 bytes used by 2910, hot joystick buttons.

    No! Check your arithmetic :) 2910 + E0 (=decimal 224) gets you to 29F0. I don't do silly things like that, honestly. :D

    Doh. My bad, sorry. :) I did monitor them and they did stay 0. :)

    Many thanks for your time and investigations, I apprecate it. :)

  7. Hi Pete,

    The default 777 (in fs2002 at least) has the same behavour. The leading edge flaps is defined by the aircraft.cfg as:

    From the fs2002 default 777:

    [flaps.2] //Inboard Leading Edge Slats

    type = 2 // 1 - tail, 2 - lead

    span-outboard = 0.5 // 0.0 .. 1.0

    extending-time = 4 // seconds

    flaps-position.0 = 0 // degrees

    flaps-position.1 = 0.5 // degrees

    flaps-position.2 = 0.5 // degrees

    I tried to monitor those (2a98, 2aa8) locations, they always returned 0's, but I thought the locations might have been overridden by the 224 bytes used by 2910, hot joystick buttons.

  8. Hi Pete,

    I am building an analogue flap gauge and have run into a problem.

    In a 767, at Flap 1, the Trailing Edge of the flaps do not move, only the Leading Edge.

    The trouble comes in that the flap pos reading that FSUIPC is returning seems to indicate the position of the TE flaps only, not the LE, so I can not tell if my flaps have readed Flaps 1 or not.

    I could watch the handle position and simulate the transition time, but I would rather reflect the true A/C flap positions.

    I see there are two sets of values in the gauges.h, 2a98 and 2aa8, do you know if they return different values?

    Cheers!

    Stuart.

  9. Hi Pete,

    I was wondering if you have seen anything in your investigations regarding the failing of individual gear?

    I can 'fail' all the gear by writing zero or non-zero to 0xbe8 and forcing the gear control, but writing to the individual gear positions at 0xbec and on apears to have no effect, I assume FS is just discarding them.

    Also, have you seem anything regarding the amount of force feedback being applied on controls, like yoke or rudder?

    Cheers!

    Stuart.

  10. Erk, Sorry I misread your mesage, I thought you were using an 'unoffical RW', but you are just using an early version. That should be okay.

    What versions of wideclient and wideserver ar you using?

    You INI files look okay at a glance, I will study them a bit more closely later today, and try and replicate what your doing on my systems.

  11. My guess (and it is only that) is that the internal class name or window name that wide client is using to look for roger wilco is different in your hacked apart version...

    Two things you could try:

    1 - Don't use RWon/RWoff, set a PPT key in RW, and then use the keysend facility to write to the roger.exe process, just like any other process, as described in detail in the documentation. You may need to get wide client to start roger.exe so it knows the window handle.

    2. Try the proper version of RW and see if it works, then you know for sure where the problem is, and know where to direct your energies.

  12. Hmm let us see:

    - You don't tell us what OS your using.

    - You don't tell us what version of Flight Sim you are using.

    - You don't tell us what version of FSUIPC you were using.

    - You don't tell us what version of FSUIPC you think your using now.

    - You don't tell us what version of RW you upgraded to, or how you upgraded.

    Add to this that:

    - Resounding (Roger Wilco publishers) have nothing to do with Pete, they are two very different programs.

    - Thousands of other people have upgraded Roger Wilco, and not one other person has report this problem.

    - The payware version of FSUIPC is not available yet, so Resounding would not have it.

    - Roger Wilco and Flight Sim do not interact in any way.

    And the most telling thing of all:

    You post a message with a subject that is all in caps and is followed by multiple exclamation marks, lacking in any technical detail and making wild accusations.

    My money is on the fact you have done something else to break FSUIPC, and its nothing to do with RW.

  13. Hmm, it seemed pretty easy and straight forward to me, what problem are you having?

    You go to the joystick tab page in FSUIPC.

    If you have one throttle input to control all 4 engines, then on page one you click Map to 4 throttles, then you move to page 3.

    You then Click Set, move the throttle all the way forward and click the Set button under max.

    Move the throttle to idle and click the set button under idle.

    Then move the throttle to the rev thrust setting and click the set button under rev.

    If you have 4 throttles, do the same as above for each individual throttle, and don't click the 'map to 4 throttles button'

    Cheers,

    Stuart Whelan

  14. Many thanks once again Pete!

    I did have a very good hunt through the WideFS docs before I posted, and again just now, and I can't see any of the info you just explained (whew, I hate it when I bother you for something explained in the docs. :) )

    I appreciate the time and effort that went into your explanation, it has cleared this up considerably.

    Thanks again!

    Stuart.

  15. Quick question here...

    It WideFS a simple passthrough conduit to FS, or does it cache data locally?

    Is there any 'recommended' polling frequency for applications using WideFS?

    Currently I poll ever 100ms for anything I am displaying as a gauge or numeric value, and once ever 500ms for other stuff such as local QNH, Control configuration, parking brake and altitude..

    Is there a log setting I can use to see if I am thrashing widefs?

    Okay, so that is more than one question.

  16. I am trying to use the delayready facility and am having problemsBut Eicas.exe starts straight away.

    See the word "after"?

    Doh. :)

    What are you trying to do with it anyway?

    I was having problems with an application failing to make its very first read from FSUIPC, and I thought delaying its startup may help. It turned out to be a timing issue within my appilcation, so the problem has been resolved.

    Thanks!

  17. I am trying to use the delayready facility and am having problems.

    I am using Wideclient 550 on WinXP with FS2K2 over IPX.

    In the user section of my wideclient.ini I have:

    [user]

    Log=Errors+

    DelayReady1=60

    RunReady1=c:\code\projects\eicas\eicas.exe

    But Eicas.exe starts straight away.

    In the log I get:

    ********* WideClient.DLL Log [version 5.50] *********

    Date (dmy): 14/06/03, Time 17:58:06.359: Client name is BEASTIE

    47 Attempting to connect now

    63 Connection made okay!

    219 New Client Application: "eicas" (Id=3264)

    3969 Reception maximum achieved: 0 frames/sec, 0 bytes/sec

    3969 Reception average achieved whilst connected: 1 frames/sec, 243 bytes/sec

    3969 Max receive buffer = 296, Max send depth = 0

    3969 ********* Log file closed (Buffers: MaxUsed 1, Alloc 23 Freed 23 Refused 0) *********

    Any ideas?

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.