Pete Dowson

I spent a lot of time experimenting over the weekend, trying to use these offsets to implement both taxi-winds and wind smoothing. I've not really got anywhere yet -- there's a strong possibility that the weather input to the sim engine is NOT via these values. But one thing I have found out for sure -- 3480, the Z axis wind component, is NOT the vertical wind. FS is consistently following the system it has for the other dynamic values (see the Notes at the end of the main table in my Programmer's guide): X = Lateral Left-Right Y = Vertical Up-Down Z = Longitudinal, forward-backward. I think this is related to True North, not the aircraft orientation. I don't know what you discovered earlier, with half the Z component, but maybe lift changes are being influenced by changing the air flow over the wings, not by Y-component air velocities. Anyway, maybe you need to concentrate on the location for Y not Z, assuming it is actually used in the sim engine. I'll continue experiments on the others for taxi and smoothing, but I am not holding out much hope yet. Regards, Pete

Not that I know of, no. You can clear the engine down with the FSUIPC clear all weather facilities (both from a program and via the hot key). Possibly the fact that you are re-loading the flight it just saved means it thinks it doesn't need to. Try renaming the saved flight so when you load it it looks like a different one. You'll need to rename the WX file too to match. Or you could try clearing all weather AFTER saving the flight and before reloading it. Regards, Pete

Okay. 16 x 16-bit words for raw values (though currently the max range is 0-127, it may well change in future), and a 16 bit word containing control flags for connection (0) disconnection (1). I'll look for 34 bytes space some place. If you don't mind a rough beta with some other stuff half-baked and undocumented (probably nothing relevant to you in any case) I can probably add this this week. Is that too soon for you? For an official release it would be July sometime, though. Regards, Pete

Sorry, I know nothing at all about AIBridge, and I've never used Multiplayer. None of the pictures you included mean anything to me. Have you got the latest version, from Jose's page? http://jcboliveira.flysplash.org Password? Does it need a password? Sorry, this is most certainly something I know nothing about. Regards, Pete

Sorry, no -- there is no difference on any of my three PCs with the start-up time, with or without FSUIPC. As I mentioned, FSUIPC is really not doing anything to speak of until after the menu phase, and when FS is ready to fly. Even then it isn't doing much until asked by other programs. Of course right at the start it does read its INI file and KEY file, and start a LOG file. Check those (in the Modules folder) see if they are very large -- they should all be pretty small. Even if they were large that would in itself no slow things down. But possibly your disk is short of space, or has not been defragmented in a good while? The only other thing I can think of which might slow loading times is a shortage of memory. Whilst FSUIPC doesn't itself add that much more to the FS memory requirement, it does add a little and that may just be enough to cause some swapping out to hard disk if you've not got quite enough. Regards, Pete

Not sure what you mean. I don't know any program which passes offsets from EPL itsef to FSUIPC. The EPICINFO module allows soft axes and POVs to provide values to specified offsets, via parameters in EPICINFO's CFG file. FSUIPC does provide button and switch programming for EPIC. You just go to the Buttons page in FSUIPC options, press your EPIC button (or operate the switch) -- FSUIPC will recognise the button/switch and allow you to assign functions to it. within the many functions you can assign there are facilities to access a sepcified offset too. Also there is a program called EPICMapper, or something like that, which may do the job too, and FSCommunicator handles EPIC stuff as well, I believe. Regards, Pete

Sounds easy enough -- would this be post-calibration in PFC.DLL? For all axes or only those not allocated in PFC? With an option to disconnect the assigned function? I'll make a note and put it in the next version. Unfortunately the next release will probably not be till July sometime as I'm part way though some quite massive changes for the new PFC MCP and the Jet Cockpit (see http://www.flypfc.com). Maybe I can send you a Beta some time earlier though. Regards, Pete

No. I think DDE actually uses the same method as FSUIPC's "inter process" data passing though -- i.e. memory-mapped data. The interface used for FSUIPC was established way back in FS95 days by Adam Szofran. Regards, Pete

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