Pete Dowson

There was little change in any case from the versions before that. I am positive that updating FSUIPC is nothing to do with it. If there is no log then FSUIPC is not running, which can only mean that you are loading FS9 from a different installation, not the one where FSUIPC is installed. An additional proof that this is so is that there is no FSUIPC.INI file either That's the file which would contain your settings, and a default setup is generated the first time FSUIPC is run. That would make no difference at all because none of the files associated with FSUIPC are hidden. The option you have to change, as documented in the FSUIPC user guide, is Hide extensions for known file types That needs to be unchecked to see the ".log" and ".ini" types of the main files you have missing. Pete

024C is documented as 4 bytes, (4 x 8 = 32 bits, so a DWORD, or double word) and it cannot be negative, so it must be a UD. This reference to a thread about numbers in the FAQ subforum will be useful: http://forum.simflight.com/topic/63908-about-bits-numbers-and-hexadecimal/ Pete

There are now some good working answers to the above problems, kindly posted in detail by Kevin ("Yakpilot"). They appear to be so clear and useful I have moved them to the FAQ subforum for a more durable reference. See http://forum.simflight.com/topic/80097-problems-with-windows-10-autosave-the-answers/ So, thanks Kevin! Pete

I think you are still misunderstand. The control 66477 does have any parameters at all. It is just a toggle. More misunderstanding here too! A "control" which is also known inside FS as a "KEY EVENT" cannot have a "state". It is a message, an event, a command. I keep telling you this but you persist in misunderstanding. It's something you assign to a button or keypress. It does not exist outside of requesting the designated action! You cannot test for it afterwards because once it has been sent, that's it, it's gone! 3122 is a collection of 8 swtich settings, one in each bit of the byte. (Remember -- a byte is a collection of 8 bits). When a bit is set to 1 then it means that switch is ON (or True, if you like). When it is 0 then it is OFF (or False). As I showed in my last reply, in the part you evidently ignored, to test the state of the switch you must test the state of the relevant bit. In the case of the Marker sound being enabled or not, it is bit 2, which is the 3rd bit up so worth 2 x 2 (2^2) or 4. (You DID refer to that FAQ thread I hope?). Controls cannot have states!! I keep telling you the same thing but you persist! :--( I think there are uses of the logic library in many of the Lua examples provided and written by others. But what is the problem? There are only a few logic actions. In arithmetic you have + Add - Subtract * Multiply and / Divide. you are aware of those, right? Well, logical operations have similar operations. The main ones you'll need are And and Or, and maybe Not. In other programming languages And is represented by &, Or by | and Not by ~. These pretty much accord with their meaning in English when operating on simply True and False values. With bits in bytes it's not much more complicated. But I cannot tutor you here. You'd be best Googling the subject. Meanwhile why not use what I gave you? I seem to be wasting my time providing answers on a plate for you! :sad: Pete

If there is no log file then FSUIPC has never been run, as it ALWAYS produces a log file. Listed files:- FSUI.DLL 01/09/2004 FSUIPC.DLL 09/09/2013 FSUIPC INSTALL 22/09/2015 FSUIPC.KEY 22/09/2015 FSUI is part of FS and nothing whatsoever to do with FSUIPC. It is FS's user interface -- all the menus and things. FSUIPC INSTALL will actually be FSUIPC INSTALL.LOG. You appear to have Windows hiding filenames from you -- please do turn that stupid option off. It does advise you to do this in the FSUIPC documentation. File Version :- 3.9.9.9 Product Version :-3.999z8 Date Modified :- 09/09/2013. And as you see, it is over two years old.! So please explain what you mean by this: So far nothing you show makes sense. And either the log is there and you don't see it, or FSUIPC is not being run. In the latter case it would mean that the Modules folder you are looking in is NOT the one related to the installation of FS which you are running -- you must have another. The fact that FSUIPC is not even running would of course explain immediately why AFCAD isn't connecting to it. Without knowing what the "last two updates" you refer to means, I'm afraid I haven't any further way to help you. Pete

No. Toggle controls ignore the parameter, they just toggle the action -- i.e. turn it off if on and on if off. That's why they are called "toggles". Since controls are things SENT to FS to make it do something, they aren't read-outs. And even if you did read them (FSUIPC intercepts them for logging), their parameter would not necessarily indicate the state. Whether the control does somerthing or not is up to FS and the subsystem involved. And, as just stated, in the case of Toggles, there's no parameter of use in any case. Reading offsets is generally the only way of determining the state of things in the main FS engiine. The L:Vars you've perhaps been used to reading are Local Variables (hence the name) and are very specific to particular gauges. That's why they don't reside in offsets -- if they were part of the main FS engine they would be there instead! I don't know what you mean by " I'm not sure that the read offset is a solid reference when the actual marker sound is not audible:". The flags in 3122 show the state of the option, not whether a sound is actually playing at the time. That's no good. Bit 2 (i.e. value 4) is only one bit in use in 3122. Testing equal to 4 would only work if you made sure all the other sound options were switched off! To test a single bit in an offset you need to separate it, like so: soundbits = ipc.readUB(0x3122) if logic.And(soundbits, 4) ~= 0 then ... I strongly suggest you review the thread on bits and numbers in the FAQ subforum (http://forum.simflight.com/topic/63908-about-bits-numbers-and-hexadecimal/, and also try perusing some of the Lua examples supplied in your FSUIPC Documents subfolder and written by Users in the User Contributions subforum. Pete

You misunderstand. No option in FSUIPC can possibly change the IN numbers -- those are what Windows' joystick drivers are providing. They are from the device or its software and are the values FSUIPC has to work with. The OUT numbers are the result of the calibration, not the IN!!! If you are assigning in FSUIPC too, check the IN numbers on the Assignment tab. Unless you are using some add-on formula to manipulate those, they are exactly what is fed through to FS or FSUIPC calibration, depending how you assigned ("direct to FSUIPC calibration" does what it says, whilst the assignment to fS controls makes the values go to FS first, then they get intercepted by FSUIPC -- or PMDG, or both! The NRZ option is supposed to set the minimum OUT value to 0 (idle when using FS's reverse-capable throttle controls). It cannot change what the device or its driver supplies, the IN value! In that case, since there is no way FSUIPC can influence the IN values, it is something else, outside of FSUIPC which is doing this. I only quoted the Saitek problem as originally what you described sounded like the same sort of Registration problem. But if your throttles are okay on other aircraft it plainly wasn't that in any case. It would just make the response slower as it is averaging multiple successive IN values before working out the OUT value. It is for very jittery axes caused by dirt or bad power supplies. Any change to the calibration values affect the calibration, of course. If you don't apply a slope, calibration is simply a way of mapping the actual inpout values to the desired (by FS) output values. This is a pure linear calculation when there's no slope applied, so the output will be just as smooth, or otherwise, as the input. Your problem is with the input, according to your description. I don't understand, therefore, why there's no problem with other aircraft. So now I am really confused. What is different? What have you changed, and why? According to all the other reports i have seen from PMDG NGX users, calibration of throttles (only -- doesn't affect other axes) is definitely not advised with that aircraft. There will be conflicts. BTW I don't have or use the PMDG 737 -- I have to use pure no-system no-cockpit aircraft models since I have a hardware cockpit running Prosim737. That provides the systems. Pete

While installing FSUIPC? There's no possibility of such a message originating from the installer! It simply places the updated module in the Modules folder (creating it if necessary) and installs updated documentation and other goodies in the FSUIPC Documents subfolder. Please explain more carefully exactly what you see and when you see it. Note that the Installer creates a Log showing every step it takes. It is called FSUIPC4 Install.log and you'll find a copy in the Modules folder and also next t the Installer itself, wherever you ran that. Please view that Log or paste it here so I can help you and reassure you that the installation was good or otherwise. There are two checks made when FSUIPC4 is run -- i.e. when you start FSX. Nothing to do with the Installer. The messages which can arise then are one of these: Pete

PFPX and TOPCAT, together. Moving map, charts, etc is Aivlasoft EFB. Pete

As far as I am aware, you cannot calibrate throttles for the PMDG 737NGX in FSUIPC, because that model demands to see the throttle inputs at a higher priority level. In order to calibrate the throttles FSUIPC has to intercept the inputs at that level, manipulate them according to your settings, and send them back to FS at a lower level. This creates direct conflicts in the NGX because there are two competing values arriving. To check calibration of your throttles in FSUIPC, select a default aircraft, or at least not a PMDG one. The full range being RECEIVED from your throttle lever should certainly be in the region of -16384 to +16383. That would be for a well calibrated (in Windows) axis, or a modern digitally controlled axis with no Windows calibration. The IN values shown on the calibration tab should increase gradually from the one to the other. All FSUIPC does is use the positions you SET as Minimum and Maximum to work out how to map that movemetn to the OUT values needed by FS, which are also -16384 to +16383, or 0 to 16383 for the No Reverse Zone option you've chosen. So, big question: do the IN values change slowly as you move the axis slowly, or do they jump in the way you've said they do in the aircraft? All that does is create a dead zone. It cannot change the behaviour of the input values. Check that the IN values change smothly as you move the throttles. If so then your only problem is trying to calibrate in FSUIPC for an add-on aircraft for which this is a no-no. If the throttle lever gives input values which jump, maybe all the way or maybe at the half-way point, then this is a typical Saitek installation error which is corrected by a Registry edit -- for this see the FAQ subforum thread http://forum.simflight.com/topic/79464-some-saitek-axes-only-provide-partial-movement/. Pete

Active Sky, in its earliest forms, used FSUIPC to control the weather, and could therefore interface via WideFS too. The later versions which used SimConnect on FSX were also FS9 compatible and automatically used FSUIPC on FS9 and SimConnect on FSX, but could use WideFS for FSX if told it was interfacing to FS9 even though the Server ran FSX. The current version of ActiveSky, ASN, is all SimConnect AND direct control into FSX/P3D -- it puts its own hooks in. It is this which allows is such precise control over the weather and especially in cloud placement (which is also why its weather radar is so accurate, down to specific rain cloud areas). Quite honestly, ASN runs best, and very well too, on the same PC as FSX, but it can be run on a SimConnect client. The instructions for doing this are quite clear I think. You still need also to install it on the Server so that it can use its direct hooks. Pete

You are adding to a 2-year old thread which was in error as it was. This thread was about removing FSUIPC, not about any error message, so why are you posting here? You provide no information except that you get an error message. What version of FS or P3D are you using? FS2002, FS2004, FSX, P3D? What version of FSUIPC are you using -- the number, please. I really cannot help without information. Pete

Why are you posting the same question twice, and in different threads? Please see my reply to your earlier message. Pete

FSUIPC3., the one for FS9, has not been updated for years, so what exactly do you mean by "the last two updates"? You need to look elsewhere. Perhaps you are running FS "as administrator" and AFCAD normally, or vice versa? That would prevent them communicating. If you think there's a problem I'd need to see the FSUIPC.LOG file, from the FS Modules folder -- but close down FS first. Pete

You should start the new log near the 6 hour point! Pete

I think other programs in those days (FS9? So long ago! ;-) ) wrote to the acceleration offsets instead, to brake aircraft at different rates. There was one famous program (which I don't even remember now) which used those values for catapult launches and tailhook braking. Pete

Right. So I misunderstood your questions right from the start when I tohught you were trying to assign a 3 way switch. Pete

Right. And the reason is not clear from the Log because it only shows the first 1 hour 20 minutes. This is from the very start of the log file. Within 7 seconds of everything being "ready to fly", Simconnect is already floundering, not able to keep up with the demands mad on it. This one is recoverable. But then: That's 60 seconds later. Looking through, this failure repeats every 60 seconds. Don't you notice any pauses every 60 seconds? I suspect this is due to a flight being saved at 60 second intervals. The PMDG aircraft are notorious for taking ages to collect all the data to be saved and created large files with the state of everything. Unless your system is really very well set up for disk caching and with fast writing disks, then this appears to take too long. Quite honestly, if you are using some autosave program, or the Autosave in FSUIPC, I would advise against it when using PMDG aircraft. But alternatively, you can change the SimConnectStallTime parameter in FSUIPC's INI file from its default of 1 (second) to something larger. This will make it be more tolerant during such episodes, but perhaps at the cost of upsetting client programs. The rest of the log shows the same things continuing, and it finishes after a mere 1 hour and 20 minutes. So there's no information there about what happens after 6 hours. The performance of your system doesn't look too good though -- how do you manage to tolerate it for 6 hours? ;-) Rather than submit a 6-hour log, with the 60 second repeated re-connections going on and creating a massive log file, when you get close to the 6 hour point, go to the FSUIPC Logging tab and click "New Log". That'll save the log till then and start a new on. Pete

This is confusing! So you are NOT trying to assign actions to a real hardware 3 position switch? You are just using ordinary buttons? If you want one button to move through different controls each time you press it you just need to make use of the offset condition. Use a free user offset, such as 66C0, increment it cyclically with an Offset Byte Cyclic Increment control, and make the condition based on that value. The example in the FSUIPC4 Advanced User's guide uses two buttons. here, I've pasted it for you to save you the bother (but you should read the section on button programming in any case): The two button method allows selection of any of the positions, becase the extra button preselects the one to be actioned. But you could use just one button if you always want to operate the complete cycle. For that you'd simply assign the cycllc increment action to the same button, so the above example becomes: 32=B66C0=0 P117,6,C1 030,033=B66C0=1 P117,6,C1 034,0 34=B66C0=2 P117,6,C1 038,0 35=B66C0=3 P117,6,C1 042,0 36 =P117,6,Cx510066C0,x00030001 Note that I moved the increment to the end, so it executes last. Assuming 66C0 startsequalling zero. Pete

You give lots of rather irrelevant information, but nothing about FSUIPC. For example, what is the version number of the FSUIPC you are using? Have you made sure it is the latest, the only supported version (4.945)? What tells you that FSUIPC has "stopped working"? Just because your ACARS program stops does not mean FSUIPC has stopped. Does the FSUIPC entry in the Add-Ons menu disappear? What tells you to blame FSUIPC? If there is any problem which FSUIPC detects it will be logged. That is what the log is for, so next time it happens, first check whether the FSUIPC entry in Add-Ons is there, and, either way, grab the FSUIPC4.LOG file from the FS Modules folder, and take a look inside -- paste its contets into a mesage here for me to check it for you, if you like. Pete

You can make as many assignments to the same button as you wish. FSUIPC executes them in order. But if you have a 3 position switch, surely each position is detected seperately -- or at least one position = "released" and the other two different button numbers? If not, then the wiring of the switch is all wrong, with all three positions, or at least two of them, wired together! I think you are rather confused here. The FSUIPC macro facility is a method of allowing a single or sequence of commands, whether L:Var writes or simple control or keyboard assignments, to be stored in files (.mcro files) with names which can be assigned in the Buttons & Keys tab. Maybe you are assuming that "macros" always means "mouse macros". Mouse macros are a specific type of macro which operates mouse action areas in gauges which are suited. But that is only one type of macro (and the most recent addition to the range of things macros can do as well). I think you need to review some of the documentation and examples. Also browse through others' work in the User Contributions subforum. Pete

Please always post support questions in the Support Forum. You are lucky I saw these posts! Axes are not read nor transmitted by WideFS, only buttons and switches. This is documented. If you want to send axes from a client PC you'd need to write a Lua plug-in to do it. Pete

And they are? Anyway, I checked on the default A321 in FSX, with "Event Logging" enabled in FSUIPC so I could see what controls it used. The SPD adjustment knob, when pushed, actually sends "AP PANEL SPEED HOLD". I don't know how to "pull" it. The control is a toggle, so each time you press that knob it turns the mode on or off. Likewise the heading adjuster, when pressed, sends AP PANEL HEADING HOLD, another toggling control. Unsurprisingly the ALT knob operates the toggle AP PANEL ALTITUDE HOLD. I think these controls are pretty universally used on aircraft with MCP-type displays for their Autopilots. They are certainly easy enough to find in the FSUIPC assignments, and of course in FS's own assignments, though FS doesn't use the formal names in its menus. Pete

With FS's auto-rudder set, you steer on the ground using your aileron control. There's nothing FSUIPC can offer to do any differently if you have no rudder or steering tiller. You just have to practise more. Pete

If you mean the autopilot mode buttons for speed select, heading sleect and altitude slect, then the FS controls for those are clearly listed in FS and in FSUIPC. In FSUIPC they would be one or more of these AP_AIRSPEED_HOLD 65859 AP_AIRSPEED_OFF 66094 AP_AIRSPEED_ON 66093 AP_HDG_HOLD 65725 AP_HDG_HOLD_OFF 65815 AP_HDG_HOLD_ON 6580 AP_ALT_HOLD 65726 AP_ALT_HOLD_OFF 65816 AP_ALT_HOLD_ON 65808 [LATER] There are also "PANEL" versions, AP_PANEL ..." of some of these. Please see the list installed in your FSUIPC Documents folder, or just look through the AP controls in the assignment dropdown. Those names are as listed in FSUIPC's drop downs and are the internal names FS uses. The numbers are the actual control numbers sent in messages. However, if you are using an add-on aircraft, like the Aerosoft Atibus, they might have their own autopilot controlled by their own controls. Many such add-on aircraft do their own thing and you'd need to research that separately. ete