Pete Dowson

And again toobut at least I saw the error in your program! Please check the instructions for auto-registering DLLs and GAUs in the FSUIPC SDK Access Registration document. If you fix that I am convinced it will work fine, with the original name of the Gauge, in all versions of FSUIPC made this year at least. You have the key, it is even in your message above. 3.22 should be downloadable soon, but it appears Enrico is out this afternoon. Pete

No, please test with 3.22, being released today, as I asked. Information for old versions is really not a great deal of use to me. As I said, FSUIPC is changing all the time. Besides which, as I also said, there is better logging in the new version. Please check the announcements at the top of this forum. The new version has been released and will no doubt be up on the usual sites within a few hours or so. There is no big rush in any case. From now until Monday I am tied up with family matters. It is my Father's 90th birthday and we have relations converging on us from all over. One observation, however: if (FSUIPC_Write(0x8001,12,chMyKey,&dwResult)) // register my key This is completely wrong. For gauges and DLLs the data written is the 12-byte Key followed by the complete Gauge or DLL name, zero terminated. This is clearly documented in the Access Registration document in section 4. Please check. There is NO NEED to rename your gauge. Please do not. If you still have problems with 3.22 and/or the correct auto-registration code, please use the logging, as I asked. Pete

I was unable to perform any tests because your user refused to send me the Gauge to try without your permission. All I can suggest is that you re-test with FSUIPC 3.22, being released today. The FSUIPC code is being developed al the time, mostly in response to user requests. Well it sounds like you may actually have an error someplace, as there are plenty of gauges which are working fine with multiple '.' characters and auto-registration. There was only this problem with the manual method. If you think there is still a problem with the automatic method I would need a log with IPCreads and writes enabled. Be sure to use 3.22 though as I don't want to test old code -- and there are some improvements to the logging in this newer version. Forward only! It is too late for a Beta or other changes for 3.22, as I told your user. I had a deadline of today. Any further changes will await the next version. Oh, and the key is as already issued to your user. Pete

What sort of response are you expecting? If you have joystick inputs for aileron and rudder I should think they would override these controls in any case. To be honest, I've never tried or used those controls. FSUIPC just gets the list from FS, so it varies from FS version to FS version in any case. Whether those are really programmed to do anything in FS I do not know. I do know some controls don't work, some aren't even hooked up inside FS -- they are either left-overs from older versions which they forgot to delete, or they were planned and never made the final cut. Do ALT M F to get the FSUIPC options screen up, go to the Keys page, and look at the right-hand side. Find the keypress you want to delete by pressing "previous" or "next" till you see its details displayed, then click the "Delete this entry" button. OK out of it. If you check, this is actually explained in the Keys section of the User Guide, thus: Pete

Yes, but only if the tank was full when you started. Normally you only fill the tanks enough for the journey, allowing for taxiing, alternates, reserves, and so on. Only for a full range full load would you start with full tanks. If you are seeing negatives your code is wrong. If you are using signed values in your code then large numbers may seem negative. If VB doesn't support unsigned numbers then you need to work out some way of dealing with it. It isn't much use showing me VB I'm afraid, I don't know it (and from all the problems it seems to cause, I don't want to know it :wink: ). The Intel processors (in fact all processors I know) support unsigned numbers, as does C/C++ and most other languages as far as I know. Maybe some other VB programmers will help you out with this. BTW PLEASE use the supplied utilities to help you out. FSInterogate can be very instructive. It displays these things in a variety of formats and will probably show you where you are going wrong. Regards, Pete

Have you checked the values against what FS reports in the Aircraft-Fuel menu? Please do. It reports 2313 US Gallons for the centre tank! Your value of 5311 is the TOTAL capacity of all three tanks -- this is confirmed by Boeing references. The value for the level is NEVER negative. Maybe you are treating it as a signed integer when in fact it is unsigned? A percentage value ranges from 0 to 100, it cannot be negative. A 100% full tank is a large positive number, 8388608. i.e. 128 * 65536. If you treat it as an unsigned number, divide it by 65536 and 128 then you will get 1 for 100%. Multiply by 100 before dividing for a more accurately descriptive 100. Regards, Pete

It is Dowson. This is not actually true. Certainly there is a bug in the current version which terminates the name at the first dot, when input via the Application Registration dialogue. However, the entry can be made manually into the KEY file. It is certainly also true that older versions failed to self-register (via the method of writing to offset 8001) a GAUge or DLL if the filename contained more than one dot. That problem came to light on the first such gauge encountered, some time last year, and was fixed then. The ACS gauge was the first with such a filename which, because it did not contain the code to write the Key, had to be manually registered, and this was reported in the last day or two, when I was asked for a Key for it. I have corrected the Registration code in version 3.22 of FSUIPC, which is due to be released tomorrow (Friday) some time. Not being in possession of your gauge, I am unable to test this, but one of your users did do some test and recently informed me that it was solved, even before I have made this release. I could have provided the manual way (editing the .KEY file) in the Freeware Keys thread, but I felt this was possibly confusing to users and, after all, I am releasing a revised FSUIPC within a day or so of producing the Key in the first place, so there was no inordinate need. I really do not see how I could have provided better support in this case. Please ask your own user for confirmation of this. Pete

But FSMetar is probably accredited in any case. The difference in your two tests was using a VERY old version (3.03) and a very new version (3.21). Why not use 3.21 (or better, 3.22, released tomorrow) instead? you seem to be making a complicated detective story out of a simple thing. Regards, Pete

This is only because, when programming it in the FSUIPC options, it only looks for switches going from "off" to "on". There is no need to recognise them going "on" to "off" as well -- they are still the same switches, NOT different ones! The FSUIPC options page shows places for programming them both on the "press" and "release". For a toggle switch the "press" is when you switch it on, the "release" is when you switch it "off". Isn't this rather obvious? No you don't. Just program both the press and release. .That was all about LATCHING a button type switch to make it operate like a toggle switch. Your toggle switches already operate like toggle switches, don't they? They latch on or off? If they are spring loaded to centre then they are more like buttons, that is different. But if it is the GF T8 I think they are proper toggle switches already. Nonsense. Please look again. See the places where you can program a separate action for the Press and for the Release? How have you come to such an incorrect conclusion?? .There are entries corresponding to each function PM provides. I think the assorted display options on the ND are selected by the GC controls by parameter control -- see the list in the Advanced User's Guide (I just checked, STA is listed, thus: 90 STA (added Aug '03) I think you need to do more research. The PM website has an up-to-date list of all the FSUIPC controllable things, it's kept up to date by Enrico more often than I release new versions of FSUIPC, so you should look there. Version 3.22 will be released tomorrow. Please upgrade then. As far as I can see there is nothing to be "fixed" in your extensive list. You seem to be overlooking many things. Please just dig a little deeper, and especially look at what is already available. Regards, Pete

The MS Traffic Toolbox was written by the same guy who developed the Traffic parts of FS2004 in the first place, so it was easy for him. For me, finding each little scrap of inforamtion is a type of self-imposed torture, hours and hours of tracing through disassemblies of FS modules and trying to make sense of the horribly convoluted code their present day programming in C++ brings. I really don't have the time, patience nor motivation to go any depper into that specific area than I have already. I nearly got to grips with the departure and arrival times, which in my view are much more important, but failed dismally in the end. I have absolutely no idea how the gates assigned would be obtained internally. Maybe MS will make it easier in FS2006 and publish an SDK which makes this information accessible. As it is the "Air Traffic Information" part of the Panels SDK offers even less than FSUIPC! Regards, Pete

Sorry, I've no knowledge at all about FSMetar. However, version 3.03 of FSUIPC is pretty old now and is completely unsupported. Please keep up to date. The current version is 3.212 and I am releasing 3.22 this weekend. Er, how are you "unregistering" FSUIPC when you install 3.21? Are you deliberately deleting the KEY file? Please, just install the latest FSUIPC and keep up to date if possible. I cannot support old versions. Your registration is NOT just for "3.03" it is for all version 3.xx. Regards, Pete

There is no direct control of doors provided in FS that I know of. In fact the selection of doors is a problem because using the door control (the Toggle) operates the door selected by a real keypress soon after (1, 2 ...). Unfortunately you cannot combine these into one control (I've tried). If you are only concerned with the main door, then, as noted in the FSUIPC History document (and in the detailed announcements of changes at the top of this Forum), you can obtain the state of that door, at least in FS2004, at offset 3367. If you are programming some interface for your cockpit, then using this to decide on whether to issue the toggle control should give you what you want. Well, you can, of course. If you assign the control both to "press" and "release" then the toggling control will be issued when you switch it on and off. All you have to do is get it synchronised to start with. I'm afraid the reality is that very many of FS's controls are only toggles, so this synchronisation is something many of us have to do at the start of a flight. Think of it as part of your cockpit preparation. And if you adopt the good practice of closing everything down at the end of a flight, and reload the situation with those same settings next time, then even the synchronisation check won't be needed. This is the time during which it waits for the door selection (1, 2, 3, ...). I'm afraid there's no way around that except to press '1' (or send it) immediately after the control. You could do that in FSUIPC assignments, but you'd need to add that by editing the FSUIPC.INI file. The Advanced User's Guide for FSUIPC gives you enough information to do that. Regards, Pete

From what others have told me, you don't even have to ask. If you open your account the Key is apparently retrievable. No need for emails or other hassle. Regards, Pete

One thing I thought ofthere's a bug in some recent FSUIPC releases which prevent the PM "by parameter" controls from working. This has been fixed and I am releasing Version 3.22, probably Friday. I still don't know either what version of FSUIPC you are using, nor which specific PM controls you are trying to use, so I cannot be more specific, but perhaps you can try again when you get version 3.22? Please always give version numbers and precise control names and parameter values in future. It would certainly make supporting you faster and more rewarding! Regards, Pete

I've traced through what happens when you confirm a time change in the FS2004 dialogue. it seems it broadcasts a message through the chain system inside FS. I've identified the correct chain and message, and I have modified FSUIPC so, if I detect a change made to offset 023B, I send the same broadcast message. This seems to stop that frame rate slow down. I think, without the broadcast, there are parts of FS still working on the unchanged time of day, possibly duplicating textures or similar. This change will be in version 3.22 of FSUIPC, which I plan to release before the weekend, with luck. Regards, Pete

All the PM modules talk to each other via FSUIPC offsets and WideFs. The FSUIPC commands interface to that system. It doesn't matter where your modules are, provided that the WideFS link is working -- PM sees to the rest. KeySend is only for making WideClients send Key Presses to their local applications. You can try sending such keypresses, but it isn't as efficient nor really as easy to set up. If your PM MCP can control the PM ND on another PC, so can FSUIPC. The offsets are the same. However, I do not know how much of the interface documented by PM for the FSUIPC offsets also applies to the RJ. You will need to list explicitly the facilities you want to use and ask Enrico. Regards, Pete

"Last" doesn't mean anything I'm afraid. the "last" versions some folks have seen and downloaded are very old indeed. Please always quote version numbers. Hang on, let's not go too fastso, you DO see the GoFlight buttons in FSUIPC? Therefore all this stuff about WideFs, KeySends and so on is irrelevant, right? Which "PM function by parameter" are you trying to use, please? Did you try any of the ND-specific controls, the ones to operate the displays and ranges and so on? Please be specific, because some things in some builds of PM modules work and some don't. Some things don't work with some modules not present, but this again depends on the builds. And whilst I release a new version of FSUIPC monthly, if I can, Enrico releases new builds several times a week, sometimes. I'm sure this can be sorted out, but it needs explicit details and probably some help from PM. Okay, that's a good idea, but you will probably be asked to be more explicit there too. Things can be investigated but details are always needed. Regards, Pete

Oh, rightif I wanted to do that sort of thing I'd use the original Setup menu FS faces you with by default on loading -- you can select airport, aircraft, time, weather, etc there. There's a facility for loading a flight by name, and you can read the name of the current FLT too, so you can do it that way, or you can send the appropriate FS control to do it. But whether FS will use a cached copy of the file or re-read it from disk I don't know, you'd need to test it. Odd, that -- this is with both Local and Zulu time adjusted? Did you try also updating the time difference at 0246? I really have no idea what FS is doing to slow itself down, but possibly it is somehow confused? Try also to ensure that all the changes are written together. I've just tried it, and you are correct, there is a drop ..though it seems to slowly pick up again here. However, it should not drop in the first place. This is new, I think, with FS2004. I wonder if it is trying to handle both sets of textures. Maybe it needs the earlier ones "cleared" first, somehow. I might look into this more when I get some time. Seems rather odd. There's also a control (the one usially assigned to CTRL+;) -- SITUATION_RESET. I don't know if that will reload the file from disk though. You can send controls through the FSUIPC interface. Regards, Pete

What software is driving the GF displays? FSUIPC certainly doesn't -- it is merely a switch and button facility. The CRS is not a PM function, it uses the standard FS OBS1 and OBS2 facilities. Use the FS controls instead. I added "fast" versions of these recently. There was a but reported in one of the PM builds where that happened, and it was fixed by Enrico the same day. I think you need new PM builds. You may find it worthwhile to get into the PM Newsgroup and check things there, as well as post there, as it is 100% relevant to what you are doing and there's a wealth of ecperience there. Buttons can be programmed through FSUIPC, but it does not handle displays. If you want the lights and displays to operate then at present you have no choice but to use GoFlight assignments only. Sorry, that's a terribly confusing paragraph. If there's really a question there, can you re-phrase it please? I've not got one, nor do I know what it is like, but there are happy users. If you have criticisms of it why not direct them to GoFLight? On the whole I think you mainly need assistance from PM users with GoFlight units, and I do think you are more likely to find those on the PM Newsgroup. Regards, Pete

Are you seeing the Goflight buttons in FSUIPC's "Buttons" option page? If not then check what versions of WideFS and FSUIPC you are using, and that you have installed the GoFlight driver on the WideClient PC. There are all sorts of ways of doing this for Boeing amd airbus cockpits, but I don't know if they are applicable to PM's RJ also. This is a question for the PM support team, I think. You could try the PM Newsgroup -- there's a lot of experienced folks there. Not sure what you mean by that -- the PM controls through FSUIPC won't normally be by a key press. You need to clarify all this with PM please. Sorry, I don't really understand this statement. Pretty much everything that can be done with PM modules can be done through its FSUIPC interface. Those commands which are not explicitly listed in FSUIPC's drop-down are available through the assorted controls by parameter functions I added. It isn't WideFS which controls anything. You program the buttons in FSUIPC. The first step is to find out why you don't see the GoFlight buttons in FSUIPC. After you get that working (and it can only be a matter of wrong versions or missing GoFlight driver), then you assign the appropriate PM controls in FSUIPC's drop-down list. Which those are for the RJ cockpit I'm not sure. I would think they share the Boeng/Airbus controls for those which they have in common, but this is something to check with PM. Regards, Pete

The SDK contains examples of VB usage is the ZIP called "UIPC_SDK_VisualBasic.zip". There are also extras for the VB.NET programmers in another ZIP, also in the SDK. I am not familiar with VB at all, but looking at the files in the VB ZIP it certainly looks as if you should have enough there. The main example source file appears to be "General.bas". I'm not sure what all the other files are for, but I'm sure that as an experienced VB programmer already you should recognise them. Regards, Pete

This is a problem with the most recent versions and is corrected in the next version, 3.22, which will be released this weekend, I hope. The work-around for the time being is to add the line PollInterval=66 to the main [buttons] section in the FSUIPC.INI file before loading FS. This will slow down button polling a little (but not much compared to earlier versions). Just remember to remove the line when you get version 3.22 or later. Regards, Pete

That's a bit extreme isn't it? It doesn't destroy files, and Microsoft published a tool plus instructions on how to remove it and keep it away. Look at these (thanks to Katy Pluta): KB Article: http://support.microsoft.com/?kbid=841720 Download Location: http://www.microsoft.com/downloads/details.aspx?familyid=76c6de7e-1b6b-4fc3-90d4-9fa42d14cc17&displaylang=en Online version of this tool in the form of an ActiveX control here: http://www.microsoft.com/security/incident/sasser.asp You always need to keep a note of all those outside of the PC -- you never know when disaster will strike. If it isn't a virus, it could be a disk crash. Sorry, I don't keep a database nor do I issue the keys. I do the programming and the technical support. The sales and registrations are all done by the suppliers. If you bought it from SimMarket, simply go to http://www.simmarket.com, open your account there, and retrieve your key. I've been told it is quite easy to do. Regards, Pete

Two points there: 1. You can set an option in FS to use the system time instead of the Flight time. Have you tried using that? 2. In any case, it would surely be more effective to write the time you want it to load with into the default FLT file? Ah .. this is what you meant by "load FS" -- the reloading of the textures? This is not an FS reload as such. It has to reload the textures because they change according to time. No, you have to change both local and zulu time, not just one or the other. Maybe you are not getting them in correct synchronisation? Regards, Pete

Yes, that's the whole point really. Whatever language you are using, it is best to read the variables into the correct types to start with. I've searched for info on VB and for floating point there are types "Double", "Single" and "Decimal" in VB6. I don't know what "Decimal" is but I'd be amazed if Double isn't the same as C's double or FLOAT64, and "Single" C's float (FLOAT32), The only ones that may give problems in VB are the 64 bit fixed point numbers and, for some weird reason completely unfathomable to me, strings! (VB seems to have the worst most incompatible string system that could be invented, judging by the number of questions and problems this area causes). However, from the same source which gave me "Double", "Single" and "Decimal" for VB6 (the book "Visual Studio.NET for Dummies"), it seems that VB6 also supports "Long" for 64-bit FIXED point numbers (!), and Short for 16-bit numbers, as well as the common Integer for 32-bit. Otherwise, for the 4-, 2- and 1- byte values you can of course read them into a standard 32-bit Integer, but that must be initialised to zero first so that the unused bytes of the 4 are clear and don't give a false value -- some support queries have arisen from this being forgetten too. Regards, Pete