Pete Dowson

If it is genuine freeware, and Eric doesn't object, I can make a key for it, for manual registration, and add it to the Freeware Keys list in this Forum. I'd need some more details, perhaps a copy of the gauge. Zip it and send to petedowson@btconnect.com. But I'd prefer that someone gets Eric's permission first. I don't like treading on toes. Regards, Pete

It cannot be done. Even Microsoft was asked and said there was no way at present. The closest you can get it to use the Multiplayer interface and create MP aircraft that way. Actually you are not reading it or quoting it correctly. It certainly does NOT say you can generate data for AI-traffic. Here is the relevant paragraph: As it exactly says, it exactly means that you can enter data into the TCAS tables for aircraft created by Multiplayer. The "AIBridge" program by Jose Oliveira uses this facility to allow multiplayer aircraft to be seen on TCAS when flying on-line with Squawkbox. Neither, there are no new AI planes, you cannot create them. All the facility does is put data in the table, exactly as it says. This is so that TCAS gauges reading the table will plot the aircraft. I don't think you can generate AI traffic except by creating an AI traffic BGL. AFCADs are airport and gate details, not AI traffic files. There's no traffic defined in AFCAD files. AFCAD stands for "Airport Facilities Computer Aided Design". It is a program with which you can define airport runway, taxiway and gate layouts. There is no traffic at all in AFD files. FSUIPC is not a file editor not a traffic compiler. To make or modify AFCAD files use AFCAD. If you want controllable traffic Multiplayer is the only way. AI isn't easily controllable (though FSUIPC does provide a way of sending them commands). Regards, Pete

Odd, as far as I know, no other VB programmers need to do this. In VB you can certainly have 4 digit hexadecimal numbers. In fact, for the standard 32 bit integer size you must be able to specify decimal numbers up to 8 digits. Values like &H1234ABCD and &HFEDCBA98 should be perfectly valid. I cannot see why Microsoft, in the change from VB to VB.NET would deliberately restrict hexadecimal constants to 3 digits. It makes no sense at all. I was hoping some other VB/NET users would chip in and tell you what you are doing wrong, but is seems they aren't around at present. Regards, Pete

Not &H432? I thought the prefix for hexadecimal in VB was &H. Maybe I'm wrong. And surely you can include the 0 as well if you like, for clarity: i.e. &H0432. Are you saying VB restricts hexadecimal numbers to only 3 digits? that &H124C and &H1248 are illegal? That's incredible! I really cannot believe that! If that is so you'll have to convert them to decimal. Does it allow decimal numbers bigger than 999? :o :shock: :? The more I hear about VB the wrose it seems to be! :( Pete

Ah, right. I was only being careful because, in C, only static (global) storage is initialised, the dynamic (local) stuff is just space reserved on the stack. Regards, Pete

This is because the reporting of illegal access has now been made more consistent. The gauge which isn't working ("cm_conc_TCAS.GAU") has never been provided with an access Key for FSUIPC -- in fact I've never heard of it. The only difference between 3.12 and 3.22 in this regard is that now you know about it! Regards, Pete

I assume there's an FSUIPC_Process somewhare after the Read? If so, there are only two possible answers as far as I can see. Either 1) FS doesn't have the focus when you press the key. FSUIPC is only receiving whatever FS is receiving, it isn't a universal hot key. Or 2) The key you have as ` isn't the same as on my keyboard. It's one of the keys which varies. Try programmimg something more standard first. If thast works, you need to find out what keycode your ` key gives. You could do that, for example, by programming the key in FSUIPC's Keys page then checking the code in the INI file. There is one other possibility, and that is a programming error, but from what you privide here that seems unlikely. You can check this quite easily, however, in FSInterrogate. Write your 000000DF to 3210, return focus to FS whilst FSInterrogate s scanning that DWORD, press ` and see the DWORD change to 010000DF. If you want me to check the actions between your program and FSUIPC, please log IPC reads and writes and show me an extract. Regards, Pete

Thank you very much, Sebastien. Regards, Pete

Does that work? Shouldn't you set "gsneedle" to zero before the Read, or are all variables in VB.NET zeroed for you? Pete

Yes, but so is a text file or a DOC, etc, etc. All that happens is that certain applications are associated to certain filetypes, and it is the associated application which is loaded and run. All you need to do is find the name of the application which is run to execute a .vbs, and run that with your vbs file as its parameter. Regards, Pete

Not as far as I know. maybe someone else has some ideas on this. Regards, Pete

most of the text in the document dates back to FS2000. The main exceptions are the additions since then. Rather than re-edit everything, I added another column for an "Ok" for FS2002 (or not, as the case may be), then, with FS2004, another column. These are the two rightmost columns in the table. sorry, the column headings aren't repeated on every page (not sure how to do that in Word, assuming it is possible). Anyway, you'll see Ok's in both FS2002 and FS2004 columns for all those. Sorry, you've lost me. What are H and C in this context? Pete

Well, apart from the fact that I've never heard of this scripting (is this new in WinXP?), all FSUIPC does is run the program by calling Windows with a "CreateProcess" API call. I would guess that this always needs an EXEcutable program to place into the process. The error number is the one returned by Windows. Looking it up I find: 193not a valid Win32 application. ERROR_BAD_EXE_FORMAT which confirms that a VBS file is not an executable program. I assume that there is a process (EXE) you can call to execute a VBS file, but I don't know what it is. With DOS BAT type files you had to do this sort of thing by running COMMAND.COM with the BAT filename given in the same command line after a /C: switch (I think! My memory is failing these days!). Regards, Pete

You missed Centre tanks 2 and 3, and also external tanks 1 and 2, offsets 1244-1260. These were added for FS2000 and could not fit in the original FS98 space next to the others. Best to use a search facility on the Programmer's document, it will find things which may be missed by eye. Regards, Pete

The value is not a "short" (16 bit) but a signed byte (8 bit).

The facility in FSUIPC does rely on the signal from the NDB actually being detected. If that signal isn't seen then FSUIPC cannot know what to set. I will check it here. That facility has probably lain disused for a long time -- maybe it is dependent on something in FS2000 or FS2002 not available in FS2004. BTW, it either sets the fraction to 0 or to 5, it never subtracts anything, so the fluctuation should be between xxx.0 and xxx.5 only. Just in case I cannot easily reproduce it, can you give me a specific NDB location and aircraft location so I can try it here as you have it there, please. Regards, Pete

65 is A not O. The FSUIPC control most certainly writes the A (with additional high byte bits 0x10 or 0x20, alternately, to ensure they are noticed) to the offset 542A, which is documented in the PM offsets document (on the PM website) as being the GC Keys input. You can easily prove this to yourself by using FSUIPC's Monitor facilities -- Logging page, right-hand side, offset 542A, type U16. Select hex for ease of recognition. your "A" is 41 in the low byte. If the GC needs two such keys to activate, this is a PM matter I'm afraid. All I can do is offer the facilities to drive the PM interface as it is defined. Can you refer this problem, with these details, to PM support, please? Again, I'm afraid I do nothing with these values other than write them to the documented PM offsets. According to PM documentation (and indeed my reproduction of some of it in the FSUIPC Advanced User's Guide), the addition you have to make for "Control" is not 200, as you have added, but 512. This is, indeed, 200 in hexadecimal -- but then the complete value in FSUIPC terms would be x252 (hex 52 = decimal 82). You seem to be a little mixed up over decimal and hexadecimal values here. Why is this? The documents (both the FSUIPC Advanced Guide and the PM Offsets html) are pretty clear in this area. Both give values in decimal for these. It does work fine here. Maybe you are using different PM builds to me? Check that FSUIPC is working by monitoring the locations it is writing to -- in this case 5428, again a U16 type value. Then, if this looks good, report your problem to PM. Sorry, but this is a confusing question. The facilities are programmable in FSUIPC. You cannot run FSUIPC anywhere except within FS. If you program the buttons in FSUIPC on the FS PC then they apply to PM no matter where its modules are. If your buttons are on other PCs than that running FS, WideFS (current versions) transmit the button presses to FSUIPC in the FS PC unless you have explicitly told WideClient not to scan buttons in its INI file. Regards, Pete

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