Pete Dowson

Ah, I see. In C a constant can be forced to be a double by simply adding a decimal part, thus 360.0 The VB "#" method is a bit like having to use "F" for float (the 32-bit version), as in 360.0F, or even 360F. Thanks, Pete

The explanation is in the Log: "Timed out response: connection assumed lost!" The poor client is not getting anything from the Server and times out after 18 seconds (the default for this). Is this happening on all Clients? Have you looked at the WideServer Log. Perhaps that shows a problem there? Pete

Wow, you read my answer too quickly! I amended it again when I saw some other errors. Please re-read it. Pete

No! You do all the reads and writes, as you like. Then only ONE process! The reads and writes (and gets) take almost zero time, the Process calls cause a process switch and take maybe hundreds of milliseconds each! One process call performs ALL your reads and writes in one call! Delete most of the code! For example: See? The single Process processes all of the queued Reads and Writes. That's its job, to pass ALL of your requests as one batch to FS! The only limit is the total size -- only 31000 or so bytes can be handled in any one Process request, counting the data plus red tape overhead of 16 bytes per read or write. Your list is nowhere near. Since you never process any of the results, why have a separate variable (r1 ...) for each? Even if you did check it, you should do so immediately, so you still only need one variable! Of course you could do the sequential Reads and Gets in a loop if you put the t1's to tn's in an array. Also, there's something wrong with your code in any case. You have but you are only reading an Integer into t1. The others are 64-bit doubles, as you seem to have recognised in the Reads by making the size 8 bytes. BTW I'm no expert, but doesn't the ZFW, by definition, already include all the payload, merely excluding the Fuel? Pete

It's actually FSUIPC, and you should always report the version number please. If it isn't the latest (3.53 or later at present), then update it first. Calibrating throttles will not affect the mixture. It sounds like you've calibrated the Reverser, which, as documented, uses the Mixture control by default -- though not the "Engine 1 Mixture Control" but the generic Mixture control, for all engines. If you fly props as well as jets you need to ensure that the option to have the reverser activated for jets only is selected. The only other possibility, which is nothing to do with FSUIPC at all, is that you have the Sensitivity in FS turned right down on that axis. Make sure the slider to well to the right. By the way, if you get yourself in a muddle with FSUIPC options and settings you only have to delete the FSUIPC.INI file, or edit it and delete just the Joystick calibration sections, and start again. Regards Pete

Doesn't the elevator trim work on that in a helicopter? No, that would be an horrendous thing to try to do in FSUIPC, the way things are organised. The whole calibration computations would be thrown out. The only thing I can think of is to use the axis assignment facilities to assign your control NOT to any analogue input at all, but to a series of INC/DEC controls (i.e. using the right-hand side of the assignment facility). Program a centre zone which sends the axis control with a zero, and a succession of zones either size which send one or more INCs or DECS (depending on direction), with probably a repeat action at the extremes. It's messy but you'd end up with something more like keyboard control but using the stick. This is almost exactly what elevator trim does, in effect -- I'm very surprised it doesn't apply to helicopters. Have you tried applying a trim axis? Regards, Pete

No. I have reproduced the problems here. It looks like Windows cannot handle either the record/playback or PostMessage systems for keys which cause programs to change from modeless to modal (as when entering menus). I have tried tracing it, and using Spy to check on the progress of the messages into the program, and Windows gets itself knotted and all of them screw up. The logic in WideClient is fine, it is definitely sending all the right things. I'm afraid there doesn't appear to be any solutionunless: The only way which seems to work is the directionless "SendInput" method, as I use in FS itself from FSUIPC. For this you'd have to leave off the "RunReady1" parts on the KeySend lines, and specify UseSendInput. The problem with that is that you must be sure to leave Traffic Look with the keyboard focus, otherwise the keystrokes will go elsewhere. My advise is to have both ground and airborne displays on view, side by side, as set up in the default INI I supply. Regards, Pete

I really have no idea how you get an overflow. You need to debug your code to see where it is occurring. It is nothing whatsoever to do with FSUIPC. Your code shows a Subroutine in which, everytime it is called, Opens a link to FSUIPC (this involves seriously heavy calls to Windows to create a memory mapped file and set a unique Atom for it), writes just one value, with one Process call, then closes the link, which closes the memory maped file. I really do hope this is not indicative of how you are programming, as yours will be the most inefficient program ever to interface to FSUIPC! :-( If the VB.NET code you are using (presumably from the examples in the SDK) follows the C source examples I provide, then the only purpose of writing to 330A (a read-only location) is to make sure I get an entry in the log showing the Version number of my original C source code in the SDK. The reason you get several is because you are repeatedly re-opening the link to FSUIPC. See above. The VB.NET debugger doesn't even show you the line which gives the overflow error? Are you sure? It must be the worst debugger in the world then, or you are seriously misusing it! If it won't point to the line, try single stepping through. Surely it supports single stepping? You have all the source code, and the error is occurring in your program. Sorry, I have to give up helping at this point. It really sounds like you have chosen the wrong language altogether if it is so bad as you make out. :-( Regards, Pete

If it is transferring files, it certainly isn't through wideFS or FSUIPC. Regards, Pete

Please check the documentation! WideFS is just an extension to the FSUIPC interface for applications talking to FS. FSNav doesn't use FSUIPC. The modules folder is a folder in FS's folder, it is nothing whatsoever to do with anything WideFS does, except that it is where add-in modules for FS, like WideServer.DLL and FSUIPC.DLL (and FSNav.DLL) go. Are you using ANY program which interfaces to FSUIPC? If not, then WideFS really isn't much use to you. You should read the details of the program before purchase. From what you are saying, all you are after is a way of transferring files from one place to another. Windows Explorer does that. See "My Network Places" in Windows Explorer, or try mapping a drive to wherever you want your files to go. Regards, Pete

I have no idea about how you'd use either of them, including the second one, but in FSUIPC all data is simply an array of bytes, exactly that. I don't know VB.NET, but I assume you can use the first one for INTEGERS (it does say "Param As Integer"), which are 32-bit (4 byte) -- but this offset is a "short" (16-bit integer). Aren't there any other choices? I should think it would be a bit like C++ with 'overloaded' procedures, the compiler choosing the correct one by the type of parameters. However, if you use a constant like 64 or 8000 how can it tell what type? Did you check the logging? Did you try debugging? I'm sure there must be some references for VB.NET that explain how to use the language? Regards, Pete

Free offsets? You should really apply for an allocation, as a "free-for-all" use of offsets which don't appear to be allocated will most certainly result in clashes between applications in the long run. What sort of "noticeable delay". I have 8 PCs in regular use n my cockpit, all connected by wideFS and running assorted parts of Project Magenta. The "delay" between operating a switch and seeing the result is occasionally there, but it is minimal. Certainly acceptable for switches and dials/rotaries, and even analogue flight controls unless it is a jet fighter you are flying (where response ineeds to be absolutely instantaneous). Project Magenta cockpits all over the world use WideFS. If you have problems with WideFS please check the Log files -- both for WideServer and WideClient. You can also display the WideFS frame rate on the WideClient title bar, for monitoring in real time. In most circumstances you should be able to easily maintain the same sort of frame rate as FS -- but keep the latter down to something reasonable, to suit all of your clients. I usually set the FS Frame Rate limiter to 25 or 30, though on my main 8 PC system (which has all fast PCs, none less than 2GHz, and a firewire network, 400mbps) I set it at 50 or 60. Running everything with WinXP SP1 (at minimum) helps too. Regards Pete

I don't understand VB.NET. Why have you defined a "ThrottleValue" variable and not referred to it in the FSUIPC_Write? The FSUIPC interface which I programmed has a pointer to data in memory, the only literal (numeric) value is the number of bytes being transferred. Your code doesn't seem to match anything FSUIPC might understand. Where in your Write is the size of the value being written? How does the system know whether you want to write one byte, 2, 3, 4 or 5000? Surely your value "64" should be in your variable "ThrottleValue"? BTW it is extremely (EXTREMELY) inefficient to use FSUIPC_Process for one variable at a time. You should collect all the things you want to read or write and do them all in one process. What arithmetic operation is going on? Maybe whatever your "FSUIPC_Write" routine does, it only handles one byte, in which case, obviously, 8000 won't fit. As I said above, you have no length. How does it know? But you are not using variables. "64" and "8000" are NOT variables! You have declared a variable, but you are not even using it! Please have a look in your VB.NET system and see if there is a Debugger you can use to trace through. It should tell you immediately where your overflow is. Debuggers are very useful when developing programs. Also, take a look at FSUIPC options. Check the "Logging" tab. If you enable IPC read and write logging you will be able to see EXACTLY what you are achieving over the FSUIPC interface. IUt will show the data actually being sent. You may be surprised. Regards, Pete

Best to make assignments using the Keys or Buttons sections in the FS options, on screen, not by editing the FSUIPC.INI file. I would ignore the Advanced User's guide until you are less of a 'newbie'! ;-) The Keys and Buttons sections are easy and explained in the user documentation, not the Advanced guide. Regards, Pete

You don't have to, it isn't mandatory. It depends what you want to use the heading you are reading for. It is a True heading, not a Magnetic one, which is good for navigation by maps but it won't match your magnetic compass heading. The magnetic variation gives you the difference between them. It varies all over the world. Regards, Pete

Ah. Good. Well, in general it is usually better to provide the ServerName rather than the IPaddress, as you are less likely to change that. What version of WideFS are you using? Are both Server and Client running WinXP? With the current version of WideFS and XP all round you should never need to specify server name, IP address, ort anything. No, there's no need, thank you all the same. Regards, Pete

There's no possible values as 49153 or 65519 in a 16-bit signed number. The capacity of 16 bits won't allow it -- you are treating the value incorrectly, as unsigned! As documented, the range is -16384 to +16383. Your "49153" is actually -16383 and "65519" is -17. What's an "elevator rudder"? As to how FS or specific add-on aircraft animate the surfaces visually I have no idea. It doesn't matter to me, as pilot, because I can't see them from the cockpit. But you should always test on a default aircraft. If the PMDG animations are not as good as you would expect you need to complain to PMDG. Otherwise I assume it is an FS limitation. But I don't think the animations have any bearing on the actual flight characteristics. Regards, Pete

Some weather programs (FSMeteo and ActiveSky come to mind) actually control the FSUIPC settings themselves, to save you doing it in FSUIPC. Assuming FSMetar doesn't do this, really it is up to you to select what you prefer. Certain wind smoothing and graduated visibility are among the facilities you should check, but others, such as the surface limits on visibility and the optional addition of an occasional upper cirrus layer, are purely user preferences. Just experiment. I do discuss that, where it matters, in the documentation, and you will also see that the weather options are actually different between the two in any case, so what you see is what is applicable. Regards, Pete

It isn't an error message from either WideFS or FSUIPC, but the number 14 probably comes from the interface in the program you are using. If they are using the code I provide in the FSUIPC software kit, then "14" means "Maybe running on WideClient, but FS not running on Server, or wrong FSUIPC". WideFS doesn't use COM ports and a null modem cable, unless that's how you Networked your PCs (very unlikely, far too slow). You must mean GPSout, not WideFS? Why would Google Earth want your FS IP address? If you are using WideFS it is WideFS which talks to FS, not Google Earth's interface. You sound very confused. Does the WideClient title bar say it is Connected? If not you have a Network problem -- look at the WideClient and WideServer log files. If it does, then the most likely thing wrong is an illegal or otherwise bad FSUIPC or WideFS user registration key. Have you got more than one email address, as I cannot find the one you use here amongst the valid registrations? ZIP up your FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll check it. Regards, Pete

Why awkward? It operates as a proportion of max deflection (FS doesn't appear to operate "trim tabs" as such, and the range of the trim seems to equate to the range of the elevator itself. The only other value is the one at 2EA0, which is a double floating point value giving the angle in radians. Not sure that's going to be any easier for you than a simple integer! Regards, Pete

It is on the 4 throttles page that you calibrate your separate throttles. You only have two of those -- 1 and 2. Just calibrate them , first. When you are happy with the calibration, then simply click the 1->12, 2->34 option and finish. You do not calibrate 3 and 4 (you haven't got them) and you do not need to worry about them. If you followed the steps as documented this would not have confused you. This is part of the purpose of documentation, to keep things clear! But you only had to read the paragraph in the documentation BEFORE the one you quoted here earlierI don't understand why you ignored that when it described exactly what you needed. These facilities have been in FSUIPC now for many years, and this is the first time I am aware of anyone thinking that those 12, 34 notations meant twelve and thirty-four! I wonder how I might accomplish that? ;-) Anyway, I'm glad you have got it working as you wanted now. Regards, Pete

What version of FSUIPC? Do you mean the new Axis Assignment facilities in the interim versions (see above)? And what sort of differences in the values are you seeing? Mostly changes, if they arise from the hardware, are caused by temperatire and humidity variations. The other possibility is deterioration of the potentiometer (wipers wearing down or dirt on the wire windings or carbon surface). If you've not tried yet, look at the Axis Assignment facilities in the new interim version of FSUIPC. These won't fix a failing joystick, but it may help you see more precisely what is happening. Regards, Pete

I don't think any of the "sparXX" offsets work in FS2004 in any case. Are you writing for FS2002 or before? The only ones common to FS98-FS2004 are the "usr" ones (offsets 0DD6 to 0DDE). I am sorry but I have no idea how you'd use them. I would guess that in the BGL for a scenery you can read and write these variables, and in an application program interfacing to FSUIPC you can do so too -- hence communication between the scenery and application programs. Regards, Pete

Aha! John, I just saw the solution to my confusion! The "Plane_heading" variable you are using IS defined as floating point ("Single", I'm fairly certain, is a 32-bit floating point variable type, the same as "float" in C). THIS is why you don't get zero or -1! The one crucial line I didn't notice in the previous post with that formula is Public Function Plane_heading() As Single I can sleep now! ;-) Pete

i.e zero as near as dammit. But that isn't surprising if you still have Heading defined as a Double. You cannot read a 32 bit fixed point number into a 64 bit floating point variable and expect to make any sense of it. I already pointed this out!! Apologies for one mistake in my example earlier -- I should have typed 360 not 360.0. The latter is for floating point, which you weren't using! But please re-read my previous reply, where I already pointed out your mistake in defining Heading as a Double. You must still be doing that to get a result like 4.94065645841247E-323! Pete