Pete Dowson

Those are NOT from "FSUIPC4.LOG". They appear to be two small fragments of the FSUIPC4 Installer log, nothing to do with FSUIPC actually running. If that's all there is of the Installer log, then I don't think you have FSUIPC installed properly at all! Please look again. Pete

Er ... this is NEW information! So 4.90 works for you whilst 4.91 does not? That's amazing! There's really very little different between 4.90 and 4.91 but it is a much better clue than all the millions of little changes since 4.80! I'll look again next week with this in mind! Pete

I didn't need the Install log. The main log is odd, as although it shows that joysticks 0 and 1 are detected without error, it never sees any input from them whatsoever. On my system with Saitek devices connected, the log rapidly fills with many messages showing input from those devices. You don't have any other software installed for those dvices, do you? Saitek software? It looks like I'm going to have to add more logging in a different area to see why there are no returns from these devices. I've not seen anything like this before. But unfortunately I'm away soon for a few days -- back Monday. So I can't get to it till then. I suggest you use whatever works for now and I'll get back to you then. Regards Pete

The DBS software involves more than a car -- isn't there a DLL also loading? Did you edit the DLL.XML file? Did you not see my last message? I can't really help without information. Have you tried DBS support at all? Pete

I hope the google translation is okay. With all current and recent versions of FSUIPC you should be using Profiles, nit "Aircraft specific" settings. Profiles are defaulted. I cannot really help without more information, please. I don't even know which FS you are using! Perhaps start by pasting in your FSUIPC INI file (or FSUIPC4.INI file) from the FS Modules folder. Regards Peter

"RunIf" will only start them if they are not already running. And put the full pathname in quotes ("... "). Pete

Maybe, but it still uses the same principle, 16 top bits for whole metres, lower 16 bits for fractions -- 1/65536ths. These sort of representations date back as far as FS98 days and pervade FS. Nowadays they are more usually held internally as 32 or 64 bit floating point numbers, but FSUIPC has to convert them to the original FS98 format for compatibilty. The whole point of FSUIPC was to present a compatible interface across all versions, FS98-FS2000-FS2002-FS2004-FSX, and even CFS1 and CFS2. Regards Pete

Sorry, I don't understand. You are already reading the data you want, using a Lua plug-in I assume? Where do FSUIPC offsets come into it? What do you actually need to achieve? Regards Pete

They are like little programs. Only a program interpreting them can "convert them to an actual action". The best you can do is read them and understand what they are intended to do. For normal button + control / kypress macros, the format is defined in the Advanced User's guide, and the list of controls is provided in the List of Controls document, both in your FSUIPC Documents folder. Other macros, those generated by the Mouse Macro facility, and unfathomable because they relate to binary addresses within gauges. They are not suitable for user editing. Regards Pete

Values in FS are represented in units which afford the best precision in the space avaiallbe. For an angle from 0-360 this is done in a 16 bit value by making 65536 represent 360. (360 is the same as 0). So 65535 would be just 1 1/65535th of a degree less than 360. For a 32-bit value the same applies, but 65536*65536 = 360. And so on. The altitude in 0570 is a 64-bit value, in metres and fractional metres, as documented. The top 32 bits are metres, the lower 32 bits are 1/(65536*65536)ths of a metre. Just consider the whole 64 bits as a number with the binary point in the middle, 32 bits of integer, 32 bits of fraction. There is no hex representation of any values other than radios and transponders. They are all actual numbers. As documented in fact. Use FSInterrogate which can display these things in all manner of ways. Perhaps you might understand better then? Regards Pete

I didn't sleep well, so got up rather earlier than usual, so I managed to see your new reply: Yes, a temporary change in order to get more information of the problem, NOT any sort of "solution". I wouldn't have expected ANY changes in behaviour at all, just a much bigger log file! But only the first line is in the INI you showed me. If you really did add the lines properly, then this can only mean you tried adding the lines whilst FS was running, instead of before! That would remove those lines, because the logging options can't be changed whilst FSUIPC is running! I don't know why you expected there to be any difference! The ONLY thing I changed was to add more logging, as I keep saying! No, I told you to post the LOG file, which would have provided more information if you had added the lines to the INI file correctly BEFORE running FS! It seems you don't actually read what I write. It is nothing to do with technical misunderstandings, it is things like reading "INI" when I write "LOG". If you do that then I cannot support you at all in future. I want to solve the problem in case anyone else gets it too. But I really cannot help unless you do the simple things I ask so I can obtain more information. Don't you see this? When you read the messages please read the actual words thast are there, like "LOG" instead of "INI". And do not edit the INI file when FS is running. That's okay. It isn't inconvenient for me, but it is for you, and because of this mess it could now be a week before it goes further as I am very busy for these two days (it is my 70th birthday today), and then I'm away till next Monday. However, I will try to get back later if I can. Regards Pete

What "temporary solution"? I've not come up with any solution yet because I don't understand the problem. I told you that! I added more logging in the interim release, version 4.913a, in order to try to find more information to tell me what is going on! Please read what I write a little more carefully or we'll get no where at all! Er, hold on. "Calibrate the yoke"? You cannot calibrate the yoke unless you've assigned the axes on it to something to calibrate!!!! I assumed you were talking about ASSIGNMENTS not CALIBRATION. I can't see anything at all in the log because you haven't supplied one. You just posted your INI file again! AND I can see that you haven't even bothered to add the lines I asked you to add! Those lines were to give me more information to help you out!! So are you now saying you can see and assign buttons!!?? Earlier you were saying that FSUIPC didn't see your devices at all! I'm sorry, but I have to finiish with this for now. I'm going to be out for the next few days. I respectfully suggest you read back over this thread, because there appears some misunderstandings going on. You don't add the lines to the INI as I asked, you don't supply the log, you talk abouty calibrations and not assignments,. All this suggests that you are perhaps not reading my messages and not understanding that you need to assign axes before you can calibrate. I might be able to check back tomorrow night, or maybe Wednesday, but if not it could be a week from now as i'm away. If there is a genuine problem here I need information before I can provide any solutions, let alone "temporary" ones. That's what logging is all about. It tells me what is going on. :sad: Regards Pete

Hmm. See nothing there which is going to be different. And the Joystick names etc are identical to those detected by 4.91. It DOES recognse them because it adds them to the INI. Pete

Hmm. Very strange. I've added some extra logging. Please download FSUIPC4913a and copy the DLL into your Modules folder. Edit the INI file, adding these lines to the [General] section: Debug=Please LogButtonsKeys=Yes LogAxes=Yes LogExtras=xA00008 This will (or should!) cause a lot of logging, so it's only temporary. It should log every single read of every joystick which is (a ) successful, and (b ) different from before. Go into FSUIPC's options, try to assign some buttons, then axes. Show me the log and tell me exactly what happened on screen. Currently I don't understand it, because there's no difference at all in this part of FSUIPC since 4.80 (or even since 4.0). And it is perfectly fine here with Saitek axes and buttons. Pete

Well, if that's a newly generated INI file with 4.91, it is seeing the Saitek devices okay, as you can see. So there's no reason why you shouldn't be able to assign. What have you actually tried to do? Are you assigning buttons and axes in FSUIPC, or are you assigning in FSX and only claibrating in FSUIPC. I can't tell from the settings because there are no buton assignments, no axis assignments, and no calibrations. Regards Pete

Got it! Thanks. Yes it works fine. Download FSUIPC4913 Offset 0BFD, one byte, 1 = on, 0 = off. Can write to it too (it uses the Antiskid brakes toggle to match what you write, if different). I've not got time to do a documented release at present. I'm accumulating a small collection of updates and will release next week some time. Regards Pete

I moved your post from the "FAQ" subforum, where it is lucky I noticed it, to the Support Forum which is where you need to be to ask for support. You NEVER need to re-purchase FSUIPC4. You are entitled to all updates, forever. There is no difference whatsoever in the way FSUIPC 4.9 reads joysticks to that used in FSUIPC 4.8. All versions of FSUIPC4 use standard DirectInput facilities in the same way as FSX itself. Please, yes, post the log file from 4.91, and, more importantly, the INI file showing your settings. Just paste them into a message. Pete

Okay. I've added it but I'm having a hard time testing it. Which aircraft does it operate with, please? I've tried using the ANTISKID BRAKES TOGGLE control on the default FSX 738 and that makes SimConnect still return FALSE for the active setting. Is there something needed beforehand? The engines are running. As soon as I can verify it I can make an interim build for you to use. Regards Pete

No, it is not currently available through FSUIPC, but it would be dead easy to add it. It's just that no one has ever asked for it. FSUIPC4's interface to FSX was intended as a compatibility layer for programs written to work with FSUIPC on FS9 and earlier, so the prime objective was, of course, to match the data as far as possible. Things extra in FSX or P3D have been added later, on request. Where there are suitable SimConnect variables it isn't a problem, just a matter of finding a suitable spare offset locatin (only a BYTE needed in this case) and adding it to a table. I'll have a look now ... Regards Pete

Yes, in the Download Links subforum. It handles messages sent to FS via FSUIPC, but not those sent via SimConnect. Only the new Lua function I mentioned hooks the latter. Pete

As the Installation guide, also included in the ZIP, stated, whether the Loader is used or not depends on whether it is present in the Modules folder at the time you run the Installer. Therefore, after deleting it, you need to re-run the Installer. That module is the standard C++ Run-Time library and is used very very intensely by all parts of FS. If there's a BEX error occurring in that it is most certainly being caused by some sort of in-memory corruption, which is pointing towards hardware I think. Are you overclocking the PC or any of its components? Have you checked that the memory chips aren't failing? (I do that by removing one at a time). That's an access violation. API.DLL is, again, a general utilities DLL part of FS, used quite a lot. Access violations usually occur because of data corruption, bad pointers. That could be in-memory or from scenery or aircraft data files. I really can't see a link to anything FSUIPC might be doing, in use or dormant. Of course, the fact that FSUIPC is present in memory (as well as the Loader, the way you have configured it), will change the memory configuration, so if it is indeed a memory problem it may simply not occur so often, or at all, with different thngs loaded in different places. I see n alternative but to try various changes, in a process of elimination, including possibly the memory chip configurations and, if you are overclocking, reducing that (temporarily) to see if that makes a difference. The only time I've ever had "BEX" and/or "Stackhash" crashes were with my previous system which was overclocked a notch too far. I took it down a multiplier (4.8 to about 4.6 GHz) and it was okay thereafter. Regards Pete

Why the FSUIPC4 loader? Best not to use that -- some folks have said with that in memory they get strange results. I've never been able to reproduce anything odd, but it might be related to the order of things performed in SimConnect with rival SimConnect clients. With many thousands of FSUIPC users and only you reporting a "BEX" error, I have to really say there's not a lot I can really do to help. Is there any information with this "BEX" error (which is not something I'm at all familiar with anyway) which might lead to specific code? Is there any way to narrow down exactly what FSUIPC might be doing for you at the time you get the error? Don't forget that FSUIPC is primarily passive. It simply sits there receiving information from SimConnect and placing it in "offset" locations for applications to read. If it actually does anything it is only because you or an application requests it. Does anything you have installed actually use FSUIPC for aything, at all? If so, then the reason you don't get the problem without FSUIPC might simply be because the dependent application(s) then don't behave the same. Or maybe it's related to some hardware driver invoked through FSUIPC due to axis or button assignments? Maybe you can work around the problem by disabling DEP in Windows? See http://techblissonline.com/enable-disable-dep-in-windows-xp-vista/. Pete

No, that facility does work for messages sent from Applications to FSX via simconnect, as it says. It was released in 4.905, and is (naturally) still in the current release, 4.91. The documentation is actually in the Lua plug-ins documents, along with an example plug-in for WideClient to show the messages on a client screen. See the documentation for the event.textmenu function in the Lua library pdf. The example plug-in is also called textmenu.lua For the simple text messages that facility does actually remove them from the FS screen. Unfortunately that didn't turn out to be completely possible for the menus. The best I could do was move the menu to top left and make it smaller. On my projected scenery screen it's out of sight. Regards Pete

Sounds like it was something in the FSUIPC4.INI file, because having deleted it you had a new one created from default. There's nothing else likely to have the effects you describe. This is why I said this to you in my last message: Did you carry forward your INI file from 4.74 days? A lot has probably changed in two years. If so, can you try renaming it so a default is created? Let me know. If it then works, please paste the older FSUIPC4.INI into a message here and I'll take a look to see how that might happen. It is a shame you've now presumably lost the INI file which was giving the problem, because I would have liked to have seen it so that I could take steps in future to deal with such problems automatically. Regards Pete

What FS messages and menus? There's no way to move built-in messages and menus, but some add-on ones can be 'moved'. Perhaps you could explain what you want to do. Did I? What reference please? "Changes" documents accompany interim releases, in the same ZIP file you download, and only describe differences since the last major release. This is to save re-releasing complete new Manuals just for minor updates. When the next major release is made the details are included in the main documentation, and also listed in the FSUIPC4 History document. All documentation released in the main releases is found in your FSUIPC Documents subfolder, as stated in the Installation guide accompanything the installer. Regards Pete