Pete Dowson

Not many of us are, but even a cardiac surgeon can describe what he sees, surely? You say "it is not opening", but what is it doing instead? disappearing, hanging, crashing? And take a look in the P3D folder called "Modules". Is there an FSUIPC5.LOG file there? If so open it with a text editor and paste it into a message here. Sorry, I do not support that way. Especially with zero information provided beforehand.. One other thing. Is your P3D up to date? You did see the important message associated with FSUIPC 5.122 saying that it needs at least version 4.1 of P3D installing? If not then I'm sorrt, but you should ALWAYS read the Changes notices included in the download. If you are running 4.0 then find the Modules folder and delete FSUIPC5.DLL. You cannot use any current version of FSUIPC with the older version of P3D4. Pete

FSUIPC does not stop P3D "opening". Are you sure FSUIPC is even being loaded? What happens instead of it "opening"? Pete

No, it won't PFCFSX.DLL is loaded by FSUIPC, not by FSX. In that case FSUIPC isn't starting fully. Is it registered? Otherwise you need to purchase a registration. If it is registered, please show me the FSUIPC4.LOG file. Pete

Can anyone translate this please? Google here doesn't seem to want to cooperate! Pete

It is probably only because PlanG doesn't recognise P3Dv4. Many add-ons do carry out version checks. Another possibility is that you are running P3Dv4 "as administrator" and PlanG normally, or vice versa. Processes running at different privilege levels cannot share memory, which is the method the FSUIPC interface uses. Does PlanG have a support forum or website? You might get more specific help there, if so. Pete

You can't do it, and it is totally unnecessary in any case. The email address in the Registration is never used as an email address. it is only a way of making your identity more unique. There's little uniqueness in names alone. Pete

As the log indicated. For some reason the installer was denied access to the folder it created, which is really weird. And the other files are correct, though therre's no KEY file, which is why it shows as unregistered. Let me know after you've re-downloaded and re-run the Installer. Once that looks good we'll investigate the Registration problem. Currently I'm still thinking it was a bad download. Pete

The above is very strange. It says the folder was created okay, but then none of the files can be installed! That makes no sense. Access cannot be denied to a folder the same program just created! I've never seen anything quite so strange. Can you tell me exactly what files are there, in the P3D Modules folder? And in the subfolder FSUIPC Documents? (The Modules folder is E:\P3Dv4\Modules) BTW, when did you download 5.122. The package was replaced once because of a corrupted upload. Just in case you could try downloading it again. Please be sure to clear your cache first (F5 I think). And try installing first without registering, so we can see if all the files are correctly installed. Pete

Try saving this in the FS Modules folder as a file called "freezeAlt.lua" althi = ipc.readSD(0x574) altlo = ipc.readUD(0x570) while 1 do ipc.sleep(10) -- 10 mSecs = 100 times per sec ipc.writeUD(0x570,altlo) ipc.writeSD(0x574,althi) end Then, run FS. Go to FSUIPC options and assign a button or keypress to "Lua freezealt", and another to "Luakill freezealt". Use the first keypress or button to freeze the altitude, and the other to release it. Testing here I get an altitude variation of only 1-2 feet. That's with P3Dv4, so your results may differ. (I don't even have FS2004 any more). You can try reducing the number 10 in the sleep line to make it set the altitude more often -- see what suits you and your setup. Please note that I normally do NOT write plug-ins for users. I'd prefer they did their own research, so that they learn more and can do more things subsequently. I supply many examples and documentation in the FSUIPC Dcouments folder, and Lua has an excellentreference and tutorials on their website. Pete

You posted into the FAQ subforum, so you are lucky I noticed it! The subforums are NOT support forums, but mainly for reference, being an accumulation of usefaul material. Please ALWAYS post here, to the Support Forum if you really want support! And a title of "Help" is no use. Every one comes here for help, so how is that going to attract folks who might know the answer to your problem? Please always use a more descriptive title1 What does that mean? It makes no sense. What is this about? You need to explain what you did. Maybe show the macro, say where you put it and on what name, and state what offset(s) you are trying to access. And if they are PMDG offsets you need to first enable them in the PMDG settings, in the aircraft's SDK. Without any information there's really no way anyone can help. Pete

I don't think so, but did you check the supplied controls list? You'd need to write a Lua plug in with an loop writing the initially read altitude back to the altitude offset as fast as possible. even then, because you wouldn't always catch it before the next frame was displayed, so you'd still get the occasional nasty jitter. Only way to do it properly would be to write your own small DLL in C or C++ to get into the innards of FS2004. But that would also involve hacking into its cod, so a knowledge of x86 assembly code would also be needed. No job for a non-programmer. Pete

What "everything"? Obviously the DLL.XML file had NOT been deleted, as you can see from the log you posted: The DLL.XML file is in C:\Users\Paul\AppData\Roaming\Lockheed Martin\Prepar3D v4 That's where you need to delete it! Pete

I've managed to do some tests here, now, and, indeed, it is the "UseAxisControlsForNRZ" option which is messing up the sync point making facility. It is using the -16384 to +16383 range for the throttle to be sync'd, but the 0-16383 range for the master throttle. This is actually a really good catch, so thank you! It's an original bug, dating right back to when the sync option was implemented! Amazing that it has never been reported before! And you found a good work-around for your case -- copy over the sync positions from a "UseAxisControlsForNRZ=No" calibration. The other way it to calibrate and sync first with that option set No, then change it afterwards and "reload" the calibrations. The fix internally, which I will implement, is basically that -- ignore the "Yes" setting whilst recording sync points. It will be in the next interim updates (4.972a and 5.122a) which I'll post in the Download Links subforum in a few days. Pete

Supplied by PFC? What is that called and where does it run, an EXE or a DLL? So the throttle quadrant levers are assigned in FSUIPC, but if it's the console I used to know I'm pretty sure everything else if done automatically. You don't need to assign anything else. You've still not answered questions which might enable me to help! Have you disabled controllers in FSX? Because the most likely thing that is happening is that you are seeing some automatic assignment there which is interfering! Show me the FSUIPC4.LOG from the FSX Modules folder. Sorry, what "2 pot"? Are you deconstructing the console? Building your own controls? I think you need to sort all this out with PFC. I can't figure out what you've got or what you are doing from your posts here. You seem to feed one snippet of information through at a time, some of which appears contradictory. Pete

There are no facilities in FSUIPC to "add AI aircraft". You need either to write and compile A traffic scenery file (BGL), and place it in an active scenery folder such as Scenery\World\Scenery, or use the special interfaces provided by FS/P3D to inject objects, which you then have to manage yourself or supply a plan for them to follow. For information on all that you need to refer to the FSX or P3D SDKs. It is all well outside the scope of the FSUIPC interface. Pete

This is the SAME as two days ago! When that message is logged, you also would have had a message box telling you that the DLL.XML file is bad. You need to delete it THEN re-run the Installer! Pete

FSUIPC knows absolutely nothing anout multiplayer mode. It is simply not involved. There is nothing in it which is remotely concerned with it. They are both older and unsupported FSUIPC4 versions. It is obvious that FSUIPC did not crash or hang, and it didn't stop receiving SimConnect messages or that fact would be logged. You only allowed it to run for 53 seconds after the line you mention, which was part of the initialisation, so i assume that FSX was waiting for some MP event. What were you expecting to be logged in the 53 seconds? Please use supported versions if you want further support. Pete

Sorry, but i do think it is definitely the older one. The date and time on the Installer EXE inside should show as 20th Nov, 11:08. I think you are merely re-downloading the same one from a cache, probably on your IP server. You either need to clear the cache (press F5 I think), or, possibly easier, download from a different place. If you downloaded from the Schiratti site, try the Download Links subforum here, or vice versa. Pete

As stated very FSUIPC 5.122 is not compatible with P3Dv4.0. Please see the Changes document included in the download ZIP. It will only work with P3D 4.1 and later. You need to update. Pete

I assume you mean "mouse macros", which aren't supported in P3Dv4. Macros generally are made by yourself using a text editor, and are simply assignable sequences of controls or commands. "mouse macros" are similar, but are encoded with an actual code offset in the Gauge DLL or the relevant aurcraft (and it's specific version or issue). All the "macro making" facility did was determine which code offset would do the job of operating the switch. Mouse macros have become almost useless over the years as more and more add-on aircraft have moved to other methods -- mouse macros depended on gauges being very strictly written using the old FS2002 SDK issured by Microsoft. Even MS themselves didn't do that for many of their default gauges. By FSX time many gauges were being witten in XML, where usually Local Panel Variables (L:Vars) are more applicable, and some, most notable the PMDG series, provided a complete set of "custom controls". Both systems can be used in FSUIPC. P3Dv4 gauges will invariably have been re-written and re-compiled using the L-M 64-bit tools. Pete

So, as I asked previously, is that the one using my PFChid.DLL or PFChid64.DLL, or is it self-supporting or with its own driver? (I'm afraid I don't keep up with PFC developments over the years). Also you've not ansswered the other questions in my previous reply. Could you take a look, please? I think it will be quicker for me to get to a point where I could suggest things one I have all the relevant information. Pete

That looks like the problem one, produced by the faulty uploaded Install package. Please as I thought I'd advised, re-download the ZIP and re-run the Installer. Pete

Me too. I have bee pressing L-M for some better facilities for such things, but to no avail so far. They seem to think the current Simconnect text window facility is adequate. Well, if I can figure out of way or making them share the one available Window without "clobbering" each other, maybe that might be an interim solution. But how do you think that could be made to look sensible? I have to provide the P3D function one long string with everything in it, each time it needs updating. Pete

That's rather odd. I suspect you'd get the logging if you used the FS controls in assignment instead of "direct to calibration". Seems that FSL take the values before SimConnect can give them to me. As I say, I do have some debugging log options to get them before that, but let's leave that for now. Interesting. That implies the "UseAxisControlsForNRZ" option is only adversely affecting the vlues input to the syncing operation. These are all good clues. I don't have the FSL aircraft, but I might be able to set something up to do the same sort of thing. Well, as I said earlier, i generally advise not to use "direct to" nor "calibration" for aircraft like all the PMDG boeings and other similarly advanced aircraft, which do tend to be designed to read devices and do their own best effort with them in any case. This is especially true of throttles, far less so for yokes, rudders and ailerons where there's a lot of personal taste to how the handling feels. Odd that there are few if any other posts here about the FSL Airbus. Pete

Addendum to last message: Until I can get to check this, could you try changing "UseAxisContrlsForNRZ=No" again on the FSL. I know this gives you only 50% to 100% thrust movement, but I'd like to double-check that it is the difference this parameter makes to the Sync Action. If so i will know exactly where to look. the code in FSUIPC is actually quite complex there, having been developed and added to quite a bit over the years. Make a safe copy of your FSUIPC5.INI file first, so you don't lose any work you've already done. You can then quickly restore it afterwards. Pete