Pete Dowson

Sorry, I do not know any VB. In the FSUIPC SDK the only examples which are mine are those in C. When you pause FS, its time stops. This has always been the case. How else could it be? What does "pause" mean otherwise? If it doesn't stop time then aircraft should still fly or fall, whatever. When you speed FS's sim rate up, time flows faster, when you slow it down it flows slower. When you pause it, it stops. Of course. I really don't understand why you'd expect otherwise? Pete

For values that can only ever be positive, you cannot have negative values unless you are storing them and using them incorrectly. For example, in a BYTE (8-bit) variable, the value 255 is positive and the value -1 is negative, but they are BOTH represented by hex FF (11111111). You need to understand that "positive" and "negative" are not absolute but dependent on the way you declare and/or use the values you have. I have no idea what Label19.Caption is, but why is the dwResult10 declared as "Long" but the "fuel10" as Integer? Is the VB Long unsigned whilst Integer is signed? And why is the place for "fuel10" provided as "VarPtr(fuel10)" whilst the return value for dwResult10 is just left as it is? Both should be pointers to the variable to receive the result -- how can one be a "VarPtr" parameter, whatever that means, whilst the other not? They should surely be on the same footing? Both are returning 32 bit values, after all. There's little difference at all. I don't know VB, but from this example I am sorry to sat that it really looks as if you do not know quite enough about it either. I do hope someone who does know a little more about it can intervene here and help you sort this out! Regards, Pete

Sorry, I don't understand. what do you mean by "whenever I tune it the fluctuation starts."? There's been no change to that (antique) facility for years. Pete

I've not changed anything in the weather area at all. When you say "the version before this one", which is that, exactly. What you see as a version may not equate to the issue sequence. Maybe you could talk to Damian about this. I'm sure that he can sort it out with me if he thinks there's been any changeas there's been no coding change in the weather area at all it is not possible for me to investigate your problems without more specific details. Regards, Pete

Oh dear, this is always the same with you. You tend to become rude and unbearable so quickly, as before in private email. Why do you think my email address is blocked to you? Excuse me, what is in any way ambiguous about the text in the documentation I supply and you seem not to want to read (as you even implied in an earlier message). This is the relevant paragraph: Don't you see that part"but a terminating zero at the end of the latter."? I don't mind the fact that you missed this point, but you don't have to be so nasty about it, as if it is all my fault that you don't read the details correctly. How did you ever learn to program if you don't notice details? No, there is no need to omit anything. There is no need for any word on that matter because it is all handled in FSUIPC. Special characters are not a problem. You are not supposed to edit the KEY file in any case, there are no instructions so to do. Please be reasonable, you are reacting quite irrationally. It is because you shoot off half-cocked like this that we stopped communicating before. Aren't you ashamed of doing the same in public? What is that supposed to mean? That you are clever? You are not showing it at present. It is not clever to post such foolish unconstructive messages. In that case I need at least the log file showing it. You seem to be the only developer to have such problems, yet you react as if I've never helped at all. I will fix things if they need fixing, but I need data to work with. Perhaps, if you had given permission for your user to send me your very worthwhile gauge in the first place this would all have been resolved by now. As it is you seem to be climbing up some wall with no good reason and without any appreciation of what is needed for correct resolution of a problem. The data in the memory you are writing to will vary. If it happens to be zero where a zero should be written you are lucky, of not you are not. If you are prepared to be more reasonable in your messages, let us continue. If you are not, please desist. I may not be responding so fast over this wekend due to family commitments, as I said earlier. Pete

Add 1 to the length so that your writes to 8001 end with the correct zero, as specified. THEN show me logs. Not before. Please refrain from trying to be so insulting, and obey the specification first. Then I will look at it. but it will certainly not be till Monday now! Pete

Is your gauge really named "ACSZuluMD11.gau". If not, use the real name, please. FSUIPC need the REAL name. You need to add 1 to the length, otherwise the zero terminator, as specified in the interface, and as mentioned in my message, is not included! Pete

I've seen them all work and run fine. But I am sorry, they are not my code and I only know the C parts. Maybe others will help you. Do you have a registered version of FSUIPC? If not, then possibly the examples aren't getting access to FSUIPC because they are not registering. Check the FSUIPC log file. Unregistered programs will get zeroes. Regards, Pete

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