Pete Dowson

First please ALWAYS only post new support questions to the Support Forum, here. You posted in User Contributions, which actually is for User Contributions, not user problems and questions! It sounds very much like you have both FSX and FSUIPC processing your controllers. NEVER have assignments in FSUIPC if you are assigning in FS. If you assign in FSUIPC, disable controllers in FS! The axis names used in FSUIPC are those by which the axes are known and also actually labelled in the DirectInput Windows programming interface for joysticks. I doubt that FS is using incorrect names, so it sounds like you have dual assignments. Note that FSUIPC's steering control is actually a separate control, which can be assigned in FSUIPC, but the direct programming axis FSUIPC provides is actually using the RUDDER, not the FSX Steering Axis (which was new to FSX). The FSUIPC documented feature for transitioning from tiller to rudder control with increasing ground speed only applies when using the rudder-based FSUIPC direct axis. Pete

I don't know if that's possible or not -- I don't know XML nor how gauges are written with them. However, i think you can read and write local panel variables (L:Vars) in XML gauges, right? FSUIPC can also read and write L:Vars, even (with a recently added facility) through the offset interface too. So, you could either change your 66C0 etc using methods to use L:Vars, or have a little Lua plug-in with copies 66C0 etc changes to L:Vars and vice versa, Pete

You are really in the wrong Forum. I can't deal with FSX crashes, only things related to my own programs. TERRAIN.DLL crashes are almost always due to bad or corrupted scenery. You'd need to try to find out which one. AVSIM have a forum dedicated to FSX CTDs and crashes. I'd try there if I were you. Pete

"waiting for clients" indicates that yje client isn't connecting to the server. with no connection it will never work. It is nothing to do with "ClassInstance". You need to have a working network for any WideFS options to work. Assuming the Network is connecting okay for other things, then it is probably your Firewall preventing WideClient getting seen on the Server. The WideServer.log and WideClient.log files would be the most useful to see what Windows errors are reported when the connection is attempted. The whole point of programs logging thnigs is to help in these situations -- that is why all my programs always make log files. Pete

Are you testing with the PMDG 737NGX or 777X, by any chance? If so the only assignments which work correctly are those to the normal Axis throttleN set controls, and you cannot use FSUIPC calibration. This is because both those aircraft read the throttle axes directly, not from the normal FS input which FSUIPC feeds. The same could conceivably apply to some other add-on aircraft, so always check things with default aircraft. Otherwise I'll leave it to Thomas to look at your files as I'm now away till Monday. Pete

You don't read what I write, do you? You don't seem to want to be helped! :-( I didn't say YOU installed bits and pieces all over, but that add-on installers do! But it isn't a "virgin fs" if you are installing into it! And are you comparing every single folder and file in FS? After installing in your so-called "virgin FS", are you then uninstalling there and re-installing in your "real FS"? If so, how are you working this? Many installers, FSUIPC included, install into the copy of FS which is the registered install. You cannot have more than one copy of FS registered in the registry! But you said the opposite just a little way back, here: Your problems are nothing whatsoever to do with MakeRunways and you are obviously in the wrong Forum. But I've been trying to help you and you simply ignore that help! Your SCENERY.CFG files are different, or one has paths to sceneries which do not exist in one of the copies of FS. I did suggest you simply check which SCENERY.CFG files are being used by MakeRunways in each FS copy, but evidently you cannot be bothered to do that. By comparing the two files you would clearly see if they are different. And also, just copying them over is no use without also copying all of the sceneries that are listed in the CFG as being local to that FS. All I can do is repeat what I said before. Doing what you are doing is simply asking for lots of complicated problems. It really does not make sense. I don't think I can help you any more. You don't seem to want my help really.. Pete

Well, some say it does, but then some say that seems to not be happening now with 3.3. I know FSX-SE is a lot better in this area to FSX -- they did improve it there. If you want a log, by time, the setting you have is fine. Just ignore the other messages of no interest. But the memory free/used values are available for other add-ons to read, and the is a program which displays it, and also a little Lua plug-in. You don't need any logging options then, and don't need to look in the log. I'm sorry I don't have any references. The plug-in one I use, which also displays Frame Rate only works on a client PC using WideClient (I don't like displays on my FS screen). If you run WideFS I can give you that to try. Otherwise you'd need to search -- thy the AVSIM FSX/FSX-SE and Prepar3D Forums. Pete

Sorry, I've no idea what you want to do. If the switches are seen by FS and FSUIPC then of course you can assign them to various things, but what do me mean "get a logging or lua variable"? "Get" what to where and for what? Best to post support questions to the Support Forum. This subforum is really a reference section and I rarely look here. Pete

Oh dear. I think you are asking for a lot of trouble. Many things install bits and pieces in all sorts of places. The only copy of FS9 which will work correctly with all the add-ons is the one you aren't actually intending to use! The way to do what you want is just make a complete copy of the FS folder just after a first install. Then keep that as a "virgin" FS to compare with the other. But it is too late for you to do this unless you want to start all over again, from scratch, installing everything again. The way you are doing it will mess things up quite well. I can't even imagine the mess most add-ons will be in, nor to begin to describe any solution EXCEPT: use the registered install, the one everything adds to, as your usable FS. The other one, the one you currently use, is no longer trustworthy and I can't see any use for it now. For an explanation of what MakeRunways is doing -- how it is getting different results for the two -- just see which "Scenery.CFG" file it is using. That's its only guide as to what sceneries to scan. And it will be the same one used by FS. The RUNWAYS.TXT file in the relevant FS folder will show the full path to the SCENERY.CFG being used at the top. in the first few lines. Pete

No, you misunderstand. Not angry. Just puzzled as to what you were asking (as I said there are no errors shown), and why you enabled extra logging in the first place. I see Thomas explained some the messages you seem to think were errors. Pete

Sorry, what "explorer errors"? I see nothing about any errors. I don't know what you are asking about. And why start your question with "Also"? That normally means you've already asked something. There are entries in the log which you appeared to be requesting by enabling £Extras" logging. This logs all sorts of useful information, but what are you looking for? Why are you even looking at the log? Do you have some problem or other? Just turn the logging options off if you don't know what they are for. Mostly they are to help debugging problems, for for that you need problems to begin with. Pete

The SimConnect handle is the one FSUIPC gets when it first opens a dialogue with SimConnect, during initialisation. It is used for everything, 100% of all requests from and commands to SimConnect! It finally uses it to close the connection at the end, when FS is closing. The only time it gets a new one is if it thinks the current connection has failed (my SimConnect timeout has expired), or you use the re-connect SimConnect control option. It just passes on the parameters you supply. Nothing more, nothing less. I think you'll need to report it as a P3D fault if you think it doesn't work. Pete

I thought you were saying the sim was freezing then the "Sim stopped" line appeared, which seems more reasonable to me -- that's why I explained when Sm stopped was logged in so much detail. The line showing a PLN filename is just logging the fact that a plan was just loaded into FS's GPS. I don't know anything at all about LINDA. I certainly didn't know it loaded plans. But if the plan loading is causing the hesitations, why do you want them back? The add-ons I was referring to would not be scenery. Scenery should not cause hesitations, unless you are talking about slow loading of buildings when approaching airports. I think most folks suffer that with the heavier airports. Pete

It's fine. Hasn't he tried it? There is another thread here asking exactly the same questions. Why not take a look first. It really isn't very far from here. FSUIPC didn't change since 3.3 was released. The installer will currently grumble because theP3D number is higher than it knows. There'll be a new FSUIPC installer out by tomorrow, but currently there's no harm done at all. Pete

NO! I've never mentioned "WideServer". The thing on your client PC is called WideClient! The parameter is in the WideClient.INI file! It is the Client PC, not the Server PC where you have the problem, right? Why would you ever think of changing anything on the Server? There is no "ClassInstance" parameter on the Server, because it is running inside FS. FS IS FS, it isn't WideClient trying to LOOK like FS!!! Please do read the messages I've been sending here. I do feel I waste my time a lot when I explain things and folks don't read them. Look back, you'll see we are always talking about the client PC, the one where you have the problem. And WideClient is explicitly mentioned. Pete

It may well do, but it also includes details of the two places I know of for CFG files and describes options for using the DLL.XML and EXE.XML files there, too, even using their semi-automated system I think. I must admit I didn't go into any depth in this matter. Seems far too involved for a simple add-on like FSUIPC, though I can well appreciate how much easier and more sanitory it could make addon aircraft and scenery installing. Pete

The joystick interface in Windows, operating on USB connections, is, like all USB provisions -- by nature multi-user. Any number of programs can access and poll the state of any number of USB devices. The only way to make one exclusive is to have a special low-level driver or hooking program which prevents them being passed through. This is why you should never have joystick controllers enabled in FS whilst assigning them in FSUIPC, or vice versa. I'm afraid Thomas's Profile suggestion wouldn't work UNLESS you can make the operation of your Real Trim application only apply in a specific profile -- perhaps on starting it and stopping it when appropriate. Or ask the developer of that program to provide an on/off function which you can operate with another button or keypress, perhaps? Pete

Strange. Sorry, but I'm certainly not going there. The full SDK documentation is on-line, not downloaded with the SDK. The details are all there. Those are the ones I refer to. Nor were they ever installed by default in FSX or FSX-SE. They've ALWAYS been created and amended by add-on installers as needed. (There were just examples provided in the FSX SDK). So you really want to throw my Installer away? If that is what you want to do it is entirely up to you. You'll have to make do with downloading the DLL on its own, when such interim versions are available, and waiting for the separate Documents package to be updated, as and when. Alternatively you could make a batch file (or adapt one you are using) to automatically delete EXE.XML and DLL.XML files from the places you don't want them. But whatever you decide to do, please don't ask for support for old unsupported versions of FSUIPC if you decide to not update. Pete

For a technical explanation, the "Sim Stopped" message is only logged on two events, both notified to FSUIPC by SimConnect: The most usual one is "SimStop": described by MS as follows: The simulator is not running. Typically the user is loading a flight, navigating the shell or in a dialog. Note that this does not include "pause" which pauses simulator time but not all of the other things going on in the sim, and "MultiplayerSessionEnded", described in the P3D documentation as: sent when the multiplayer race session is terminated. If a client player leaves a race, this event will be returned just to the client. If a host leaves or terminates the session, then all players will receive this event. This is the only event that will be broadcast to all players. Autosave doesn't normally signal either event as it isn't really a stop at all, but it can cause hesitations when using add-on aircraft which themselves freeze the sim whilst collecting all their data to save. The PMDG aircraft are especially noticeable for this. However, autosave hesitations would be regular, as the interval set for them. If your freezes do really coincide in time with the Sim Stopped logging, then they are evidently very irregular -- in your extract there's 118 seconds (nearly 2 minutes) between the first two, then another 453 seconds (over 7.5 minutes) to the next! You'll probably need to do some elimination tests, running without many add ons then gradually adding them back and re-testing each time. Pete

Strings? Sorry, what are you talking about? All I suggested was CHANGING the "ClassInstance" parameter from 0 to 1. There are no "strings" involved in any of that. Where are you getting such ideas from? Pete

You should not need to close it manually. It takes a while for FSUIPC to close all the threads, especially if you have any Lua plug-ins running. Also network use can delay the final termination. But if you've waited and it never closes that's something else. I've had that happen with some versions of P3D, but it's been okay with P3D version 3 so far. You don't get it with FSX do you? Pete

Ah, it probably needs a driver. Isn't there something called "SPAD" which does that? Pete

Rescripting what Lua? I certainly do not supply any Lua plug-ins for any controllers. Why do you need scripts? Why not just assign normally? LINDA is not supported here. You need their Forum I think. I don't know it at all. Yes, and easily if the "knob" is seen as an assignable axis in FSUIPC. I don't know what the knob looks like to FSUIPC. If it's detectable only as a pair of buttons you'd need to program it for INC and DEC type actions using controls. Pete

Sorry, please explain. P3D is designed to have two DLL.XMLs and uses both. The one in the AppData is fine, and there's nothing wrong with FSUIPC continuing to be loaded from there. It is a cross-platform add-on and I think it most appropriate for it to be loaded from the same compatible DLL.XML location. I append, below, what the P3D SDK says about them. And there are implications. FSUIPC should be loaded late in the total list, but not after ASN's connection DLL, and the only way my installer can ensure both criteria is to check and edit the DLL.XML in the Roaming folder. Having changes made at this stage to the method will introduce confusion for users and risks double loading. I see that the SODE animation DLL attempts to load itself twice with entries in both places. If you just let the FSUIPC4 installer work as it should you wil have no problems. I don't know why L-M have done this for DLL and EXE files. It makes some sense for many of the other CFGs, especially those for scenery, objects, effects and so on. But not for these. And why is the Prepar3D.CFG still in Roaming? If you mean by "I have used the new add-ons function" that you have used its XML config method and command line facilities to install FSUIPC, then I would ask why, when FSUIPC's installer makes it so easy for you in any case? And anyway, even if you want to do it for some good reason, why not use the method for updating the Roaming DLL.XML, not the ProgramData one? I see you can opt for either. Pete ----------------------------------------------------------------------------------------------------------------------------- The priority for how add-on library (DLL) and application (EXE) configuration files differs from content and is initialized as follows: ProgramData: Configuration files named dll.xml or exe.xml found at: %PROGRAMDATA%\Lockheed Martin\Prepar3D v3 Roaming: Configuration files named dll.xml or exe.xml found at: %APPDATA%\Lockheed Martin\Prepar3D v3 If multiple configuration files are found, then the list of paths are merged together when processed according to the above priority.

This is an old misconception. You are restarting it before it has finished closing down. It takes a good few seconds after the FS window disappears. FSUIPC detects it is still running. Pete