Pete Dowson

You must have missed this entry in the Release Notes (first Announcement in this Forum) and in the History document: This was in version 3.212. I'm not able to find any other exit indications I'm afraid. No, sorry, I know of no way at all to interact with ATC. Regards, Pete

Yes, but by the time you've reached the menu in order to choose, FS has already chosen and loaded an aircraft. It is not to do with the one you are choosing, but the default one FS is loading before that. By starting with a default FS9.CFG FS will load its default aircraft. Provided you've not added any gauges to them, this should clear up the problem. If not then investigate the Modules folder, see if there are any add-in DLLs other than FSUIPC. Regards, Pete

By the way, I think all these: 3470 8 Ambient wind X (double) 3478 8 Ambient wind Y (double) 3480 8 Ambient wind Z (double) 3488 8 Ambient wind velocity (double) are in metres per second. FS seems to work in those units internally. The fact that you have found that by writing to the Ambient wind Z vector you can make a difference to the aircraft behaviour is very interesting. It opens up another line of research for me -- into how to provide wind speed limits, "taxi winds" and wind smoothing on FS2004. Maybe if I constantly write to these values I can at least make the sim act as if the winds were limited or smooth even if the weather data says otherwise. When I'm looking into this, perhaps I will find an easy way to allow you to provide a specific up or down draft -- like allocating another offset for you to write a required Z wind component to, which FSUIPC could apply on every FS frame. One thing I'm not too sure of at present is the X, Y, Z notation -- I don't know if these axes are relative to the aircraft, or the FS world, and in the latter case, whether X and Y are oriented to True North or to the aircraft's longitudinal axis. Some experimentation is called for! Regards, Pete

That sounds like a perfect job for a little program to do. Maybe someone who wants to learn to interface to FSUIPC could take it on as a training exercise? FSUIPC itself is not really the right place for such an application -- to start with it has no idea where KORD is and would have to have some database to look up. It is really outside the scope of an interface program. Regards, Pete

If by "choosing a flight", then no, because FSUIPC does nothing at all until it is actually running. None of its code is activated until FS is pretty much ready to fly. Do you by any chance have a complex aircraft panel as default? FS seems to load up whatever you have as default initially EVEN if the flight you choose at the menu doesn't use it. Then it unloads it all and loads the chosen one. If the panel loading by default is one which tries to use FSUIPC, it won't get any joy until FS is almost ready to fly (certainly not until you are well past that initial menu) and this may be causing it to take more time than otherwise. Just in case, or as a test, try deleting your FS9.CFG file and let FS make a new one (keep a copy of course, in case you want to restore it). You definitely have some add-on, or possibly something corrupted, which is related to the aircraft data then. It certainly isn't FSUIPC which is crashing or directly causing any crash, as it actually traps any crashes occurring whilst it is in control and logs them, automatically. I think it is some add-on panel or gauge, or possibly another DLL, which is detecting FSUIPC is present, asking for data, getting zero in response (because FSUIPC is not yet active) then using this invalid data and causing the crash -- the few details in the crash message seem to confirm this. The log shows everything is okay in FSUIPC, except that this aircraft you are using: 63692 AIRCRAFT\iFDG A320-214\Airbus320-200-CFM56-5B4.air 63692 Aircraft="Airbus A320-200 - IFDG WTA" is accessing FSUIPC in an incorrect manner -- it is trying to use it like an external application. This is extremely inefficient (and it most certainly won't work with an unregistered FSUIPC installation). If I were you I'd try to determine which Gauge in that aircraft's panel is doing this, and remove it. Regards, Pete

These offsets both map to the same place, and that is half-way through the Ambient Wind Z value :o . This is accessible directly, as a Double float, at offset 3480, but it's behaviour and usefulness is unknown at present -- maybe you will find out more. This offset is one of a number which were added in 3.22 but have not yet appeared in the SDK (I've just been too busy!). In the interim I list new mappings in the Release Notices -- in the History document, and in the first Announcement at the top of this page. You will see that these are the wind elements available: 3470 8 Ambient wind X (double) 3478 8 Ambient wind Y (double) 3480 8 Ambient wind Z (double) 3488 8 Ambient wind velocity (double) 3490 8 Ambient wind direction (double) They don't, it is merely an artefact of the mapping carried out inside FSUIPC to provide access to variables in various places inside FS. Unlike FS98 where all this stuff was concentrated in one memory area, the data listed in the Programmer's Guide is obtained from all over FS -- even the data that was in one data area in FS2000's SIM1 is, in FS2004's SIM1 split into smaller private data areas only accessible through pointers to pointers to pointers and so on -- FSUIPC follows all these to access the data for you. In other words the vision of all this being simply in memory for you to read and write as you please is a mirage, an illusion, created by FSUIPC to make the programming the same as it was in FS98. This is the problem with most of the values which are derivatives -- they may have an effect, but will be re-calculated on each cycle. I think the success of catapults and hooks was only by repetetive changes over a period to slow down/speed up the action. Just changing a value which is continually re-calculated has no lasting effect. I don't know. You'd have to find out by experiment. You mean to say you aren't even a registered user of FSUIPC? :( If you register FSUIPC you need no other access keys. Pretty much all the developers I know of register FSUIPC so they can get the sort of support I am providing. After all, the SDK itself represents a lot of work in itself. You don't really need an access key for your program, even if it is freeware, until you have something you wish to share will others, possibly unregistered users. Sorry, I've no idea. I am not a scenery writer. As far as I know there are BGL instructions which can set them and read them. You really need a BGL programming reference. Regards, Pete

Ah! I see, sorry. The email address and some other details are provided in the Sticky thread near the top pf this Forum, entitled (perhaps not clearly enough?): "Applications for FSUIPC Program Access Keys". You will also need to read section 4 of the Access Registration document in the FSUIPC SDK, and send me, via that email address, the details it mentions. Yes, of course. Please see the FSUIPC SDK (available at http://www.schiratti.com/dowson) which will give you full details. Regards, Pete

Aiview was almost identical to the TrafficToolbox utility made by Microsoft. The official FS2004 version is available on the Microsoft site: http://www.microsoft.com/games/flightsimulator/fs2004_downloads_sdk.asp Regards, Pete

I don't know. Does the program use FSUIPC? What does the author say? If it is "live" software (i.e. author still active, and the software is intended to work with FS2004 and FSUIPC), then it would be much better (and polite to the author) for Freeware access to be arranged through him. Besides which there is information I need about the program in order to make the Key. Also, when the Key is made, if the program is still being maintained and supported, it would be best to build the key into the program. If not, then the Key would have to be published as an alternative, for user entry. So, if the program uses FSUIPC, please, in the first instance, ask the author to contact me about getting a freeware key. Thanks, Pete

No it doesn't. You are simply talking about turning the FSUIPC option on and off, which is what that bit in 32F6 does. Why do you want to change the value too? Battery voltage is the measure of battery charge. When it drops below about 16 or 17, poof! It all goes dark! :lol: Try using the FSUIPC Monitor (Logging page, right-hand side) to observe how the value behaves, with and without the FSUIPC option enabled and with different values for the discharge divisor. Regards, Pete

But what if you did this: dim dm(5) as string If FSUIPC_Read(&HC33, 5, VarPtr(dm), dwResult) Then If FSUIPC_Process(dwResult) Then msgbox(dm) End If End If Isn't this really what your version boils down to? It seems extremely odd to have to expand the characters, already in ASCII the way you want them, into hexadecimal character form then back again. That's taking weirdness to extremes! :o [LATER] I just had a scan through some older threads here, as I was sure this must havecome up before. Try this thread: http://forums.simflight.com/viewtopic.php?t=22508 It seems to end up with a more sensible solution. Still makes VB look poor to me, but not as daft as the antics your code has to get up to (if you don't mind me saying so -- ingenius, but daft, yes? :wink: ). Applying the solution there, your example would become something like: Dim dm(5) As Byte Dim dme_txt As String If FSUIPC_Read(&HC33, 5, VarPtr(dm(1)), dwResult) Then If FSUIPC_Process(dwResult) Then cnt = 1 Do While dm(cnt) <> 0 dme_txt = dme_txt & Chr(dm(cnt)) cnt = cnt + 1 Loop End If End If msgbox(dme_txt) (Thanks to Armando!) Regards, Pete

You can do it by program. Either use the FSUIPC facility but switch it off (offset 32F6) whilst the APU is not running (and no Ground Power is available -- don't forget the ground power option! :) ). Or you can investigate manipulating the battery directly -- offset 2834 should be useful. It's not so easy to do it just using controls, if that's what you are thinking of. Though the facilities to manipulate offsets may help to some extent I'm afraid they don't emcompass floating point values. You could try to fake enough of it to work. Regards, Pete

I'm not at all mad (well, not in that sense! :wink: ), but I must admit that I don't understand it at all. Why isn't a string a string? Are you by any chance compiling with a wide-character or Unicode option set someplace? Those character codes are not ASCII, but 16-bit codes (i.e. 2 bytes for each character). However, for the basic ASCII subset I think the high byte is always zero. So if this were the case at least the first character should appear correctly. I don't understand how all you got was a decimal integer representing the first 4 characters. Regards, Pete

The number you are quoting is DECIMAL! You canot take a decimal number and convert it to a set of hexadecimal bytes simply by chopping it up into pairs! Please refer back to the example I gave you! You are not reading what I wrote! 808333630 is actually hexadecimal 302E313E, which is wrong but close -- the ASCII character codes there are 3E 31 2E 30 I think you may have a small error in your number, because this gives ASCII string ">1.0". I think the first character may have been something different. If your decimal number was 808333620 instead then the sequence would be: 34 31 2E 30 which is "41.0", a reasonable range from a DME. You won't see the terminating zero because your number is from the first 4 characters only (4x8=32), a 32 bit integer can only accommodate 4 characters, not 5. The fact that the "number" is so close to being a good ASCII string means you ARE reading the data correctly via FSUIPC. Your problem is only in the way you are looking at it. Someone who knows how to program VB needs to help you, unless you can refer to some books, because I have no idea why you cannot look at the data you are getting as a string instead of a number. Regards, Pete

Sorry, I don't know. I've not done anything at all for X-Plane. You'd need to do a search. Regards, Pete

Not a problem, Pete is short for Peter! However, my family name is actually Dowson, with two o's, no 'a' at all. :wink: Regards, Pete

But any string character data, viewed as a number, would look strange. View it as a string of characters and see what it looks like. For example, take the string "Pete". Inside the computer, in ASCII, this is 4 bytes (one per character) plus a zero terminator. Ignoring the latter for the moment, the 4 bytes in hexadecimal would contain: 50 65 74 65 If these 4 bytes are viewed as a 32 bit integer, the hex value is 65746550 which in decimal is 1702126928. Doesn't look much like "Pete", but it's the same data. Regards, Pete

I know this is addressed to JD, but I have to butt in and say how amazed I am that VB has so much difficulty handling things as basic and simple as strings. As long ago as 1978 I remember using the very earliest forms of Basic, and their handling of strings was exemplary. I really can't understand what Microsoft has done to it all. :cry: Anyway, just in case your comment causes more confusion, please note that the FSUIPC_Read and _Write procedures themselves do not care one iota what the data is. The form of the data can be absolutely anything you like. It is most certainly not just a "long". What you are confusing the DATA with is the pointer TO the data. That's all FSUIPC needs -- the pointer to wherever the data is, in memory, and of course its length, in bytes. After all, all the interface has to do is move stuff from one place to another (one process to another, or in the case of WideFS one PC to another). In most languages pointers appear to be quite fundamental and straight forward. They are simply addresses in memory, something fundamental to computers almost since Babbage. I don't know what VB has done to them but they are evidently a continuous cause of pain. Since much of the Windows API depends on pointers too, I really can't understand how folks actually manage to make VB programs do anything useful. :wink: Sorry, I can't be more helpful, but this is so disparaging. :cry: Regards, Pete

For either multiplayer or wideview you really need two or more good computers. For my own program, WideFS, you need one good computer running FS and the other computers can be anything to suit whatever programs you want to run on them. Many such programs are quite happy with very mediocre PCs. Regards, Pete

Ah. I see. The D3D rendering is irrelevant to WideFS as it doesn't deal with graphics at all. It only links one FS computer to others not running FS so that other application programs (not FS views) can link to FS from client PCs. I don't know of any program which send FS graphics to client PCs. WidevieW (not WideFS) is similar to Multiplayer in that it links several PCs all running FS. Regards, Pete

I don't remember how long the Button Pulse holds the flag for the button. Up until recently FSUIPC polled the joysticks once every 55 mSecs (i.e. 18 times per second), though that changed to 30 mSecs default in FSUIPC 3.22 and will be slightly faster still in the next version. You can speed it up by adding the PollInterval parameter to the main [buttons] section in the INI file (as described in the Advanced Users Guide), but you need to take care not to impair FS's performance. The joystick API doesn't do anything with the buttons except set the flag or clear it, as a button is pressed or released. The application of Button Pulse in EPIC was to simplify the original sequence which was "Button On -- Delay -- Button Off". Obviously having the delay in-line in EPL code made programming more difficult when sequences and other actions were required. In other words, the answer to your question is "it depends". I hope I've given you enough information to decide for yourself or experiment wisely! Regards, Pete

I'm sorry, I don't understand. Rendering of what, please? Regards, Pete

The order of the joysticks in FS's list doesn't necessarily reflect their numbering in the Windows joystick software, only the way they are listed in the registry. Compare the order in Game Controllers. In Windows 95/98 the USB Epic was a nightmare, because almost every time it was connected the order of the joysticks would be different, and even the numbers as seen in Windows were different. At least using Win2000 or XP has sorted that, but there are still some oddities. FS uses DirectInput for its joystick access, whilst I use the original Windows Joystick API. The joystick API is actually a subset of the full DirectInput (for instance supporting only 32 buttons per joystick instead of DirectInput's 64), so it is possible to have connections which aren't seen by FSUIPC, but I've not come across any yet. The work involved in moving to DirectInput is too horrendous to contemplate, and doing so would actually lose some of the flexibility I have (e.g. with treating POV inputs as up to 8 buttons). There's no need to observe or anyicipate anything, is there? Using FSUIPC you don't really need to worry about the joystick/button number. Just press and program. However, if you ever use any of my other EPIC supporting programs, like EPICINFO, you'd need the joystick numbers as seen by FSUIPC, not whatever FS seems to imply. Regards, Pete

Because that data is a character string not a number. I hope JD's answer helps you. Regards, Pete

Try 31A0. In fact, try writing to any or most of the assorted velocities and accelerations in offsets 3060-30B8 and 3178-31D0. FSUIPC does route these through to the Sim Engine. I don't know what effects you can generate, but certainly it is by manipulating things here that applications like carrier hooks and catapults have been implemented. I'm reasonably confident you'd be able to do something, but I don't know enough to advise you in detail I'm afraid. You will have to experiment. I doubt that you could add thrust on a glider because the internal data sections referring to engine behaviour and performance simply don't exist when there are no engines pre-defined. You'd need to fiddle it by constantly writing accelerations and/or velocities. Just ways of purpose-written scenery to interact with programs and vice-versa. The BGL can read/write those as well as a program. Regards, Pete