Pete Dowson

First of all, you are writing in C or C++. Have you used the language before? Just match up what you wrote: FSUIPC_Write(0x1400, 48*2, 1000, &dwResult); to the prototype defnition for that function as declared in the Header (FSUIPC_User.h): extern BOOL FSUIPC_Write(DWORD dwOffset, DWORD dwSize, void *pSrce, DWORD *pdwResult); Now, don't you see anything amiss? Check each parameter. For size you have 48*2 -- i.e. 96 bytes. For the pointer to these 96 bytes you have "1000". But 1000 is a number! If it is treated as a pointer it will point to 96 bytes at address 1000 in memory That's not even going to be in your program, so will cause an access protection error. This is why I asked you what you thought you meant by the line you wrote. I cannot understand what you are thinking. If you want to write 96 bytes you need to prepare an array of 96 bytes, or a structure of that length, with all the data you need already inserted! And provide the pointer to it! Maybe you are only begnning with C? If so, I should warn you that interfacing to fSUIPC is not really a beginner's project. You should really look, perhaps, at using a Lua plug-in For examples of FSUIPC_Read and FSUIPC_Write in use, check the UIPCHello source in theUIPC_SDK_C.zip package part of the SDK. Odd. Everyone says that, and sometimes "many times", but still manage to show they either have not or have skipped over some essential parts altogether. Of course, not exactly, It would be impossible to provde code examples for every possible thing folks wanted to do! But reading and writing offsets is not really very different from one offset to another. And the "ReadThis.txt" file in the C parackage does explain things which you have apparently ignored, as in this part which I quote with emphasis on the relevant part you seem not to have read: The following Library calls are used to accumulate Read and Write requests: BOOL FSUIPC_Read(DWORD dwOffset, DWORD dwSize, void *pDest, DWORD *pdwResult); BOOL FSUIPC_Write(DWORD dwOffset, DWORD dwSize, void *pSrce, DWORD *pdwResult); In both cases you supply an offset, identifying the data required or to be written, and a size (in bytes). The pointers "pDest" for reads and "pSrce" for writes naturally must point to the area to receive the result or (for writes) the area containing the data to be written. These pointers are defined as "void *" here so that you can use whatever component size or structure you like, as appropriate for the data in question. Regards Pete

Assign the one button to whatever the two or more are supposed to do. The initialbutton need not be a real button or switch, so you do not lose one. e.g. InitialButton=15,31 8=P15,31,C2968,0 9=P15,31,C2969,0 Pete

Okay. I thought 50 or 100 mSecs as a minimum. I'll see if I can add it before my upcoming August holidays. Pete

FSUIPC responds to inputs from GoFlight devices. It does not really "scan" them. Same really with HID devices -- it is just that an "on" signal represents a change, and changes are signalled. The GoFlight interface does not do that. You can either scan them yourself using a Lua plug-n, or, perhaps more simply, use the "InitialButton" option in the INI file (see Advanced Users guide). Or have a macro performng your actions which is performed initially via the [Auto] secion in the INI. Another thing you could try is reversing the meaning of the rocker switch? Regards Pete

The first item is nothing to do with the other two. You can't, it is "virtual", not real. FSX is limited in total to 4Gb including all of its code, data, and system modules -- because it is a 32 bit program, not 64-bit. It is only a warning -- when only 300 Mb is left. If you take action then, like saving a flight or leaving a complex area or reducing AI traffic, you might not crash. You can turn the warnings off if you like -- an INI file parameter as described in the Advanced User's manual. Pete ]

Hmmm. Interesting. I can't see any reason for a difference between XP and Win7 though -- the code for all the graphics involved in local to FS. I don't think it is dependent on driver behaviour at all. Pete

Yes, it is 128. It would be a rewrite of the complete macro system. The L:Var name was pushed into the tables in the space normally occupied by the macro name, which is why you can't have both. L:Vars is a "bolt on" rather than a new facility. I'm really not wanting to make such drastic changes at this late time. Sorry. Pete

Can you explain what you think this line is supposed to mean? FSUIPC_Write(0x1400, 48*2, 1000, &dwResult); It makes no sense, it does not fit the template, and should not even compile. There's no pointer to the data to be written, and which value is supposed to be the data length? Please take a look at some examples, or at least read the parameter definitions so you know what the Function needs for its parameters. Regards Pete

FSUIPC only has any control over messages written to that position via FSUIPC. That what is meant by "application messages" -- FSUIPC applications. It sounds like you are hoping or expecting it to interfere with FSX's own messages, or those written directly using SimConnect. There's also a little red note appended to the parameter in the FSUIPC4 advanced users guide saying [I'm not sure this works at present] and in the six years of FSX I've not had any feedback on it in order to confirm that or otherwise, probably mainly because almost nothing uses the facility these days. Certainly, I don't have any applications using the facility these days, and those which I used to have use ShowText to redirect them to another screen, usually on another PC. FSUIPC4 has much less control over these things in FSX than FSUIPC3 did in FS9 and before, I'm afraid. Regards Pete

FSUIPC only actively stops one specific scenery-related crash, in G3D.DLL. It cannot really help with any others. I've never heard of any "MENUS.DLL" crashing at all. It isn't a part of FSX, being new to Prepar3D, so you ought to be reporting the problem on their Support Forum. Regards Pete

Why not use a simple Lua plug-in? there's an example of something very like what you ask provided in the Lua plug-in examples. It's called "Record to csv.lua". Pete

I cannot support such an old version of FSUIPC. You muse update to 4.84. You always need to ensure no axes are assigned in both places, unless you want them to conflict. The safest way is to disable controllers completely in FSX because otherwise it can automatically reassign them. Pete

Hmmm. Interesting idea. I never implemented a normal event on LVar chages because of the performance problem when continuously reading them, but having a polling interval could solve that. I'd like to impose a minimum interval though. What do you think would be the longest minimum which could be tolerated? Regards Pete

Exactly as documented, 1.5 nm air range, 0.25 nm ground range, with optional cyclinder altitude difference in feet. Where do you read 500 feet? What 'n' are you talking about? The ZapCyclinderAltDiff is optional. It isn't normally present. The cyclinder mode is not operating unless you insert this parameter, and as it CEARLY says, you give n in FEET. It is all clearly written. Why? I cannot explain any clearer here than the way it is explained in the documentation. It tells you the units and what to insert. What is the problem? Well, you inserted these. They are not present by defalut. And 'n' should be a number as explained in the documentation. Sorry, but it is rather evident that you've not really read the documents, else how could you not see where it says "where n is the maximum altitude difference". Please, please try reading it again! :-( Only if you add one. All three are options which don't normally appear in the INI. You add them to change them. 3.999 is the minimum supported version. Please update. Currently we are on 3.999s. Pete

Did you search on "vertical" or "ground"? I'm sure that will find it very quickly. Pete

Do you simply mean the "on ground" flag at offset 0366? Or the offset which provides the verstical speed at time of touchdown? Serch on the word "vertical" or "ground". Pete

Very wasteful. Just have one macro 1=L:BCBGL=SET without the parameter and use the parameter field in the assigned button or switch parameter field. Probably, because each macro file is supposed to contain a large number of macros, not one in each! Use the parameters in the assignment for variations on one control. Collect all macros for one aircraft, or at least a complete subsystem of an aircraft, in one macro file. I don't know offhand. i can look it up for you, tomorrow maybe, but you should realy never need to know. Multi-line macros do all of the actions with one assignment, so that is not something you want. You surely want to select one action. That's what parameters are for and why you can provide them when you assign. Pete

Yes, but I still think you should do what I suggested -- i.e. set FS to run in Win98 compatibility mode. Regards Pete

Okay. The fix was easy enough. It is fixed in version 3.999s, now available in the Download Links subforum. Note that if you insist on running FS9 in Win7 mode, as now, then the KEY, INI and LOG files will be in the Flight Simulator Files folder or your Documents. I strongly recommend running in XP compatibility mode, even after the fix. Regards Pete

I'm wondering if this is the cause of the problem, causing the FS9.EXE to lose its tag saying "XP compatibility mode". With FS9 in its own folder, not in Program Files, you do not need to run it with Admin Rights, though that shouldn't matter in this problem. However, you have certainly not set it to run in XP compatibility mode, as the log shows: ********* FSUIPC, Version 3.999r by Pete Dowson ********* Running on Windows Version 6.1 Build 7601 Service Pack 1 You need to set the compatibility as shown here: Then press OK. Maybe you need to do this on the FS9.exe file in the main FS9 folder, not just on the shortcut. Run Windows Explorer "as administrator" in order to do this if you've installed FS9 in the Program Files folders. Oh, when you've done this you'll need to MOVE (not copy) the INI and KEY files to the Modules folder before running FS9. [LATER] I've reproduced your problem by forcing my FS9 to run in Win7 mode instead of XP. So it definitely is this. FSUIPC3 should run okay with the files in the Flug Simulator-Dateien folder, as I think it used to, so I will find out why that is going wrong and will fix it in the next update. That may be tomorrow, but if not it won't be till next week because I'll have no time. Please set the XP compatibility mode and you'll be okay. Regards Pete

There's one thing I don't understand. In the FSUIPC.LOG file you have: This is from a log file in the "Flight Simulator-Dateien" folder, correct? So, FSUIPC is USING that folder. Therefore it should see the INI in that folder. The line "Running on Windows Version 6.1 Build 7601 Service Pack 1" seems wrong to me, for FS9. FS9 is forcibly run in XP compatibility mode. At least it is on my system, and I've not selected this. The lines in my Log say: ********* FSUIPC, Version 3.999r by Pete Dowson ********* Running on Windows Version 5.1 Build 2600 Service Pack 2 and this is WITHOUT setting any "compatibility mode" values. Win7-64 automatically sets this mode for FS9. And it should. there is no way FS9 is fully compatible with Win7. it was written long before even Vista! I can only think that, for some odd reason, your install of Win7 did not recognise FS9 as being incompatible. You DID install afresh in Win7, didn't you? If you just copied it over from an older install this might explain things. So, please do two things: 1. Install 3.999r to get up to date (see the Download Links subforum). 2. Right click on your shortcut for FS9 and select "Compatibility", then check "Run this program in compatibility mode for", and in the drop down select "Windows XP (Service Pack 3)". (Please translate to german as needed). Let me know. If this doesn't work I will probably need to ask you to run a special version with extra logging. Regards Pete

Sorry, that confuses e. it IS like the picture, but it is not blank? The picture shows blank. So what do you mean? it is blank or it isn't blank? >> in my Folder: Flight Simulator-Dateien (its in Eigene Dateien) are the Files: "FSUIPC.ini" with date and time from the lastet setting in FS9 "FSUIPC.key" ist there also with Date 15.8.2011 "FSUIPC.log" is also in. << I've no idea how these get into that folder as it isn't a folder FSUIPC uses. something else must be changing the folder before FSUIPc writes the files. But I don't understand this as FSUIPC creates a full path name including all the folder names from the Drive onwards. >> these are the Data from FSUIPC.log file: User Name="" User Addr="" WIDEFS not user registered, or expired << This appears to show that your FSUIPC is not registered. Also your WideFS. Or did you blank the name and address? Sorry, which entries do you mean? There is a section which you can delete altogether, the one at the start headed: !1=[JoyNames] That has been commented out by version 3.8 which does not have a "joynames" section. FSUIPC 3.9 has created a new one. I don't understand what is going on in your system. it is unique. You did not tell me what happens when you put the FSUIPC.INI file into the Modules folder. I will have to think about this and look to see how to get more information. I'll get back to you. Pete

Just to check, I installed the Preview on my notebook (destroying my old Vista 32-bit system in the process -- I intend to put Win7 - 64 on it anyway).. Good news: the current FSUIPC4 installer (4.84) released today works fine. No problems. I don't know what was wrong before. I think it was a Windows glitch. Bad, though: what a really awful system it is!! It is dreadfully slow at everything and the most difficult thing to use i ever encountered. I did install a thing called "start8" to give me back my Start button and search/execute edit field, but i still can't find much. I can't even get any decent video drivers installed, and my bluetooth mouse is useless as there seems to be no bluetooth support at present. Either they've made a complete hash of things, or this "preview" is released far far too early and there's a lot more work to be done! Regards Pete

No. Something is very odd in your setup for this mixup to happen! I am using Win7-64 on all my FSX PCs. Please answer some questions and supply some data: When the "old version" runs, where is the FSUIPC.INI file? And what is the actual NUMBER of that "old version"? Where is the FSUIPC.LOG file? Where is the FSUIPC Install.LOG file? Please find those and show me both of them. You can paste them into a message here. Where is the FSUIPC.KEY file? The picture you supplied shows no registration details. Did you blank those or are they really blank on screen? Have you tried moving the INI file from where it is to the Modules folder? It must be there or it won't work! Pete

All those facilities are still there. nothing is taken out. The INI file is next to the DLL in the FS Modules folder, as well as the LOG file. If it isn't there then either you have never run FSUIPC in that install of FS, or you are looking in the wrong place. FSUIPC never runs without creating a new, or reading an existing, INI file. There will also be an Install log file, recording the progress of the Installation, and an FSUIPC Documents folder containing all the documentation and Lua plug-in examples. Why have you lost the INI file in which you had those parameters in any case? You didn't go and delete files at all did you? When updating you merely need to update, not delete. Pete