Pete Dowson

Not so much forgotten, but mixed up. Each time you reconnect USB devices they may get assigned a different number (FSUIPC uses Windows assigned IDs from 0 to 15). If this happens your assignments to one device can be mistaken for those from another, resulting in chaos. FSUIPC offers a way around this by letting it use letters instead of ID numbers. It then matches the letters to the ID numbers on each reload, using device names and things called GUIDs which should (?) be unique. There's a chapter about this in the User Guide (look for Joy Letters). You can just change one line in the FSUIPC4.INI file to make it assign letters automatically, but then those will be letters of its choice (A, B, C ...). You might find it better if you choose them so you can have Y for Yoke, T for Throttle, P for Pedals and so on. Good idea to keep a safety copy of the FSUIPC4.INI file in any case, as well as your registration (FSUIPC4.KEY file) and any other extras you have in the FSX Modules folders such as Lua plug-ins (*.Lua) and macros (*.mcro). But this is a normal backup safety measure, not to protect you against ID changes. LOL! My wife says I drink too much of the stuff in any case! ;-) Pete

How many clicks? With rotary encoders one click is either and "on" or an "off", so to get an increment or decrement on every click you need to assign the same thing to both "press" and "release" on the buttons assignments tab. This should make it twice as fast, to start with. Next, when you turn it fast the click rate may be higher than FSUIPC's default scan rate. You can change the scan rate -- see your FSUIPC4.INI file (in the Modules folder). In the [buttons] section you should finme a "PollInterval" parameter. If not add one. The default value is 25 (25 mSecs = 40 scans per second). That's fast enogh normally, but you could try lower values here. Failing this, if you really want a "fast" mode and a "slow" mode, then, yes, you could detect the button changes in a Lua plug in and if there's less than x milliseconds between each, make an increment of 10 instead of 1 and write it back directly instead of using INC/DEC operations. For this I would tend to make it read the current value (from the appropriate offset), and go up/down to the next multiple of 10, rather than just add 10, as it gives a more predictable, tidy result. Regards Pete

In all versions of FS the Jet fuel idle/cutoff is operated by the MIXTURE control. Mixture rich = idle, Mixture lean = cutoff. Makes sense when you think about it, and if you've actually operated those levers using the keyboard you would have noticed that they are the same keypresses as used for those settings in a Prop. Which ones? What aircraft -- the default 737? There are assignable controls for some, but in the default 737 not all are implemented in any case, some are cosmetic. Just enable Event logging in the FSUIPC logging page. This will log controls when used, by name and number. If you (temporarily) run FS in Windowed mode and enable FSUIPC's console log you'd be able to see which controls do what in real time. No. The List of FS2004 Controls document in your FSUIPC Documents folder lists all of the FS controls available for assignment, and there's a list of FSUIPC-added controls in the FSUIPC Advanced Users guide. But what controls do what, if not understood from the names, needs working out, by trying or by logging, as suggested. I cannot document what FS does, only provide access to it. Pete

Must be something gone wrong in P3D2.4 then, f it was okay in 2.2. did you miss 2.3?. The P3D Lockheed Martin forum is the place to report P3D bugs. Pete

Additional information, if you are reporting the problems to Lockheed Martin: 1. Engine on fire detection (reading 3366) and starting/stopping (writing 3366) is done using SimConnect's SIMVAR's "ENG ON FIRE:n" where n is the Engine number. These values have always been readable and writable in FSX, and I'm reasonably sure P3D. Maybe L-M messed that up in v2.4? 2. I don't know how you are trying to detect or set icing, so I can't provide any more information on that. Pete

It's your first message, late last night, with exactly the same title! Read the answer to your first posting of exactly the same question. The thread was started by you with the same title!!!! See my previous reply! Report the problem to L-M. It is not a change in FSUIPC. Pete

Yes, no problem. Pete

This looks familiar! I answered these questions already in another similar thread! Pete

Oh, yes. Problems in scenery files can play complete havoc with FS's memory and results are not predictable. And it may not even be scenery, it may even be a corrupted aircraft texture file for an AI aircraft, which livery appears more in certain areas, near specific airports. This latter happened to a friend of mine and it eventually turned out to be one bad texture in one aircraft installed by MyTrafficX. Whenever I've had such a problem with sceneries I've had to disable them, layer by layer, till I find the one containing the error, then re-install it. Pete

That would be very strange indeed, as there are no file-related facilities in Windows which are case sensitive, and I cannot imagine that FSX-SE code has been changed to bypass the Windows file access system and burrow down to privileged levels with specific disk access drivers. It would make no sense. I think there must be another explanation for the problem. Maybe they read complete directories into memory then do their own search, entry by entry, mistakenly using a case-sensitive comparison, but this would seem to be counterproductive if all they need to do is load the file. Even if you don't want to investigate further, it would be a good idea to report your findings to DTG (via the relevant Steam forum I assume). Pete

Why not test these things on default FS aircraft first? Many add-on aircraft implement their own methods, ignoring the FS provisions. Many users are finding ways around this, using FSUIPC facilities like Mouse Macros and Local Panel variables (L:Vars), and some add-ons do allow keyboard assignments anyway. Take a look at the User Contributions subforum. Maybe someone has already looked at your aircraft? Pete

The PMDG NGX doesn't use the FS autopilot, and has its own. So all the autopilot display data is not found in the normal FSUIPC offsets for FS. I did map the NGX data to other offsets, as documented in a PDF you will find in your FSUIPC Documents folder. You need to have applied the option in the PMDG NGX SDK, where you will also find the information. Pete

FSUIPC knows nothing about what mode your cockpit is in, and never writes changes to the INI file, which is where all its settings are, unless you go into its options and OK back out, so there is no way possible for it to delete key and button settings. You have something else going on. Are you sure it isn't the apparently very prevalent Windows 8 problems of losing joysticks? I expect simply going into the options and okaying out without attempting any changes would recover them as well as this makes FSUIPC rescan the devices. There's no changes in FSUIPC for these. They's been the same since about FS2000 I think. You need to report these problems to Lockheed-Marting. Pete

Please use lower case as well as UPPER case as otherwise it is almost unreadable. Also, you are posting in a completely unrelated thread. You do NOT have the same problem. You've probably just got conflicting assignments because you are trying to do assignments in FSUIPC for some reason, but haven't disabled controllers in FSX. Please post again, using normal typing, in your own thread and with a suitable title. And try using sentences and paragraphs. Pete

FSUIPC doesn't support use of the mousewheel for anything but Mouse Look related functions. FSUIPC supports joystick buttons and axes. Pete

You can do, but FSUIPC won't determine it automatically. There'd would just be the two button inputs with different phasing determining direction. You'd need to do the programming. You'd probably also need to increase FSUIPC's scan rate as the pulses could arrive too fast else and give you wrong results. There's a discussion about this on page 24 of the FSUIPC4 Advanced User's Guide. Pete

Why are you logging IPC reads and writes? It actually turns out useful, as it identifies a potential culprit. But I didn't ask you to. You are running FS Real Time with it trying to auto-synchronise. It is setting the date and time regularly -- about every 4 minutes by the look of it. That is not a good idea. It causes complete reloads of sceneries, textures everytime, and this repetiitvely can cause FS to hang or crash. I assume your FSinstallation's clock is running slow or fast, quite drastically. FS Real Time should only need to adjust by secods. FSUIPC has a sync facility with merely zeros the seconds when they should be zero -- changing minutes causes reloads. So, try without running FS Real Time, or at least turning off its Autoupdates. FSUIPC certainly is not crashing or stopping, not by itself. You have something running which is doing it. If it isn't FS Real Time, I think you need to stop every other program running and add them one at a time, one per new flight. Oh, and you still didn't answer my question from your earlier report, i.e. You say "after FSX closed completely". Do you mean YOU closed it, or it crashed. If you closed it, how? If it crashed I need to see the Windows error details for it, from the Event Viewer. Pete

It doesn't look anything like the same problem. You say "after FSX closed completely". Do you mean YOU closed it, or it crashed. If you closed it, how? If it crashed I need to see the Windows error details for it, from the Event Viewer. It doesn't look anything to do with FSUIPC from the information you've given. Pete

Just undo what you've done, if you want FS's older non-realistic frictions. i.e. delete the friction lua file from the modules folder, remove the line you said you added in the FSUIPC4.INI and make sure that parameter I told you is set to No. This isn't "performing the friction", this is removing a facility in FSUIPC which most folks seemed to want, to give more realistic rolling and side friction on the ground, and which you evidently don't, that's all. It was a facility i put in on request. I did not devise it. Pete

It is actually closer -- the code is similar, but different, to the place in FSX which I patched. The function is different -- one parameter instead of two. So I'm not sure if i can patch that one or not. If it looks like it occurs a lot and DTG don't want to know, I might look at doing it. But I'd much rather not. DTG have already warned me that FSX-SE is going to change regularly, which will mean a lot of work for me each time unless I can sort things out with them. The problem will be rather complex. I doubt if it will be a user's choice whether his FSX-SE is updated -- it might be automatic, when Steam is connected. And then add-ons which hook internals, like FSUIPC, will crash, or at least not work. i am trying to sort out a method of dealing with this at present, and adding more hooks and patches seems counter-productive from that point of view. Pete

You enabled the Lua friction file? that will explain differences in rolling resistance, for sure! You'd need to undo that, and also make sure that "PatchSIM1friction=No" is set in the [General] section of the FSUIPC4.INI file -- else default frictions will be changed automatically too. There'd be a line saying frictions were patched if "PatchSIM1friction=Yes". But it sounds like you are deliberately patching them using the more sophisticated Lua method anyway -- or even as well? Well, I think you've heard wrong. If your engines are running you won't have to even touch the levers for it to start rolling. If you are moving them then yes, it'll "rush" instead of gently accelerating. You need to keep the brakes on! However, if you prefer to have the ground friction preventing this, you now now what to do. Pete

I'm afraid I still don't like P3D enough to move over. It doesn't look so good to me, and performance is worse on my system. I've never had an OOM problem. Maybe because I don't have any cockpit -- my cockpit is all hardware, so nothing on screen. And for my FSX-SE is quite significantly faster, so much so that I can shove more sliders up. However, I'm waiting on ASN because I'm not going anywhere without it's quality weather and WX Radar in Prosim737. Odd than in all these years I've never had any real errors in FSX which I couldn't track down to video drivers or bad scenery / texture files. And then only a couple of handfuls in all 8-9 years of FSX. Lucky I suppose, plus the fact that I only fly one aircraft -- a 737 based on the default -- and without it's graphics cockpit. I've got lots and lots of sceneries, especially airports, but again only in Europe and near-Europe Middle East and North Africa. Still not gotten around to flying to them all! ;-) Pete

But the N1% reading from FS, the one shown on your cockpit, IS the thrust. There's no other. It doesn't matter how it gets to that value, whether by keyboard, throttle lever, writing the value directly in the appropriate memory location, that's it. I don't see how any control method can be involved in such a discrepancy -- unless it's the ground friction. Are you using the option in FSUIPC to change rolling ground friction values to what most folks say are "more realistic values". Have a look in the FSUIPC4.LOG file. BTW a real 737NG will definitely start rolling with idle thrust. you have to keep the brakes on to stop it. Maybe it's just that you aren't used to such realistic behaviour? Pete

Sorry, there is no useful information in your report, not even the version of FSUIPC4. The only odd thing I see in your log is something frequently stopping FS and reloading WX.PLN into the GPS. Is that you? What are the symptoms of "FSUIPC crashed frequently". Since FSUIPC operates as part of FS, when it crashes so does FS. It cannot "crash" on its own, nor can it "crash frequently" during one flight. Perhaps you are using the wrong word, and "crash" isn't applicable? There's certainly no crash shown in the log. Also there's no termination shown. Did FS just hang, or did you forget to close it down? You said Is that because it disappears from the AddOn menu, or what? It would disappear is SimConnect stopped responding, which can happen sometimes on an overloaded system, but then it should usually recover, and these events are always logged. Pete

There is nothing FSUIPC will do to control how much thrust it takes to move the aircraft. There must be other factors, like loading, wind, ground friction and so on. 26% N1 is 26% N1, 35% is 35%. What then happens is up to the simulation engine and environment. No. Pete