Pete Dowson

Yes, as shown here, in the log: Now checking DLL.XML ... ... There is a previous DLL.XML, checking for FSUIPC4 section. ... FSUIPC4 section already exists but will be replaced. (with FSUIPC4_Loader entry) ... FSUIPC4 section of DLL.XML written okay It does this ONLY if it sees that the Loader has been placed into the Modules folder. This is the Modules folder it is using and looking in: G:\Games\FSXW7\Modules\ This is what I don't understand. Might you have two installations of FSX, two Modules folders? Well, something unique must be happening on your system, because the Installer is well tested, and virtually unchanged for many releases. It is used by all FSUIPC users, including on 4 varied systems myself. The code in this area simply tests whether the Loader is present in the Modules folder and if so sets up the DLL.XML file to use it. I'd need to know a lot lot more about your system. I could add more logging to actually show the return Windows gives it when it tests for the presence of the loader, but is this worthwhile? Pete

And trim doesn't work? How have you assigned it? Maybe a sight of your FSUIPC4.INI file would be useful. And if you go to the logging tab and enable event logging, the log of you trying to use the trim would be good. Pete

It sounds more and more like a Mindstar problem then. FSUIPC knows nothing about what that code is doing. There's really no way I can help. The only folks who can help with working out what is going on when you use that page are Mindstar as they are the only folks who know their code. If they refuse to help I don't know how it'll ever be fixed. Pete

Well if the FS controls are being sent, as shown, then the problem with the graphic knob is specific to the code in the gauge. The commands would be the same no matter how you assigned them. If your gauge only operates the graphics with a mouse click, then you'd have to use a mouse click -- or just possibly mouse macros may work if the gauge is written in a specific way. Pete

I seem to remember that those are momentary contact. So you need to use Toggle controls. Pete

Ah, that's more useful. Right. The Windows Crash log isn't directly useful to me, except that it shows that the crash is due to a bad pointer. The FSUIPC log is useful though. First, this part which shows that two options which use API.DLL are truly omitted (the RED lines here do this for me): 811 ------ Setting the hooks and direct calls into the simulator ------ 811 --- CONTROLS timer memory location obtained ok 811 --- SIM1 Frictions access gained 811 --- FS Controls Table located ok 811 WARNING: Failed to install Mouse Macro hooks! 811 --- Wind smoothing fix is installed 811 --- SimConnect intercept for texts and menus option is off 811 --- P3D hack inhibits mask = 0009 811 --- Link check value = 1F6FF (should be 1FFFF) There are other things of interest in the FSUIPC log too. Here's one: 61511 **** SimConnect reconnecting now by request ... **** That means that the special control in FSUIPC to reconnect SimConnect was used. Did you do that? Is so, why? If not, then something you have installed is doing it. But the biggest clue here is this, right at the end, assuming this is where the crash occurred: 97298 Advanced Weather Interface Enabled 144504 .pln The times I've seen the crash occur after this logging it has always been due to corrupt Weather files -- either the .WX file being loaded, or the WXstationlist.bin file in the same folder as your P3D CFG file. The reason such corruption only causes crashes when FSUIPC is installed is that it is one of the very few programs which always requests weather data from SimConnect. There have been lots of threads here about this relatively common cause of crashes in both FS and P3D. Here's a link to one of the most recent ones. I strongly suggest you have a read through it. It has suggestions as to how to verify this (by other FSUIPC INI pararmeters) and what you might do about it: http://forum.simflight.com/topic/82188-p3d-v335-crash/#comment-495519 The .WX file which was probably used is the one associated with the default flight. i.e. this one: C:\Users\Fabrizio\AppData\Local\Lockheed Martin\Prepar3D v3\Prepar3D_Default.wx That and the wxstationlist.bin file can both be safely deleted. Pete

Why click "New Log"? All the essential information at the start is thereby lost. And please remove all optional logging in the logging tab -- none of that Event logging is useful at all for this. All I wanted was the straight forward default log from the start of the session to the crash. And you still haven't posted the Windows crash details. The fact that it still crashes with no API.DLL involvement by FSUIPC whatsoever (thought I can't see confirmation of this because of you starting a new log and losing that information) indicates it is definitely a problem between Mindstar and P3D's API.DLL -- probablty one of them having an uninitialised variable or bad pointer. If Mindstar continue to refuse to assist at all I can only suggest you refer it to L-M. But you will need to supply them at least the Windows crash information. That's a basic essential. Pete

Sounds like you haven't installed the correct FSUIPC version. The current supported version, for the latest P3D3.4, is 4.958. Every time you update P3D always look for a new version of FSUIPC. It has to change each time. Pete

That's not right at all. FSUIPC's installer never used to install the loader at all, it was in the ZIP only as an option, with warnings against using it. In general it should NOT be used, but folks were copying the complete ZIP contents into the Modules folder without reading the instructions, so I changed that so it wasn't included in the ZIP but installed as one of the extras in the FSUIPC Documents subfolder, so it could still be found if actually needed. The installation document, which you should have read, explains where things are. If the DLL.XML file still contained the Loader reference after you ran the installer without the Loader DLL being present in the Modules folder, then something went wrong and the DLL.XML file wasn't properly updated. Check the Install log for errors! I'd strongly recommend removing the Loader from the Modules folder and re-running the Installer to correct the DLL.XML file. If it doesn't you need to show me the Install log AND the DLL.XML file from the AppData folder. Pete

How are they so recognised? I thought OpenCockpits provided their own drivers for their USB devices which aren't standard Windows Joysticks. Or am I wrong? So you assign them in P3D? FSUIPC calibrates FS controls, it doesn't actually calibrate the joystick inputs themselves, only the results inside P3D when they get there. It isn't the same thing at all. Any software can send the values to P3D, FSUIPC picks them up on arrival. Device drivers actually often have assignments in their own interface. If you are not using any OpenCockpits software at all, then find the program "HIDSCANNER" in the "Useful Additional Programs" thread in Download Links subforum above, run it, and show me the log it makes. This part of the FSUIPC log you posted shows strange things: 734 ---------------------- Joystick Device Scan ----------------------- 734 Product= USBAXES-PLUS V2 734 Manufacturer= Opencockpits 734 Vendor=04D8, Product=0000 (Version 2.0) 734 Serial Number= Opencockpits 734 Found correct joystick Id 0 750 Product= USBAXES-PLUS V2 750 Manufacturer= Opencockpits 750 Vendor=04D8, Product=0000 (Version 2.0) 750 Serial Number= Opencockpits 750 Product= USBAXES-PLUS V2 750 Manufacturer= Opencockpits 750 Vendor=04D8, Product=0000 (Version 2.0) 750 Serial Number= Opencockpits 750 Product= USBAXES-PLUS V2 750 Manufacturer= Opencockpits 750 Vendor=04D8, Product=0000 (Version 2.0) 750 Serial Number= Opencockpits All 4 devices appear identical, totally indistinguishable. That would be a problem in itelf. Each time you power up, any of the 4 could be indentified in place of any other. This reinforces my belief that you must be using some Opencockpits software to handle them. This is "normal" if there are no HID devices identifying themselves as joysticks. FSUIPC only scans joysticks for assignment. This is why you cannot assign in FSUIPC. I ask again, are you assigning in P3D? Where in Windows 10 are these joysticks recognised? Pete

Further to my last message, you can stop FSUIPC using / hacking into API.DLL completely by adding this to the General] section of the FSUIPC4.INI file: P3Dhacks=9 Try that as well. Let me know. Pete

API.DLL? That's definitely within P3D. I suspect the difference between when FSUIPC is loaded and when not is simply related only to the different memory arrangement. without know if MindStar mke use of API.DLL and how, I can''t suggest reasons, but quite often different memory arrangements make the difference between a bad memory access causing a crash and doing little or no harm. FSUIPC does have access to API.DLL -- it has to put hooks into it for two things: 1. Mouse macros, to intercept the mouse action when making a macro, and 2. for the optional (defaulted off) imConnect text and menu redirection to WideFS clients. Nothing else. Assuming you haven't enabled (2), that just leaves the Mouse macro facility. See if that works with and without the Mindstar stuff enabled. Maybe they are hacking into the same area. Pete

Are they related? Do Mindstar even use FSUIPC? In that case Mindstar are obviously not using FSUIPC. What made Mindstar suggest that step? If they know why it is crashing then such information would obviously help resolve it. What in P3D crashes? Don't you have any information at all, like the actual crash data, the FSUIPC version, the actual build of P3D? Those are really the minimum I'd need to even start looking. An FSUIPC log from such an event would probably help too. Unfortunately that's not very helpful information then. Pete

I managed to retrieve the DLL itself and restore the link, but there's no sign of any documentation or anything else. The PC and backup systems here have changed a couple of times since that project was live. It is still "BETA" because it was never confirmed as working properly, not by any EPIC users (whom I hence assumed were extinct). By that time I had stopped using EPIC here for several years. I should think it was only a conversion over from the earlier version, so your existing documentation should be applicable. But if not, I'm sorry but I haven't been able to support EPIC now for many years. Pete

If you merely need to assign to switches, why are you doing it by editing the INI file? It is far far easier just to assign these controls in the FSUIPC options, using the control names, letting FSUIPC figure out the syntax. (Why do you need these in Macros in any case?) Without knowing how you are assigning things to the macros, I can't help, but it sounds like you are assigning the on/off macros to the push/release of a momentary switch or button. Using a momentary one you'd be better of just using the normmal toggle action.TOGGLE MASTER BATTERY. Pete

Yes, as Paul says. This method is used a lot to make a gear lever, using an axis, operate the GEAR UP and GEAR DOWN controls. That's actually given as an example in the User Guide -- see page 46. Pete

Hmm. That's odd. It must have been lost last time SimFlight moved servers. That might pose a problem, as I don't maintain or support it any more, not for many years. I'll see if I can find a copy in my archives. Pete

I can confirm this -- I just looked! ;-) Pete

Didn't you look inside any topics at all? There's not one topic per possible download! The "Updated Modules" topic contain the most updated programs, like FSUIPC and WideFS. The "Useful additional programs" topic contains lots of old stuff as well. I think that's where you'll find EPICINFO5. Pete

Why click links which aren't actually called EPICINFO5? The links are actually tied to what they say, you know. Anyway I suggest you look again. You were obviously in the wrong thread, because it is most certainly there. Pete

Did you look in the Download Links subforum? It's definitely there. That subforum is where you find links to downloads. That's why is it called "download Links". ;-) Pete

You already said it was a rotary switch. One of those has distinct selectable positions. Are you now changing that to "rotary encoder", or what? Pete

Sorry, you are most certainly in the wrong Forum. None of the software supported here has anything to do with the Internet. Pete

I added more to my reply, after you read it, it seems.

Why do you want to create it again rather than edit it in the FSUIPC options? INI files in the Profiles folder are indexed via the [Profile.name] sections in the main INI file, so that they only need to be read when one of the aircraft listed in that main INI section is loaded. If you are not changing that part, only the contents of the separate profile INI, then you can do what you like with it -- whilst FS is not running, or at least no participating aircraft is loaded. If you just want to start again it would be best to delete the assignment and calibration sections only, not the file itself, because it is being referenced via the main INI file references. If you wanted to delete the Profile completely you'd need to delete that section in the main INI too. Pete