Pete Dowson

Assigning the hat to Pan View in FSUIPC's Axis Assignments certainly does NOT use 90 degree increments. It is the same as the Virtual Cockpit pan in FSX, smoothly changing the view. In a 2D cockpit there is no panning, but the are 8 selectable views, 45 degrees apart, not 90. Pete

If the actual inputs from the device are jittering, then it is almost certainly a hardware, power supply, or connection problem. The values showing in the Axis Assignments tab are never affected by anything anywhere else in FS as they are obtained DIRECTLY from the Windows DirectInput functions. You can stop jittering getting through to the calibration part by increasing the 'delta' value in the axis assignments. This makes FSUIPC ingnore changes less than a certain value. However, this will also reduce the resultion of your axes (ie. the number of discrete steps). Regards Pete

The existing FSUIPC Throttles Sync facilities can be applied to those too, automatically. It's an option on the Miscellaneous options tab. Regards Pete

So, did you try 4.909a? If not why not, if you are using similar Lua plug-ins for your throttles? I'm afraid that information is not useful as we have moved on and the offsets do not relate. You need to always test with the latest. Try 4.909a. That seems to be a long thread with lots of suggestions and solutions. Does it list the Lua plug-ins being used anywhere? I don't have time to read it all at present. Regards Pete

No one does initially, but there are lots of examples and easy on-line documentation. It's used as a simplle scripting language by lots of games as well as by FSUIPC. Well, I should hope so as they are yours. Remove everything that is NOT required to be sent to other users, then show me again. I don't really think it is a matter of what is easier for you, more what is easier for your customers, surely? Less work by you, more for them? Pete

I would need more information to help, as there is none here. I need to see the FSUIPC log file, from the Modules folder, if one is produced, and also a SimConnect log -- there is a thread in the FAQ subforum which tells you how to get one of those. When you say "the menu of options to configure controls" do you mean the FSUIPC menu in the Add-Ons menu? If so then there are several known reasons why that can occur, and they are all due to older versions of other add-ons which cause the problems. So, I also need a complete list of all the add-ons you have installed and which might be running at thjis time. Since FSUIPC and .Net Frameworks are in no way related and have no interaction whatsoever, that is even greater proof that it is all down to another program. "Expect"? You always get quick replies from me, here, when I am at work. If I am on holiday then you'd almost certainly have to await my return unless other users here could help. Sorry, there are no refunds, and you will make no friends by making threats, especially when the problems are on your system and you don't even provide any useful information whatsoever fdor me to help. I am away now till Friday, so there's another delay ... Pete

Oh, I see! It isn't the VIEWS you want, but the cockpit walls/windows around them. I'm rather lost again. What are "key commands" in this context? FS controls ("Key Events" or K:... in XML) are numerical values which are sent internally in WM_COMMAND messages. As such they can be assigned to key presses and to buttons and axes, of which the hat switch is actually treated as both by FSUIPC. You could actually have the hat switch send both the view changing controls it currently does AND send othere controls to switch your panel bit map, if in fact it is implemented that way. Additionally, or maybe alternatively, the controls ("Key Events") sent to FS from any source can be received and acted upon in FSUIPC Lua plug-ins using the event.control function. Wouldn't this be a way of programming your needs? Regards Pete

Yes, and this is what I don't understand as I don't see a difference. Sorry. Ah, so it isn't to do with just looking out the window in different directions? You want predefined cameras, effectively. And these can't be done with the camera options? Have you looked at programs like EZDOK and OpusFSX? They do a good job. I use EZDOK myself. Regards Pete

Unless you wanted to change to a Lua plug-in to do the work for you (rather than using assignments), the only way would be to provide a partial FSUIPC INI file with your settings -- only supply [JoyNames], [Profile.<your profile name>] and [buttons.<your profile name] sections. To get around the problem on the joystick number the [JoyNames] section must include the name of the device already assigned to a letter, and use the letter in the Button assignments, which would be in a Profile specific to the FA/18. At most they'd just beed to add your [JoyNames] part to their existing section for it, and add the profile-specifc sections to the end of their current INI file. Pete

Yes. That was the idea, for those who wanted to disable controllers altogether in FSX. Hmm. I'm obviously still not understanding. Here "panel view" selects specific views in 2D mode, AND returns to forward when released, whilst still panning in VC mode. So you have view selection in 2D and panning in VC. As far as I recall (and I know it has been a long time -- I gave up FS9 when fSx came out -- but I certainly had my rocker switches on my yoke programmed to do exactly that. Sorry, but it seems I'm lost. Pete

Strange, because it works perfectly here. Maybe I'm misunderstanding what you actually need? Ouch! Why? So you didn't actually try what I suggested, assigning the Hat on Axis Assignments to Pan view (not in Button assignments)? Pete

Try assigning the hat in FSUIPC4's Axis Assignments to the FS control called "Pan view". That pans in VC mode but selects specific view directions in 2D mode. Pete

Decided to stay up late last night and get it out of the way. Too hot here in daytime in any case! Try 4.909a for me please, from this link: FSUIPC 4.909a only This is a pre-release -- I probably won't be making a formal release till next week. I need to apply the changes to FSUIPC3 as well, and test that. Yes, if you change back to using the Throttle Sync hotkey -- or the new more efficient Throttlesync on, Throttlesync off, or Throttlesync toggle controls I've now added (the ones I thought I'd implemented ages ago -- and in fact had done so but stupidly omitted them from the list which makes them appear in the drop-down assignments list!) I located exactly where it was happening, but not exactly why. It's all to do with overlapping continuous executions of the same Lua files. Each time the axis changes the Lua text file is loaded, compiled and executed. If this happens frequently enough and the execution process is slow enough, FSUIPC has to forcibly kill the thread so it can be re-executed. Not nice. There are precautions taken in many places to make sure this doesn't lead to "dangling pointers" (non-zero pointers to objects which no longer exist), but I think you might have hit upon one case not adequately covered. I tried doing exactly the same as you here, using your very Lua files, and no ending of switching back and forthwith the Sync and waggling the throttle axes would induce a crash, so it is very timing dependent. But in any case I've tried to make it more bullet-proof. With that in mind, could you please thoroughly test 4.909a with your current setting before changing back to the way it should be, and see if you can induce the crash. or not. Thanks. BTW it was because of this sort of problem, and the inefficiencies or repeatedly loading and compiling plug-ins, that I introduced the Event system. The better event-driven way of implementing your plug-ins would be to have a function doing the processing, and an event.param to call it. You'd then assign the axes to "Luavalue THR1" and "Luavalue THR2", which instigates the events and thereby executes the function which is held permanently in memory and simply suspended awaiting such events. (You'd need to get the plug-ins pre-loaded then, either via ipcReady.lua calls or entries in an [Auto] section in the INI). I didn't want you to make such changes before I tackled the crash problem, though. No rush for the test results -- by the weekend would be fine, thanks. Regards Pete

You need to download the FSUIPC SDK (Software Development Kit), and see the documentation and examples. Also look at Paul Henty's .NET DLL interface which makes things much easier if you are using a .NET language. Regards Pete

No need to post the same thing 3 times. I deleted the extra ones. I'm afraid I don't know what you mean by your question. Offsets are places in memory where data is stored for reading or writing. What do you want to do? And what do you mean by "reaction of a/c"? Pete

Okay. Good. There's a </Launch.Addon> line missing after this line: <Path>bglmanx.dll</Path> otherwise it looks okay. No. and the log you have shown proves everything else is okay. Pete

Okay. I've verified this. it is a bug! A VERY long-standing bug that no one has reported before. Had you reported it before venturing into other solutions I would have tried to fix it immediately, and will do so now. Unfortunately it may take me a few days as I have other commitments this week. But watch for updates maybe before, or over, the weekend. I'm looking at the crash report now. Pete

Before I look at that, are you saying that when you rename or remove the DLL.XML file and rerun the FSUIPC4 installer, you still get no Add-Ons menu? If that is the case it seems likely that your FSX or Simconnect installation is corrupted. Can you check the FSX modules folder and see if there is an FSUIPC4.LOG file produced when you run FSX? If so, show it to me. If not, then FSUIPC4 is not being loaded. In the DLL.XML file you show there apeears to be corruption in several lines: <Launch.Addon><Name>Addon Manager</Name><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Path>bglmanx.dll</P should be <Launch.Addon> <Name>Addon Manager</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>bglmanx.dll</Path> and <Launch.Addon><Name>FS Recorder</Name><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Path>C:\Program Files\FS Recorder for FSX\FSRecorder_FSX.dll</Path></Launch.Addon> should be <Launch.Addon> <Name>FS Recorder</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\Program Files\FS Recorder for FSX\FSRecorder_FSX.dll</Path> </Launch.Addon> The FSUIPC4 entry is fine. Pete

Not a "keyboard shortcut". FSUIPC supplies additional controls which can be assigned to button or key just like any other control. That's not the throttle sync control, then. I'm afraid you'll need to be more specific. If you've selected "no reverse zone" then that's what you get, it doesn't suddently change to a setup with a reverse zone just because it is syncing. That would make no sense whatsoever. Hmm. It appears to be almost a Lua version of exactly what the throttle sync control does in FSUIPC, except that you are using both the generic AND the separate throttle controls, which isn't a terribly good idea. Best to send the same value to Throttle 1 and 2 instead, as FSUIPC would do for you. If you don't do this your calibration, which is separate for generic and separate axes, would need very careful settings to avoid a sudden difference when you switch. I am not sure without cross-checking in the code, but I've a feeling that the FSUIPC sync balances to a value between the two axes, though it may do as you are doing and merely copy throttle 1 axis. Are you not moving the throttle 2 axis at all when you operate this option? Why and when are you using it anyway? Hmm. That's odd. I see no reason for that. Perhaps you could please tell me EXACTLY how you've assigned to these Lua modules? I'd need also to know whether you are still using both throttle levers or only one when you switch, and whether there's observable jitter on your axes which could be causing the Lua modules to be continuously loaded, compiled, executed and killed. Maybe you've reduced the Delta in the assignments? The crash information is useful, and I'll get on to that in the morning. About to have dinner... Regards Pete

If the same is occurring in all places its either USB connections of a bad USB driver or chip on the motherboard. Sorry, but I'm no hardware expert, nor do I have enough information. Are you sure you don't need to install drivers for your devices? Have they ever worked? Did you make them yourself or buy them? There aren't many commercially available tiller implementations. You aren't very forthcoming with information I'm afraid. I did ask questions in my last reply. Pete

This is not really a hardware forum -- you might find better help for repairing rudders over in mycockpit.org forums. However, there are obvious things to check. I assume they are USB connected? Are they commercial rudders or homemade? Does Windows recognise the device at all (check the devices listed by Windows in the control panel)? Try a different USB port. If the device is connected through a hub try connecting direct instead. And try changing the cable. The pot itself is unlikley to be broken. It can get dirty and give erratic results, but no response at all is more likely to be connection problems or something simple like a broken wire -- maybe inside the device of course. Regards Pete

Just installing the update won't change that. Something else has corrupted your DLL.XML file. Try running the installer again. If still no joy, find your DLL.XML file (in the same folder as your FSX.CFG), and rename it so it won't run, and run the FSUIPC4 installer again. If you have any other DLLs being loaded by SimConnect then the original DLL.XML file will need fixing. It's a text file, so you can paste it into a message here for me to look at for you. Regards Pete

If the key is purchased from SimMarket, then it is bound to be valid, so you are making a mistake. All three parts -- name, address and key, MUST be exactly as supplied. Use cut and paste. Pete

No, it cannot do that. What is happening is that the levers are "jittering" (i.e. sending small changes all the time, even when not moved). This seems to be a common problem with Saitek devices. All you need to do is use the "rescan" and possibly the "Ignore" facilities when the wrong one comes up, then do the assignment, then clear the ignore list and do the next one, etc. Please see the User Guide chapter on Axis Assignment -- this is all described on the second page of that chapter, about half way down. Perhaps you missed it? Pete

My PM displays are set to initialise blank, and only come on when the power is available. If that isn't the cause you need help from PM support. Try the PM forum at mycockpit.org. If you run PM software without WideFS is runs in Demo mode, which is presumably why you think it "works ok" -- but it cannot connect to FS from a client PC without WideFS! Regards Pete