Pete Dowson

The names you refer to beginning "KEY" are the same names as used in FSUIPC's assignments, just without "KEY ". But there's never been an FS control to switch a single display between two different radios. The controls refer to one or the other. Pete Pete

I'm afraid I don't know Linda, but the change between the 'k' and 'm' releases is very minor indeed and really cannot affect every single assignment. Perhaps you can show me the FSUIPC4 log file, from the modules folder? Pete

Hmm. Strange that there are so many G1000 controls listed (in the FSUIPC drop-down assignment lists, but none to switch the radio selection. I';ve never used the G1000. Mouse macros may or may not work with that default gauge. They only work with gauges written strictly to the Microsoft Gauges SDK, and unfortunately Microsoft themselves often broke all those rules. Many more recent gauges are written in XML, and those often use local panel variables to set and control things. Known as "L:Vars" these have names and can be set by FSUIPC assignments. There is an FSUIPC assignable control to list them on screen, and a Lua plug-in to monitor them as they change. So that's another possible avenue. Also browse through the User Contributions sub-forum above see if any other user has solved this one. Pete

Because you are using the slope on an axis where the part below the set "centre" position is being used for Reverse. There are no slopes for the reverse section, only for the forward section, the part above you selected centre. If you selected the "no reverse zone" option you would find the slope occupied the whole range. It depends u[pon exactly what you want to do. Pete

That doesn't seem to be a very friendly or productive way of introducing yourself, does it? Also, it isn't really a good idea to post questions about entirely different subjects to the title of the thread? Surely your subject not even worthy of its own thread, which, with an appropriate title, might even attract answers from folks you might not find as offensive as I? Your entire quote from an earlier reply here by myself is actually out of context. The question was about the assignment of a hat to pan view, not determining the result of a button press. You can make the action of a button conditional on another button, or even the value of an offset, but you cannot change the assignment itself. What the condition does is simply say whether the assignment it is attached to will activate or not. And conditions are only available for buttons, not axes. The use of letters instead of numbers has its own full chapter in the user guide and is pretty clear. What don't you understand? Doesn't matter. Any time you like. Before you set that you are using numbers to refer to the joystick devices, after you change it you are using letters. It doesn't destroy anything, just changes numbers to letters and makes entries so it can change which devices they relate to should you plug them in differently next time, move machines, or change versions of Windows, all or any of which can change the ID numbers which Windows assigns. As explained in the guide, you can let it do it automatically, so get A, B, C etc, or choose letters yourself, so Y for Yoke, R for Rudder, T for Throttle etc. All up to you. Please do use the User Guide for more information. Pete

As pointed out in the Installation guide included in the ZIP file you downloaded, all the documentation is in the FSUIPC Documents subfolder, withing the FS Modules folder. First stop is the User Guide, which contains chapters on each separate aspect of the facilities provided. I suspect the first part you want to look at, after possibly the Introductory sections, will be the chapter on joystick calibration, where you will find numbered step by step instructions. There are even some pictures to help. Pete

123. The values is a keycode. I'm afraid I haven't put all the names of all the keys in -- some would be difficult in any case as they vary country to country. Of course you can always name the ones you want to use yourself, like F12 = 123 at the beginning. then you can use F12 instead. Pete

Sorry, it isn't irritation so much as perplexity. I just don't understand. If you have something specific you want to achieve -- perhaps even the reason you bought FSUIPC -- but don't know how to do that, then I or someone else would probably be able to help. But just saying you've purchased it but don't know what to do with it is not really a question which can be answered. You need to say what you are trying to do, ask specific questions. Pete

If it doesn't run the reason for it failing will be logged in the FSUIPC log file. Have you checked? Just a quick look, I see this line -- Function to time the button being pressed or left released but there is no function. Later there is this line: function buttonpress(j, b, du) preceded by an "end" which doesn't seem to match anything starting! Then these lines if timebutton(true) then -- got another press in time, look for release if timebutton(false) then are calling a function which doesn't even exist. Overall it looks a right mess. I think you need to look at what you are doing before starting to edit things you don't understand. But at least do look in the Log for error messages, they'll tell you what the error is and where (i.e. which actual line). Pete Pete

I found the reason for the problem with that plug-in. Really it was taking advantage of an oversight (=bug) in FSUIPC, which I fixed a couple of updates ago. Because no one had actually noticed this bug, and in fact the correct behaviour can still be achieved by changing the "Exclude" option, I've relented and changed the behaviour back to the way it was. So now, with FSUIPC version 4.939m, that plug-in should work as it did. Pete

You sent the same message 4 times in the space of 20 minutes!! Please DO not try to flood the Forum! I've deleted the other three. You should really have read at least the simple User Guide first, to see if it was something a bit too much for you to understand. If that's all you have and all you want to do, why on Earth did you buy FSUIPC? What is it you wanted to do that you found you couldn't do by using just the FS facilities? The default configuration is fine You can still assign in FSX. The default settings don't interfere, do no harm, and some good, behind the scenes. There's no such thing as a "standard configuration". It's a bag of tools. Everyone has different needs and uses tools in different ways. You pick out what you need and ignore the rest. Pete

If it were possible, and assuming the reason you want WideClient on PC2 is to run some FSUIPC client application, how would your FSUIPC application know which "FS98MAIN" class Window to connect to? The whole reason it is not allowed is to avoid that problem. You CAN run WideClient on the same PC as FS, or multiple copies of WideClient infact, by changing the INI file parameter "ClassInstance=0" to some non-zero number. This changes the Class name, thus avoiding the conflict. I believe there are one or two FSUIPC applications which can be configured to deal with this, but hardly any. However, you CAN run Lua plugins on such a WideClient, and it will also allow the ButtonScreen facility and joystic buttons and so on to be transmitted. Pete

There are no throttle calibrations in the INI file whatsoever. Furthermore, you have assignments "direct to FSUIPC calibration" which have no calibrations, they have not even been "SET" in the Calibration tab let alone actually calibrated! Also, FSUIPC has detected no joystick devices at all. The entire [JoyNames] section is missing! So either you've edited the file before posting, or FSUIPC has never even seen a device! Your default assignments are on some unknown device 2: [Axes] 0=2X,256,D,1,0,0,0 aileron 1=2Y,256,D,2,0,0,0 elevator 2=2Z,256,D,4,0,0,0 throttle (generic, all engines) 3=2R,256,D,3,0,0,0 rudder but the corresponding [JoystickCalibration] section has no set entries whatsoever, so none of those assignments do anything except maybe forward thin gs to FS. Why bother assigning in FSUIPC "to calibration"? The only Profiles are: [Profile.Sub] 1=Submarine_Ohio_Class with similar assignments, plus one for a hat: [Axes.Sub] 0=2X,256,D,1,0,0,0 1=2Y,256,D,2,0,0,0 2=2Z,256,D,4,0,0,0 3=2R,256,D,3,0,0,0 4=2P,0,F,66416,0,0,0 but this time not even a Calibration section. And [Profile.C69] 1=Lockheed L049_6 2=Lockheed L049_5 [Axes.C69] 0=2X,256,D,1,0,0,0 1=2Y,256,D,2,0,0,0 2=2Z,256,D,4,0,0,0 3=2R,256,D,3,0,0,0 Again, identical assignments, no calibrations. [Profile.Carenado] 1=Carenado A36 Bonanza Stripes Ah, this has more: [Axes.Carenado] 0=0X,256,D,5,0,0,0 PropPitch 1=0U,256,D,6,0,0,0 Mixture 2=0V,256,D,9,0,0,0 Throttle 1 3=2X,256,D,1,0,0,0 aileron 4=2Y,256,D,2,0,0,0 elevator 5=2R,256,D,3,0,0,0 rudder But that just has default calibration (no attempt to actually follow FSUIPC instructions) for the main controls, plus, oddly one for Flaps (not even assigned), but again NOTHING for Throttles: [JoystickCalibration.Carenado] Aileron=-16380,-512,512,16380 Elevator=-16380,-512,512,16380 Rudder=-16380,0,0,16380 Flaps=-16383,16384/16 The only other Profile: [Profile.Aerosoft Airbus] 1=Airbus A319 easyJet G-EZAX 2=Airbus A320 easyJet G-EZTB has some very fancy axis assignments: [Axes.Aerosoft Airbus] 0=0X,256,D,22,0,0,0 spoilers 1=0R,256,F,L1:R,0,0,0 Lua AirbusX_Thr1 2=0U,256,D,23,0,0,0 flaps 3=0V,256,F,L2:R,0,0,0 Lua AirbusX_Thr2 4=2X,256,D,1,0,0,0 aileron 5=2Y,256,D,2,0,0,0 elevator 6=2R,256,D,3,0,0,0 rudder 7=2P,0,F,66416,0,0,0 pan view and these calibrations [JoystickCalibration.Aerosoft Airbus] Flaps=-16383,16384/16 Aileron=-16380,-512,512,16380 Elevator=-16380,-512,512,16380 Rudder=-16380,-129,-129,16380 which, again, apart for Rudder (which has a narrower dead centre zone) are default values. You talk about Concorde and "other 4 engined aircraft", but there are none here in Profiles and the only Profiled aircraft is Airbus which appears to be using some Lua plug-ins for throttle control (presumably designed to set thrust modes). Really, you aren't actually using FSUIPC much at all, and nothing for throttles apart from the Lua plug-ins. If you have throttle action at all in your Concord it must be FS which is doing it. Pete

WideFS supports 1 server (running FS) and any number of clients. My own system has 8 client PCs connected simultaneously. Your "PC Client 2" must have a version of FS (or already another copy of WideClient) running as well. That is the ONLY way that error can arise. Do not run WideClient on a PC running FS. Pete

No, not at all familiar. It is always possible to disable controllers in the FSX control assignments dialogue. Are you sure it s set correctly, or are you saying it won't change no matter how you click it? FSUIPC's INI file is not at all relevant, it is nothing to do with what FS itself is doing. Pete

It only searches the folder it finds itself in if it cannot correctly identify the program (FS version) it is residing next to. It cannot find the correct ProgramData folder without knowing the simulator version. Is the only FS application name is that folder "Prepar3D.exe", no "FSX.EXE" or other named version? Pete

Can you ask an actual question? I tried to read all this not knowing what I was looking for or why. It doesn't work, I've no idea what I'm looking at. Please state precisely what your question is. Pete

Thanks, but without the actual log it isn't all that useful. Do you remember where it got to (in the log, relating it to the later one) before the crash? I see that in the log you posted you had a stall pretty early on, with SimConnect not supplying data: 123225 **** No SimConnect events or states being received! Re-connecting now ... **** 123335 SimConnect_Open succeeded: waiting to check version okay This caused FSUIPC to reinitialise everything in its SimConnect interface. Do you get these very often? They are not good. Also I see you were running short of memory after only 35 seconds of being 'ready to fly'. That's not good either. Neither of these values seem good: Minimum available memory recorded was 182Mb Average frame rate for running time of 59 secs = 15.3 fps Could the earlier crash have been due to memory problems like this? Regards Pete

Aha! Thanks! That certainly helps as it will point me to the part which it seems I must have changed. Okay, no problem. it will be fixed in the next update, after Monday, maybe even on monday. I'll let you know in case you are still operational. Pete

The order number is not relevant, it isn't used. What is important are the other three items -- name, email and key. Just getting the key correct is not enough. All three parts must be exactly correct. Please also ALWAYS report the version number you are installing, and if you still have a problem I need to see both the Install log and the FSUIPC4 log files from the Modules folder. They are text files. You can paste their contents here -- just use the <> button above the edit area to enclose them, separately. Pete

Could you try 4.939g with that option unchecked? If it then behaves like 4.939j then I think using that check box (again) may be the answer. No rush. I won't be able to get to it till late Sunday or more likely Monday. Pete

Okay. I added a [LATER] note to my previous message above, which is also relevant and which you may not have seen. It's a puzzle for sure. As far as I can see it should never have worked like that. Did you try with the changes I suggested (not with the J41 by the look of it -- again we'd need to know why)? Off to bed now. I'm afraid i'll be pretty well tied up over the weekend, so I may not be able to progress this properly before Monday. Pete

Further thoughts on this. If i understand the plug-in correctly, I am puzzled over how it ever worked by sending those controls. It appears to depend on seeing the changes in the calibrated throttle values in 3330-3336. The correct use of those is to allow manipulation of the values, as it is presumably doing, before then sending directly to FS via the throttle offsets (as would happen by the changes I suggested above). But is it sent the manipulated values using the Axis controls, by definition those should have been intercepted, inhibited from sending to FS, fed through the calibration, and end up with another (possibly changed) value in the 3330-3336 offset. I In other words, a loop with nothing ever getting to FS. So, I think my conclusion is that, unfortunately, and maybe by experiment, the plug-in was programmed to use an oversight, a bug in FSUIPC, where the old FS98 style throttle controls were not accorded their correct treatment according to the documentation. One thing might save this. Do you have the "exclude ThrottleN set" option selected (checked) on the 4 throttles calibration page? If not, check it and retest. If that doesn't work, then maybe (just maybe -- I'd need to think through the ramiifications) I can fix it so that ignores the throttle disconnect (it should already bypass calibration, as that is what it is for). [LATER] I've now had a chance to go through the code changes I made which are referred to by that entry in the Changes document, and they most certainly would ONLY affect the Aileron, Elevator and Rudder Set controls, not the Throttles, which were always treated the same in the section of code which was changed. So it wasn't that change. It must be something else. The mystery does get deeper. I definitely think we need help from the author of the plug-in too. Pete

Certainly the change you mention (for the FS98-style Aileron, Elevator and Rudder controls incorrectly bypassing calibration) occurred between the G and J versions, so I'm wondering if this Lua was taking advantage of a bug in FSUIPC. It looks like it is sending the ThrottleN_ set controls to FS, after reading values from the 3330-3336 offsets. Thse are post-calibration axis value offsets. But it is inhibiting throttle controls, so it is sending the controls which are inhibited! This should never have worked if it were not for the bug in FSUIPC. So, if, as it looks, the reason for the new problem is that the plug-in was depending on what turned out to be a bug in FSUIPC, then an alternative way of doing the same thing would have to be found. I think that might already be allowed for in the script. See lines 51, 78, 105 and 132. They are: 65820, -- 0x088C -- Throttle set offset or control (J41 needs control) 65821, -- 0x0924, -- Throttle set offset or control (J41 needs control) 65822, -- 0x09BC, -- Throttle set offset or control (J41 needs control) 65823, -- 0x0A54, -- Throttle set offset or control (J41 needs control) If those entries were switched around, thus: 0x088C, -- Throttle set offset 0x0924, -- Throttle set offset 0x09BC, -- Throttle set offset 0x0A54, -- Throttle set offset then it should, theoretically, work -- but the comment "J41 needs control" is worrying. We would need to know why that is so and find an alternative. To summarise, if I've understood correctly, the axis is explicitly disconnected via offset 310A, So it follows that sending the axis control which is disconnected shouldn't work. It would need to temporarily reconnect it. I see the disconnects but no reconnects. Perhaps you could email the author and ask? I'd be happy to work with him to find a solution assuming this J41 (JetStream?) needs something different. In the worst case we'd need some alternative controls which would bypass the axis disconnect and get re-translated before reaching FS. Ugh. Pete

Please refer to the actual Changes document, not the brief summary in the download links subforum. The changes document is always included in the updates. Item 32 provides the description of exactly what that fix entailed. You'd then see that this change was to correct an error where the older FS98-style Aileron, Elevator and Rudder controls could bypass the calibration facilities. The change had nothing at all to do with Throttles. In fact, there has been no change in any recent updates which could account for anything different in the way throttles might be handled. Maybe you need to debug the plug-in you are using, or possibly to ask the author to advise? Pete