Pete Dowson

I win either way. If it pays for my time I can and will continue, gladly. If it doesn't and sometime else takes over, I can do something else AND maybe even get some spare time too! I am not short of ways of earning money, believe me, I turn away folks. It is just that I wanted to be able to continue FSUIPC and the other things and it has proven to be a full time job for three years already, so I really don't see that changing. By all means encourage someone else to do it all, I'll gladly withdraw. Perhaps if I withdraw now and don't release FSUIPC 3 this will encourage such an alternative development more quickly. Is this what every one wants? It is starting to make me very sad that I appear to have wasted three years of my life already. Perhaps no more? Pete

Please see the documentation, where it says: "These optionally define delays, in seconds, to be executed after the corresponding RunReady parameter, above." See the word "after"? The facility is intended only to separate multiple loads. There is no point in a delay for a single program being loaded. It achieves nothing. What are you trying to do with it anyway? I added this to separate some programs which take a while to initialise and seem to take far too long when starting together -- several components of Project Magenta on the same PC, for example, or FSMeteo and Radar Contact on the same PC. I really see no point in delaying the first and only program being loaded. The "Ready" action already stops it loading till FS is ready. Regards, Pete

As I've said several times already, Freeware addons will work without you paying anything at all once there developers have applied for and received a free access key. There is no way I am going to try to extract money for use of free add-ons. you shouldn't think so little of my efforts. Personally I could accept cash and cheques, but in the latter case only in UK pounds for such small amounts. The main payment method will, however, have to be set up to work in the same way as the donation system was. I cannot run such an operation and find time to program at the same time! Pete

What's the GPL? Well, the way it is all programmed is that any application wanting services from FSUIPC needs a Key. How that key gets in the hands of the application is subject to the license, or agreement, or whatever you like to call it, between its developer or manufacturer, and me. For freeware that agreement will probably always be an arrangement to get free access keys for as long as the application remains free. Whether that needs keys which expire now and then and so need renewing, or can work with everlasting keys, really depends on the plausibility of the freeware status and some knowledge of the bona fides of the developer and/or manufacturer. Clearer? Regards, Pete

Not until the arrangements are a bit firmer. Sorry. I wouldn't worry though, really. Regards, Pete

You are misunderstanding, and mis-judging, my intentions and the efforts I have been making to ensure that al this is as fair to all that I can make it. Please think better of me if you can. Freeware programs will have a free access key to FSUIPC. Payware programs will have an access key when licensed (i.e. for a fee). The user only has to pay anything towards FSUIPC if he wants to use any of its options and facilities. It is those which have taken most of the time and effort and look like continuing to do so, once particular problems in different FS internals have been conquered. I already have a growing list of new features folks have asked for -- things like better axis assignments, finer axis calibration points (i.e. more than min/centre/max), and so on. I hope to add these over the life of Version 3. These would complement the existing keypress and button programming and joystick calibration options. All these facilities, as they are added, are what Users pay for. The *side* benefit of User purchase is that FSUIPC will then also instantly work with all add-ons, even old otherwise defunct unlicensed ones. Sorry you won't actually buy it, but if you use none of its facilities that is fully understandable, and exactly how it is intended to work. Regards, Pete

No, you misunderstand. The user pays for user facilities. The payware developer pays for the FS access he needs to FS. That will work for accredited programs no matter whether the user pays for FSUIPC or not. Freeware programs will get free access. If the user does not need any of the options and facilities in FSUIPC he does not need to purchase it. When he installs an add-on which uses FSUIPC and is licensed for it, that add-on will work. Believe me, I have thought through all the implications very thoroughly and devised the fairest system to all that I can. Well, believe me, that too is a win! If I do not have to spend any more time on any of my erstwhile free programs, I can do other things, probably more profitable. I may even find time to do some flying and even finish my model railway. I cannot lose. If it pays for my time, it continues, if it doesn't it dies and we all get to use something else instead. Please yourself. If I get a really substantial majority vote this way, I will scrap FSUIPC now and not bring out FSUIPC version 3 or any new versions of any of the other modules. If that's what every one wants, so be it. The sooner I know this the better so I can get on with other things. Life is too short to waste for too long! Regards, Pete

Sorry, but if my income from other sources had dried up a year ago, I would have taken this step then. It is the change in my circumstances that have forced this, it is nothing to do with FS2004. The onset of FS2004 is just a useful point to do it, coming a few months after my income suddenly and unexpectedly dried up. I have spent almost all my waking hours for three years on FSUIPC and associated FS add-ons. I hardly spare time to fly. It was a hobby and a pleasing one because it was interesting and fulfilling. However, when the choice came between stopping work on FSUIPC and the other modules so I could work on something which would give me some income, or making FSUIPC somehow pay its way, I opted for the latter. Would you rather I stopped? I could have done. I still can do, if that's really what folks want. Should I call for a vote on this? Please try to be fair. I *hate* having to take this step. It looks like it will turn a pleasant hobby into a dreadful drudge. And having folks sneer and snipe at me for doing so makes it worse. I really don't need it. Regards, Pete Dowson

Taking the last question frst, whether it is negative or positive is the way you look at it. It is a 32 bit value. In hexadecimal it is FDCD6A2A, As a signed value it would be the -36869590 you quote. But if you view it as unsigned it is a much larger positive number. FSInterrogate can show you both interpretations if you like. In computers values are like that -- you can treat them in many different ways. In this case you should really be treating is as an undgned, and therefore positive, 32-bit integer. However, whether you want to treat it as signed or unsigned is really irrelevant in this case -- as far as the Heading is concerned a value of -10 is the same as +350. It's a circle after all with no beginning, no end. If the value you arrive at is outside the range 0-359, just adjust it by 360's until it looks right. So, according to my calculator (-36869590 * 360) / (65536 * 65536) = -3.09 which is the very same identical heading as +356.91. If you don't believe that go look at a compass rose and think about it. Just think anti-clockwise for negative, clockwise for positive. If you prefer just to deal in positive numbers, just read the heading into an UNSIGNED integer variable and do the calculations on that. You'll get 356.9 then without messing with adding 360. All this method of storing compass values (which is an FS convention) is designed to do is to allow the most accurate value possible to be stored in the 32 bits available. So, the biggest possible direction (359.99999... degrees) occupies all of the bits (hex FFFFFFFF). Add 1 to this and you'd get the value representing 360 degrees which is the same as 0 degrees, and zero in the 32 bits. So, a 1 in the (non-existent) 33rd bit represents the non-existent value 360. The divisor in the conversion, 65536*65536 is actually just a 1 in that 33rd bit (hex 100000000), but you cannot store that value in a normal 32 bit integer, which is why it is easier to divide by 65536 twice. I suppose I've succeeded in confusing you more by now. But just think about it a while. It really is very simple, and it works. Pete

FSUIPC doesn't actually do much on FS98, it is mostly just a transparent interface. FS6IPC is the same as FSUIPC on FS98. There are exceptions. Many of the facilities I've added which are local to FSUIPC, not related to FS in particular, will work on FS98. Joystick calibration and button and key programming should work -- though you'd have to edit this in the INI. As far as FS variables are concerned, don't forget that the memory map supported by FSUIPC was designed explicitly to make FS2000 and later look like a superset of FS98. In FS98 the Globals in offsets 0000-1FFF were in those positions, in those units. That was the whole point of FSUIPC. Therefore, the FSUIPC SDK *IS* the SDK for FSUIPC, it is NOT FS-dependent! Pete

Not in FSUIPC, at least not at present. It is an interesting idea, and something I'd be willing to consider for a future update to FSUIPC -- I'm seriously thinking of adding axis assignment and scaling, etcetera, facilities in any case. Remind me later in the year. I really won't be able to consider any changes will well after FS2004 release. Pete

Sorry, there's no fix for that that I know of. You can only see if there are any video settings which will deal with it, though I never found any. I think it is supposed to be smoothed, giving a gradual change of sky colour. This was okay in FS2000 but, like most of the visibility facilities, this area certainly took a big step backwards in FS2002. Look forward to FS2004! Really there's no way FSUIPC can fix problems with video imaging. I really would have no idea how to do it in any case. All FSUIPC can do is influence the data placed into FS and read out of it. In fact this is really its prime function -- interfacing third party applications to FS. It was never intended to be Microsoft's bug fixer! Pete

I am the same, though I started with a unipunch making holes individually in paper tape in order to bootstrap code into prototype mainframes -- back in 1963, when I started as an engineering test programmer! Since then I mostly used whatever assembly code was appropriate for each mainframe I needed to write stuff for. I did have a brief encounter with Fortran, but it didn't last long. When personal computing started in the late 70's my first non-homebuilt one was a Commodore Pet and that came with MS Basic built into the firmware. That's how I came to experience a bit of Basic, but I soon got into 6502 assembler. On the Apple I used Pascal a bit, but mostly 6800 assember. I used BCPL for quite some time (a precursor to C) before changing to C, but even then still used 68000 assembler on computers like the Sinclair QL and Commodore Amiga. C is really as far removed from the real computer as I like to get. The convoluted machine level code which C++ produces frankly horrifies me! Like you, I have to boil it down to structs and functions or procedures anyway. Best, Pete

They need no conversion. They are in standard Intel 32-bit floating point format. Just read then into variables defined as such. I don't know C# or VB, but in C and C++ this is the "float" type. The Lat/Long are in degrees (with West and South negative, East and North positive), whilst the Altitude is in feet. This is exactly as documented in the Programmer's Guide, where even a suitable structure declaration for C or C++ is provided. Please check there. Pete

This is only true in versions of FS which only had one COM frequency -- i.e. all those before FS2002. Since FS2002 I provide access to COM2 and both Standby frequencies as well -- please refer to the Programmer's Guide, offsets 3118 following. Pete

Understood, but it has to have AND and OR (not that you need them for this, as I showed), or it is too limited to be called a programming language , and bit shifting doesn't need shifts if you can multiply, it is just likely to be more efficient -- though a decent optimising compiler would replace multiplication by powers of 2 with shifts in any case. I seem to rember Bill Gates' original Basic on the first personal computers had a full complement of logical operations, so I can't see that they'd all be removed. Regards, Pete

No. the value is sent as a number, a 16-bit short number in fact. You say "no binary in VB whatsoever", but this really is nonsense. Honest. There's actually no decimal -- all your integers or longs or shorts or whatever you want to call them are BINARY. Your example 1345 is represented in the computer as hex 0541 (0000 0101 0100 0001 in binary), NOT as 1345 at all. After you've converted one integer (1345) into another (hex 1345 = 4933 in decimal) that's what you have, just another number. Send that as 16 bits (2 bytes) to FSUIPC and it will work. Please play with FSInterrogate and look at the different representations it can show you, ALL from binary numbers. All that means is that the write was done. What FS makes of what you are writing is another matter. FS2000 and before wouldn't even check -- if you sent rubbish as a frequency, it would set it. And mighty odd it looked too. FS2002 checks things and won't use an invalid frequency. Reading and writing are different things. Writing is an instruction to FSUIPC to do something. Reading is reading an FS setting. They are often not the same. The image presented by FSUIPC, of an area of memory with values you can change and read, is just that, an image. It is presented for compatibility across all versions of Fs, starting with FS98 (where, in fact, the image was the reality). Pete

Hardly anything "does" BCD, it is just a convention, but all languages "do" binary -- it's the only thing computers understand when you get down to it. 0s and 1s. I don't know VB, but doesn't it handle binary ANDs, ORs and shifts of some sort? Surely. These are essential programming operations in any language. (If not, you *can* use muliplication instead of shifts). Notice that 1345 / 1000 = 1 (ignoring remainder). Shift that 1 up 12 bits (<<12 in C, I don't know VB. Else multiply it by 2^12). That gives you 0x1000 (the first digit in your desired BCD). Take the remainder of 1345/1000 -- this is 1345%1000 in C, I don't know VB. If there's no remainder function you'd do it by 1345 - 1000*(1345/1000). So you have 345. Divide by 100 and you have 3. Shift it up 8 bits (or multiply by 2^8) and you have 0x0300. Add that to your first result (0x1000) and you have 0x1300. You are half way there. I'm sure you can figure out the rest. It really is simple arithmentic, not complex programming nor mathematics. Pete

It isn't that I don't know. It is just that it is relatively complicated and it is changing. You need to set a callback via routines currently (FS2002) in CHAIN.DLL. If you analyse any of the regular FS modules (try a relatively small one if I were you) you will find places where it installs callbacks by invoking procedures in CHAIN.DLL, and, likewise, other places where these are uninstalled, before exit. Start with the Module_Init and Module_Deinit procedures they all have. If those calls aren't in those they'll be someplace close. The next problem is that there are seemingly hundreds of different chains, all running either at different regular rates (eg Time Tick, multiples of timer ticks, frames, n Frames, n times per frame, or just on special events, like weather changes). To work out which does what needs a module to link into them ALL and log them, the accurate time, and their parameters. That's what I did years ago. I've not got it now. But I think chain 19 is mostly once per framein FS2002 in any case. But things change and it's different in FS2004. Once you start venturing down this path you'll find you've got more work cut and and it is never ending. I'm not going to do it all for you. Sorry. Good luck, Pete

There's a lot of documentation supplied with FSUIPC. Doesn't any of that help you? Try the User Guide. As it says there, it is mainly just an interface into FS for other programs to use. What they might use it for I could not say, there are all sorts of applications using it for all sorts of purposes. I assume the author of the package you installed knows what he used it for, though, otherwise why would he tel you to install it? Well, if you DO have a problem with FSUIPC then it would belong here, but you only just mentioned that it was FSUIPC you were talking about. And even then, not knowing why it is needed, what it is used for, it is not really possible to understand what you've got going on. Whilst there are facilities in FSUIPC to help you get far more precise calibrations of your joysticks than you can with FS otherwise, none of those are active unless you've activated them. If all you've done is install the DLL as is and not touched any of the options then it won't be doing anything it is not told to by the package you installed. I hope the author can help. Regards, Pete

This is NOT a message from FSUIPC. FSUIPC, once running, issues no such error messages or windows whatsoever. It is an error in one of the gauges or other modules in the aircraft which manifests itself when there's already another FSUIPC-using aircraft or DLL installed. The error is from the library code they are wrongly using, a library which is intended for EXTERNAL programs using FSUIPC and which works perfectly well in that context. This error basically means that the software concerned is using the WRONG interface to FSUIPC for internal users. It is a programming error which should be corrected and which therefore should be reported to the authors -- both the authors of the Eurowings product (who I think already know about it and will probably have already issued a fix) and of whichever other program you've installed that has the same error. They could have "fixed" it by simply retrying the connection, but the method they are using is horribly inefficient in any case. And there is no excuse because the method for using FSUIPC internally has been published for many many months. Regards, Pete

There's no place to download stuff here, it is a support forum. Are you referring to one of my modules, presumably downloaded elsewhere? If so, which one, and why do you think it could be responsible? Either way, I'm afraid I do not know the aircraft you are using and would still strongly recommend you ask the author. If you do want some help here with anything of mine, it would help me to understand what you are talking about if you actually identified the "module" concerned, and explained why you think you have problems with it. On the whole none of my modules do anything unless they are told to, and certainly there's nothing which interferes with any aircraft controls unrequested. Regards, Pete

Not sure why you are posting this question here, but maybe some visitor can help. However, I think you should try asking the author of the aircraft. Regards, Pete

Check the FSUIPC Advanced Users Guide, the section on Additional "FS" Controls added by FSUIPC. There's a list of the Parameter numbers you can use with the "PM GC Controls" item. Both TCAS and WXR options are included in that list. Pete

From FSUIPC I can only get data native to FS. I don't know Flight Deck III, but many third party aircraft "do their own thing" with instrumentation, and none of it will be accessible to FSUIPC unless the authors have made it so by using the offsets I can allocate to them. Some third party developers, like those who made the Wilco 767PIC package, provide a separate way into their data -- in that case, via a separate DLL which the external program can use. I'm afraid the only way you can proceed is to approach the Flight Deck III developers and see what they can offer. Regards, Pete