Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Capatain's Sim install isn't very nice it seems -- it sounds like it is installing an old (pre FS2004 update, Sept 2004) edition of FSUIPC and not actually checking whether you have a later version. Luke is correct. The only way to deal with it is to install the latest FSUIPC after installing the Captain Sim add-on. This is very good advice for any product, in any case. They rarely come with the latest versions. Regards, Pete
  2. "Tick"? Do you mean the INc/DEC controls? I use the same as one press on the Numpad 7 or 1 keys -- I'm just emulating the normal elevator trim, that's all. Does a real helicopter have a rudder trim? It isn't as easy as there's not the same regular controls for that in FS in any case. In fact it was a very late addition to FS altogether, even for fixed wing aircraft, and most light aircraft don't have rudder trim. I'd rather not do it if it is manageable -- after all, you have to keep some pressure, albeit quite small, on lots of light aircraft, especially with high prop revs. That's what your feet are for! ;-) Regards Pete
  3. The problem of using several PCs to try to show an extended outside view is that you just cannot get the weather synchronised on all of them at the same time in any case. I don't think the source of the weather (i.e. which program you use) is relevant. From previous reports I suspect there's also a bug in WidevieW's method of copying the weather. From what folks say it doesn't seem to be dealing with all the local weather stations as you fly, with the result that the weather "disappears". Incidentally, you can't get the AI traffic coordinated across multiple PCs either, though this probably is only of major importance when taxiing at airports and taking off/landing. FSMeteo is a weather program like ActiveSky. The two have been competing for several years now. FSMeteo took an early lead but I suspect ActiveSky is well ahead now. Both are payware of course. I don't know much about FSMetar. There is another payware weather program called WeatherMaker Pro. Regards, Pete
  4. Please try the attached FSUIPC version 3.548. I've added a facility to maintain and apply an "elevator trim" to the "elevator axis" for those models which otherwise have no such trim. The details are: 1. The new trim is operated by all the usual FS controls for elevator trim -- Elev Trim Up, Elev Trim Dn and the axis version. So you just program your trim in the same way as for a normal aircraft. 2. It only operates if you add "ApplyHeloTrim=Yes" into the appropriate JoystickCalibration section of the FSUIPC.INI file. I'm afraid I cannot detect helos in a foolproof way -- the Bell looks like one, but the Robinson doesn't, internally. 3. As a safeguard it also doesn't apply the trim if the normal FS elevator trim value is non-zero. That way you don't get two trims adding to one control even if you make a mistake. 4. The trim is only applied to an elevator axis value calibrated via FSUIPC, in the Joystick Calibration section. This is the only reliable way I can influence it. 5. For a trim indicator or programmatic control I'm reading and maintaining the helo trim value at FSUIPC offset 0BBE (16-bit integer). I cannot provide it via the standard FS indicator position as that is held at zero by FS for helos (as you found). Please let me know how you get on. I'm afraid I'm no helo flyer so I've not actually tested in action here, only theoretically. Regards, Pete FSUIPC3548.zip
  5. The kit I used to have used these and not the more complicated encoding types which you say are more popular -- in fact I didn't even know about the 'popular' types till someone sorted out a way of programming the phase-encoded types for EPIC. There is mention of the phase-encoded types in the Advanced User's document for FSUIPC -- in fact there's a complete example. I think the 2-line phase encoding type is the same as a 2-bit graycode type. I really don't know where you'd get the "simple" ones from. The ones I had (I no longer have that kit) were out of the original Aerosoft (Paderborn) keyboard-connecting control panel, so I assume the switches were German. I've not seen any in any UK catalogues. You could try the cockpit building forums. Someone there may know. Regards, Pete
  6. That cannot be. You are looking in the wrong place. Do a search on your PC for all FSUIPC.DLLs. You are getting something very very confused. It is absolutely not possible for version 3.53 to display "3.48". There is no such text in it. The last time anything like this happened the guy was checking an installation of FS on a different drive or folder to the one he was actually using! Regards Pete
  7. It was the only reason I started on FSUIPC in the first place. Anything is possible, almost -- but I am not starting on anything new, This has taken me many years full time and I'd like to make space to do some flying and maybe even get back to my model railway. I am not taking on any new FS undertakings. Perhaps, since you have ideas you will instead? Please do a search on this, and read the WideFS docs. I have explained this all sorts of ways several times. I really haven't time at present. Sorry. Sorry, what does that mean, "very long process"? You think you can make it all work much faster? The only thing which is slow is process switching -- how can you avoid process switching? Regards Pete
  8. FSUIPC's interface was defined (not by me) in FS95 times in FS5IPC, then FS6IPC in FS98. There's a lot of history. The interface has been compatible now with application programs since FS98, continuously. By all means write an interface to FSUIPC if you like, or, better, feel free to write a replacement to FSUIPC. But how to you make all the applications compatible "just like that"? I'd would really like you to do this as I would rather fly more in future! ;-) Regards, Pete
  9. Isn't this clear from PMDG? Yes, they are licensed to use FSUIPC without the user paying any extra, and no, there is no such thing as a "licensed version". They may ship a version, but it most likely will not be the latest. I only support the current version at any time so it is in your interest to download and install updates from time to time. Do not confuse "licensed access" and "versions of FSUIPC". Licenses for FSUIPC version 3 apply to ALL versions 3.xxx. There is no "licensed" version as opposed to an "unlicensed version". I have enough to do without maintaining such silly diversities. ;-) You can get the latest version of FSUIPC "for free" at any time in any case -- it is freely downloadable at http://www.schiratti.com/dowson, and there are often later interim versions, with more facilities, here, in the Announcements above. If you want access to the user facilities in FSUIPC you purchase a user key from SimMarket. See the links on the Schiratti website page, in the Announcements above, and in the FSUIPC User documentation which you will find in the downloadable ZIP. When you get the key, just follow the instructions. Regards, Pete
  10. I would be very surprised if any aircraft needed FSUIPC for its autopilot, and most certainly not the GPS which FSUIPC doesn't deal with at all. The error message isn't from FSUIPC -- there is no such message. You really need to contact the support folks for the aircraft. However, when you say "open FSUIPC in the module folder of the menu, it says that I registered for the 3.48 version !" do you mean that the menu says you are running 3.48? If so, then you most certainly are running 3.48. Did you install something after installing 3.53? If so it has probably overwritten it with an older version. Incidentally, there is no such thing as "registered for a 3.xx version". The registration covers ANY version 3. You are NOT installing 3.53 then. Go to the FS2002 modules folder in Windows Explorer, find the FSUIPC DLL and right-click on it. Select Properties then Version. It will tell you the version there. You need to ask support for the aircraft about that. FSUIPC will play no part in such matters in any case. Regards Pete
  11. Well, maybe it isn't as explicit as that (but see next paragraph), and I'm not sure it is my job to explain all things about FS, only to give advice about my programs, which I do, but what do you think joystick calibration is for in the first place? How can FS react in the same sensible way to joysticks with all sorts of different characteristics? I cannot understand how you could imagine that FS operates on your actual joystick values -- you've already shown how those can be "fiddled" to give you no reverse zone on a control for which half the whole range might otherwise be reverse, remember? The main reference data I provide for FSUIPC users is in the Table which appears in the Joysticks section of the main user guide. I realise this is only reference material, but you will see that it does state that the throttles operate the way I've just mentioned. Here is the relevant part from that table: Of course, the part you presumably referred to and misunderstood also rather implied, even stated, that idle was zero, don't you think? It also said not to bother changing it unless to could reliably set idle. The main place where the ranges of all the axis controls inside FS is made obvious and more exact is the programming guide for those writing programs for interfacing direct to FSUIPC. External programs exercising direct control need to provide the values FS is using. Regards, Pete
  12. But as I explained (did you not read all of my reply?), and as should be quite clear from the documents, the FS throttle values for forward thrust operate from 0 to +16383. Idle is 0! Always! You are completely confusing yourself with the values your joystick is providing, which is nothing to do with the FS throttle values EXCEPT insofar as they are related to them via calibration! THE WHOLE POINT OF CALIBRATION IS TO ENABLE FS TO WORK WITH ALL SORTS OF DIFFERENT JOYSTICKS. Its values are the same always -- ZERO is always idle, a negative number is always reverse, and so on. Calibration is a process of mapping your values to FS's. Of course not! And I explained why! Please see above! You are asking FSUIPC to prevent the reverser when FS's throttle is above -15000. If is is below -15000 is it pretty much applying 100% thrust in reverse already!!! No FS aircraft allows this in any case -- max reverse is usually about -4096 (25%, it is set in the AIR file or by an Aircraft.CFG parameter). PLEASE read what I am saying, and also what the documentation is saying! I know EXACTLY what you want to achieve. Just delete the line you've messed up (MaxThrottleForReverser=-15000) and it should work fine, unless you cannot always get the throttles to a complete idle (0), in which case increase that parameter a little. It really should never need touching if you calibrate correctly! Look, I'll even reproduce the reference in the documentation: See the bit saying "the reverser will not engage until all throttles are reduced to this setting (normally 0, or idle)", even clarified by the bit saying "You can try a non-zero value here if you cannot calibrate your throttles to produce a stable idle zero"? Are YOU having difficulties setting idle? If not, why fiddle with this? If you are, you need to INCREASE it from its default of 0, not whack it right down to an impossible to reach value!! No. Sorry. Regards Pete
  13. Why have you set this to such a strange value? The default is 0, or maybe 256. What this now says is "don't engage the reverser until the Throttle value is less than -15000". In other words, don't engage it until it is way below max reverse already (most aircraft have a max reverse of -4096 or so). This value is set to allow the reverser to work even if the throttle calibration isn't spot-on, and the current Throttle value (inside FS) isn't quite zero. Forward thrust throttle values run from 0 to 16383. If this parameter were set to 16384 then you could engage reverse even with throttle at full max thrust (most unrealistic). With your setting you can never engage reverse thrust! So, why did you change it? Are you reading something I wrote somwhere that suggested it was correct? :-( I've just re-read the description in the documentation and I cannot see how you could possibly have decided that -15000 was a good idea. (See where it says "idle zero" for instance?) FS's throttle runs from around -4096 reverse to 0 idle to +16383 full forward. This is what calibration attempts to achieve for you, converting whatever strange values come from your joystick into the values FS understands. Regards Pete
  14. Pretty much all of the applications (other than aircraft installed INTO FS) which need FSUIPC to talk to FS -- check http://www.schiratti.com/dowson, there's a list of a lot (but by no means all) on the right-hand side. Myself, I use Radar Contact, ActiveSky or FSMeteo, FS RealTime, FS Flight Keeper, several Project Magenta modules, my own TrafficLook and WeatherSet2, etc etc. Surely you would decide what YOU want to do first, then configure things accordingly, not buy something then think of a use for it? That really was only ever useful in FS98 days, for Chris Brett's EFIS98 program, which had a set of gauge-type displays docked to FS's window. The bitmap was a way of providing it with a cockpit sort-of background. These days probably all separate FSUIPC applications don't dock to the FS window at all, so you don't really need or use the WideClient window -- though it does get used if you want its button capabilities mousable -- those are really designed for a touch-sensitive screen though. I use one in my cockpit. Otherwise you are better off minimising or even hiding the WideClient window, as it gives more screen space for real applications. Regards, Pete
  15. That's annoying. What about the trim axis? If it is truly dead, I would need more code to maintain my own copy. If the axis works, I could make the INC/DECs work too, just a little indirectly (i.e. via the axis control). Try the Robinson, please. I think that's a prop internally. I won't get time to look at anything here till later next week. Pete
  16. All that is very interesting, but none of it really can be at all to do with anything of mine. You've got something in a mess there. I suggest you review everything you've installed or changed recently and try to undo them one by one until you find it. Either that, or re-install FS altogether and start again. The fact that you are getting two of some things seems to imply you may have some duplication or other odd things installed in your modules folder. You haven't been messing with anything there have you? Most of the DLLs are essential parts of FS and shouldn't be changed, and certainly nothing should be renamed or duplicated. For general advice and help with FS2004 I suggest you visit the FS2004 Forum. Regards, Pete
  17. WideFS is an extension of the FSUIPC interface, for external FS applications (i.e. those you can run OUTSIDE of FS). It says this clearly in the documentation. FSNavigator is exactly the opposite. It is not an FSUIPC application -- it does not use or need FSUIPC. So even if it was an external application it wouldn't run on WideFS which is an FSUIPC interface. However, FSNavigator is not even a separate application, it is installed into and runs as part of FS itself. How do you propose to even get FSNavigator, the program, moved over to your other PC? There's no separate program as such to move! Regards, Pete
  18. Couldn't I use the trim values for that? i.e. an option to add the trim to the elevation value continuously (but keeping it in limits of course) -- assuming, that is, the trim values are only being ignored by FS, not being zeroed. (to find out, please monitor offsets 0BC0 and 0BC2 in FSUIPC's Monitor -- see Logging page. Monitor them as S16's. If they respond to trim inputs (keyboard or INc/DEC controls or an axis input), then this seems the easiest and most reasonable. BTW does this lack of elevator trim action apply to all FS helos, or only those using a truly helo model? One of the two in FS2004 is classified internally as a prop I think. Regards, Pete
  19. Sorry, I don't understand you. what software? If you are using Microsoft FS (are you?), then the prop pitch and mixture controls are part of the basic FS design and have been available in most versions of FS I can remember. What sort of "update" are you talking about? FS supports up to 4 throttles, 4 prop pitch controls and 4 mixture controls, separately for up to 4 engines. It also provides a generic set which control one or more engines from one input according to engine selection facilities 9like E+1 2 3 4). All these are assignable in FS's own assignment facilities. Are you looking there? Or are you using FSUIPC's recent axis assignment facilities? You do really need to explain a little more about what you are doing and how you are doing it, and what the problem is. Regards Pete
  20. But if you are using the correct FSI (version 2) and the FSI file I supplied, the Altitude display is shown as one 64-bit value not an Alt-Hi and Alt-Lo. But in that case, if you have defined the variable you read "Alt Lo" into as unsigned, it is actually impossible for it to take on the negative value you show. Something is screwy somewhere! Anyway, since you now have an even later development system than I do, why not move over to using 64-bit integers where they are appropriate, and make your life much easier? Pete
  21. FSUIPC doesn't touch anything unless you ask it to. Just delete the FSUIPC.INI file in the FS Modules folder. It sounds like you have made a bit of a mess of the settings. By default none of the joystick, button of keypress programming options are active. Regards, Pete
  22. In actual fact, the Alt is really just one 64-bit fixed point number. It is only represented in FSInterrogate version1 as Alt Hi and Lo because that program could not handle 64-bit fixed point. It cannot be negative, as the lower 32 bits of a 64-bit number has no sign bit -- the only sign bit in a 64-bit signed number is the one right at the top, which in your terms is in the Alt Hi part. The number is unsigned, but it is a fraction and has the same sign as the high part, so after evaluation, if the high part is positive, you add it to it, if it is negative, you subtract it. It is far easier if the language you are using supports 64-bit numbers (eg __int64 in C/C++). Okay, in that case you are nearly there. Since it should have been treated as positive, you need to add that to the most positive number that fractional part in metres could hold, plus 1. Since that would be 1 metre, in feet your answer is 3.28084 - 1.4066 = 1.87424 ft. Now you must add that to the feet from the high part, if that is positive, but subtract it from that if it is negative. One of you is approximating somewhere then, as that would make one metre equal to 3.28051 ft. However, it is close enough for normal purposes! ;-) Surely you are not still using FSInterrogate version 1? My last version of the SDK only provided an FSI file for FSInterrogate version 2, which is far superior. Correct, it is never negative as it has no sign bit. It is the way you are interpreting it, not the nature of the number. It sounds like you are using that dreadful Visual Basic which doesn't bother to provide any support for unsigned numbers! :-( Pete
  23. No idea, but the Client log is only half the story -- you never said what the Server log showed, nor whether this was just on one of the Clients or all of them. If all that is happening is simple timeouts then you have something taking time off WideFS for long periods -- 18 seconds is allowed by the Client before it decides the connection is broken. But without any information I cannot tell you any more. Pete
  24. Sorry, there is no solution apart from purchasing an FSUIPC registration. That F16.GAU is programmed rather strangely, and on some folks systems the registration never works, and on others it always does. I have no problem at all with it here. Some folks have found it works fine after they completely re-installed Windows, so it maybe something esle which interferes with it. You'll find lots of threads here about it, though none recently. It is the only GAUge on the planet which has this problem, which has proven intractible. In the past I've recommended folks try other freeware TCAS gauges which are well behaved and actually register themselves automatically -- look for those by Lee Hetherington, for example (ILH_TCAS.Gau and others, I think). Regards, Pete
  25. The whole purpose of the separate throttles facility in FSUIPC was to provide an idle centre and a reverse zone. You could do what you want very easily just in FS alone. However: What would be the point of that in any case? You NEED an non-zero idle zone anyway to get an Idle position. What you are after is making the zone BELOW idle impossible to reach. If -15409 is the minimum your axis provides then you could do something like Throttle1=-16383,-15450,-14000,15805 for example. Now the reverse range (-15450 to -16383) is impossible to reach, and you have an Idle zone from your minimum (-15409) to -14000. If that's too big, adjust the -14000, as you like. Regards Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.