Pete Dowson

All for the FSX process? Wow. The log shows only that FSUIPC4 is loading and starting okay but that it never gets further than asking for a SimConnect connection -- FSX is crashing before SimConnect returns. The mention of DINPUT is interesting -- I'm wondering if the crash is occurring in one of the hardware drivers, from where FSUIPC is doing its scan of devices so it can identify them. Mind you, it's done that before it gets to trying a SimConnect connection. Still, it may show something. Try adding these lines to the [General] section of the FSUIPC4.INI file, and show me the resulting log: Debug=Please LogExtras=x200000 The other thing you could try, in case the crash is ccurring on a regular button scan, is to stop button scanning by setting: PollInterval=0 in the [buttons] section. Pete

By "latest" what version number do you mean, please? I always need version numbers. Are there any logs? If FSUIPC produces a log (FSUIPC4.LOG) in the Modules folder I need to see it. Also please show the Insstall log. Have you checked the error report in Windows logs? That will tell you the failing module, the error code and the offset. Regards Pete

Are there entries in the Windows error log? Because that is the place to look first. You should be able to find the name of the actual DLL responsible and both the error code and offset address. When you installed FSX from a backup, did that include the files in the <user>\AppData\Roaming\Microsoft\FSX, ProgramData\Microsoft\FSX and Documents\Flight Simulator X Files folders? Because apart from the SimConnect "trust" bug, which when recovered from once is never known to fail subsequenty with the same program, the only other thing I know what can cause crashes during initialisation are those caused by corrupt Weather (.WX) or Weather station index files. In the former case FSUIPC doesn't even get to run, so you get no log, in the latter case you get a partial log, up to the point where FSUIPC first asks SimConnect for the weather. InitDelay fiddles are ony to avoid SimConnect clashes with other Simconnect applications. If you've no other addons they won't make any difference in any case. This never makes any difference because the DLL is exactly the same, and that's the only part involved. If the DLL was corrupt it wouldn't load in any case because its signature would be wrong. If that's as far as the SimConnect log goes then it has not even tried to load FSUIPC. In fact it has done nothing. The other log you showed was NOT the FSUIPC Install log, but the FSUIPC4.LOG, the run time log, which contradicts the SimConnect log because it shows FSUIPC4 did load. At least it did on one occasion at least -- you'd need to compare the data/time stamps on the files to see whether they correlate. The FSUIPC4 log shows that SimConnect never returned after FSUIPC4 ask for a connection. I suspect it crashed. The Install log, which you omitted, might be useful, but most of all the Windows error report, as I said at the start. However, based on what you've said so far I think the SimConnect installtion is corrupted, and is crashing FSX as soon as anything tries to use it. The only other thought I would have is a hardware problem, such as bad RAM stick. A faulty RAM can give any number of varied crashes depending on memory usage of course. Is your 16Gb of RAM on multiple sticks? If so I'd try a process of elimination with one removed at a time. Regards Pete

Sounds like the very common Saitek instalation problem which can I believe be fixed by a Registry edit. There are a number of threads referring to it here, some pointing to solutions, but I think your best bet is the Saitek support forum. I don't know why they've not fixed this long ago, it's been happening for a long time. Regards Pete

It occurred to me that FS will be using the "PAN" commands instead of the VIEW commands, and that from what you say these might operate differently in cockpit and spot modes. Have you tried them? I'm not sure why you tried a third-party method first. There are two possible methods using PAN commands provided in the FSUIPC User Guide -- search for the boxed section enititled Example of assignments for HAT programming for smooth panning Try those please before venturing into complex programmed options. Regards Pete

As the manual states: Having made it negative, thought, you'd need to correct the range by adding more, so you'd need something like *-0.01,+327 I've not tried this. You may need to tune it a little. Pete

Fixed in FSUIPC 4.831 and 3.999m, available now in the Download Links subforum. Regards Pete

Yes, I can verify this. Looks like a bug. Sorry -- I will fix it today. actually '9' is for Shift. Ctrl would be 10. Regards Pete

They are quite straightforward -- in factr more readable than macros. There are a lot of exaples provided in the package installed in your FSUIPC Documents folder (in the Modules folder), and even more contributed by Users in the User Contributions subforum. Regards Pete

As well as using a Lua plug-in as suggested by marcelo, for such simple things as multiple assignments you can simply edit the FSUIPC INI file to assign as many different keystrokes or controls (mixed if needed) to the one button. Just make one assignment in the FSUIPC options, then load the INI file into a text editor like notepad, find the assignment (by joystick and button number), and add more lines with new line numbers (the nmumbers before the =) in the same format fpr the additional keystrokes you need. The list of key and shft codes is provided in the Advanced User's manual, and there are examples in that manual too. Regards Pete

Not sure why you posted twice. I'm just about to go to bed now, and I'm out all day tomorrow. Post again, please, on Thursday. But first please look again in the Advanced User's manual, in the section on Button Programming, and find the part where there are examples of the format for offset conditions. I'd like to know what is difficult for you so I can see what can be explained better there. I'd really rather get the documentation better than do the actual work because the latter way means I have to do it all the time. This particular subject hasn't cropped up here before otherwise presumably the document would have been improved already -- after all, that part is over 10 years old now! ;-) Regards Pete

I know! And that is why i told you EXACTLY what to do! But you didn't do it! Why do you ignore what i say? What is the point in you keep coming back for advice then not taking it? Why not simply make the little change I told you about to the one you posted earlier? Two lines to change -- an end inserted and one deleted. I tested here, it then works! It only didn't work because you did not make the original changes as instructed. All you needed to do was be more careful and do it properly! So you did fix it as I suggested, after all? That's good, because I am out all day tomorrow (Wednesday) in any case. So why post another, older copy, before you edited it incorrectly? Pete

I'm afraid that, except for a minority Japanese version sold in Japan only, SimMarket have exclusive rights on these, and it is worth me keeping the agreement intact because of the generous agreements we have in place. Spain will also, of course, be seen as one of SimMarket's main target areas -- the Portuguese proprietor is actually resident in Lisbon I think, not a million miles away! ;-) There was a Spanish translation of the FSUIPC User Manual at one time, but it's so many years ago now that I think it's disappeared as being inadequate for modern versions. Sorry to disappoint you in this, Regards Pete

Why haven't you posted the script you are using which doesn't work, instead of posting a script you cannot possibly use because of editing errors?. This is utterly frustrating!! If you want help you have to be more forthcoming. If a Lua script gets errors it won't work -- at al! The script you just pasted here will not load, therefore it will not work AT ALL -- it isn't a looping problem, it's a simple mess you made when adding the changes! I just told you how to fix it. Instead of "keep on trying" why not just do as I said? I don't understand why you ask for help then ignore it!!! :sad: Pete

Er ... and you run this, and everything works except that the turbulence sound does not stop after you land? I don't see how, because it has errors in it which will stop it loading. You appear to have placed the routine called "function onground" in the wrong place! Didn't you bother to look at the log? This would have told you what was wrong and in which line. You now need an "end" inserted before the line function onground(offset,value) and you need to delete the extra unwanted end at the end of that function. Then at least it will load and have a chance of working!! Pete

"Sensitivity" is controlled by FS then. FSUIPC is not doing anything. Check your dead zone and sensitivity sliders in FS. Pete

Please can you simply paste in the Lua script you are trying to use? I want to look at what YOU are using! I don't want references to other things and instructions! I need to see exactly what you are running! Pete

Okay -- but version 4.7xx is pretty old now and not supported. Please update. The current full version is 4.827 (with Installer), and there is a later interim update also available. See the Download Links subforum. So how did you originally assign them? Why do you think that? The most obvious reason for what you are seeing (and in fact the only one I can think of) is that the hardware, or its driver, is constantly sending signals -- i.e. jittering -- so much so that when you "rescan" the same jittering axis is picked up. That could be hardware, cable, USB port, or driver. You could try parking all the levers at one extreme to 'fix' the value so it doesn't jitter, or alternatively you can simply use the "Ignore Axis" button to temporarily avoid scanning that axis whilst you assign another. That is exactly what the "Ignore axis" facility is for! Regards Pete

I can't help without more information. You don't even say what version of FS you are using, let alone FSUIPC. FSUIPC will recognise the same axes and buttons as FS does, as it uses the same Windows facilities -- so, have you tried FS? Why are you assigning in FSUIPC in any case? Why not assign in FS? Regards Pete

Sorry, I've no idea. You'll need to post your Lua program here and explain what it is you want to do. Regards Pete

The yoke is simply a standard joystick device with buttons and is recognised as such by FSUIPC just as it is in FS and any other program using joysticks. There is no "connection" needed. I'm afraid I don't know anything about the other things though. You need to go to Saitek support. I've never heard of any hardware "connecting" to Active Sky though -- that's a weather program for FS, not a hardware interface. What does it od, move the clouds around? ;-) Regards Pete

That's the way i use it, because I am inside a cockpit viewing the outside would through a window onto a projected screen. I need to know that on release I am actually looking forward. UIt is very easy to get disoriented otherwise. Generally, though, most folks prefer the standard pane view, with continuos adjustment. Really? How do you do that? Maybe that's only in FS9 -- it's so many years now since I used FS9 I don't recall. Why not just assign the hat switch in FS if its treatment is better for you? If you want two modes for any switches or buttons in FSUIPC assignments you'd need to do it via conditionals -- the Advanced Users guide for FSUIPC explains that, but it does involve editing the INI file. You can't do it in the Dialogue at all. At least in FS9 there is an FSUIPC offset which tells you what mode the currently selected window is in -- 8320 is 1 for cockpit, 2 for virtual cockpit, 3 for tower, 4 for spot and 5 for top down modes. So an offset condition could be used to make it operate differently. Regards Pete

Compared to what other version? When it is at 50%, what is the OUT value in FSUIPC calibration? You should ve calibrating for 0 at idle unless you are using the "no reverse zone" option. How are you assigning the throttle? In FSUIPC or in FS, and if in FSUIPC, by which method and to which control? When calibrating in FSUIPC are you correctly following the steps to calibration? Are you using a reverse zone on the throttle, or using the "No Reverse Zone" option? There is absolutely no difference in what FSUIPC does. There is no sensitivity adjustment in FSUIPC at all -- that is part of the aircraft modelling. The correction to the incorrect axis offset values was made in the middle of last year, long before 4.827, and the problem it fixed was reported by no one until that point. It seems that bad programming practice had led some aircraft implementers to simply assume the bug was correct and that the documentation was wrong, so for over 4 years no one bothered to tell me! :sad: All that "AxieWrongRange=Yes" does is to restore this old bug so that the obscure and infrequently used offset returned to its same, old, bad faulty value. There are no other changes whatsoever in how axes are reflected in the offsets, not in any of the other axis assignment and calibration facilities. If you have a complaint about a specific aircraft you will need to go to their support. Pete

Keystrokes are the same for E and e -- it is the same key, not two different keys. All "Caps Lock" does is add the Shift indication. If you want shift E press Shift and E. It wll show as Shift and e. Pete

Try FSUIPC 3.999k or 4.829 -- both now available in the Download Links subforum. Regards Pete