Pete Dowson

Version 4.26 is pretty old and totally unsupported. The oldest supported version is 4.50. Please update your setup. Regards Pete

Nothing in FSUIPC touches anything in FS's own cockpits. Since FSUIPC is merely a single module, the DLL in the Modules folder, reinstalling the same DLL never accomplishes anything. Did you actually DELETE the INI file you had before, so that FSUIPC resorted to defaults -- i.e. doing nothing? What "settings" made this differences? Does deleting the INI file make it "work" again? I really cannot offer any help without proper information. Look in the FSX Modules folder. In there you will find an FSUIPC4.LOG file. Show it to me. Possibly you have a serious SimConnect problem -- the log file will show. Pete

There are no such messages in FSUIPC 3.90! It sounds like something installed a much much older version -- before 3.70 probably. You'll get no support with an older version. If you want help from me, please install 3.90. If you get any problems with FSUIPC you must show me the FSUIPC.LOG file, please -- from the FS Modules folder. Regards Pete

Write to me at petedowson@btconnect.com with your proposals. I'm out the rest of this evening but I'll deal with it when I return. Regards Pete

I have no idea where you are looking, but if both PCs have the same IP address then they are not distinguishable on the network and cannot communicate with each other. Furthermore, the IP address which the client is looking for is completely different again -- not only not in the same network, but not in the same network group! I suspect you have a complete network b***s up which you need to sort out. Can you tell me why you edited the WideClient INI file and what you changed? Something most certainly is really out of whack! Pete

You don't need to "do" an FSUIPC log -- a log is ALWAYS produced! And it is impossible for an FSUIPC4.LOG file to contain only one line. There are headings and all sorts even before anythingfrom the session is logged! Pete

That IP address looks suspicious: Local IP addresses are normally somerthing like 192.168...... Please check your FSX PC. I suspect your router or switch is fooling Windows on the cleimt into getting a wrong IP address. Let's see the Server log. If you can find your FSX PCs IP address you could give that in the Client INI (via "ServerIPaddr= ..." instead of "ServerName="). Alternatively, if your two PCs are both in the same WorkGroup, you shouldn't need to tell WideClient the Server details at all -- by default WideFS doesn't use such details but connects automatically. Regards Pete

I doubt that installing an aircraft will affect your network settings. And WideFS doesn't change itself. If your WideClient is being told (via an edited INI file) to specifically select the Server by IP Address and you aren't using fixed IP addresses, then maybe your IP addresses have changed. If not, then either you've changed something and don't remember, or something on your network is corrupted, or has developed a fault. Not with only the information you've provided. There are always log files produced by WideServer and WideClient. Both are relevant and are always the first place to look on any sort of problem. The FSUIPC4.INI file may also be relevant. By all means paste the text from them here if you don't spot the problem yourself. I also always need VERSION numbers -- FS, FSUIPC, and WideFS. Regards Pete

The value was incorrect before -- as was kindly pointed out by another user. The value was always in the range 0-1 before FSX, but i made a mistake in FSUIPC4 which was not corrected until recently. This correction is actually documented in the list of changes in the Updates Announcement, as follows: 13.[FSUIPC4 only] The CG offsets 2EF8 to 2F18, inclusive, are all now fractional instead of percentages, for compatibility with FSUIPC3 (i.e. FS9, FS2002 and FS2000). To obtain a percentage, multiply by 100. Please do browse the list of changes when downloading an update. The main purpose of FSUIPC is to maintain compatibility with previous versions -- that's why I developed it in the first place, in FS98 days. Regards Pete

Sorry, Esound was an old experiment to provide event-triggered sound additions in FS and has not been supported for many years. I'm surprised it even runs in FS9. I use a Project Magenta program called pmSounds, which being a separate EXE can be run on WideFS client PCs as well as the FS PC, giving a multitude of possibilities for cockpit sounds on assorted well-positioned speakers.. Regards Pete

The parameter isn't relevant for any of those in any case. This may well be true. what works and what doesn't in Project Magenta has varied quite a bit over the years as it has been continually modified. All the FSUIPC PM controls added did work when they were implemented, some 8 to 10 years ago. According to the PM documentation, they should still work now. You should also note that some of the offsets are read and actioned by the Glass Cockpit module (PFD) itself, and some by the MCP (or FCP) module. It may well be that your setup is work in some ways but not others. That sounds like the stuff in the 04F4 offset is working, but the bits in 5418 are not. You'll note from the PM Offsets document that 04F4 is processed by the Glass Cockpit, whilst 5418 is processed by the MCP. So the connection MCP->GC modules needs checking. But first prove to yourself that the correct bits in the correct offset (5418) are being set by your button. If they are being set but never reset to 0, then PM's MCP isn't working properly. To check offset changes use the Monitor facilities -- right-hand side of the FSUIPC Logging tab. Set the offset to 5418, the type to U16, and check the "FS display" or "Adv display" option at the bottom for a real time display on screen. Also check the "normal log" option so it goes into the log from which you can show me extracts if necessary. You could also use the MCP program's EFIS controls to try changing the GC range and mode, just to see if that works. However, I don't know what offset that uses to taslk to the PFD module, if any. You really need PM support -- as I have on many occasions for questions like these. But also try the voluntary support forum over on http://www.mycockpit.org/forums . Someone there might be able to help. Regards Pete

Not with WideServer, because it is a facility built into FSUIPC. Please check the section in the FSUIPC Advanced User's guide entitled Programs: facilities to load and run additional programs You'll find there a way of doing exactly the same thing. Regards Pete

That's not right. You can have parameters with any control -- even many of the standard FS controls take parameters. I've never known any problem where the parameter got reset to zero -- you'll need to give me more information about that. All it does is store that field as a parameter no matter what the control chosen, even if it doesn't actually use a parameter. They operate via the relevant offsets. I use a lot of them in my own cockpit, in fact, including the ND range inc and dec which works okay for me. If you mean the Advanced User's guide, it is supplied along with the normal User's Guide and the History document (detailing changes release to release) within the FSUIPC ZIP file (for FSUIPC3), or installed in your Modules folder (for FSUIPC4). Please refer to the first page of the User Guide, where it does actually tell you what files you get. I have no other "site" than this Forum. But I don't supply documents which are part of every release here separately. You need to go to Enrico Schiratti's "Dowson" page and get the main Release ZIP. I spoke generally. Some of the PM offsets use bits, some values. It depends which you use. The ND Range inc / dec used by FSUIPC's PM controls happen to be bit-oriented. They are in offset 5418 -- set bits 20, 21, 24 or 25, as documented for PM, thus: CRNG- Bit20 (Captain ND range -) CRNG+ Bit21 (Captain ND range +) FRNG- Bit24 (F/O ND range -) FRNG+ Bit25 (F/O ND range +) FSUIPC actually queues requests for you, waiting for the bit to zero before setting it again. not so easy to guarantee doing it yourself. Good. The ones FSUIPC uses are all there. Regards Pete

All of the PM controls in FSUIPC operate directly on PM's offsets. You'll find documentation for those on the PM site. You can Monitor the offsets involved (right-hand side of the Logging tab). See if your button is changing the correct bit in the correct offset. If it is and PM is not responding, it is a question for PM support. All of those offsets used to work fine, but there are so many releases since they were presented that I'm not sure what PM maintains any more. Regards Pete

Such false signals occur now and then. Yes, your virus checker is giving a false positive -- you should inform them so that they improve the patterns they check for. The DLLs are super-compressed and encrypted, and protected by a Globalsign code signature. When code is compressed and encrypted there are virtually no code bits for a virus checker to check, but the random assortment of bits the process produces can sometimes match the small bits of pattern that some virus checkers look for. Your protection in in the code signature. Right-click on the unzipped DLL and select Properties-Signature, select the signature detail and ensure it says it is okay. Pete

Yes. Use a "shift" key as well -- any of Shift, Control, Tab will do, or one of the two special keys Windows and Apps (either side of the ALT keys either side of the space bar). Regards Pete

Thanks for the logs. I see what the problem is already. The big clue was the fact that in the "after" INI file, the one with the lost settings, the final line was: Mixture=-1 whereas it should have been: Mixture=-16384,16 The other clue was the file size AFTER -- 128,001 bytes. That's 128,000 (the size of the buffer I allocate) plus 1 byte for the end of file marker. My allocation was based on twice the biggest INI file I'd ever seen. Yours exceeds that by 100%! I'll have to change the code to dynamically allocate as much as might be needed, then maybe double it! :-) Looking at it, you have a lot of duplication throughout your sections. You aren't using the ShortAircraftNameOk facilities so that aircraft of same types cannot be grouped. Really, I think you'd benefit quite a lot from using the Profiles facilities, setting up a different profile for each class of aircraft plus control configuration, then simply assigning new aircraft to a profile name in the drop-down menu you'd then get. The Profiles facilities were really aimed at exactly your type of situation. The smaller INI file you'd get would be more efficient, and your aircraft library could be extended as rapidly as you liked with very little hassle for you and your settings assignments. Meanwhile, I will change the code to use a dynamic allocation so that this problem does not recur. Watch the Updates announcement above for a new interim version, maybe by or over the weekend. Regards Pete

No, it isn't. FSUIPC's logs aren't named for someone else's code, and they go to the Modules folder along with its other files. Maybe you have told SimConnect to create a log there? Check for a SimConnect.INI file in your Flight Simulator X Files folder in your Documents, if anywhere it'll be a parameter in that file. Pete

What "high" amount? You most certainly do not need a registration key for FSUIPC4 for that add-on. Please go and read the instructions for FSFlyingSchool again. you are misreading them. You do not get a free key for FSUIPC4! Pete

you sentr the same message twice in different threads!!! I replied to the first one I saw. Pete

The log extract you provided only shows you sending the NW_GLOB command 5 in the first 16-bit word at C800) to FSUIPC, which merely changes the weather mode to Global (which it was in any case as you see). In order to actually set any weather you have to send it in an NW_SET, NW_SETEXACT or one of the equivalent _PENDING commands! Anyway, I really cannot spend all the time needed to decode the binary data. Can you please enable Weather logging in FSUIPC, which will show things more clearly. I'm sure you'll see what you are doing yourself then. If you want further help also please tell me what weather you are trying to set, and what results you see which you think are wrong. Regards Pete

Ah, glad you identified the problem. Thanks for letting us know. Regards Pete

I think the list is determined by what Jeppesen supply -- the weather downloads FSX performs, as with FS9, are put together for them by Jeppesen. The file in the same folder as the FSX.CFG file is actually an updated copy of the installed one in FSX's "Weather" folder -- modified by any omissions or additions on the last FSXweather download -- but I note that Queensland isn't in the original install either. Incidentally, it wasn't listed in FS9's file either. Regards Pete

Let's stop there a moment. The log shows the wind and QNH at your departure airport AND at the "nearest weather station" to Queensland, the one you say is 100nm away, to be similar and probably close to whatever ATIS you received, so I would be surprised if the weather at Queensland was a lot different -- and the interpolated weather at the aircraft shows similar too. Not the same, as you say. ErPerhaps unsurprisingly, the weather logged by FSUIPC is actually what it is described as being in the log itself! There are English words (or abbreviations perhaps) which do tell you. Check the parts I show in red below, in these typical entries in your log: Weather Read request (At Station) to area 3: ICAO="NZCH", Req=0 Weather Received (type 3 request, AtStation): "NZCH&A36 000000Z 04004KT&D915NG (weather requested AT a specified station, in this case NZCH). Weather Read request (Nr Station) to area 5: Lat=-45.02, Lon=168.74 Weather Received (type 5 request, Nearest): "NZDN&A1 252306Z 21007KT&D304MG ... (i.e. nearest weather station to you, the aircraft you are flying! The Lat/Lon in the request is your aircraft's) Weather Read request (Global set) to area 1: ICAO="GLOB" Weather Received (type 1 request, AtStation): "GLOB&A0 000000Z 04004KT&D915NG ... (i.e weather at a known station, or GLOBal weather, as here -- GLOB is FSX's special station ID for global (=default) weather) Weather Read request (At Aircrft) to area 4: Lat=-45.02, Lon=168.74, Alt=358.9 Weather Received (type 4 request, Interpolated): "????&A0 252356Z 21207KT&D323LG ("At Aircrft" should be self explanatory. The Lat/Lon is the aircraft's, the response is Interpolated weather which FSX is setting AT the aircraft, for the Lat/Lon/Altitude given.) FSUIPC4 reads GLOB and "At aircraft" weather at regular intervals, and weather at a requested station when requested. The weather data goes to different areas and can be read separately by programs. The FS98 compatible weather offsets reflect the weather at the aircraft, as they always have. If weather is requested for a non-existent station, as is happening with your utility, then FSUIPC4 supplies GLOB weather, but indicates this (the ICAO set with it will be GLOB, not the ICAO ID requested). Really FSUIPC has no choice -- it has no database of ICAO IDs, else it could look up the Lat/Lon and get interpolated weather. It is up to the utility to do that. Sorry, I've absolutely no idea what FS does in compiling its ATIS. I'm amazed it even provides a response to ATIS if there's no weather station listed. Are you using add-on scenery which adds the ATIS frequency, or is it included in FSX by default? If so I would have thought they would have included it in the weather station list. Incidentally, I've really never used FS ATIS, in any version. I've been a long term user of Radar Contact, which compiles its ATIS from FSUIPC, and does it correctly (using Lat/Lon). ;-) Regards Pete

Strange, you should be able to attach -- a lot of folks do. But always ZIP files first. Anyway, it may be easier to attach the ZIP to an email -- send to petedowson@btconnect.com. Please explain what was done prior to the INI file being made. Really, I'd like to see a "before" (i.e. the INI after you somehow enabled the settings in question, with them working) and an "after" -- when you reloaded and found them not working. Please include the FSUIPC4.LOG for both too -- best make two separate ZIPS with the two files in each, "before" and "after". Tell me the name of the aircraft in question. Regards Pete