Pete Dowson

That's not good -- a new key won't solve anything. I need some more details. First, make sure please that they are using the latest version of FSUIPC. I really can't help with older versions. The current version is 3.22. You will notice from reading the "history" document, or browsing all the information on revisions in each successive release in the Announcement at the top of this forum, that there have been many changes and improvements in the whole area of registration, especially for gauges and modules. If, using the latest version of FSUIPC, there are still any problems I need to see the FSUIPC Log for this, with IPC read and write logging enabled. Regards, Pete

Okay. Glad you got it resolved. But the IPC read/write logging should have helped you in any version, that's been there for years. It was how I developed FSUIPC for FS2000 in the first place -- running FSUIPC on FS98 to compare results. They aren't my files, but I'll just have a look to see if I can understand what you mean. (Why is C# so unlike C? :( ). [LATER]: Your quote from the original: int idx; for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) { IPC[idx] = param[idx]; //xfer byte array to IPC managed FifO buffer } seems in error, for sure, as "idx" and "i" are mixed up in the 'for' statement. But the currently released version (a file called "fsuipc.cs" in the inner Zip "UIPC_SDK_CSHARP Revision 1.11") has these lines: for ( idx = (Token + 4) ; idx < (Token + dwSize + 3); idx++) { IPC[idx] = param[idx - Token - 4]; //xfer byte array to IPC managed FifO buffer } This looks to have almost the same effect as your replacement, EXCEPT that it seems to copy one byte less (to "Token+dwSize+3" instead of +4). Your code is certainly clearer though, and I don't understand why a new loop variable (idx) was introduced when there's a perfectly good "i" already available. I'll take the liberty of inserting your code in place of the one there, ready for a revision 1.12. Thanks. Why is C# so horribly long-winded and complicated compared to straight C? Is this all to do with it being "managed"? Why would anyone want it? Regards, Pete

Folks who don't have problems don't tend to write, so mostly, when you visit places like this, of course, you read mainly about problems. Always make sure you have the latest version of FSUIPC -- current is 3.22. There are no known outstanding problems at all with Key programming in this version. Well, the term "mapping" in this context isn't mine. I always refer to it as key programming. And this has its own page in the FSUIPC options, called "Keys". There is a whole section in the FSUIPC User Guide about this page, and yet more (advanced) information in the Advanced User's Guide. However, you are not wanting Key programming or even key mapping, as you are using a hardware module with buttons and knobs, aren't you? The Keys part of FSUIPC is for programming keys on your keyboard. You want the Buttons section, to let you program your buttons, switches and knobs. Again, this has its own options page, and sections in both User Guide and Advanced User guide. I suggest that, before you start anything, you at least peruse the User Guide. Perhaps you should have done that before paying for a Registration, in case you decide it isn't for you after all? :wink: Regards, Pete

No, not particularly a misnomer. It's just that you made no mention of such things in the original query. It sounded more like you wanted to mimic flying ("a slew type function"). Rather than mess with LLAPBH, which will not mimic forces but just jump the aircraft in the same way as slewing does, albeit very finely if you like, I would suggest you experiment with the actual accelerations directly. I know some of these are used successfully, for example, in implementing aircraft carrier catapulting and hooking. Regards, Pete

You write the data to FSUIPC and it pretends it came from FS and puts it into the TCAS tables for others to read, just as if it was real AI data. That's it. Nothing very clever. I only provided this facility because I didn't know of a way to get data for multiplayer aircraft internally from FS. Those folks who know how to program Multiplayer can, of course, also get the very data TCAS gauges and the like need --- hence this facility. Actually, since MS recently produced the traffic data part of the panels SDK I could probably rewrite this to get the MP data internally now, although this does assume that users download the SDK and install the extra MS DLL module this requires. So, I think I'd rather stick with it as it stands. I really cannot see this ever being the way to "create" AI aircraft in FS even if anyone knew how. There's just not enough information, no reference to aircraft files for the graphics or performance, and so on. Furthermore, AI aircraft are supposed to be "artificially intelligent" in that they fly themselves, completely unlike MP aircraft which are images generated inside FS which move according to the MP position and other data. The two concepts are rather different. Sorry, I couldn't find this in the docs, could you give me a tip where to look? Offset 2900 in the table of offsets. To find things in the document, with no index, try using the search facility in your word processor. Searching for "traffic" would have found it, eventually, for instance. Please read my comments above. It was precisely because I could find no way to access MP data from inside FS that I added the facility you first asked about! Regards, Pete

Sorry, I think this is a question for the Squawkbox folks, The connection for multiplayer used by Squawkbox is nothing to do with FSUIPC. No changes to FSUIPC would make any difference here, sorry. Regards, Pete

No, and it depends, respectively. First, please make sure you are using FSUIPC 3.22. Second, please turn on IPC read and write logging, then try again. Either show the log snippet here, or Zip the Log file up and send it to me at petedowson@btconnect.com. There's not enough information here or me to help further, yet. Sorry. "Soon"?? This is the first question I've received from you about this, and when I get some information I will see what it is you have wrong. I do my best to respond quickly, but please forgive a few hours delay now and then. There are other aspects to life I have to see to on occasion! :wink: Regards, Pete

Position and orientation, yes -- but why is the subject "dynamic forces"? For position and orientation the mnemonic is "LLAPBH" -- Latitude, Longitude, Altitude, Pitch, Bank, Heading. These are all grouped together in FSUIPC offsets 0560 - 0583, in exactly that order. In FS2002 and before the Sim must be in Slew, Pause, or Zero Sim Rate modes for the latter three (PBH) to take effect when you write to them, but in FS2004 all six are effective. Bear in mind that between you writing to these, the simulation engine will be continuing and changing them, probably using the same velocities and accelerations as before. I'm not sure how you intend to deal with this (except by setting Sim Rate to zero, or using Slew), but you may also want to investigate the dynamics too -- offsets like 3060 and following and 3178 and following. You can try writing to these too, but I don't know how effective that will be. Regards, Pete

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