Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Yes. FSUIPC4 is a different program. It had to be re-designed and rewritten for FSX (and, hopefully, the future versions of FS). Pete
  2. Okay. the Manager kindly personally checked into exactly what happened here, and this is his reply: I hope this is clear and enables you to sort out what you want to do. Regards Pete
  3. I think they are all saved with a flight. Just set everything the way you want, then save the flight marking it as default. Pete
  4. I've sent a copy of your original message here to the Manager of SimMarket. I really can't do anything else. Sorry. Let's see if he can help. Yes, okay. I didn't notice the order number before. Regards Pete
  5. Thanks Hervé! And a Happy New Year to you! [LATER] I've had a look can get the Pressure altitude for FS9 too -- in fact I'll do so in the next interim update, and put it in the same offset as for FSX! Odd no one has asked for it before. Best Regards Pete
  6. Yes. Pete
  7. I thought you had to go retrieve your key, not wait for it to be sent? with all the stuff I've ever bought from them that was how it worked. I'm not sure i can do anything except send them a copy of your message here. Of course your identity will be your false "name" here -- why do people like to hide behind them? What is there to be ashamed of? -- so I don't see how it can help at all. Regards Pete
  8. Yes, you can do that. In the "Buttons and Switches" option page when you operate the Hat you should find that it is recognised as a series of switches, 32 at 12 O'Clock through to 39 at 10:30 -- assuming your hat recognises 8 cardinal positions. FSUIPC treats each position as a "button press" and when you release it that's a button "release". If you don't program the release section, then on release nothing will change. The controls to assign have names like "View forward", "View forward right" and so on. Don't forget to de-assign it in FS. Regards Pete
  9. Sorry, I don't think I understand that question. Of course FSUIPC works without WideFS. FSUIPC just needs to be installed into an FS installation. It doesn't need WideFS! WideFS is for linking FSUIPC applications to an FS PC running FSUIPC from a PC which is NOT running FS at all. If your second PC is NOT running FS, then your question about installing FSUIPC on two PCs is irrelevant, as you cannot install FSUIPC without FS. Pete
  10. Yes. Your registration for FSUIPC is for you, for as many computers as you, yourself use. If there are two or more users each should purchase his or her own registration. Regards Pete
  11. I think you can do it directly in FS, but the "priority" is then simply "the last signal wins". So if one it untouched it won't be read UNLESS it has any "jitter". One way around jitter is to make sure the centre "null zone" is big enough to overcome it -- if FS cannot sort it certainly FSUIPC calibration can. The other way, using FSUIPC, is to assign the second yoke axes to other, otherwise unused, FS controls. Then you tell FSUIPC what those control numbers are and it reads them as alternative flight controls. When FSUIPC is doing this it takes the MAXIMUM deflection of the two controls, so it is quite unlikely that unintended changes are made. For details of the FSUIPC facilities see the "Multiple Joysticks" section of the Advanced User's guide supplied with FSUIPC4. It is near the back. If you are running two copies of FSX on two PCs, linked by FSX's "shared cockpit" mechanisms, then one is acting as Pilot Flying and the other as Pilot not Flying, and the roles are switched by command. Regards Pete
  12. 4.212 works perfectly in this regard, I have just re-tested it here. The problem you have, I believe, is simply that whilst you have told FSUIPC to calibrate your Throttles and your Pitch axes, you have not yet done so for your Mixture controls! This can be clearly seen from the state of your INI file. The changes in 4.16 or so mean that axes are not intercepted and "stopped" by FSUIPC unless calibrated -- this was a deliberate change to prevent problems with some add-on aircraft. For any of FSUIPC's axes facilities to work you need to, at minimum, press the top left "Set" button in the relevant section (so that it now reads "Reset") -- you need to do that for mixture 1 and Mixture 2 on the 4 mixture page. Best to calibrate too whilst you are there! Regards Pete
  13. Hmm. These terms tend to confuse me these days (old age? ;-) ), but if you mean the altitude read from the altimeter then it is in offset 3324. I found it by searching on the word "altitude" (You see, I don't actually remember all these offsets, I have to search for them too! ;-) ). Note that it might be in feet or metres depending on the user's choice, also readable. Regards Pete
  14. Please re-test with the current interim version, from the FSX Downloads above. Also check that you do not have any double assignments. Let me know after you've tested with the latest version, and then please also show me the [JoystickCalibration] section from your FSUIPC4.INI file (and the [Axes] section if used). Regards Pete
  15. The same problem actually did affect FSX + LevelD 767, too, only I put it down to the excess latency -- from intercepting the FS controls used by the Autopilot via SimConnect and relaying them on. I thought that it was this delay causing control to be erratic. The solution in FSX was simply to not intercept any axes which were being assigned in FSUIPC4 for direct calibration. It turns out that my understanding of what was really happening was not quite correct, though happily the solution was the right one. The change in FSUIPC 3.773 is effectively the same as that done in FSUIPC4 way back in version 4.16 (August 2007). This is the write-up in the History document about it: Axis assignments in FSUIPC which are set to go direct to FSUIPC calibration (rather than via FS controls) do not now enable the interception of those controls from FS. This makes this version (again) work correctly with the Level D 767 provided that either FSUIPC is not used for aileron/elevator/throttle calibration, or it is but via its own axis assignments directed to its own calibration. Of course not. Are you misunderstanding something? Regards Pete
  16. Ah, good. Thanks for confirming! Pete
  17. Try just searching on the word "Tank". Here it finds it on the second attempt. Offset 0AF8. Hmm. I've never heard of that and I've no idea where in FS it might be, but there's a control listed in the List of 2004 Controls called "TOGGLE_ALTERNATE_STATIC", so it must be in the drop-down list of assignable controls in FSUIPC. Try it. If it does what you want you can always operate it through the 3110 offset. It is number 66317. I think you need to refine your searching methods -- certainly the tank selector is very easily found by searching for "tank". Regards Pete
  18. I think that tends to confirm my theory. The elevator exis centre is okay, operating in your calibration from -3120 to +4992, so including the critical 0 value. The ailerons on the other hand, with that calibration, will be sending a right-aileron signal (-ve value) when 0 is set by the A/P. It looks like the A/P assumes 0 is wings level (which of course with normally calibrated well-balanced pots it would be). This being the case I have high hopes for version 3.773, now being uploaded to the Other Downloads announcement. No, the level D is trying to use the same axis controls which you are overriding. I think most aircraft do this, but probably not for minor changes -- you probably have to be quite severe in the movement of the axis. I think it is designed that way so you can take manual control quickly in emergencies. I use Project Magenta, not any FS A/P, and it certainly does that but I don't know if any add-on aircraft do it. Okay, thanks. Regards Pete
  19. Okay. I've been mulling this over in my head the last couple of days, and it occurs to me what might be happening. Now so many other reports I really cannot think are due to the same problems you have. I think the earlier parts of this thread do really apply in the majority of cases. But let me discuss your particular case. You see there is no difference whatsoever in how FSUIPC treats ailerons to any other axis. I'd like you to confirm, or otherwise, the CENTRE positions you have to calibrate in FSUIPC for your yoke (both aileron and elevator) to operate in manual flight to your satisfaction. For if your aileron centre is well off the otherwise expected 0 position then here is what I think is happening: The LevelD autopilot, unlike real and most other autopilots, is probably assuming that specific values for the aileron control do specific things to the banking/roll of the aircraft. for example, rather than monitor the bank angle and adjust the ailerons left or right to maintain a required bank angle, it assumes, for example, that the value 0 will give zero bank -- i.e. level wings. If this is indeed the case, and your calibrations in FSUIPC place the wings-level position well off the otherwise FS-defaulted 0 position, then I can see how the A/P would lose control. In the case of the LevelD aircraft and FSX I had assumed that it was the extra latency, of intercepting axes via SimConnect, which upset LevelD's control, but it may have been a combination of that and the sometimes slightly off-centre calibrations folks had. The problems folks reported in FSX were far greater and more difficult to overcome than those reported earlier in this thread for FS9. In FSX the solution was to make FSUIPC4 not intercept axes which were being assigned "direct" in FSUIPC4 itself. Assuming my theories above to be correct, I am going to provide an option in FSUIPC3, which I shall probably have set by default, to avoid intercepting axes which are assigned directly. Please try that and let me know -- it'll be FSUIPC 3.773, probably later today (Tuesday). Check the "Other Downloads" announcement above. Regards Pete
  20. Okay. there are two ways of getting over that. First way is to always start and end your flights with the cockpit in the same state -- normally a parked, cold and dark state with all switches correctly off. That way even toggles stay synchronised. The only real problem with that is that if you crash or have any other interruption which causes you to revert to a different state you are again out of sync. The second way is to use the facilities in FSUIPC as make switches write to internal locations in FS, via the "Offsets". There are offsets corresponding to each of those switches, and there are Offset Byte/Word/Dword Set controls in FSUIPC's dropdowns which can be used to write stuff to them -- 1 for on, 0 for off. To see the full extent of what can be done that way you'd need to download the FSUIPC SDK and check the offset list in the "Programmers Guide." Driving the indicators on any GF module isn't automatic. FSUIPC itself has no hardware output facilities. I did produce a freeware module called "GFdisplay" which can drive LEDs from Offset values. Check that out. Regards Pete
  21. FS does actually implement up to 4 separate generator switches internally, though the controls which operate them do refer to "alternators". The term is used interchangeably it seems. I don't think you could have looked very far because there are "TOGGLE ALTERNATOR1", "TOGGLE ALTERNATOR2", "TOGGLE ALTERNATOR3" and "TOGGLE ALTERNATOR4" controls listed that I can see. The usual experience with FS is that the battery drains far too fast, unrealistically so (e.g. in FS2002 the 737 it drains too fast to do a realistic overhead check and so on before starting the APU). FS2004 is better than FS2002, but the whole problem was the reason for the "magic battery" life extender provided in FSUIPC. Some add-on aircraft "cheated" and maintained the battery at full voltage forever even when not being charged. If yours does that then I'm afraid there's no fix. Note that once the battery is allowed to drop below a certain voltage, it becomes a system failure and requires a full repair (aircraft reload or menu failure cancelling) -- merely getting the generators or APU going doesn't help then. None of the aircraft I know of are normally flown with the batteries switched off. They get charged by the alternators/generators whilst still in circuit, same as in a motor car. You don't switch your car battery off whilst driving do you? Regards Pete
  22. Okay. Glad you're mostly sorted out. Thanks for keeping us in the picture. Pete
  23. I had a look at this and it was easy to do, so I've added it in the latest test versions, available in the Downloads Announcements above. With those all you'd need is IgnoreThese= 2.17 in the [buttons] section of your FSUIPC.INI file and that spurious indication will be ignored, whilst in the dialogue. I'd still advise trying to find and rectify the cause first, however. Regards Pete
  24. Have you read the earlier messages on this thread? I have, and it seems there are solutions whilst still calibrating in FSUIPC. Please start at the beginning of the thread and read it all. Regards Pete
  25. It sounds like that device is producing spurious indications regularly, looking like it does have such a button pressed. FSUIPC always shows the last button it sees going from "unpressed" to "pressed". You can check this using the JoyvieW program attached. Also see if you get it with the device unplugged. It is most likely to be a hardware problem, either in the device itself, or in the USB cable or USB socket. You could try plugging it into a different socket (though be prepared, then, for the Joystick number to change in FSUIPC). If you are connecting it to a USB hub it may be that the power it is getting from that hub is insufficient. With axes, which can jitter naturally, I do provide an "ignore list", usable only on-line, so you can get past the repetitive recognition of a jittery axis. It isn't easy to implement the same sort of thing for buttons -- and with working hardware it shouldn't be necessary, but I might consider adding an INI-file only facility to list "bad buttons" which should be ignored. This would only be a desperate attempt to make things work when they are broken. But first please try the things I suggested. Regards Pete joyview.zip
×
×
  • 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.