Pete Dowson

Does FSUIPC work okay -- is it reporting any problem? If not i think you should talk to HiFi Simulation and check before acting. With Gold being FSX + Acceleration combined, the installer lists will only have the one entry for the entire program -- after all, it was just an updated FSX you installed, not a Base FSX and then some updates. Really, my advice for FSUIPC only originally applied to the Base version -- it gets rather fraught with the three versions of SimConnect being there. If ASA is only complaining about the SP1 version, then, if FSUIPC is happy with the SP2/Accel version (check its Log file to see), you might be able to delete the SP1 SimConnect folder only, then run repair from the disk. However, I think you ought to ask HiFi Simulations support about this before doing anything. It may be that their checking doesn't quite match what FSX Gold installs, somehow. Best to be sure it is an actual FSX problem first before possibly making it worse. Regards Pete

Don't you just love self-correcting software? :shock: Pete

I don't knowAre you reading this in the FSUIPC Advanced User's guide? I just copy extracts from the PM documentation at http://www.projectmagenta.com/pmoffsets.html for easy reference. Did you cross-check to see if things have changed? Are you sure you are using PM builds in which these work? Sorry, but I think PM support is the correct place to ask these sorts of questions. I cannot support their software. If you are sure you are sending the correct values, the rest is up to their modules. Regards Pete

Sorry I have not gotten back to you sooner, Pete. It's been chaotic here. The FS9 implementation certainly works "correctly" in 3.908, and I think the FSX does. My memory is giving out. Thanks! Pete

Why are you doing all this manually, when I so carefully designed it to work so well using the in-program options? why restarting FSX when you could merely press the Reload button in the buttons Tab? The format for Controls instead of Keypresses contains a C. If you used the options to assign your buttons you would have obtained the correct syntax anyway, which is: 1=P0,23,CM1:1 2=P0,15,CM1:2 Buttons can be assigned to Keypresses (K) or Controls ©. Macros are just Controls -- as listed in the Controls list in the options. The format you are using is only applicable to [Keys] because Key assignments always must be Controls -- there is no facility to assign keypresses to Keys. There is no 'C' or 'K' for [Keys] because there is no need, but obviously [Keys] would need the 'M' for a Macro. So you get Mn:n is [Keys] and CMn:n for [buttons]. But thanks for the report -- I see there is an error in the Advanced user's guide in this respect, which I will correct. Strange, it has been there all these months. Seems most folks do use the Options dialogue. ;-) I may make FSUIPC accept your format too, however -- there is no reason I can think of not to, and it looks like I was thinking that way in any case when I did the documentation! BTW What version of FSUIPC are you using? The version number is ALWAYS needed, or I cannot usually help. Regards Pete

Okay, thanks. I will be too busy till next week but will look at it then. All of the XYZ world velocities and accelerations are provided, as I pointed out, so you are okay. Don't use the body axes if you want world axes. If you need rotational accelerations in world axes you will have to compute those from the body rotational accelerations. Ah, what you refer to as "differences in update time", we know as "acceleration". It is the acceleration, i.e. the rate of change in velocity, which is felt as force. "G-force" means "Gravity force" and is normally the force felt from the acceleration called gravity. So you want the three accelerations, as I thought. But if you want them to measure the feeling of forces on the pilot, you want the accelerations in the BODY axes, because the pilot is sitting IN the "body" of the aircraft and his left/right/up/down/forward/back are of course NOT the same as the World XYZ axes. Regards Pete

NEVER publish your key! I may have to rervoke that if someone else works out how to use it! :-( If the registration is being rejected you are entering something wrong. ALL THREE PARTS -- name, email or address and key MUST be identical to the original registration. If you've forgotten the name or address you used, log onto your account at simMarket and retrieve it. Pete

Thanks for letting us know! Regards Pete

4.50 is not the latest update for FS9 -- for FS9 and earlier you must stay with FSUIPC3. FSUIPC4 is only for FSX and ESP, and is a different product. Version 3.71 of FSUIPC3 is very old and has not been supported for a long time. You should certainly update to version 3.90, which is supported, or even one of the later interim builds posted here, in the Updates Announcement above. When you bought the Registration you bought version 3.xx, not any specific release. Rehards Pete

I mean: Pitch : Pitch, Bank : Roll, Yaw : Heading Okay, you have those. Don't you recognise them? GS ground speed is not the same as VS vertical speed, but both are clearly available -- separately. Ah, by "GS-velocity" I think you don't mean "Ground speed", which is speed over the ground below, but relative to world coordinates. Right? And you have all those, they are clearly described. I've never heard of any of the normal velocities of a body being cllaed "sled". Where does that term come from? Sorry, "accumulated"? You mean added up? This makes no sense! If you mean differentiated (as opposed to integrated) possibly you are talking about accelerations? I've already pointed you to those. Don't you care about rotational velocities and accelerations at all? Body axes are they X,Y,Z orthogonal axes in the aircraft, the "body". So a sideways velocity would still be sideways no matter whether the aircraft were horizontal, vertical, otr what. The body velocities and accelerations are relative to the AIRCRAFT body, the pilot if you like. Of course. "float" is only 32 bits and has a different number of bits in the exponent. Regards Pete

Okay. Thank you! The 6 prime values in FS are "LLAPBH" == Latitude, Longitude, Altitude, Pitch, Bank and Heading. These are altogether starting at offset 0560. I don't know what you mean by planetary axes -- do you mean the velocities and accelerations relative to the world axes, perhaps? If so these are at offsets 3190 to 31D0 -- but there are no offsets for the rotational accelerations relative to world axes, only to the body axes. And I don't know "sled"? I've no idea, but I suspect you are interpreting the 64-bit double float incorrectly. I think you need to check it with a reliable program such as FSInterrogate, or use the FSUIPC monitor facilities to display it on scree -- see the right-had side of the Logging tab. What are you reading it into? "result" obviously needs declaring as "double". Are you doing that? Regards Pete

What are you looking for in your Documents folder? You don't need special privileges to look in there -- I really don't understand now what you are trying to do! Do you mean the Modules folder? If so you really aren't doing it correctly., then. And in any case, what exactly are you wanting to do when you find these files? Okay .. in that case there is definitely at least an INI file and a LOG file in the FS modules folder. It is not possible for it to run and not produce these. The DLL is no different whether it is registered or not. The only thing which makes it registered or not is the KEY file. You certainly either have a pirated key in use still, then, or the date of your PC precedes the date the key was purchased. You need to delete the KEY file from the FS Modules folder -- the REAL FS Modules folder, not the one aliassed by Vista. I'm wondering whether you are only not recognising the KEY, INI and LOG files because you have Vista set to hide the fieltypes of those it thinks it recognises? Either change that option, so you can see the filenames properly, or look for the FSUIPC file which Windows thinks is a "Registration Entries" type. Likewise it would call the INI and LOG files "Configuration Settings" and "Text Document" types, respectively. Regards Pete

Okayone easy way to do that is to bind the LIB as it is into your DLL and export them there. You'd have a dummy DLLmain function which did little, and that's it. Or, as you suggest, use the supplied source and adapt it as you like. You could then change the retry system or the error reporting, as you wish. Regards Pete

Sorry, this is not very clear. you want to create an FS DLL, or just a DLL to run inside your own EXE process? Right -- so you ARE talking about a separate process from FS? not a DLL running inside the FS process? Yes, the Lib_source.Zip is precisely what it says, it is the source from the LIB. Why do you think it is not? If contains all the LIB functions -- can you not see them in the C file? It was written in the days when Exports were declared separately in a DEF file (I think). These days you can to it with in-source declarations. cdecl export stuff. But if you know how to write DLLs you know all that stuff. Regards Pete

Sorry for the delay. I'm off sick at present with the 'flu' and only working short hours. :-( In that case it can only be one of two things: EITHER 1. The key you are using is an illegal one, generated by a pirate key generator, OR 2. The key was purchased AFTER the current date set on your PC -- check the date in Windows and correct it. If it is "registered" there must be a .KEY file -- else it is unregistered in any case. And if there are no .LOG nor .INI files, then FSUIPC has never been run at all. I suspect you've allowed FS2004 to install in its default place, in Program Files, which, in Vista, is a protected folder -- nothing can write to those folders without Elevated Admin privileges (as for instance an Installer). Because FS2004 is not aware of such an environment (being written well before Vista), and because Vista knows this, it creates aliasses for all of FS9's folders and hides the real ones from you, elsewhere than in Program Files. So what you see, normally, is merely what was installed -- nothing more. To see the real contents of any Program Files folder in Vista you must run Windows Explorer in Elevated Administrator mode -- i.e. right-click on its icon and select "run as administrator". Note that there may be many other add-ons fooled by this. If you get other problems with them you may need to run FS2004 and the add-ons all "as administrator", or else re-install FS2004 in some more sensible folder, like C:\FS9. Regards Pete

What, to Register FSUIPC, as in the picture you supplied? Why supply a picture in any case? I wrote FSUIPC, I know what it looks like! Yes, in order to Register FSUIPC you have to buy a Key. But why do you want to Register FSUIPC? If it is to use the user facilities that FSUIPC offers, then fine. They are all described in the User Guide, which I assume you must have read so you appreciate what you are paying for. If you are buying it just to run an Add-On, then I think you are mistaken. As I said, there are very few add-ons indeed which need a Registered FSUIPC. I have told you this before, but you don't seem to read what I write. :-( Pete

You could probably do all that using a simple Lua plug-in. Check the examples given -- particularly "record to csv.lua". You should be able to send the output to a named pipe instead of a file, and use the pipe over a network. If not, maybe I can add some extras to the library to enable this. None of the documents installed for you in the Modules folder have anything to do with programming in C++ or creating DLLs. You need a proper C++ reference and some notion of writing programs for Windows. Once you've mastered that, you'll need to find information on making a DLL work inside FS -- there's a little information around, but it isn't an officially supported method. FSUIPC is really designed to interface to external programs (EXEs), and there are examples of that in the SDK. Regards Pete

There are hardly any add-ons i know of which need you to pay for FSUIPC -- you do NOT purchase FSUIPC for its interface to Add-Ons. All the key will do for you is unlock the user facilities, for joysticks, button assignments and so on. If you look at the documentation supplied in the FSUIPC ZIP you would see what it would be you were paying for -- and none of it is related to add-on support! I think you must be totally misunderstanding something fundamental. If you have problems with an Add On, please go seek help from their support. Please do NOT buy FSUIPC hoping it will solve an add-on problem. It won't. Regards Pete

Which English words didn't you understand? The error message points you to a definition of something in a file, a definition which you are violating for some reason. Surely it is within your ability to look at the given line number in the specified file to see what it might say? Can't you open text files in an editor and look at them? I think you need to learn more before trying to attempt something like this, then. Sorry, but you will simply be completely out of your depth. You are really in the wrong place to learn programming. You need to start somewhere else I think. Good luck! Regards Pete

Generally, if they can be displayed in a gauge they are accessible. There may appear to be exceptions, but in those cases it is usually because the gauge code itself is deriving a displayable value from other values emanating from the simulation core, which is the source for the FSUIPC offsets. Best to ask specific questions when you have them. Obviously no one can really answer the general question "how do I do what I want to do when I haven't yet defined it?". Regards Pete

I think you'll find that "hint" is changed in the latest documentation! My certificate expires in August and none of the Authorities now sell certification to individuals, only Companies, so SimFlight stepped in for me. Regards Pete

You use the offsets which (a) provide the information relevant to the cockpit gauges you need, and also (b) are actually supported by the base FS model upon which you a building your craft. The latter point is important to note. The simulation method in FS for the Robinson is very different from that for the Bell, and so on. Each supports different read-outs for instrumentation. One of them is more like a prop plane in this respect. You'd have to determine which values were usable for your model. Don't the names and descriptions of the offsets in the documentation help? Certainly there's a rotor RPM, but "pedal" is "rudder" still -- it controls the rear rotor or its vanes, to set or control yaw. And your "pitch position" is ambiguous -- there's the pitch of the craft, as on the AI, and the "elevator" which represents the forward/backward movement of the cyclic, whilst "aileron" would be for the left-right movement of the same stick. There's FSInterrogate2, part of the FSUIPC SDK. If you are referring to the Offsets Status document for FSX, surely you also have that program? If you are not even referring to the offset documentation, why on Earth not? You can also use and extend the Lua plug-in provided, the one called "display vals". You can alter that to display what you want, in real time, on the FS screen. Regards Pete

Ah, right ... Yes. Very annoying, that. Regards Pete

Thank you for emailing me your name and the original email address. As you will see from my reply, you appear to have both your name wrong and the email address wrong, at least according to the original purchase details. Please get them right and it will work! :-( Pete

You are writing it as a what? 16-bit value? if so all you are doing is writing to the lowest two bytes of the 8-byte double floating point value. I've no idea what that will do, it's a waste of time. If you wanted to do something really approximate you could write to the two 2 bytes, at the offset + 6, but you'd need to work out the correct exponent and mantissa values and put those in the appropriate bit positions. You could of course use a Lua program again -- to read a 16-bit value from one offset and write it as a double float to another. Haven't you tried that? It wouldn't be that much different from the program i showed you earlier. while true do cowl = ipc.readUW(0x66C0) mycowl = cowl / 16384 ipc.writeDBL(0x37C0, mycowl) ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use) end Though really you should only do this when 0x66C0 is changed, so use an event (event.offset) to call a function, instead of having a loop like this. Regards Pete