Pete Dowson

Good! Just before you posted this I found the message here that I "dimly remembered", about why Broadcasts may not work. Here's the salient parts: Do you know if any of this applies in your case? Else i'm rather mystified as to why the Broadcasts weren't seen by your Client. Regards, Pete

Okay, the Logs show nothing but that the Client never ever sees a broadcast from the Server. With an all Win2000 or XP setup I think that's only possible if the PCs are on different subgroups (i.e. the subnet mask, often 255.255.255.0, when applied to the IP addresses of both PCs shows a difference) -- or there's a Firewall in the way. I do have a dim recollection of someone else who had a problem with broadcasts -- it may be worth a search through this forum to see if you can find something. Meanwhile, if you are sure your Firewall isn't in the way, you could avoid depending upon a Broadcast from the Server by using the normal Server and Protocol parameters in your Wideclient.INI. ServerName=FLIGHT Protocol=TCP I notice that you also have the IPX/SPX protocol installed on the Server: 18797 Initialising IPX/SPX server 18797 ServerNode=0.0.4608.38167.23325 Maybe you were using that before, thus getting around many of the TCP/IP restrictions? If so, and if you have IPX/SPX installed on the Client, try this in the Wideclient INI instead: ServerName=FLIGHT ServerNode=0.0.4608.38167.23325 Protocol=SPX Regards, Pete

Are you sure this is not simply the elevation of the Weather Station reporting that particular wind? FS2004 is different from previous versions in that there is NEVER a "global" weather setting -- no matter how the weather is set, it it local, controlled by the weather station locations. The problem arises is when away from the weather stations. Then the weather is derived from three WX stations via interpolation. What actually then happens to your AMSL/AGL for the surface wind I don't know. It is almost impossible to find out for sure unless you have loads of time and patience on your hands. Isn't there an airfield there with a weather station at 600'? But you just proved this was only true whilst over an area of terrain which happens to be at your "base altitude". That isn't relaible -- all those formulae do is assume it is TRULY AGL, using the terrain altitude as it changes. But I can't really believe that from what you've said in this very message! There's a consequent problem which you have (conveniently?) avoided by having no higher wind layers -- that is what happens to the next layer up (and so on) as the ground one "bulges" upwards over terrain to meet it or even overlap it. Does it simply disappear, or rise too? If the latter, are all of the upper wind altitudes AGL? I really don't think they can possibly be. Regards Pete

So the values are neither AMSL nor AGL. AGL must be related to the actual ground altitude below. if it isn';t you cannot compute the AMSL -- I'm afraid don't know what your local "base" elevation is now how to find it. This all sounds really horrible, and certainly a change from FS2002 and before. I don't know how to advise you to proceed. I shall certainly document the uncertainly of those values in the next SDK update. In FSUIPC it is the other way round. In FS2004 the NWI corresponds most closely to the information I can get out of FS. That information is then maped onto the older interfaces, like the NWI and those old FS98 vaslues you are looking at. So, if that's all you are looking at I don't thik you are gaining anything. How can you compute the AMSL -- where do you get this "base elevation" from? Regards, Pete

At first sight it looks like a firewall problem, which would affect WideFs but not Explorer. Try disabling WinXP's firewall (which is enabled by default since SP2), or at least giving permission for WideClient and FS9 to talk. Otherwise, please show me the WideServer and WideClient LOG and INI files. They will contain the first pointers. Pete

Sorry, I've no idea what you are talking about. This is the first message in a rather anonymously entitled thread, so there's no history at all! :-( That's the version number of the FS2004 original release, some three years ago. If you are using the FS9.1 update then the number will be later than that. It's actually "Dowson", not "Dawson", and none of my programs are downloadable from SimMarket at all. You can get them from http://www.schiratti.com/dowson, as always (for the last 10 years or more), and if it is FSUIPC you need there's only ever one supported and current, and the package for that is named FSUIPC.ZIP. It currently contains version 3.70 which works with both versions of FS2004, as well as FS2002 and FS2000. Regards, Pete

Yes -- but again easier to set in the on-line options. And really this is where I am still not following you, I'm afraid. If you want each of the 8 positions to give you one fixed 45 degree view, why not simply use the direct controls that give you those? i.e. the "VIEW FORWARD, VIEW FORWARD RIGHT, .... through to VIEW FORWARD LEFT controls? Those are made for the purpose. The same 66416 value (= PAN_VIEW) is there because that's what you assigned. FSUIPC isn't in the habit of ignoring what you ask for and putting its own ideas in place. Hats have a centre 'off' position -- when you release them they return -1. Please update to 3.70. I don't support old versions. Er .. for some reason you are logging IPC Reads. Why? The logs for reading C000 are from a Module you have installed which is reading the Weather data. It most definitely is NOT 3.65. There are three ways for checking version numbers: 1. Right click on the DLL, select Properties -- Version. 2. Run FS, go to FSUIPC options, look at the first Tab displayed. 3. After running FS, look at the first line in the Log. There's also a 4th but less reliable way, and that is to look at the User Guide in the Zip, first page. Either you downloaded the wrong version (your ISP probably hadn't updated its cache) or you have installed something since which has overwritten the later one. Probably because instead of checking the option to Log events you were logging IPC Reads, which are not relevant here at all! None of this is going to tell me how the Hat behaves. Please re-program it as a POV to do as you think you want it to in FS, delete (temporarily remove) your FSUIPC programming for it. Then enable both Axis and non-Axis Event logging in FSUIPC. Test all hat positions USING FS. It really isn't so useful programming FSUIPC and then showing me FSUIPC doing as you programmed. Nothing is actually learned that way (well, by me at least ), do you see? We need to know what it is doing in FS, not in FSUIPC! Didn't you ever look for JoyView? Regards, Pete

There would be little point unless the hat is providing continuous changes. If it is only giving 8 discrete values then it can be fully programmed already. Really? That has never been reported before, and certainly, years ago when I did have a joystick with a Hat I could obtain the 8 positions separately. I need to know what your hat is doing to achieve that, please. Where's the logging? That would likely be either because you assigned the wrong controls, or the right controls with the wrong parameters, or you have the FS CFG "pan_in_cockpit_mode" parameter set incorrectly for what you want to do. Because it is NOT an axis, not even for FS, it is a "POV", and the only POV support FSUIPC offers in as 8 buttons. I thought we went through this? You can assign parameters in the options, on screen. Why do you want the syntax (but, yes, it is in the Advanced Guide, and anyway you've already been using it, haven't you. You showed me in your previous message -- you just had 0's for all the parameter values). I really cannot help much without information about how your hat works. Did you not get any, not do any logging, or look for that Joyview program? Pete

Maybe, in FS2004I am not sure. I didn't think anyone was using the FS98 weather offsets any more. I've tried to maintain support for them through FS2000, FS2002 and FS2004 but they are so far divorced from what really goes on in FS2004 that it gets quite hairy, and with all the new, impressive, weather programs long ago moving over to more powerful and appropriate interfaces I doubt these have been tested thoroughly enough. If they are truly AGL, can you try flying or slewing over hills and see if they go up and down all the time as the ground rises and falls beneath you? Let me know. You see, if it doesn't, then what is that lower wind doing? Is it going up and down with the ground? If so and the next layer is not far above, what happens when they collide or intrude, is the layer above obliterated, or is that too rising and falling, and so on up to 60,000 feet or wherever? I don't think the spot-check way you are measuring / checking is really so reliable. You are expecting FS to set the weather the way you are thinking it should be set. The proper way to see what FS thinks the wind layers are is to go into the Weather Dialogue each time, and read the altitudes in the Winds section. Another more reliable way would be to switch on the wind display (Shift+Z) then slew upwards and see which altitude the wind DOES actually change -- make sure any FSUIPC wind smoothing is off first of course. Please let me know. I think after 3 years of FS2004 it is a little late to change it, and some comparisons with FS2002 and FS2000 would be needed to to verify whether I have the programming wrong or the documentation, and really, at this time, I don't have the time. But I'd be interested and I'll certainly note it. BTW you can also compare it with what the FSUIPC AWI reports (by using WeatherSet) and also the NWI (WeatherSet2). The AWI is really the 'modern' weather interface which matches closely what FS2004 is capable of. Regards, Pete

Not just laptops, also many Desktops/Floorstanders. I've had great success with some I bought very cheaply. Nice small things, just really a lead with a USB plug on one end and a COM socket on the other, just a little bigger than normal. They are real cheap, made in China, and the only name on the packaging is "Best connectivity" . I've had bulky expensive name brand ones which are a pain and don't work properly, but these (around GBP 6, or $10 I suppose, each) are excellent. Regards, Pete

Well, that is all that has changed which could possibly affect anything in the joystick calibrations. It is really sounding as if, somehow, your FSUIPC.INI file has got corrupted. Why not just re-calibrate, or find a backup? It's part of the aircraft-specific facilities and applied to Buttons, Keys, Axes and Calibration sections. Since you don't use Aircraft Specific sections you wouldn't have noticed it, so it isn't of any consequence. Yes, that's what you need to do. This merely confirms very strongly that you need to calibrate. It sounds very much like you have got it using default values, which would be designed to place the "centre" in the centre, of course. FSUIPC has no idea about your 'detente'. You have to calibrate the centre around that position. It is so easy to do, please just check the instructions. It is but 30 seconds work! No, not at all. The values in your INI file are messed up. Please just re-calibrate. Regards, Pete

Yes, but I will be incorporating GPSout and AutoSave in the user facilities of FSUIPC 4, with their own options pages. They'll be available to registered FSUIPC 4 users. Regards, Pete

Well, it wasn't so bad when I got it -- I started with FliteMap when it was still MentorPlus, and one-time upgrades were a lot cheaper than they are now. I somehow wangled reasonably priced matching NavAid and FliteMap updates all the way to 9.0x and about Jan 2005 or so's NavData (I think, not sure without looking). Yes. I've never used it, mind. Yes, I did contemplate getting Jepp View, but for World-Wide coverage that was/is expensive. These days, though, I tend to only fly in Europe so I suppose it could be a consideration -- if it doesn't involve and update to 9.16! ;-) I do have an out of date complete set of Jeppesens in lovely leather binders (World-Wide) -- bought those bit-by-bit over a period. Nice for browsing -- I do still like paper, unfortunately. But for all practical purposes I now use nDac from NaviGraph. Regards Pete

Sorry, the "FS" was a typo for "FSUIPC" (ALL versions since joystick calibration wasadded about 8 years ago). No, that was well before 3.70 and is quite independent. The only new thing affecting Joystick Calibration settings in 3.70 was the "ShortAircraftNameOk=Substring" option, related to aircraft-specific settings. Did you read all my last message? If so haven't you any other answers? Pete

As you will have seen from Mr. Fournie's explanation, it appears that FliteMap is dead w.e.f version 9.16. You have no moving map features in that version. :-( Regards, Pete

Thanks for the info. Butouch! Boy, am I glad I am still on a version before 9.16! Thanks, I'll take a look, but I'm pretty much tied into FliteStar at present through my plan conversion utility (FStarRC) which gives me FliteStar-made plans in Project Magenta, FS and Radar Contact formats. [LATER] Just had a quick browse. They don't state coverage anywhere, but it does appear to be very US-centric. I tend to fly (sim-wise) 90% Europe, with EGCC as base. My Jeppesen FliteMap is a Corporate World-Wide edition, with NavData updated last year ready for FSX. ;-) Regards, Pete

Okay, so let's see what you said: 1. Is this with a default aircraft. If not, change to a default aircraft first. 2. Are you assigning axes in FSUIPC or in FS? 3. If you are using FS with separate axes for each engine, then there are a total of 5 zones on the axis range -- below full reverse null zone, then the reverse range, then a null idle range (the "centre" settings), then the forward thrust range, and finally a null zone above full thrust. It sounds very much like you have calibrated the throttle wrongly, OR 4. Are you using the facilities for Aircraft-Specific calibrations, and if so, is this one such specific assignment set? If so, please note there is a bug in 3.70 which occurs in aircraft-specific calibrations if "ShortAircraftNameOk=No". Try changing that to "Yes" or "Substring" for now. This bug was reported by one user (only) so far and doesn't seem to occur on all systems, but I have tracked it down and the fix will be included in the next FSUIPC update. Meanwhile this parameter change is a good work-around without any side effects. If that is truly the case then it clearly needs re-calibration. The values in the INI file are only ever set by you, when calibrating. They are never changed by the program otherwise. Regards Pete

Sorry, there is no such thing as FSUIPC 5.536. It probably won't exist for at least another 3 or 4 years. Please downgrade back to the current version, which is 3.70. When you've got a valid and correct FSUIPC installed and tested, come back by all means. But I cannot help with non-existent version at all. Sorry. Regards, Pete

Do you mean FliteMap? As far as I knew, you paid extra for the GPS input facility in FliteStar, and then it was called FliteMap (although admittedly the installed binary is still FliteStar.exe! ;-) The version I am using is 9.04 and I have no problems at all. Strange they would reduce the list so much, especially only in a point update. My version 9.04 (Build 7523) lists loads of GPS's by make (left scroll window) and model (right scroll window). Almost all of the Models are also listed with different protocols after the model number, including NMEA 0183. There's also a "make" called "Generic" for when you don't know or care, and the 'models' there include Aviation protocol and different NMEA varieties accepting different (explicit) sentences. I have it set to Garmin -- GPS 95 NMEA 0183, but it works with most of them in any case as long as they are NMEA. My GPSout sentences are RMC,GGA,GSA. If Jeppesen have for some reason removed most of the GPS input facilities (which would seem very odd), then all I can suggest is trying every one till it works. You could also enable all the NMEA sentences in GPSout (but keep the frequency low and the speed high as this will really clog things up otherwise) until you find one of the FliteMap settings which work, then start removing sentences to see which you really need. I assume you can still set the speed too? They haven't fixed it at the default NMEA speed of 4800 have they? That would be awful. I use mine at 38400, the highest in the drop-down for speed setting. Regards, Pete

Ah .... FSUIPC sees a Hat as 8 switches/buttons, whereas I think the PAN facility reads it a little like an axis -- the Hat values being the parameters. Are you sure it isn't continuous, like an axis? Re-assign it in FS and use the Event and Axis logging in FSUIPC to see what FS is passing. I really have no idea because I don't know what the old HAT switch assignment is doing. I don't have one, you see. But first, please tell me, WHY are you trying to do this the hard way, by editing the INI file? Have you looked at the Buttons assignment facilities in FSUIPC. Surely it must be 1000% easier to do it on-line, where you can move the hat, assign a control by name and so on .... you have me quite puzzled! Since I don't know what your "old Hat" was doing, and I can't try this way (not having any such hat), I really can't say. Surely it is easy for you to test? Are you saying you've not even tried it? I don't know, because i don't know what your Hat does in FS in the first place. Check the logging as I suggest. It may work better if you program it as a PAN VIEW with a parameter to tell it the direction -- typically hats return a direction either in degrees (0, 45, 90, 135, etc) or in 100ths of a degree (0, 4500, 9000, 13500 etc). The log should help tell, otherwise you'd need that JoyView program I've uploaded here a few times. If you can't find out from logging, let me know and I'll see if I can find it and attach it here too (or you can scan the threads here with papaer clips indicating attachments). Note that, if the Hat is providing continuous changes, like an axis, I will consider adding it as an extra assignable Axis in FSUIPC. I would be completely dependent upon folks like you to test this for me, but otherwise I don't think it would be a big problem -- just a matter of finding the time! Regards, Pete

Yes, but if you are also trying programming you have to be classed as a programmer too, and programmers do certainly need to think logically and be able to read and get into such details with care and understanding. That does even apply to VB programmers, I assure you. Otherwise maybe programming is not a hobby for poultry farmers? ;-) Regards, Pete

Erthe subject of your message says "how do I register my program ..." but the text says that YOU would like to register. Which is it? Program access to read and write FS values is not the same as User access to all the documented user facilities. Did you look at the documentation at all? The registration business is all described quite early on. You don't need to read it all. Regards, Pete

In the first byte you will have the code for 'Z' (90, or hex 5A). In the second there are all the shift codes. For simple Shift just bit 0 must be set. Bit 0 is the lowest bit, value 1 (2^0 = 1). You simply make a value from all the bits you want set. Isn't the documentation clear enough on this for you? Can you clarify what it is you don't understand, please? You should write the whole 4 bytes as one 32-bit value (an integer in VB, probably, or is it a long?). This would be no different to writing any other 32-bit (4-byte) value. In the case of Shift+Z the whole 4 bytes, assuming no other options are to be set, are, in order hex 5A, hex 01, hex 00, hex 00. Now, as a 32-bit value you have to remember that the first byte is the LEAST significant (i.e. lowest in value), so in hexadecimal the 32-bit value is: 0000015A or in decimal simply 346 (being the 256 for Shift, plus 90 for Z). No, Window ennumeration has never been a facility in FSUIPC, probably because it has never really been asked for. It is also not always obvious how to determine these. The Window Class for all such is "FS98CHILD", so that doesn't help a lot, and the title is, I think, dependent upon language version -- maybe it can be looked up in the LANGUAGE.DLL. Ideally, perhaps the Windows ID number should be used. This corresponds to its position in the Menu and its number in the PANEL.CFG file, as well as the Shift+N value used to toggle it on and off. But there again, any window can have any title as dictated by the PANEL.CFG, so determining which might be a GPS is problematic. Regards, Pete

Do you mean the keycode for FSUIPC's hot keys for applications, or what? I'm not sure of the context. Regards, Pete

There won't be an offset for a control action like that. You can either simply write zero to both aileron and rudder control offsets, or send the actual FS control corresponding to the '5' button to offset 3110. I can't remember what control it is, but you can find out easily enough by switching on FSUIPC's event logging (in the Logging tab of the Options), and pressing it -- look in the resulting Log file. Pete