StuartWhelan

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.

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.

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.

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?

Guilty as charged. :) I read through the SDK very carefully, but not the FSUIPC release notes. I shall do so now. :oops: Can I request full details here? :) Many thanks!

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!

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. Yes, I would also presume that the 0 and 1 and inboard and outboard. 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? :) 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. 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. :)

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: 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.

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.

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.

Hi Pete, Any idea if EpicInfo will work with FS2004 as it stands, and if not, do you have plans to make it work at some later stage? Cheers! Stuart.

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.

Awesome, I have set up a desposable email address for the pics: legowing@simhardware.com I am a C++ programmer, and I write a lot of code to interface into flightsim using FSUIPC (If fact, it is about to become my full time job) I would be happy to work with you to help you interface your wing to FS, its a fantastic project. Will look forward to seeing the pics!

Sounds really interesting, got any pictures or anything?

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.