Pete Dowson

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

Providing others can find the dtails by the subject at the top it doesn't matter. Best to choose a specific heading though -- some folks use things like "FSUIPC?" etc, which doesn't help others much. FS FlightKeeper is good, and it has lots of extras too, but it isn't free. Regards, Pete

I'm not surprised. You can't read a fixed point value into a floating point variable (Double) and expect to make any sense of it. apart from the fact that a Double is 8 bytes long (64-bit) and you are reading only 4 bytes, the format is entirely incompatible. What does the # do in 360# ?? I would expect that too, as it would happen in C too. Dividing by 65536 is like shofting right by 16 bits. Do it twice and all 32 bits you read have gone already. (JD says it doesn't happen in his VB6, which mystifies me). Why did you change to "Double" then, in the first example? Surely you know by now that is a different sort of number, and you must know after 5 years that 64 bits is more than 32 bits? Regards, Pete

Provided you aren't running the VB program in debug mode, you can apply for a free application key. I need details about the application -- the Access Registration document in the SDK explains -- see Section 4 onwards. Send the information it describes to me at petedowson@btconnect.com, along with a time you need it to work for. Regards, Pete

No, but I still don't have enough information. You are feeding me just one thing at a time! ;-) There is an option which may change things: PostKeys. Try setting the to Yes if you have it as No, or omitted. Let me know. I'm afraid I won't be able to try what you are doing now till Monday. Regards, Pete

You sent a Log to the FSInterrogate author, which he asked me to look at. The key you are using is actually a pirate one, it isn't legal. In any case, your 'mentor' should not be sharing personal keys. If extra keys are needed for school projects then I expect temporary (time limited) ones could be arranged. But it would be far better, for non-commercail developments, whether academical or not, to have specific application keys, not a user key at all. Regards, Pete

2700 ???? As an aside, not relevant to your problem, but you should not really be calling FSUIPC_Process individually for each value, as each one invokes a process switch. It is very inefficient. Do all the Reads and Writes you want to do, then the Process, then the Gets and calculations. One reason for a little inaccuracy could be here: You are assuming a whole number of lbs to the gallon. With a number as small as 6, lopping off the fractional part could cost you anything up to 16% You should keep the original and simply divide by 256 at the end, when you've got the results in units of 256ths of a lb. Why are you multiplying by 100 in these? You already converted the levels to a % between 0 and 100. If, say, the tanks were half full so these values were 50, you'd end up with a total twice the total possible. You should be using (TankLevel / 100) as the proportional multiplier, not the inverse. This sort of error isn't related to FS data or interfacing at all. You need to "dry run" your code before compiling it -- i.e. follow it through logically, with pencil and paper and hypothetical figures. You'd soon find simple errors like this then. Regards, Pete

Hmmmvery odd -- the whole system, or just one program? If so which? How are you directing the keystrokes? WideClient offsers several methods. Regards, Pete

Hmmm. Odd. The VB generated code must convert everything to floating point no matter how you couch the arithmetic then, and convert back after. Strange then that it gives an overflow when you do the multiplations first. It seems very inconsistent doesn't it? I shall never understand VB, it is too illogical. Microsoft seem to have made a lot of very odd design decisions in that language, with many inconsistencies (like extending an unwanted sign bit when you want hex 8000 or more ;-) ) Best Pete