[Need Offset for "TAILHOOK UP/DOWN" command]

Hi all,

The FFX 737 series has retractable outboard landing lights by using the tailhook command in FS2002. I need to wire up my real landing light switches and would like to incorporate this. Any info on known offset or ideas would be great.

I'd actually never even heard of a Tailhook command till seeing your message, but looking in my list of FS2002 controls I see just the one, listed as:

TOGGLE_TAIL_HOOK_HANDLE 66391

At present I have absolutely no idea where this might dwell inside FS, but you could use it via the FSUIPC facility to send any controls to FS -- see offset 3110 in the Programmer's Guide.

[later]

Just glancing briefly through some of my decodes of FS innards I do see a variable called TAILHOOK POSITION, and in fact I do know (now) where to access this, so in fact I could probably map this to a new offset for you to read and write a setting, rather than simply toggling it.

However, there's really no way I can divert myself from work on FS2004 at present. If using the TOGGLE control is not adequate for your needs I suggest you write to me again about this well after FS2004 release time, say August/September, and I'll see if I can add such a facility. It doesn't look to be very much work.

Regards,

Pete

[Problem with Joystick ???]

The button settled for Rw is not the same settled for brake of course

Sorry, I thought you said "the shoot button is settled in Fs command tab to activate brake as usually".

Anyway, if it still doesn't work as expected when the button is ONLY programmed through FSUIPC, then I suspect it is set to pulse rather than hold. This may be either in the device itself, or maybe in the driver. Try just programming an action on the "Release" and see if that action is taken when you just press and hold. If so, then it sounds like it is a function set elsewhere, either in the device itself or its drivers.

You should also be able to check this in the Control Panel Game Controllers section. See what that indicates.

Maybe it is only that button affected. Try another one, perhaps, in case?

I can't really think of anything else at present I'm afraid.

Pete

[Problem with Joystick ???]

I forgot to add this:

If you REALLY want to brake as well as operate RW with the same button then you can program both functions in FSUIPC. But this would need editing in the FSUIPC.INI file. Details are in the Advanced User Guide.

Pete

[Problem with Joystick ???]

The shoot button is settled in Fs command tab to activate brake as usually

It's a really bad idea to have the same button activating FS actions as well as FSUIPC actions. I wouldn't be surprised if that is the cause of your problem. FS reads the buttons via DirectInput, FSUIPC uses the standard Windows API. It sounds like there's a conflict which makes the button look released to FSUIPC.

Pete

[FSUIPC_Process() has big delay]

When I dropped frame rate to 17, FSUIPC_Process delay jumped to ~45 ms.

When I increased frame rate to 47, FSUIPC_Process delay started to jump anywhere from 5-22 ms. And in one case, it measured 0.086 ms.

Increasing frame rate to 80 drops FSUIPC_Process delay to 1-12, with a few delays being less than 1 ms.

All sounds relatively logical. The processor load from FS itself is obviosly partly to blame, but mostly its down ot the frame cycling by the looks of things.

Pete

[NEED HELP PLEASE]

How I can configure my SAFELINE JET STUDIO console with FSUIPC???

Something in the back of my mind nagged me about this "SafeLine" thing, so I looked through the older threads. There's a thread actually entitled "SafeLine Console". Isn't this relevant to your query? Looks like it.

It seems that it was eventually confirmed there that this device is not dependent on FSUIPC, and that some folks do have problems with it, seemingly depending on the version of Windows they use.

Check that thread.

Pete

[NEED HELP PLEASE]

How I can configure my SAFELINE JET STUDIO console with FSUIPC???

I've no idea. Does Safeline Jet Studio even use FSUIPC? What is it? Maybe someone else can jump in here who might know this program. I hope so.

Pete

[FSUIPC_Process() has big delay]

I don't know how to make my function get called every frame.

One thing which might be interesting to check. As you said, the 27 mSecs you are experiencing is remarkably close to being in step with your stated FS frame rate of 30 fps. Why not try to change the frame rate and see if this affects the measured elapsed time on your thread calls? Try both limiting the frame rate (in the frame rate limiter in FS) to, say, 15 or 20, and also see what happen if you get it much higher (reduce some of the display options).

Just a thought. Of course the 27mSecs at 30 fps may be a simple fluke. But if it isn't then you've already got a way of matching the frame rate.

Regards,

Pete

[FSUIPC_Process() has big delay]

Could you tell me how to make my function get called every loop iteration in FS?

Most things in FS are called via "chains", which are, in most current versions of FS, set up and controlled by CHAIN.DLL . However, there are many different chains called for different things and it is not easy to sort out. Additionally you would have to rewrite and research this for each version of FS. I really have no idea what FS's "loop iteration" would be, there's no single thing you could pin down.

I think most people who do add-in Modules must have them operated by timer calls (SetTimer with a procedure) or by having a simple small thread which loops, and sleeps, sending a message at intervals to an invisible Window procedure in the DLL.

I don't know what you are trying to do as a DLL but I normally try to discourage having more such continuous activity running inside FS itself, which is why I strive so hard to provide a good service for external programs. The advantages of EXE's are that you can do what you like, take full advantage of all Windows facilities for processes and threads, not have to worry about different versions of FS very much (FSUIPC takes care of that), and not really have to worry about the impact your code has on FS performance -- which is a major concern for internal DLLs.

Additionally, an EXE interfacing to FSUIPC will also run on a separate PC via WideFS -- surely a really big advantage as then both your program and FS get to run better. The current versions of WideFS can easily manage to provide updated data at FS frame rates, which is surely all you need.

Regards,

Pete

[FSUIPC_Process() has big delay]

More thoughts on this.

I've only just noticed that you are calling FSUIPC from a separate thread, not the main FS thread. Correct? The Open2 method uses SendMessage. The MSDN data on this as it relates to threads says this:

"Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message."

.. so your "SendMessage" is actually behaving more like a PostMessage, just adding another item to the complete Message queue for Flight Sim's main thread (in which FSUIPC runs). This rather defeats the object of the SendMessage. FS uses the message queue very extensively in any case. Within a single thread SendMessage calls the appropriate Window procedure directly, so it is then as efficient as a direct call.

I seem to recall a time with Windows programming where you were'nt even supposed to use SendMessage between threads, only PostMessage. Looks like they've got around that by treating them the same when this arises.

Really FSUIPC cannot do anything until it receives your Message. Once it does it processes it very fast indeed. I suggest you call FSUIPC in the normal FS main thread and see what results you get then.

Pete

[FSUIPC_Process() has big delay]

I have timed FSUIPC_Process() function, the damn thing eats ~27 miliseconds each call.

You've got something wrong there. It is almost always less than 1 millisecond, not measurable with the normal timers.

But I need at least 50 times per second.

That should be easily achievable, and is actually exceeded even by some external programs which have to do Process Switching as well.

I noticed that game frame rate is also about 30. Perhaps it's not possible to call FSUIPC_Process more than once per game loop?

The data update will certainly not exceed the FS frame rate. All the parts of FSUIPC which obtain and populate the data which you are reading will be running at the FS frame rate at best (for some lesser items which involve procedural excursions into the nether parts of FS I reduce the frequency a little).

However, the IPC calls, whether via the direct WM_IPCACCESS message you are using, or by the SendMessageTimeout from another process, are dealt with immediately and involve no delays within the FS process, unless something else is taking processor time away during this period.

If fact, if you enable "Extras" logging, FSUIPC itself will Log any IPC call which takes longer that 20 mSecs. If you want it to log all the times for all the calls add a line "Debug=Please" to the [General] section of the INI, and set LogExtras to 8 (instead of Yes). But don't leave this sort of logging on, it will slow things down a little itself.

I'll donate 10 bucks if you can take 10 ms off that function call. :-)

(it's not much, but I'm not getting paid for this project)

I assure you it really isn't possible to take 10 mSecs off something that rarely gets to 1 mSec. If you are measuring more than 1 mSec consistently you have something going wrong.

Maybe it's related to the data you are reading/writing? Many of the Write requests do provoke actions in FS, which will take more time -- for instance Saving a FLT can be provoked by simply writing through FSUIPC. That will take a few milliseconds no doubt.

Pete

[FSUIPC and WideServer/client & windows xp.]

The top toolbar in FS (when activated) shows that WideServer is running and between 2 -4 connects. That is suprising as with only one other computer active I would not have thought that it would show 4 connections.

This is actually explained in the documentation. The Server is timing out and disconnecting those clients which don't send it messages and the clients are re-connecting when they time out and don't see messages from the Server. The server timeout is deliberately longer than the Clients, so these events overlap and produce what you see.

The error message in Flight Trakker is as follows:-

"Error Source: ucACARS.ACARS_ON()

Error Number: 1

Eror Description: Maybe running WideClient, but FS not running on server, or wrong FSUIPC."

4. In FS_METEO V.2 after clicking "start" the status line shows "Waiting for FSUIPC...."

Yes, these both simply mean the client is not getting responses from the Server.

********* WideServer.DLL Log [version 5.01] *********

Please upgrade to Version 5.50. I cannot support old versions. Let me know how you get on when you are up to date.

Pete

[how to create a module?]

could I get source code for EPICINFO.GAU ? it doesn't have to work, I just want to get the concept. I can probably figure things out on my own, but it's easier to use examples :-)

Sorry, it hasn't actually existed now for about 5 or maybe 6 years. For the "concept" of writing gauges, just get the Panels SDK. The one which shows how to write gauges in MSVC and has examples, not the recent XML stuff. You might need to search back for the FS98 or FS2000 one, I don't know. I've not really downloaded or looked at FS SDKs for several years.

Pete

[Scenery variables with FSUIPC]

I was wondering would it be possible to read and write scenery variables via FSUIPC? I mean those variables used in scenery designing for example animating objects and so on. Is it somehow possible?

Not in any way I know, sorry. It's an area I know little to nothing about I'm afraid. Way back in FS4 and maybe FS5 the BGL commands had facilities to access parts of the GLOBALS.DLL, which is withing the area normally addressable by FSUIPC, but that direct access from BGLs disappeared long ago.

Pete

[FSUIPC and WideServer/client & windows xp.]

I have no problem getting the client computers recognising the server computer but I cannot get any of the computers to recognise FSUIPC (ver 2.974) which is housed in the MODULES directory[\quote]

Apart from the insignificant thing that the current FSUIPC version is 2.975, there's no such thing in WideFS as "computers recognising FSUIPC". If WideClient is running then it "pretends" to be Flight Sim with FSUIPC includes, so that any applications will connect to it.

Some programs will only operate then they are getting valid data through from FS. The thing to do with them is simply start them AFTER FS is running and WideFS is communicating. This will be when FS is actually ready to fly and not before. You can use the "RunReady" parameters to get WideClient to load such programs only when the interface can supply their needs. Check the WideFS documentation for details.

The programs being loaded on the client computer is Flight Tracker (V7.0.1) and FS Meteo (ver 5.2).

Well I don't know Flight Tracker (though I have it here someplace), but I use FSMeteo every day and I know it loads okay with "RunReady".

I have searched all computers and cannot find other copies of the ini files so I am a bit at loss as to where to turn next.

Sorry, what "other copies" of what "ini" files do you need?

The client log file is as follows.

That looks fine, except there are apparently no exchanges with the Server. Was FS running? Where's the WideServer log? That might show something, don't you think?

Pete

[FS2002 Capabilities]

How do I program the speed/alt based audio cues...? I mean how to get the data and how to send back the audio?

You could try using my ESOUND module, but please be aware that I am not supporting it these days. Otherwise you would need to write a gauge. For that you'd need the FS PANELS SDK.

There may well be some other packages which can make sounds based on events. Flight Deck Companion (FDC) and Enrico Schiratti's PMSounds come to mind, though they may both be over the top for what you want. There may be others. Sorry, it isn't really something I've been interested in -- I try to replicate a real cockpit in my setup.

Also I looked inside the panel.cfg but could not determine the palce where the shift+1,2..is used.

This section (as an example) determines which [WindowNN] section is activated by each such key combination, and gives the names you see in the Views dialogue for the panel.

[Window Titles]

Window00=Main Panel

Window01=Radio Stack

Window02=GPS

Window03=Annunciator

Window04=Compass

Window05=Mini Panel

Window00 is selected by Shift+1 and so on.

Pete

[how to create a module?]

How to create FS modules? not gauges, but DLL modules. Am I supposed to use FS SDK for this? I have looked at it, but it only talks about gauges and panels. Perhaps I could do things their way, but my stuff is non-graphical. I don't need mouse input or draw.

My first "module" was a Gauge -- EPICINFO.GAU to be precise. It had no mouse input, no graphics, nothing to do with panels. It simply used the PANELs system to get itself loaded.

There is no SDK for add-in Modules. Those that are written are done by hacking into the FS code to see how to do it. But GAUges are more than halfway there. Take a look inside them and compare them to the DLLs.

Pete

[Throttle calibration question]

Is the range of values read at (e.g.) 3330 (Throttle 1 axis) the same as that expected at 088C (i.e. -4096 to 16384) assuming calibration done? Also, does FS interpret any part of the range at 088C as reverse thrust or is -4096 idle and 16384 max?

Actually the range at 088C et cetera can be -16383 to +16384. All -ve values are reverse thrust. The -4096 I show in the document was just the 'normal limit' for jet reverse as I saw it when I wrote it. In fact the maximum reverse thrust is set in the AIR file and can be more or less than that. If you have an AIR file with the max reverse set to -16383 then you can go just as fast backwards as forwards!

You can read the maximum reverse thrust in 333A. FSUIPC now calibrates reverse to that limit, and this actually changes according to the aircraft you load.

That given, I think you should be able to simply copy the value you read in 3330 into 088C, with any manipulation you want in between.

Why don't you just look at these locations using FSInterrogate? I think you'd then get a feel for what is going on. It'll all become clear .

Regards,

Pete

[Throttle calibration question]

Hmm - is this possibly doable by mere mortals using the fsuipc sdk? If I sample the pot input via Direct Input I could run it through such a table in my app. I don't have the docs in front of me - can this "digitized" data be output to fs2k2 via an axis or offset(s) in fsuipc?

Yes. In fact you don't even need to do the direct input bit yourself unless you really want to. (Actually I wouldn't use DX in any case, the ordinary joyGetPosEX calls seem perfectly adequate to me!).

If you check the Programmers Guide for FSUIPC you will see that at offsets 3328-3337 you can read the axis input values -- those read by FS itself, and at 310A you'll find switches to allow these to be disconnected from FS. Hence you can read the values yourself, manipulate them how you like, then write the results to the Throttle control areas at 088C, 0924 et cetera. This is the method you'd use for "fly-by-wire", for example, on an Airbus, where the throttle position only represents a desired "mode" not a specific throttle setting. Take care to keep replenishing the switches at 310A as, for safety reasons, FSUIPC will cancel the disconnection every so often otherwise.

Regards,

Pete

[Throttle calibration question]

On the FSUIPC joystick page for throttles I went through the steps to set and calibrate the throttles but here's the thing: They each work fine but don't line up very well with each other at the same N1 except at idle or max.

I think I could improve this by physically detaching the pot for 1 lever and moving it back a bit. However this involves pulling some nails, etc - am I missing a way to do this in the software?

No. Unless you can get pots which are really very precisely matched I don't think you can ever get them perfectly lined up. (Actually, I don't really think the real throttle levers in the aircraft are necessarily precisely aligned to get the exact same performance from the engines -- at least they don't look that way when I've been in the jump seat, especially with Auto-Throttle engaged, which it invariably is after take-off).

You can use the FSUIPC throttle sync facility to get them all doing the same thing -- that 'cheats' by copying the throttle 1 values to all the others, overriding the separate inputs. That's okay when you don't want differential thrust and all engines are working okay.

To get values the same for each physical position of the throttles, each one would need many calibration points, with a table to convert the input value to the desired output. This is actually a facility provided on EPIC cards -- each input axis is processed through a 256 byte table (the raw inputs are in the range 0-255, so this suits). I could consider something like that for a future version of FSUIPC -- I have been considering adding full axis assignment and calibration facilities in any case (by-passing the FS CFG stuff), and would certainly add this then. But I cannot consider any such addition yet -- not till well after "conquering" FS2004!

Regards,

Pete

[Reading a value from FSUIPC]

I have no idea what was causing the lag..... but it's gone away.Now my simple black compass needle follows the reading displayed on the FS2002 whisky compass perfectly.

Okay, good.

(I used the whisky compass rather than the heading just because FS2002 puts the actual heading in the whisky offset, but heading * 360 / ( 65536 * 65536) in the heading indicator offset, but now I know t works I'll change the offset and do the math to get the actual heading out.)

Don't forget the whiskey compass, being magenetic/mechanical, doesn't read accurately except when flying straight and level. If you want your compass to behave like that then that's fine, but don't rely on it in turns, climbs, descents, or at least make the appropriate allowances if you do.

If you want it instead to behave like the gyroscopic heading indicator then you should use the heading instead, but adjust it for gyro drift (offset 0C3E) for more realism.

Regards,

Pete

[Help needed w/ FS2K2 radio freq offset handling]

OK, now I need to write the function to parse the digits and then case test, etc

Okaygood luck. I'm sure you will sort it out now!

Pete

[FSinterrogate Question ?]

Using FSinterrogate.exe to display LAT, LON & ALT in TCAS. Which expression should be used to display the Factored values?

Joined find a file TCAS_FSI.zip with the Project file TCAS.FSI.

The current version of FSInterrogate unfortunately does not provide any facilities for this - the LAT LON and ALT are in 32-bit "float" format, and FSInterrogate only supports floating point in its 8-byte, 64-bit "double" or "float64" format.

Pelle was developing a new version which would inlcude this format and, at last, strings, but I think he's been far too busy with work to finish it.

Pete

[WideFS and Windows NT 4 SP6a.]

Yes, you are right, I only want to run the client on the NT server. I have downloaded WC 5.53 and edit the .ini file, bu it is still showing the same error message.

Ah yes, sorryI now see that it is much more complicated than I thought. I needed to re-code some of it to use run-time linking -- currently it needs that entry as a bound-in link, which is what is causing the error.

Sorry. forget that parameter altogether. It is gone. This version 5.531 sees if it can use the routines (they are in NT's Kernel32.dll) and if it can, it does, if it can't, it doesn't.

Pete

WideClient5531.zip

[Help needed w/ FS2K2 radio freq offset handling]

[i used the 'stock' code from the FSUIPC vb.net sdk for read/write/process/get.

I'm not saying you are in error READING the value, only in interpreting it. It is no use showing me examples of VB.anything, I'm afraid. If your code is in error I hope someone who uses this language can jump in and help you. But I am not he, sorry.

The read is successful (I convert the result to string and display) but I don't get a BCD! However hexing what I do get yields the BCD or close to it e.g. for 120.60 in COM1 I get 8288 as a result (hex of 8288 = 2060).

You are therefore not understanding what "BCD" means. 120.60 is represented in BCD by 0x2060 which is decimal 8288. so when you read 8288 this is correct for a frequency of 120.60. What can be more obvious than this? You already just proved it to yourself!!

Please use FSInterrogate where you can see the values read in all sorts of formats, all at once! Then maybe you will understand?

Thanks for the great treatise on BCD. I just need to actually FIND the BCD so I can manipulate it!

If you get 8288 in decimal as you say, this IS the BCD (Binary-Coded-Decimal) version of 2060 as in hex it is 0x2060, as you already so clearly pointed out! Why are you asking HOW to "get the BCD" when you've "got it"?????

Pete