Pete Dowson

Sorry, no. If it isn't a separate process it might be an add-in DLL, like FSUIPC. No, I didn't say it only cleared clouds and vis etc. I said the "clear weather button" tells FS to clear the weather -- to set the clear weather theme, if you like. It resets everything. standard pressure, standard temperature, no clouds, no wind. What I said, if you read it properly, is that this doesn't stop whatever is setting the wind from setting it again, as immediately as it wants to. It wouldn't stop anything setting anything. It just clears the weather once, at that time, when you use it. it does not carry on clearing weather for ever after!! Drift? On the ground or in the air? On the ground a wind from the right will tend to push the tail to the left, making the nose point more into wind, so when you are taxiing you will tend to veer to the right, into wind. This is because the tail plane is on the rear of the aircraft. It is called "weathervaning". In the air, "drift" is naturally with the wind, i.e to the left with a wind from the right. You are simply an object in a moving air mass. Both of these phenomena are correctly simulated in FS (though the weathervaning does tend to be overdone, overcoming tyre friction far too easily). I don't know why you should think they are incorrect!? I would think that very much depends on the altitude. No, it won't. It can't. It certainly sounds like you have FS set for real weather. Are you sure you aren't loading a flight AFTER setting this "user defined weather", and it is resetting the weather mode as it would normally? Regards Pete

Actually, forgive me for butting in, but having cockpit buttons for these SA_WXR functions is something I've managed to get working just recently. So, here are my Button parameters: 334=P66,2,Cx01006D01,x00 ; WXR Tilt reset 335=P66,2,Cx01006D00,x11 ; ditto 336=P66,3,Cx31006D01,x003C0001 ; WXR tilt up (+ve) 337=P66,3,Cx01006D00,x11 ; ditto 338=P66,7,Cx41006D01,xFFC40001 ; WXR tilt down (+ve) 339=P66,7,Cx01006D00,x11 ; ditto These are lifted directly from my FSUIPC INI file, so ignore the line numbers (change them to suit your INI), and of course change the Joystick Numbers (66 here -- part of the Virtual Buttons used on my touch screen via WideClient), and Button numbers (2, 3 and 7 here) to suit your needs. Note that there are two Offset controls needed for each operation. The common one for all three is the one which tells WA_WXR to obey the other in the correct way. Regards Pete

I looked at my code, ready to work out a fresh fix, only to find i did change this ages ago. Then I noticed from the Log you supplied that you are not, in fact, using version 4.548, but still version 4.50! The fix was actually made in 4.52, back in June, as noted here in the History document. Regards Pete

You only need a key if you want to use the facilities FSUIPC provides. There's all the information you need, including where to purchase it, in the documentation which, as it states clearly in the Installation guide, is installed in your FS modules folder. There are also lots of Announcements at the top of this Forum which give you a load more information, and there were even pretty big and obvious links on the website you downloaded FSUIPC from direct to the sales booths. Regards Pete

Yes. Damned nuisance that. You'd think they'd provide a HomeGroup package to apply to Vista and XP. Oh yes it is! In fact WideFS doesn't use any filesharing at all, so it doesn't even need that! It is only the Broadcasting over a network which only works on the WorkGroup. The Server uses Broadcasting to tell all possible clients, in the workgroup, where it is. You can always do what folks always had to do, before Broadcasting was introduced by Microsoft, and tell the client what the Server in and what Protocol to use. This is explicitly stated in the section I just pointed you at!!! Oh dear. :-( You do NOT need to do both! The parameter additions are the work-around if you don't want your PCs in the same workgroup! Until WinXP you always had to provide the ServerName and Protocol to the client in any case, I just took advantage of new facilities in XP and later for automatic operation, but took the precaution of leaving in the original method AND highlighting both with a RED pointer in the document. I'm really at a loss to know how to help folks any more than that! If UI supplied disks I'd plaster it in big red print on the packaging with black and yellow radiation warnings to grab attention! And in any case, setting the workgroup name is as easy as setting the computer name. It is in the Computer Properties. Forget homeGroups, that isn't anything to do with WideFs. That's to do with file and media sharing. Pete

FSUIPC never generates any wind. With "allow changes to FS's own weather" unchecked, pretty much all of that has no effect. It'll only have effect when you run a weather setting program that uses FSUIPC. It must be getting set by something else, then, via FSUIPC. FSUIPC never suppresses the wind. The "clear all weather" facility merely sends a command to FS to set clear weather, but if another program or module sets wind again it won't stop that. The FMS doesn't show winds whilst on the ground, because the wind is computed by the drift it causes. The IRS data is used for that. And you wouldn't feel wind whilst taxiing if you have the FSUIPC option set to reduce taxi sidewinds to 1 knot. You do know, don't you, that FS's weather is dynamic? It will change from what you set, at a rate dependent on the rate of change setting in the options. Try using the Windows task manager (Ctl-Alt-Del) to see what processes and programs you have running. You could also try using FSUIPC's weather logging to see if anything is being injected. Regards Pete

Okay. But there appears to be more going on that that, from the log: First there are these apparently different mouse clicks in different places. Would that be some sort of preparation, like getting the overhead up etc? Do you recognise the Xxxxxx numbers at all. (It might help if you showed the macros you have for this aircraft, especially the one for the APU, so i know which one is relevant). 73149 Mouse by function: RX6d530*X55cc (flags=20000000), Module="ESDG_CitationX.GAU" 76347 Mouse by function: RX89700*X55cc (flags=20000000), Module="ESDG_CitationX.GAU" 77595 Mouse by function: RX89830*X55cc (flags=20000000), Module="ESDG_CitationX.GAU" 77720 Mouse by function: RX89830*X55cc,17 (flags=00020000), Module="ESDG_CitationX.GAU" Then we have these three different mouse actions on one mouse rectangle, presumably the 'start'? 91823 Mouse by function: RXadf90*X55cc (flags=20000000), Module="ESDG_CitationX.GAU" 92088 Mouse by function: RXadf90*X55cc,11 (flags=00000800), Module="ESDG_CitationX.GAU" 92088 Mouse by function: RXadf90*X55cc,17 (flags=00020000), Module="ESDG_CitationX.GAU" followed a good 11 seconds later by a similar sequence on a separate mouse rectangle: 103413 Mouse by function: RXae000*X55cc (flags=20000000), Module="ESDG_CitationX.GAU" 103694 Mouse by function: RXae000*X55cc,11 (flags=00000800), Module="ESDG_CitationX.GAU" 103710 Mouse by function: RXae000*X55cc,17 (flags=00020000), Module="ESDG_CitationX.GAU" I assume the first 3-action sequence is for "Start", and the second for "Off". In each case the first is "mouse left button single click", the second (11) is "mouse leave", and the third (17) is "mouse button release". So, try constructing three-line macros for each, using the values shown. Let me know how you get on please. Regards Pete

Okay. Sorry if my reply came across as harsh to you. It wasn't intended. When I express surprise it is genuine. I admit I'm not a good tutor and I certainly haven't got the requisite patience to be one. I have tried my best to provide good, definitive documentation, and it has been gradually improved over the years, mostly through feedback. FSUIPC is, after all, over ten years old now and I've had a lot of it (feedback, that is). I still get surprised, though, at some of the unique ways folk find to misunderstand things. I really don't know how to cover it all so that nothing is ever misunderstood -- how can I if I don't understand how it can be, at least in the ways it is? Regards Pete

The "offset" edit box won't appear in any case unless you select an Offset control. All those values you list are marked "2", meaning they are WORDs (2 bytes or 16 bits). So you use one of these FSUIPC controls depending on what you want to do: Offset word set to write a value Offset uword increment and offset uword decrement to inc/dec an unsigned value Offset sword increment and offset sword decrement to inc/dec a signed value Offset word cyclic increment and offset word cyclic decrement to inc/dec a value cyclically (i.e. returns to 0 after max or vice versa) The offset is x followed by the offset value you've been given, and the parameter, for Offset word set, is the value you want, but for the incs/decs is composed of two values -- best explained in the FSUIPC user guide. See the boxed section entitled "Offset Increment/Decrement controls" in the Buttons chapter. Regards Pete

Generally only because folks don't bother to read the documentation and therefore don't make sure the WorkGroup names are the same on both PCs, and can't be assed to use the workaround if they don't want their PCs in one workgroup. This continues to happen, I'm sorry to say, even though I put a notice in RED in the document, in the most important section, thus: Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! Amazingly folks find it easier and quicker (?) to post their problems here rather than simply look! :-( Didn't you even think of looking at the supplied documentation? Of course, because you haven't installed IPX (you don't need to if you don't want to use it, it is optional). There's no point in showing me INI files that are standard and unmodified. Assuming you have no firewall blockage, the Logs simply show there's no connection, and this is almost certainly because you have the two PCs in different workgroups (as usual). :-( Please please please, read the first few paragraphs, at least, of the "Configure your Network" section of the user guide. After all it does follow immediately on from the Installation section. Surely it isn't too hard to find? Pete

The log certainly shows it isn't to do with the Lua threads piling up. There are 1153 cases of the Lua program starting, and 1151 cases of it ending. So, at the end of the log there are still two cases of it still running. I've not yet located where these extras were started, but I do find it not coincidental there are two distinct key combinations both running the same Lua program -- Tab+1 and Tab+3, so probably there's one instance of each. Looking furthur at your code, it is rather large for something you might want to have repeating reasonably quickly. It contains multiple functions which are really completely separate and could be much faster shorter separate Lua plug-ins. Don't forget it is re-read and re-compiled each time it is executed. You could probably, instead, have a Lua program running continuously which acts on Events. Butbefore going into that I think it would be much more efficient for you to split it up into its separate parts, each executed for their separate functions. You have some odd parts in the Lua which could be deleted. These have no effect and should be deleted: elseif SPVarInc == 12 then elseif SPVarDec == -12 then elseif SBVarInc == 26 then elseif SBVarDec == -26 then Also, this sort of thing GEVar = ipc.readLvar("L:Sperry_gain_elevator") if GEVar <= 0 then ipc.writeLvar("L:Sperry_gain_elevator", 44) elseif GEVar > 0 then ipc.writeLvar("L:Sperry_gain_elevator", 0) end would be more efficient as: gain_elev = "L:Sperry_gain_elevator" val = 0 if ipc.readLvar(gain_elev) <= 0 then val = 44 end ipc.writeLvar(gain_elev, val) Anyway, I can't see what might possibly be causing a crash, unless the gauges dealing with these L:vars cannot cope -- maybe they don't have protection against re-entry, and they are getting their stack corrupted and hence probably corrupting other code -- maybe even to the extent of affecting saved parameters (FLT or other files?). You may need to consider another method of doing the updates. There are standard ways around this sort of thing. For instance, you could have a value in which you accumulate the increments/decrements, and only read/write the Lvar at intervals, say every 250 mSecs or so, or when there's been no further call for 500 mSecs. You'd certainly need to use the Event library facilities for this -- you can trap key presses as events -- and you can have your Lua program automatically started when you load the relevant aircraft. Having a Lua program ready compiled and running awaiting keypresses (sleeping most of the time, of course) is much more efficient in any case, even if you don't regulate the changes into the L:vars, which I suspect you'd need to do. Regards Pete

You still have a PC with a motherboard serial port? Wow! That IS old! ;-) There's nothing that should be going wrong with that. I assume it hasnb't always done this over 7 years? What's changed. It is possible i suppose for hardware and cables to deteriorate, but less like that a software problem -- any thing you've changed recently, for instance? You might want to contact PFC support in case its down to some problem developing on their controller or in the power supply. Overheating could do that sort of thing, for instance. Regards Pete

It may simply be that you have Windows set to cut power to USB devices (its attempt to be "green"). Check in the Device Manager. Find the Power management part of every USB item and uncheck any options which allow Windows to remove power. If this isn't it, then there's something wrong with the COM connections between the device and the PC. Are you by any chance using a relatively cheap USB serial port adapter? You can get them down to about $10. I found those to be a false economy -- you need a good quality one. I've now changed over to using serial port cards rather than USB adapters -- the one made by Brainboxes is very good, and works very well on my Windows 7 64 bits systems too! ;-) http://www.brainboxes.com/category/pci_rs232.aspx Regards Pete

Okay. Thanks, Pete

Ah, that's certainly a video driver problem. You should never have any such problem swapping between the two modes. Yet more confirmation of driver problems. I only use FSX these days. I've been using GTX 280, 285 and 9800 GTX cards with Win7 64-bit ultimate quite happily -- driver version 182.50 or later. I'm currently trying the latest Betas from www.guru3d.com. Regards Pete

If they are connecting through the programmable interface to FSUIPC, and not just acting like a standard joystick with buttons for users to program, and if they are a commercial company out to make some profit on what they are doing, then, yes, of course they should have a commercial agreement with me, and probably pay for a license (unless they are a charitable non-profit organisation which is doubtful). That has always been the case, even in the days of Adam Szofran's FS5IPC and FS6IPC. That's the problem isn't it? I used to force programs to apply to me for an Application key else they couldn't get access. If now that I don't I find I get many more like VRInsight I shall have to reconsider that option. It's been working on trust quite well for a couple of years. I'd hope for that to continue. I spoke to the VRInsight folks at Lelystad and they promised to get in touchmaybe they will. I've sent a reminder. Regards Pete

Sorry, I don't recall what we used before. The possibly useful ones are listed in the Advanced Users document for FSUIPC, in the mouse macro section. Regards Pete

Ugh. I'm still waiting for them to contact me about a license -- they are using FSUIPC without any agreement, payment or permission. Hmmm. Maybe you manage to bypass my 2repeat" checks that way. I don't know. Please enable key/button logging and show me the resulting log. Pete

That should do the trick though. So, the devices were asleep when FSUIPC first started, so they didn't register. Moving them wakes them up. FSUIPC rescans for newly attached devices in the options dialogue, but it doesn't do so all the time during a session as it is inefficient. I expect they would have been fine if you'd waggled them to wake them up before or whilst FS was loading. Regards Pete

Look in the FSUIPC advanced users guide. Search for "DH" or "MDA" and immediately find that there are two parameter values for the built-in FSUIPC control "PM MCP Kcodes (by param)", one to set DH mode and the other MDA mode. Otherwise for all things PM, check the PM documentation on their website. All of the facilities that can be operated via FSUIPC offsets are documented in their "PM offsets" document. Regards Pete

Sorry, there are conflicting statements there. You say they don't work until you assign them again, but then you say that in the FSUIPC axis assignments window, when scanned, they show as already assigned! Which is correct? They should be operational every time. Are you sure they are not simply getting switched off by Windows power management? Look in the Windows device manager, find all of the USB entries, and make sure the options for Windows to save power by turning USB devices off is not checked. Windows tends to havethat enabled by default. Regards Pete

Yes, I understood that. We need to find the sequence needed in the macros to do the same thing. Hence the logging I mentioned, or more trial and error on your part. Pete

Well, it is still fixed. It has not been undone. I'll need a copy of your INI file please. I cannot see anything wrong here. ZIP it and send it to petedowson@btconnect.com. Pete

If you assign to the FS controls in FSUIPC you still shouldn't also have them assigned in FS. That would result in two controls, albeit with the same parameter, being routed through the system for every axis change. You might not notice it, but doubling the number of controls going through unnecessarily can't be efficient. And if the FS "sensitivity" was not at max and its null zone not at min, the values would probably be different, making for conflict somewhere in the add-on's logics. If an add-on aircraft needs to see the FS controls so it can act upon them in some special way (such as setting Airbus flight modes), then it shouldn't matter whether they come from FS assignment or FSUIPC assignment. It is only FSUIPC assignment "direct to FSUIPC calibration" which would by-pass the add-on's interception. Regards Pete

Maybe that was your problem in the first place? You really do need to clabrate your flaps as a notrmal non-detented axis, and check that it works okay, and in the right direction, before then switching on the detente facility. I'm amazed that you found the much more complex process of using the axis ranges option easier than using the purpose-made detente option, which is really doing the same sort of thing but much more efficiently and easily. Sorry, what numbers where "kept going back to 0 & 16384"? Neither. FSUIPC calibration. There is NO calibration possible in the axis assignments. Calibration is the function carried out in the Joysticks tab, and explained at length, with numbered steps to follow, in the documentation for that section. It is the palce where you set MIN, CENTRE and MAX values, according to their types. That's what calibration means - making the numbers coming from your assigned axes match what is needed in FS. There is NO calibration facility in the Axis Assignments tab -- that is only about assignments, and there are NO calibration facilities in FS, only assignments again. As for Windows calibration -- yes, of course, you should always calibrate your devices there first and foremost. But that is part of the act of installing a device, and is nothing at all to do with either FS or FSUIPC. If your device is acting incorrectly because its driver is doing the wrong thing there's nothing in the world which can be fixed for it afterwards. Note that FSUIPC's calibration facilities are entirely independent of how and where you assign your controls. You can assign in FS and still calibrate in FSUIPC. The axis assignments facility in FSUIPC was a new feature added much more recently and primarily aimed at cockpit builders with more complex and advanced ideas. It is not the same facility and it is much more complex, at least for everyone else if not yourself. You are presumable not even now using the axis as a Flaps Axis, but as a set of discrete bittns, each sending a specific event. That is not how the detente systems works at all -- that actually computes and sends the correct axis values instead. The facility to assign controls or other events to ranges along an axis actually can act at the same time as an axis input to FS, calibrated with or without detentes, centres or null zones. The main use for this has mostly been for Airbuses where the "throttle" also sets different flight modes. I'm sure the others got it right subsequently. Folks rarely come back and post about things that work, so you don't see that confirmation. If you read the reports above and my replies more carefully you will see they were reading things incorrectly in a couple of places. One only calibrated three of four detentes in any case, for a 737 or whatever, and the other missed the obvious thing that the flap numbers were counting from 0 -- on a 9-position lever, positions #0 and #8 are already set by your normal calibration, they are the extremes ("flaps up" and "full flaps"). So you only ever calibrate detentes for the central 7. Okay. That's one way. You could also have assigned in FS, or assigned where you did by the default method, via FS, in which case the control you assigned to would have been "Axis flaps set". But the way you chose is the most efficient. Ouch. Why? All you do on the axis assignments page is assign the axis. The right-hand side is for doing all sorts of special things that cockpit builders like to do. What in my documentation led you to even start fiddling about over there? I just don't get it! :-( No. the first thing to do in the calibrations tab is to press the "Set" button top left in that section, so that it changes to "Reset". Then you are in calibration mode. If it does not say "Reset" you are not calibrating in FSUIPC! Then you calibrate, following the numbered steps in the documentation. That is what they are for, for you to follow. You need to do that, and check the results, BEFORE moving on to set the detentes. If you try to set detentes on an uncalibrated axis it will never be right. You would also have found, that way, that you needed to check the REV option pretty soon! Please please do try using the documentation and following the step-by-step approach. I really don't understand why folks continue to ignore most of the tings I write. :-( Regards Pete