Pete Dowson

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

They are control (or key event) numbers, not "parameters". 66339 is the FS control called Toggle elect fuel pump. You can assign to it directly in FSUIPC's assignments list by name, by far the best way! There is a complete list of all of the possible named and pre-defined FS controls, arranged by both by name and by number, included in the FSUIPC Documents subfolder, in your FS's Modules folder. If you do need to assign a control number which is not an FS pre-defined one, such as those used and listed by PMDG for their 737NGX and 777 models, then these are known as "custom controls", so you select <custom control> in the assignment drop-down, and this will provide a way to enter the actual number. All FS controls can have a parameter as well, which will mean a different thing for different controls. Pete

Yes, that's fine. Best always to have a backup. Er, FSX won't let you disable controllers? Sounds like a corrupted FS install. Sorry, not sure what this has to do with FSUIPC? Pete

Why do you say it is a "conflict"? Why are you logging events in any case? Many add-on aircraft, especially those by PMDG, use FS contorls internally and keep sending them. I've never been sure why, but it happens with many of them. They must have their reasons. If you are wanting to use the FSUIPC event logging for something and don't want the events you are looking for obscured by this horrible add-on action, you can use the "DontLogThese" parameter in the FSUIPC INI file -- please see the description of this parameter on about page 11 of the FSUIPC4 Advanced Users document. Pete

FSUIPC is never going to delete any of your valid INI file sections. If the ones you say were not in the INI, how did you show them to me here? If they were not in the backup of your INI it must have been a corrupt or edited or abbreviated copy, not a true copy. The [ClientNames] section is nothing to do with Profiles. It is constructed to contain the names of your WideFS client PCs, and your entry says that at some stage you had a client PC named FRANS4 connected. I suggest, since you obviously somehow have the missing sections, you add them back into the file where they should be. Pete

By WideFS I assume you mean WideClient, which is the program which goes on the client PC -- i.e. the remote one, not the FS one -- in order to emulate FS running FSUIPC so that FSUIPC client applications can be networked. Obviously if you are running FS on the same PC as Wideclient then they can't both look like FS running FSUIPC. Since both use the same class names for their main Windows, this is effectively prohibited automatically. It's really nothing to do with "installing" -- there's really no installing of WideClient to do in any case, it is just a program, WideClient.EXE, which you can put anywhere you like. The only problem is running it together with FS -- as explained, they can't (normally) both run at the same time on the same PC. I say "normally" because there is an exception to this. By changng the WideClient.INI file "ClassInstance" parameter to a non-zero value both WideClient and FS (or several instances of WideClient, with different ClassInstance values) can run together. This is generally not much use in supporting FSUIPC applications, but could be useful to support features like WideClient Lua plug-ins (supporting extra libraries) and the button screen and weather radar facilities. As said, you can put WideClient where you like and use it when you need to, as outlined above. Pete

Yes. There's only the one section! See the FAQ subforum thread about Logging SimConnect.. Pete