Pete Dowson

Find the frictions lua file in your FS Modules folder. Load it into an editor. delete all lines containing "ROLLING". Save it. That's it. Can't explain it any simpler than that. Have you never edited a file before, ever? :-( Pete

Yes, that looks better. Pete

That's just the way it works. Levers only do anything when moved. It should be part of your initialisation when you get into your 'cockpit' -- move everything. In a real cockpit (well certainly modern Boeing airliners) there's a display available showing control surface positions and you'd use that to check all was well. Move everything the whole distance back and forth a few times. Helps keeps the measuring surface clean and smooth as well. (In the real aircraft you'd need to warn ground crew first of course, else it could be dangerous). You also need hydraulic pressure available first, but that will depend on your add-on aircraft simulation. Pete

You need to adapt the Lua program so that it only adjusts the sliding frictions. Just delete the lines which SetFriction for "ROLLING". The "RestoreFriction" at the start will put the FS defaults back for the rest. Take a look at the file -- it's plain text. Edit it with NotePad or similar, NOT WordPad or any word processing program. Pete

If it adds an extra . you have to as well, else the filenames won't match! Pete

That needs WideFS. Do you have that too? It's an extra purchase. Oh, and it isn't a "hotkey", it can be any joystick button or a keypress, assigned in FSUIPC to send a message (called "KeySend with a message number) over the Network to a WideClient installation which has a parameter in its INI file telling it what to do with that specific message. As well as keypresses this can start or stop an application on the client PC too. Pete

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