Pete Dowson

Oh, you want a lesson in numbers? I'll have a go, but I am not a good teacher I'm afraid. You'll probably find better lessons in a Wiki article or via Google. BINARY Binary numbers, the ones actually used in computers, are made up of "bits". Each bit can only be "on" (1) or "off" (0). So, with one bit you can only count 0 then 1. With 2 bits you can count from 0 to 3, via the combination of the two bits, thus: 00 = 0 01 = 1 10 = 2 11 = 3 A binary number can have as many bits as you need, but computers generally have addressable groups of bits, as follows: BYTE = 8 bits, running from 00000000 to 11111111 (decimal 0 to 255). WORD = 16 bits DWORD = 32 bits The addresses known in FSUIPC as "offsets" actually point to BYTES, but any size data may start at that byte address. Note that in decimal, each higher digit in a number is worth 10 times the adjacent one. So Decimal 245 = (2 x 10 x 10) + (4 x 10) + (5 x 1) In Binary the same sort of thing is true, but now each digit is only worth 2 x the adjacent one. So Binary 1101 = (1 x 2 x 2 x 2) + (1 x 2 x 2) + (0 x 2) + (1 x 1) = decimal 13. Okay so far? BIT NUMBERS Documentation like that for Project Magenta often refers to "bit numbers", like "bit 0" or "bit 17". All this refers to is the position of the bit in the overall number. Most usually (but not always) bits are numbered from the bottom, the bit of value 0 or 1. So, in the example of decimal 13 above: 1 1 0 1 the bits, left to right are bits 3, 2, 1 and 0. Using this system of numbering, the VALUE of that bit in the number can be computed as 2 to the power of the bit number, like 2^N (the power should be superscripted, but i don't know how to do that here -- the ^ convention is used in programming languages). Thus. If 2^3 means "2 x 2 x 2", the 13 could be written as 2^3 + 2^2 + 2^0 (note that mathematical convention dictates that a number to the power of zero is always 1). HEXADECIMAL Writing numbers in binary all the time is laborious and error prone, so often a different number system is used -- octal (base 8) and hexadecimal (base 16). In today's PCs hex is better because most units are made up of multiple of 4 bits, and 4 bits, as we saw, have the capacity to count from 0 to 15: so 16 values in all. So, whilst you can treat hex numbers as base 16 numbers, with each more significant digit being worth 16 times the adjacent one, in cases where you are really handling bits, as here, you merely need to think of the binary number being divided into groups of 4 bits. The different values of 4 bits, from 0 to 15, are represented in hex like this: Binary 0 0 0 0 = Hex 0 = Decimal 0 Binary 0 0 0 1 = Hex 1 = Decimal 1 Binary 0 0 1 0 = Hex 2 = Decimal 2 Binary 0 0 1 1 = Hex 3 = Decimal 3 Binary 0 1 0 0 = Hex 4 = Decimal 4 Binary 0 1 0 1 = Hex 5 = Decimal 5 Binary 0 1 1 0 = Hex 6 = Decimal 6 Binary 0 1 1 1 = Hex 7 = Decimal 7 Binary 1 0 0 0 = Hex 8 = Decimal 8 Binary 1 0 0 1 = Hex 9 = Decimal 9 Binary 1 0 1 0 = Hex A = Decimal 10 Binary 1 0 1 1 = Hex B = Decimal 11 Binary 1 1 0 0 = Hex C = Decimal 12 Binary 1 1 0 1 = Hex D = Decimal 13 Binary 1 1 1 0 = Hex E = Decimal 14 Binary 1 1 1 1 = Hex F = Decimal 15 So, to convert a binary number to hex you simply divide it into groups of 4 bits (from the bottom, least significant part) and use the above equivalences. For example Binary 1 0 1 0 1 1 1 1 0 0 1 0 1 1 0 1 becomes 1 0 1 0 1 1 1 10 0 1 0 1 1 0 1 so it is hex AF2D. The reverse conversion works too. YOUR EXAMPLES You asked how we get the hex value "10000" for bit 16 and how you calculate the value "20000000" for bit 29. Now it should be easy for you: Bit 16 is the 16th bit up counting from 0, so in binary it must be (I've already divided it into 4's to save time): 1 0000 0000 0000 0000. which you can convert to hex as I showed above ---> 10000 Bit 29 is likewise the 29th bit up counting from 0: 10 0000 0000 0000 0000 0000 0000 0000 So, hex 20000000. Of course you don't need to write down all the bits. 29 divided by 4 (the number of bits in a group) is 7 remainder 1, so it has 7 hex 0's after a 2^1 group, and 2^1 = 2. CONCLUSION With my poor teaching skills I'm afraid that's as basic and clear as I can make it. If you still don't understand I hope someone else will jump in to help. Regards Pete

It needs the scenery designed to work that way. There's no general solution. Pete

I don't have a "home page", only this Forum. If you mean the list on Enrico Schiratti's "Dowson" page, I think that was made by folks asking Enrico to put their names onto it. And I didn't think it was a list of WideFS-usable programs, only those which used FSUIPC. To be able to run on a Client PC they usually need to be separate from FS -- i.e. not need access to any of FS's files. Does AI timetable need to scan the traffic BGLs in order to get some of its information? If so, then you'd probably have to set up a number of folders on your FS PC to be shared on the network, and point AI timetable at those folders. Doesn't it come with any documentation at all? That should surely tell you how to install it and make it work? If your WideFS connection is working and it is only that program not, then it most certainly sounds as if it does need normal Explorer access to FS's files. It may even be using the Registry to locate FS and the folders -- if there's no way of resolving that the only answer may be to install FS on the client PC too, so it can find the files. The fact that it knows where you are in FS means it is connecting to FS via WideFS, so evidently that is not the issue. I'm sorry, but the answer must be in the way it wants to access files. I don't think merely copying several gigabytes of BGLs will help. I'm afraid I have no idea what it might be wanting to do. Does it work okay on the FS PC? If so, and if there's no information, no options, no dialogues or parameters you can change for it which tell it where to go from a separate PC, then I think you are stuck, that it will only run on the FS PC, or a PC with a copy of FS installed. Regards Pete

Sorry, I really cannot support other people's programs. Is "AITimeTable" even supposed to work via WideFS? TrafficInfo.DLL is an internal module for FS itself. To use that your program would have to be running inside FS, as a module or gauge. Regards Pete

It still certainly sounds like you are suffering from the rather over-strict timeout checks I put into FSUIPC 3.96. I would strongly advise you to replace the DLL with the later one from the Updates and other Goodies announcement above. There's absolutely no difference. Are you sure you don't have interference occurring from assignments in FS? You must not have the same axes or buttons assigned in both FS and FSUIPC. Only one or the other, or they will certainly interfere with each other. Sensitivity is rather a meaningless word without more context. The "slope" facilities allow you to make a control less responsive in the the centre areas and more in the extremes, or vice versa. For controls without centres the facility allows the response to vary along the range, more to less or less to more. Either way, the calibration ensures that all extremes can be reached. If by "less sensitivity" you mean "limited range" then, no, FSUIPC does not offer you that. It should never be needed. The range of a control is determined by the aircraft modeller. Regards Pete

You'd need to write a driver to handle it, then. Yes, certainly. It might not even be that complicated. The Lua plug-in facilities in FSUIPC provide full Windows socket support, courtesy of the built-in LuaSocket package. Please check out the examples provided, especially the one linking to copies of FS together, one as Master the other as Slave, all via two quite simple short Lua programs. The program you write, whether a Lua plug-in or a fully-fledged external interface program, does not have to manipulate offset values for throttle or other data, though that is one way. It could send the actual FS controls, effectively emulating an assigned joystick. However, if you want to be able to use FSUIPC calibration and other manipulating facilities, there are specific offsets which you can write to which are simply treated as assignable axes by FSUIPC and would therefore get treated just as if the values were being polled via the Windows joystick interface. I can give you more advice when you've had a look and think and determined which way you want to go. Regards Pete

Yes, and it is a good question. If you find the answer please do let me know and I'll add it as an FSUIPC offset. I've found a way to do it through SimConnect for FSX and ESP. I can't do it for FS9 or before, but if you are using FSX, let me know. I plan on adding offsets giving ICAO, Latitude, Longitude and Altitude for the 6 airports nearest the user aircraft, in order 1st to 6th. Probably in an update tomorrow (Tuesday). Regards Pete

If FSUIPC can read the joystick data through the standard Windows interface, like axis positions and button or switch pressings, then of course. Please just download the documentation and have a browse. Pete

No, other that to try uninstalling any drivers you have for all your joysticks, then re-boot, and try plugging only those two devices in, checking their numbers and retrying until you find the right sockets which will give you what you want. As far as I am aware, there is really no outside control anyone can exert on windows to force any different ID assignment than that which it, or possibly the BIOS, chooses. (You see I don't even know where it is done!). A better bet would be to get the authors of the software you want to use to change it so it accepts any valid joystick ID. Only accepting 0 and 1 seems really daft. For writing to Project Magenta? They are all documented in the PM offsets documentation -- you need to go to the PM website. Sorry, I don't understand. Are you simply saying you don't understand the documentation they provide? Sorry, I've no idea what your problem is nor whether there's even a question here. If you don't understand some term, just be specific, ask that question. It is not up to me to rewrite Project Magenta documentation for you, I do not write their software or documentation. If there's some term or phrase you don't understand, just ask. But if you want help in using Project Magenta you really need their Support. Regards Pete

I cannot guess what that error might be. you need to give me a clue. In fact what you can do is show the Installer log itself, which is why it is produced. When you get the error message, do two things: 1. Write it down so you can tell me what it is because I cannot guess, and 2. Use the file menu on the on-screen log to save it so you can paste it into a message here. That will tell us everything we need to know. No, that is perfectly normal for a 64-bit version of Windows. Regards Pete

They are only blanked is there is no joystick available with any axes -- i.e. no axes to be read. What version of FSUIPC are you using? This information is always vital. If not the latest increment, from the Updates announcement above, it may be that your joystick is timing out (taking longer to respond than expected). The timeout system was changed a few weeks ago. Please check the Announcements. Regards Pete

Thanks for confirming this, and the information on the better drivers. Regards Pete

But FSUIPC has nothing to do with any FSX windows or graphics. There's nothing wrong with the log, except that you are needlessly logging Buttons and Events, and I don't really know why you are showing it. It sounds like you have some sort of video driver problem. I've read quite a lot of things that seem to say ATI cards aren't so good with FSX -- and maybe "eyefinity" is even less so? Regards Pete

Thanks Paul. It is good to know these languages still allow such types! ;-) Best Regards Pete

No it isn't, as you certainly confirmed here: FSInterrogate clearly classifies both of those offsets as "S8", meaning "signed 8 bit" == signed BYTE. It is never bigger than 127 because you can't have a signed byte bigger than 127. You wouldn't need to any manipulation if you read it as a signed byte in the first place, but maybe the language you are using doesn't allow that? Either way, you posted complaints in this thread as if the values are wrong, when in fact it is just your misinterpretation. Regards Pete

Not surprising if XFSUIPC emulates FSUIPC well enough. I'm not surprised -- it would need the author to write a button assignment interface using GFDev.DLL. Ah, so there is a plug-in for it! But presumably not used by XFSUIPC. As it owns the offsets it would have to be acting on the buttons to allow it to change offsets, wouldn't it? Sounds like a function of the GoFlight plug-in, then, else what could be interfering? Have you tested it without the GoFlight plug-in? I'm afraid I'm not really able to help with X-Plane stuff. Sorry. Regards Pete

No, 27 altogether. 9 by "Run", 9 by "RunReady" and 9 by "RunKey". I'm sure you'll find some are just as happy starting earlier and waiting for FS to be "ready". If not, consider making a batch file to run several with one "RunReady". Regards Pete

There is no such value as 243 in a signed byte! You are treating it as unsigned, that is why it looks wrong! The range of values you can have in a signed byte is -128 to +127. A signed value of -1 will look like 255 if you treat it as unsigned -- the pattern of bits for both is the same, i.e. 11111111. Please do think about the types of variables you are using. When reading a signed value declare the receiving variable as signed. If you read one byte into a 32 bit integer you will have to sign-extend it yourself, but in C or C++ you just declare the receiving variable as "signed BYTE" or "signed char". Regards Pete

They don't seem so "strange" to me. I think they are simply a measure. All FSUIPC does is copy what it gets from FS. The documentation of -127 to +127 as the (typical) range came from an original FS95 or FS98 document, written by folks who simply observed the range of values they got. What is actually the problem? If you get a value slightly outside the range, treat it as the limit. I expect that's what the FS internal gauges do. If you think about comparisons with the real world equivalents, these are simply measurements of a signal strength or similar. Before FSX and its SimConnect SDK was published we only had hacker's findings to go by. In the SimConnect SDK these are defined more explicitly: 0C48 is a copy of this: NAV CDI:index CDI needle deflection (+/- 127) 0C49 is a copy of this: NAV GSI:index Glideslope needle deflection (+/- 119). Note that this provides only 8 bit precision, whereas NAV GLIDE SLOPE ERROR provides 32 bit floating point precision. Note that currently FSUIPC4 doesn't supply the "NAV GLIDE SLOPE ERROR", because no one ever asked for it. It seems therefore that the documentation for offset 0C49 should say -119 to +119 instead of the 127 limits (though maybe that would upset you further because of the 138 you received?). Nevertheless I will at least update the FSUIPC4 offsets list to reflect the SimConnect dox. Thanks, Regards Pete

Same sort of method. Write the heading to offset 0580. Obviously for smoothness you'd make small changes as you are still pushing back. You need to refer to the offsets lists, part of the Programmers guide in the FSUIPC SDK. Pete

You have to slowly change the Latitude/Longitude values at offsets 0560 and 0568. It didn't work before FS2004, but it's okay in FS2004, FSX and ESP. Pete

If it holds it in an "L:variable" you can access those through FSUIPC. But it seems doubtful. Regards Pete

Sorry, the Google translator seems to have made a mess of that. But if you are asking me how AES does it, sorry, I don't know. You can move the aircraft around without using slew, but I don't know if it does or not. Obviously it derives the pushback paths to be used for the scenery files -- for AES to work at an airport special scenery file data is needed. That is why the author works on each airport separately. I don't think there's any general answer. Regards Pete

Yes, and it is a good question. If you find the answer please do let me know and I'll add it as an FSUIPC offset. The only way I know at present is to use the latitude and longitude and a database, again. If you do have to resort to a database, it would be best to do a little pre-processing when your program starts. Read in the list of runways and create your internal index of rectangles (i.e. compute the four corners) sort the rectangles into Latitude and Longitude order using, say, the most south (first criteria) and westward (second criteria) corner as the index. Then your search can be made quite efficient. Regards Pete

My Google translater makes that out to say: Offset 31F4 merely operates the built-in FS pushback facilities. There are no others. If you want a more sophisticated pushback then you would have to simulate it yourself, somehow. You might like to try the add-on AES program from Aerosoft, which, for the airports it supports, has a good programmed pushback mechanism which operates correctly for the specific airport and its gates and taxiways. I'm afraid I don't know how IVAO comes into this, as that is an on-line ATC system which I wouldn't have thought would actually control your pushback for you. Regards Pete