Pete Dowson

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

I don't know. That'll be to do with the aircraft definition -- check the AIRCRAFT.CFG file, or look in the FS menu for payloads. 1400 is the start of the 61 entries, of course as you already know. It does say that, and you've just quoted it. That means the first station is at 1400, then next at 1430, etc (30 being 48 in hex). Regards Pete

Really? Where does it hang? Does it open the TrafficLook menu? Are you sure you are directing the keypresses specifically enough? Is ALT+F a hotkey for something else on that PC? No. It's an odd request actually, I've never received any requests for TrafficLook -- it was only realy intended as a demo program in any case. You can run it twice of course, once with Airborne selected and once with Ground selected, then either arrange them side-by-side, or switch bwetween them. Regards, Pete

No. I don't know how to get that information. In any case it could be more than one of them at once, through having several windows open. See the "Views - New view" menu in FS. If you are running on the same PC as FS you could find out by ennumerating the assorted child windows of FS and reading their names (titles, via GetWindowText). But even then I don't think you'd be able to tell which was the "main" window if more than one, though you could read the sizes too and "guess" that the biggest is probably the 'main' one. Right. Regards, Pete

Hi John, Doesn't this: Plane_heading = x / 65536 / 65536 * 360 give you zero or -1 every time? It would in C, as dividing a 32-bit number by 65536 effectively shifts it right 16 bits. Doing this twice shifts all 32 bits out resulting in zero (or -1 if it were negative to start with, due to sign bit propagation). If you are using VB.NET then the "Long" would be 64-bit, I think, so it wouldn't matter which order you did it in (but you'd need to set Plane_heading to zero first to make sure the top 32-bits didn't contain rubbish). Regards, Pete

I don't know VB, but in C you would get overflow errors too this way, if your "Long" is only 32 bit. In C, I use double dHeading = (Heading * 360.0) / (65536.0 * 65536.0); The use of the forms with ".0" on the right-hand side forces the calculations to be performed in floating point, so there is no overflow. I then store it in a floating point variable to retain accuracy -- however, if I only needed it to the nearest degree I'd use: Heading = (long) (((Heading * 360.0) / (65536.0 * 65536.0)) + 0.5); Note the "+ 0.5" part to round it to the nearest whole degree. If VB cannot mix floating point and fixed point (I'd be surprised!) you might get away with converting it in fixed point in a different order, to avoid the overflow. i.e. Heading = ((Heading / 65536) * 360.0) / 65536 By dividing first by one of the 65536's you "make enough room" in the 32 bits to multiply by 360 without overflow. The cost is a little loss in accuracy, but not much -- the result will still be to 1/65536ths of 360 degrees, or about 20 arc seconds. ;-) This is more about understanding arithmetic than it is about programming, you know! You need to be able to apply a little logic too. ;-) Regards, Pete

Well, this probably isn't the right place to find code, though some folks do post examples in different languages. You actually need the FSUIPC SDK, from http://www.schiratti.com/dowson. Check the programming document, there's a table in there listing what are known as "offsets". The heading is provided in offset 0580. Just read it into a 32 bit integer and convert it to degrees as documented. If the result is negative, just add 360. There are examples for assorted languages in the SDK. You should be able to use one of them, change it to read and convert the heading. Regards, Pete

Sounds like a registration Key problem. Are you using version 3.53 of FSUIPC? If you purchased your registration in 2006 you must use 3.53 or later, as announced above, and notified in the Emails from SimMarket. If you are using 3.53 (or later), or purchased your registration before 2006, Zip up the FSUIPC.KEY file from your FS Modules folder and send it to me at petedowson@btconnect.com, and I will check it for you. Regards, Pete

Okay. When you try it, assign axes in the normal way, and Ok out of the Options. Then edit the delay into the appropriate parameters, as shown. Note that the delays do not occur when in the options -- otherwise it would make assignment changes and calibrations mighty difficult! Regards, Pete

At a rough guess it is a function that converts metres to feet (m to f). In other words * 3.28084. Regards, Pete

Okay. There is likely to be more problems with mixed systems like that. I would nowadays advise everyone to update to WinXP if possible, since SP1 it has been far better with Networks than the Win98 family ever was. I wouldn't have said that when XP first came out -- I thought it was dreadful. But it got fixed. I am actually working on a new version of WideFS which also supports UDP. The three protocols it will then support are TCP (the IP protocol TCP/IP uses), SPX (the sequential part of IPX/SPX that I use), and UDP, which is another IP (Internet Protocol) installed with TCP/IP. The advantage of UDP is that it has much less red tape and is fast. However, its disadvantage is that the main reason it is fast is that there are no checks. It is "connection-less", meaning it sends the stuff out but doesn't know nor care if it arrives. Similarly, it doesn't care if it all arrives out of order. In a local network properly wired and working one would think that the excessive checking of TCP and SPX isn't needed, which is why I'm adding this new option. For instrumentation only it probably isn't important if the odd message goes astray, there'll be another in a short time. For control of AI aircraft (AISmooth, etc), Weather, and cockpit switches and so on, maybe it is more important to make sure everything is correct. However, WideFS itself does impose checks -- sequence numbers and sumchecks, so if it does go wrong at least you will be able to find out. On a fully XP network I am making it possible for the Server to specifiy the preferred protocol, which will be used by every client which hasn't a specific protocol assigned. This way it should be easy to run tests, comparing performance with it all TCP, then all SPX, then all UDP. However, this needs XP as it uses features not available in older systems. Regards, Pete

Yes, it will do if it is unable to respond to the clients -- please read the documentation where it explains why. This part of the log is too late -- it is where WideServer is actually reducing the number of open sockets (connections). The problems would have been earlier in the log, showing continuous connections from Clients whilst your FS was frozen. Those sorts of errors shouldn't be occurring, but they are isolated incidents and recoverable. I'd only worry if they became frequent. These problems are where the Clients are not getting anything from the Server. They time out, assume the connection is lost, and try to reconnect. It is that which (temporarily) increases the connection count, as described in the documentation. From the information you have supplied it appears that the CAUSE of the WideServer problem is FS freezing, and the EFFECT is the increasing number of connections from Clients timing out. You need to find out what is the problem with FS -- possibly a scenery, texture or traffic problem? Please ALWAYS state version numbers for any of my programs when asking for help. I could normally see these in the Logs, but you've made such small extracts I cannot do that here. Regards, Pete

No. How would that work, and why would you want it? Merely to save doing ALT+P and a few mouseclicks? Don't forget the "automatic calibration" still expects you to move your yoke etc back and forth to its extremes a few times -- and afterwards you normally need to adjust the settings manually, as, for safety, the automatic calibration wastes quite a lot of axis movement at each end (and in the centre). And surely this is something done once then forgotten. If your calibration is drifting off so often that you need to re-calibrate automatically every now and then there is something wrong somewhere. I have had PFC equipment for years and have only calibrated once or twice (except for testing new facilities on occasion). Regards, Pete

Yes, this is good enough if accuracy to 1 metre is sufficient. ;-) Regards, Pete

Your "Long" is 32-bit only then, same as your Integer. "Double" will be floating point, not fixed, it is one of thetwo standard types of floating point representations supported by the hardware. The other is 32-bit, known as "float" in C (maybe "Single" in VB6?). Yes, floating point is an entirely different format. Please look at this, which I just found by Google: http://dev.mysql.com/tech-resources/articles/visual-basic-datatypes.html Looks like you will either have to make do with 1 metre accuracy or do the stuff in two parts as I suggested. Or, of course, you could upgrade to VB.Net? ;-) Look at this (about VB.Net): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vadatLong.asp Regards, Pete

I don't really know VB data types, but I think you have an error there somewhere. You define dwResult and vertical speed as "Long", so I assume "Long" refers to a 32 bit value? If that is so, then you are reading 8 bytes into the altitude "long" which is probably 4 bytes only (i.e. 32 bit). Even if the extra 4 bytes only destroys something unimportant, and therefore doesn't crash your program, your variable "altitude" will only contain the fractional part -- which, incidentally, is unsigned not signed as you are computing it as. There are two alternatives, at least. If an accuracy of 1 metre is sufficient for your needs, then simply keep your code the same excpt read offset 0574, and don't divide by 65536 * 65536. Otherwise you need to find if VB6 supports 64-bit fixed point numbers. If so, read into one such. In C/C++ Microsoft added the type __int64 for this. There is also an extension to the C/C++ definition to allow "long long" to mean the same. Check your VB manuals. I have a brief VB.NET reference here, and that shows "Integer" as 32 bit, "Long" as 64 bit and "Short" as 16 bit. If that was true in VB6 then your code should more or less work, excepting that you should either redefine Vertical speed and dwResult as "Integer", or zero them beforehand to make sure there's no rubbish left in the unwritten high 32 bits. Maybe VB6 has no 64-bit integers, in which case you have more work to do. You will have to read the altitude in two parts -- the fraction from 0570 and the units (metres) from 574, both into Integers. You can convert both, separately, then add them -- the integer part only needs multiplying by 3.28084 to get feet. The fractional part similarly, then dividing by the 65536 * 65536 value. However, there's a problem -- the fraction isn't signed, all 32-bits are significant, and it has the same sign as the integral part (obviously, as it was really only one 64 bits number, with one sign bit at the top). I don't think VB supports unsigned integers (very bad omission), so you'd need to figure out some arithmetic manipulations to get the fraction correct. Probably something like checking if it is negative, then, if so, negate it, do the calculation, then subtract it from 1 metre (3.28084 feet by now). Once you have a (positive) fraction properly computed, you need to add it to a positive integral part, or subtract it from a negative integral part. Don't be frightened by any of this. It is really all simply logic and arithmetic. Regards, Pete

This is a well known deficiency in FS, and isn't new in this version. The way the hardware-assisted fogginess works is universal, i.e. operates on the whole view, whether up down or across, so as the visibility is gradually extended, it does so downwards too. Microsoft did try to rectify this for true fog (less than a few miles visibility), but they did this by adding a thin cloud layer on top of their visibility layer. That sort of works, but it looks even worse in my opinion, once you get higher, because the edges of that cloud are clearly defined at the cloud drawing cut-off distance. I'm hoping things will be better for visibility matters in FSX. In my opinion the best were in FS2000 -- FS2002 was dire, worse than FS2004 in this area. Meanwhile the only way to prevent it would be to have restricted visibility all the way up -- i.e. limit your maximum at altitude to the same limits as on the ground. That can result in even less realistic effects. Regards Pete

Yes, using the new facilities in the latest interim release of FSUIPC (3.538) -- see the announcements above. In fact the gear lever example is one of those I illustrate in the documentation for the new facilities, which you can also download (separately). Regards, Pete