Pete Dowson

Are you sure you are using the registration for FSUIPC4 / WideFS7, and not for FSUIPC3 / WideFS6? The registration system has not changed since it was first created in 2003, so you definitely have something wrong. I can't even check because you come here with a false name. Pete

You are getting something wrong. You must enter all three parts -- name, email, key - EXACTLY as originally provided when you purchased it. If you are not sure, use cut and paste. If you don't remember how you spelled your name you'll need to re-retrieve the details from your SimMarket account. Pete

I expect "- -" to work okay, but it isn't good arithmetic and is in danger of looking like -- which Lua uses to denote a comment. Subtracting a negative number is the same as adding a positive one (elementary school arithmetic?), so you should have:

Yes, sorry about the typos. Trying to do things quickly -- away tomorrow for 2 weeks, and lots to do beforehand! You've got some jitter on throttle 2 -- FSUIPC responds to the first axis change it sees. If it stops even the rescan finding the other axes you can temporarily tell it to ignore the misbehaving axis. It's all described inthe user guide. Could my saved flight be messing my LUA script up somehow....still not functioning. No. Nothing except you can change a Lua script. No, only if you opt for Button & Key logging, or enable the Lua debugging option. See the Logging tab. If this was not optional you'd get huge logs, entries every time! But, sorry, more errors in my original advice. I was in a hurry! It is using the event system, which means it should be loaded and stay resident. If you only need it for one Profile, add this section to the INI file: [Auto.name of profile] 1=Lua throttle1 2=Lua throttle2 If you always want it operating, just use [Auto] with no profile name. Then reassign the throttles to Luavalue throttle1 and Luavalue throttle2 Sorry about the original advice -- I was mixing up two different ways of doing things. Pete

Yes, should be okay. The axis output number you want is the one shown in the axis assignment tab. You won't be able to calibrate, so don't bother. Any calibration adjustment you find you need will have to be done using more arithmetic in the Lua plug-ins. You could do, but I don't think you need to -- this capability is already built into the FSUIPC calibration facilities. That has cut-off as minimum, and an idle zone above that. Just calibrate to your desired lever positions. The only reason it isn't like that for throttles is that the regions are usually reverse thrust -- idle - forward thrust. If you did want to do it the more complicated way, like the throttles, you'll need to look up the correct FS control numbers to use -- there's a complete list installed in your FSUIPC Documents folder. Pete

Either. If any of them matterd it would only have meant you okaying trust confirmations. Okay. So three possibilities: 1. THere is an error in the DLL.XML file which I didn't spot, or 2. One or other of the modules loading is conflicting in some way (though this seems unlikely -- you should still get the trust question), or 3. There's something is the Registry or elsewhere which is telling SimConnect not to trust it. To eliminate 1 and 2, please rename or save your DLL.XML file, then rerun the FSUIPC4 installer. It will create a new one with only it loading. For 3 see this thread in the FAQ subforum: http://forum.simflight.com/topic/74745-fsx-automatically-mistrusts-modules-fsuipc-not-loaded-solution/

Definitely the second option. I've implemented this sort of thing (Flightlink and PFC radio stacks and MCPs) and the first method is not good at all, you get overruns due to queuing. With the second, just update the value in the Sim when you haven't seen an update from the device for a time, say 500 mSecs (but experiment with that, it depends on the device and so on). There's not really any point in updating it before, unless it is adjusting something visually in FS which you need to see as well (eg the heading pointer on a PFD). Then I suppose you'd need your regular timed updates. Of course, if something else in the Sim updates the value (eg loading a flight) then display that straight away, discarding any as yet unwritten value from recent local changes. Pete

That should have been there in any case. Something obviously went wrong with the FSX-SE install. Yes, what you did was to correct an obvious omission when you did the FSX-SE install, although I think normally it would be "SetupPath" in the HKEY_LOCAL_MACHINE section. The FSUIPC4 installer copes with either. I don't know of any other cases like this -- the installer has always correctly created the installation or application path entries in the Registry. Perhaps you should report this to DoveTailGames in case it's a new bug in their installer. Pete

The log file shows all was fine, but that was on 2nd May. Have you not tried since then? Not sure why you want to paste the [Trusted] section, and it is too big for me to search through. Why not just delete it all? Pete

No, the current installer will install wherever your versions are. It finds the locations from the Registry entries for the installation. If your Registry is wrong then many programs will fail. Did you manually move the FSX-SE installation instead of using its install process? That is not a good thing to do. I suggest you reinstall FSX-SE following normal procedures otherwise you will get lots of problems from lots of installers. Also make sure you are trying to install the latest version of FSUIPC -- FSUIPC 4.939n. If you ever do have any installation problems at all with FSUIPC, when using the latest version, I need always to see the Install log file. That is why one is created! Pete

Which "app"? Lua is a public language and has its own books and website. I think there are full tutorials on their website. The Lua libraries added by FSUIPC are documented in the Lua package installed in your FSUIPC Documents folder, in the FS Modules folder. Similarly, the FSUIPC User Guide describes FSUIPC user facilities. Pete

Of course, because 4.939i is out of date and pre-dates the release of FSX-SE build 62613!!! The earliest supported version at present is 4.939n. Pete

Well, you omitted to show the WideServer log file, but I don't think it will show a problem either -- neither of the logs show anything wrong, if fact they show a perfect session. However, the two logs you do show are for different times and days, Date (dmy): 10/05/15, Time 01:11:16.158: Client name is KENS_LAPTOP1 compared to 187 System time = 09/05/2015 22:57:47 and in any case the FSX session continued for some 7100 seconds after RCV4 started, but you closed the Client after only 180 seconds or so! You need to show logs relating to the same session, the one where you get the problem. Are you seeing "waiting for connection" in the WideClient tite bar when you think you are losing connection? Pete

I can outline what the plug-in needs to do. You'll need to fill in the values. Here, it is short enough: x = fill in here the number read from the axis at the point where you get 21% thrust y = fill in here the number from the axis where you want normal thrust to continue z = fill in here the maximum value seen from the axis function throttle1(n) if n > x then if n > y then n = x + ((n - y) * (z - x) / (z - y) else n = x end end ipc.control(66420, n) -- 66420 is Axis throttle1 set (use 66423 for throttle2 end event.param("throttle1) Do one such plug in for each throttle, then, in FSUIPC axis assignments, assign each throttle axis to the relevant Lua plug in -- eg if the plug-in is called "mythrottle1.lua" the assgnment is to Lua mythrottle1. I might have made a mistake in the arithmetic, but I think it's okay. You'd need to test. But first you need to determine the values you need to match the positions on your throttle levers. Pete

XUIPC.DLL is a basic part of FS, handling its user interface. It is nothing to do with FSUIPC. You need to report crashes in FSX-SE to DoveTail Games on their support email, along with the MDMP file which is produced in the main FSX folder. Pete

There is nothing looking wrong in either of the files you show. Perhaps there is an FSUIPC4.LOG file being produced which shows what the problem is? If not, then the most likely cause is that you have at some time refused permission for FSUIPC to load, and there's an entry in the FSX.CFG file which tells FSX not to load it? Check the [Trusted] section there Pete

I'm sorry, but FSUIPC cannot possibly interfere with any of those functions when directly input to FSX. You need to look elsewhere. Pete

I don't know. Have you tried? Pete

Why not? If you plan to write a Lua plug-in to do the job, and need help or get stuck, why not ask? I can help. I'm not about to do it for you, but I'm here to ask as you need. Your last reply seems to imply you;ve taken some sort of offence to what I've been advising. Why is that? I've only been trying to be clear about what you probably need to do from my understanding of what you describe. I don't really know why you thought I didn't understand in the first place. Pete

Your G3D error will not have been the one FSUIPC used to trap -- that one is fixed in the version of FSX-SE you are using, which is why FSUIPC doesn't attempt to trap it. You need to report your different one to DTG support. Send them the MDMP file you should find in the FSX folder. Send to dtgflightsupport@dovetailgames.com Pete

It just means that the wnd.bitmap function isn't in the version of WideClient you are using. It needs to be version 6.999g or later. Pete

I'd need to see the WideClient and FSUIPC4 log files from the server and the Wideclient log file from the client. That's what logs are for, to show what might be going on. You can paste them into a message here. Use the <> button above the edit area to enclose them neatly. The current version is 4.939n. Please update first. Pete

So, where I said this: "You could have three ranges set there, one operating the throttle axis from 0 to 21%, one keeping it at 21% over a sufficient range for you to be sure to make that work, and the other allowing it to increase normally.", way back when, you could have said, "yes, exactly", right? Except of course thar doing it by mere assignment is no good because above the fixed 21% mark it would suddenly jump to a higher value, depending on how wide a range at 21% you need -- as I also pointed out later. So, the only way is the way I suggested here: "You just have a Lua plug-in which uses event.param to receive values from your throttle axis. You would need to process that value and decide what to send on to the simulator -- using ipc.control with the control value for Axis throttleN set (N= engine number), or Axis throttle set for all engines. You need to work out some arithmetic to limit the result sent to FS to 21% until something happened (though what?)" except that now we know what the "something happening" is -- the incoming value being that where your "flight idle" notch is. Beyond that you'd need a formula to convert the remaining, higher, incoming values to the correct thrust range of 21-100% Pete

FSUIPC's settings can't have changed just because you install an updated aircraft. I think you might need to post on the PMDG support forum to find out what they've done. , The only currently supported version is 4.939n (the letter can be quite important). No, updating FSUIPC merely replaces the program itself and the documentation, though that doesn't change very often. It never ever touches your settings, plug-ins, profiles or macros. Your registration is not touched or changed. The installation allows you to bypass re-registration. Just click on "Not now" when it asks. Pete

You just have a Lua plug-in which uses event.param to receive values from your throttle axis. You would need to process that value and decide what to send on to the simulator -- using ipc.control with the control value for Axis throttleN set (N= engine number), or Axis throttle set for all engines. You need to work out some arithmetic to limit the result sent to FS to 21% until something happened (though what?) Maybe I don't fully understand your "problem". Have you yet tried just putting your "notch" on the position where things change? You seem to be wanting something very odd -- I don't know how much of the axis movement you want to waste! (Seems a little on the daft side to me, in fact, sorry to say).. Or do you simply want to limit it to 21% until you press a button? That would be much easier, and more sensible to me. Pete Pete