Pete Dowson

Registrations normally work for all 3.xxx versions, excepting registrations purchased in 2006 need 3.53 or later (a date check error -- I had expected FS2006 in 2005, but Microsoft fooled me! ;-). Without registration FSUIPC is doing nothing unless the programs or aircraft you are using it with are accredited, of course. To test 3.48 with accredited programs or aircraft you will have to delete you FSUIPC.KEY file (or just temporarily move it out of the FS Modules folder). Regards, Pete

You can set Latitude, Longitude, Altitude, Pitch, Bank, Heading. In FS2004 you can set this in flight modes, in previous versions the sim has to be in Slew, Pause or Zero Rate mode. In Flight modes the sim engine will be moving it between your updates of course. The airspeed is a result of the sim engine and is a physical thing. You can't actually change the sim engine results -- or at least not for long (up to one frame). If you don't want the sim engine running then you use slew or pause mode, or even zero sim rate mode. GPS position is a result of using a GPS -- it is the actual world coordinates you change -- i.e. you move the aircraft, not fiddle GPS readings. Regards, Pete

With WideClient 6.596 you either need to run it with Broadcasts operating correctly (i.e. on XP systems for Server and Client -- maybe Win2K though this is not yet clear), and the "AdvertiseService=1" parameter correctly defaulted in the Server INI files, and not have any Server details in the Client INI, OR you must specify not only the ServerName, IPAddress or Node but also the required Protocol. If Server details are specified in the Client INI files, the broadcasts from the Server are ignored in any case. If Broadcasts aren't being used then there is no use for the "ProtocolPreferred" parameter in the Server INI, because by the time the Client can get this information it must already have sorted out a protocol. I attach version 6.597 of WideClient (only -- the Server is not affected) which is similar, but operates correctly in that if you omit the Protocol parameter and specify the Server name, address or node details, the protocol is chosen automatically -- with SPX preferred if a Node is specified and TCP preferred otherwise. In either case, Broadcasts from the Server are ignored because you are specifying the Server explicitly, locally. The ideal situation, reflected in the default INI settings, is for all PCs in the system to support the Mailshot broadcasts (i.e. be using WinXP), and for the only protocol specification to be the ProtocolPreferred one in the Server's INI. There would be no need for any Server details or Protocol in the Client INI. This setup would allow you to test any of the three protocols across all clients by only changing the preference in the Server INI. I hope this is clear. I am trying to make things very simple, but it is quite difficult when there are so many possible exceptions! ;-) Regards, Pete WideClient6597.zip

Okay, I found a problem in WideClient . I can only reproduce your Log if I stop my server broadcasting (by setting AdvertiseService=No in the server INI file). For some reason it is now ignoring the ServerName and ServerIPaddr parameters UNLESS the Protocol is specified explicitly, and since is deletes "UseTCPIP=Yes" without replacing it, this presents a problem for those not using Broadcasts. Anyway, the main indication in your case seems to be that the Broadcasting isn't working, so I still need to know what your Server is running and to see the INIs. Meanwhile I'll fix the reading of the Server name or IP address details and re-issue WideClient only. Thanks, Pete

Seems like the broadcasting isn't working anyway. If you specify the Protocol in the clients the ProtocolPreferred parameter is totally redundant. It only affects what is transmitted in the broadcasts in any case, and you don't seem to be getting those. However, without all that the Clients should default to TCP, and if that doesn't work they should then try SPX and UDP, in that order. They do here. I still need more information please, including INI files and Server log. The Server initialises all of the protocols it can in any case, setting a protocol there is redundant -- you never did it before, remember? I need to see the Log please! Regards, Pete

Hi Thomas, You shouldn't need to set the protocol explicitly on the XP clients. That merely makes the "ProtocolPreferred" setting in the Server redundant, and the clients then have no choice. I don't know about the Win2K ones -- does my Broadcast system work for those? i.e. do they connect okay without being told the ServerName or ServerIPaddr? Regards, Pete

Are you running winXP on all of them? If not then you'll need to provide the Server name to those which are not running XP, or all if the FS PC isn't running XP. The log seems to indicate that those clients aren't receiving the Broadcast. Only XP can provide that facility. This isn't a change from the previous version of WideFS. You didn't delete your previous INI files did you? Ah. Not sure about Win2K. What's the Server running? It won't see them unless they see the Broadcast, which they don't. The Clients have to send an "I'm here" message to the Server, but they can't when they don't know who the Server is. I really don't think there's anything I have changed in this part of the mechanism which could result in these symptoms. I'd like to see the Server Log in any case, and maybe the INI files. Does the Win2K one normally work with the ServerName missing? Regards, Pete

One think I recall, when someone else had a similar problem, was this: add TableFog=0 into the [DISPLAY.Device *] section of the FS9.CFG file. This, I presume, fixes a problem some drivers have with the way FS displays fog. I think this snippen originally came from a post on one of the AVSI< forums, back in January. On the other hand I think the person who tried it got it to work only once, then it reverted. What did fix it in the end was a re-install of FS -- apparently he had something corrupted. Personally, before taking such a step, I would try deleting the default-loaded FLT + WX files (or even all your WX files) and possibly also the FS9.CFG file. This is because I think the most likely scenario is a corrupted WX file, maybe from a bad download. Corrupted WX files have long been known to cause odd problems, and these could well change with or without some other add-on present, whether FSUIPC or something else. This is because the presense of the add-ons changes the memory configuration and the timing of events, so different things happen as a result of the one original problem. I hope this is of some help. Regards, Pete

No, it means that FSUIPC doesn't offer any facilities for you to change the weather settings. It doesn't touch FS's weather at all unless asked, and you can't ask it. If your weather is being changed through FSUIPC it will be another program doing it, or else you have some problem with your graphics card or its driver settings. Why having FSUIPC there or not would make any difference I've no idea, but generally it will be because of whatever is using it. Anyway, delete your FSUIPC.INI file before running FS next time, in case it has been corrupted. Regards, Pete

FSUIPC isn't actually doing anything itself as your FSUIPC is not registered. Since it isn't registered there won't have been any settings you could have changed. Regards, Pete

The FSUIPC user guide, of course! Where else? You program the buttons in the button page in the FSUIPC options, so of course that is where it is documented!! :roll: I take it from the rest of your rather insulting and very presumptious message that you won't be here again, which is actually rather good news for me, as you've been almost monopolising my time and most of the forum for a whileand yet still don't take any of my advice. I really hope you understand aircraft and flying rather better than you seem to do English. Good flying and good bye. Regards, Pete

Ah. How quaint! If he's getting ASv6 CTDing he most certainly needs to deal with their support. There's no way I can get inside someone else's program even if it was something I should be doing. The ActiveSky folks should be able to get to the bottom of it with enough information. It obviously connects to FSUIPC okay as his log shows. Pete

But you said you were running the GF45 on the FS PC. Please go back and read your message! This is the crux of that confusion, which you still have not resolved. Please read this part of your message AGAIN! If, instead of doing what you say you were doing, but are trying to run it on a client PC, then why not say so? Ah but it does, clearly. YOU read it! Here, I will extract the relvant paragraph: I AM SAYING NO SUCH THING! You can put the thing wherever you like. It ws you that said you moved it. I don't care a fig where you have it, that is entirely up to you! Of course! The documentation is very clear on that. You aren't even looking at it for sure! See these parts, for example: It is becoming more and more obvious that you are simply not bothering to use the documentation at all. I shall henceforth reply to such questions with "see the manual", as this is simply getting too exasperating. I should not need to keep quoting parts of the documentation merely to refute your inaccurate and untrue accusations! Nonsense. Read what it says. It's a case of programming things as you want them to be. It is the flexibility which it is becoming evident that you do not like or understand. Since that is the case I respectfully suggest that you don't use FSUIPC at all and ask GoFlight to support whatever it is you want. Regards Pete

Sorry, but the documentation has stood the test of time, over five years or more. I can answer specific questions here, but you don't even ask specific questions, only general ones which would require reproducing parts of the documentation. As far as the GF devices are concerned there are practical examples and file extracts which can be used in the GFdisplay package, but I certainly wouldn't expect you to look that far. Apart from that. FSUIPC treats GF devices as mere bundles of switches or buttons just like any other, and the programming of those is not only intuitive but has been explained to death here innumerable times. You must try to help yourself to some extent and not expect everyone to be telepathic and understand your questions, most especially when they are self-contradictory, as in the recent example. If there are specific parts of the documentation which you don't understand, spell it out and ask, but don't just keep asking me to solve problems that it seems you cannot explain at all, and, worse, give no helpful information for. Can't you see that it just wastes both our time? Regards Pete

But this is the confusion -- you said you moved the GF device to the FS PC, didn't you? You actually said it in the same sentence, viz: I really strongly suggest that you actually READ what you are writing to make sure it is what you mean before you send it. Please! How would that display anything to do with pitot heat? If you want to program displays on your GF devices without using GF software then you have to use my GFdisplay freeware. FSUIPC doesn't know anything about them at all. The button facilities are for programming buttons. I'm sorry, but I don't use GF devices and I really cannot support them. All I provide is an opportunity to program their buttons and switches if FSUIPC recognises them. For everything else, including support of hardware and GF software you have to go back to GoFlight. Well, many users certainly manage to use the GF rotaries with FSUIPC assignments, and it is thoroughly tested with them. I think you are not reading things correctly, again. If you are seeing no response in FSUIPC's buttons page when you turn the knobs then I really don't know what you've done. I suggest that you reinstall the GF software and start again. I really cannot help with such skimpy information. If you cannot see the buttons, switches and rotaries from your GF devices in FSUIPC then the GFdev module isn't available in the correct place, the place to which it is installed by GF's installer. Please see my documentation. As for GFremote or other ways of using GF devices, this is all outside my area of competence. Sorry. You will have to rely on GF support. Pete

What WideClient folder? You cannot use WideClient on the FS PC! I'm not surprised. It seems you are not reading the FSUIPC documentation again. The GF rotaries produce 4 button inputs in FS -- two each way, one for fast one for slow. Furthermore they send pulses (on-off-on-off ...) as you turn. If you want every click to matter you have to assign your controls to both press and release for both slow and fast buttons! You cannot do that without uninstalling the Go Flight software -- FSUIPC will always detect the buttons. If you don't want them to do anytthing you have to delete the assignments. What display? I don't know of any red pitot heat display! Yes of course. PLEASE READ THE DOCUMENTATION. There are shut down parameters in both WideServer and WideClient INI files, all described in the documentation. You are sending lots of questions here on all sorts of subjects, almost all of which are easily answered yourself if you'd only use the documentation. Please try that BEFORE writing here. Regards, Pete

No, as I've mentioned here many times before, it is an error in FS. When you arm spoilers on the ground they deploy. Pete

FSUIPC doesn't do anything with any aircraft. Some aircraft use it, but even then only usually for stuff like TCAS displays. You have something else wrong with your system. This shows ASv6 has connected okay, and has cleared the weather and set the FSUIPC weather options. It also shows some Squawkbox stuff running okay. I really have no idea what your odd term "porks" means, but this shows ASv6 is working with FSUIPC okay. The log also shows that no aircraft (loaded in this part) are using FSUIPC, so it won't have any affect on them whatsoever. Next time you show me a log please make sure it is a complete log -- i.e. close FS first. Regards, Pete

Just try assigning a different keypress then -- it sounds like they use the one you chose as a hotkey for something. Regards, Pete

Four button returns? Aha! That certainly occurs with the rotaries, where FSUIPC/WideClient create a "fast" and a "slow" button for each direction -- the rotaries send pulses at varying speeds according to how fast you turn the knobs. Anyway, if that's what it is returning, then, yes -- though if you want a more delicate trim you should really only program one in each direction -- but check the repeat whichever way, so you can hold the lever up or down for a continuous trim change. [LATER] Ah .. wat a minute. Is the trim on the LGT a wheel, like the trim wheel in a Cessna? Sorry, I seem to have fogotten most of the little I knew about the GoFlight stuff. I only had them for a while, whilst I was programming them. (Not enough space to keep everything! ;-)) If it is the wheel, then, yes, it is actually a rotary, just like the ones with left-right turning knobs on other deives like the GF MCP and the GF 45, 46, 166 devices. In that case check the FSUIPC documentation where it does explain about the 4 buttons, fast left, slow left, slow right, fast right. You could take advantage of those for sure. Program the fast versions for Trim Up/Down on both press and release, but the slow ones on only press. That will give you two speeds of trim, one faster than the other. I think I covered this in my examples in the documentation and accompanying files for GFdisplay. You may want to look there and take advantage of work done already. Here's an extract from the documentation: Regards Pete

Depends whether you are calibrating the brakes in FSUIPC or not. FSUIPC is more precise -- FS's slider is more guesswork or trial and error. For FSUIPC you just press them a bit (however much you think you might press them accidentally, and a bit more) and click the MIN set button. Pete

The trim lever on the GoFlight LGT is not an axis at all, it is a double pole centre-off sprung switch, represented as two buttons, one for up and one for down. There is absolutely no way possible to use a button or switch as an axis with more than one value each -- axes must provide variable parameter values to be of any use as axes. Regards Pete

If I remember rightly, I didn't understand why. FS has mixture and pop pitch assignments for any axis it can detect. Did you go into FS's Options-Controls-Assignments and try? Why? The ability to assign axes in FSUIPC is only very recent, and the facility isn't even on general release yet. Surely you should be using FS's assignments in the first instance. That is plainly not true. There are facilities for assigning axes to almost anything in FSUIPC, rather more than there is in FS in fact. Please explain how you think I can add facilities for yet more assignments when everything that is possible to be assigned already is available? Pete

Download and install the latest Glass Cockpit software from the PM website. Pete

How are you telling? Do you have the red "brakes" message on screen? Are you using rudders with toe brakes? If so, keep you feet well away from the braking part, or calibrate with a much larger null zone. INI for what program? I've not heard of any such adjustment in any case. Regards, Pete