Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Hmmm. The problem could be within the Citation code or within FSUIPC. We may need Eaglesoft's support to help with this. I've no other similar reports at all, not with FSUIPC effectively hanging. Can you confirm, please, that EFB's moving map is still following the FS aircraft position and showing the AI traffic moving as normal? It isn't whether EFB does it's normal job, but whether it is actually still connected to and getting information from FSX. This is important to know because if it isn't then it would point more towards a SimConnect hang. The fact that the FSUIPC dialogue isn't being brought up when you select it might also indicate this. Is this the complete log AFTER you closed FSX down? Did FSX close properly? Check by looking in the Process list in Task Manager -- ensure FSX.EXE is no longer listed. You cannot tell from the absence of any FSX windows. This is where your flight loaded: 217216 J:\Flusi\SimObjects\Airplanes\Eaglesoft Citation X 2.0 X\CitationX.AIR 217918 Aircraft="German airlines Eaglesoft Citation X 2.0 blau" Then, just under 15 minutes later, FSUIPC detects a stop -- usually meaning a Menu was called up, or you pressed ESCape and the End Flight? query appeared. Can you tell me exactly what happened, what you did? 1094847 Sim stopped: average frame rate for last 860 secs = 40.6 fps The point here is that if you did this after FSUIPC appeared to stop, it couldn't have actually been FSUIPC that had hung -- if it was it couldn't have logged the message. Then, further, nearly two minutes later, an attempt was made to load a PLaN with no name: 1210677 .PLN and then another stop 16 seconds later: 1246511 Sim stopped: average frame rate for last 150 secs = 52.3 fps Were all these events long before the problem appeared? If so they are presumably irrelevant. If you did close FSX down and this is the complete log then I would have expected the FSX.EXE process to still be running, waiting for at least FSUIPC to close down. We might nee a Simconnect log and more logging in FSUIPC, but those will be huge to I need to try to understand what is happening in more detail first. Regards Pete
  2. I don't think that'll necessarily help -- you said you did that before. You just need to calibrate with a larger zone for idle. The instructions for calibration do advise you to move the lever away from the extremes enough to achieve both full throttle and idle. That usually dpeends on the particular aircraft you are using. Some just don't work corrctly with a reversing axis (FS itself doesn't provide one). Obviously you also need spare levers for reversers if you aren't using a zone on the throttle axes. But none of this helps with why you are getting spurious reverser operation. We need that axis logging to see what is doing that -- and you could test, too, with the reversers temporarily de-assigned, as I already suggested. If that stops it we can probably conclude that they are giving spurious inputs. Regards Pete
  3. You posted in the FAQ subforum, which is the repository for answers to Frequently Asked questions. I've moved it to the proper Support forum for attention. Please post support questions here in future. If there's no response in mouse macro making mode to your mouse click, then there's probably no regular C++ gauge table entry relating to that mouse switch. The mouse rectangle definition is an entry in a table which is created by the Microsoft gauge-making SDK when the programmer of the gauge compiles his work. If he doesn't use the Microsoft macro definitions for the gauge 'hot spots', or instead builds his gauges using XML or raw C/C++ programming, then nothing in the FSUIPC mouse macro facility will work. The rectangle section of the tables is the part which provides FSUIPC with the Module offset (the Xxxxx*Xxxxx format). The other form, which can really only be created by the original programmer, uses just a number instead to refer to the nth entry in the table. This is needed when there's more than one table entry referring to code at the same offset Xxxxx. For the latter to be at all useful, the mouse macro production mechanism must still normally generate a response. The only use of the rectangle number is to make sure the correct offset is used rather than only the first one seen. The FSUIPC log file should show what is going on. Did you look? You might need to enable Button logging. Then, without the help of the original programmer of the gauge, you'd probably have to disassemble the gauge, find the releavant tables, and work out which one is needed. This would need some assembly level programming knowledge. If you refer again to the Advanced user documentation, it does not really say that you could do it manually yourself, it says, to quote: "Now I’ll explain what the values in this specification actually mean, but in general no user will actually be concerned with them, as they either have to be supplied be the gauge maker (the add-on panel supplier), or, more usually, be generated automatically for you by FSUIPC, through use of the Mouse itself in mouse macro creation mode". I'm afraid I don't know (and in fact I've never hard of) a "LamaX", but are you sure it is even written in a form which supports mouse macros? Many modern panel gauges are written using XML or other more modern methods, instead of the venerable MS gauge kit, and tend to use Local Gauge Variables (L:Vars) instead. Regards Pete
  4. Okay. Also note that most toe brake axes need reversing (the REV checkbox in calibration), otherwise they are on when released and only off when fully pressed. Reverse BEFORE calibrating. Regards Pete
  5. I don't think you are reading the user documentation at all, are you? That sort of thing often happens with jittery controls. All you need to do is click the Ignore button for the axis you don't want to see, then ReScan. That's why there's an Ignore button! Pressing ReScan by itself doesn't do any good if the same axis is continually sending changes! No, only with the documents. Maybe you forgot about them? They are all in the Modules \ FSUIPC Documents folder, as you are told in the Installation and Registration guide. Pete
  6. FSUIPC never puts nor reads any such file from the "Flight Simulator Files" folder -- in fact it doesn't touch it -- so I'm sure that's not relevant. It sounds more like something went wrong on the earlier install, though there's nothing in the Install Log showing that. Ah well. A mystery never to be resolved i guess. Good flying! Regards Pete
  7. You found that, but couldn't see the Log? In Your INI file, I think you might need to change this: UseAxisControlsForNRZ=No to 'Yes'. Some aircraft need this for correct operation when using the No Reverse Zone axis option. Aileron=-15000,0,0,15000/8 Elevator=-15000,-512,512,15000/8 Rudder=-15000,0,0,15000/8 LeftBrake=0,15000/24 RightBrake=0,15000/24 Throttle1=-14000,-512,512,15000/40 Throttle2=-14000,-512,512,15000/40 Spoilers=-15000,16380/16 Flaps=-16383,15000/16 Reverser1=-14000,15000/8 Reverser2=-14000,15000/8 Odd that the values here are so, er, precisely on multiples of 1000, as if you've set them manually instead of by actually using the calibration facilities. Why is that? I see you have the Filter option set on almost all of the axis controls. Why? Generally it isn't a good idea unless the controls are extremely poor or you have a bad power supply to your PC which makes the readouts vary a lot. The filtering was added for old dirty worn controls and/or bad power levels, as in third world countries. The calibration for the "Boeing737-700wl" profile is different: Aileron=-16380,0,0,16380 Elevator=-16380,-512,512,16380 Rudder=-16380,0,0,16380 LeftBrake=0,16384/24 RightBrake=0,16384/24 Throttle1=-14000,-512,512,16383/32 Throttle2=-14000,-512,512,16383/40 Spoilers=-16383,16384/16 Flaps=-16383,16384/16 Reverser1=-14000,13136/8 Reverser2=-14000,13078/8 In fact, apart from the Filtering (which is actually off on Throttle1), and the minima of -14000 on throttles and reversers, it looks like you've never done the calibration at all as the other values are all default. Same goes for '737-700', except you have filtering off on both throttles and both reversers for that, and you've got two manually set values for the Flaps. Aileron=-16384,-512,512,16383 Elevator=-16384,-512,512,16383 Rudder=-16384,-512,512,16383 LeftBrake=0,16000/24 RightBrake=0,16000/24 Throttle1=-14000,-512,512,16383/32 Throttle2=-14000,-512,512,16383/32 Spoilers=-16383,16384/16 Flaps=-16000,16000/16 Reverser1=-14000,16383 Reverser2=-14000,16383 Apart from these rather unusual things, there's nothing there that would engage reverse unless the reverser axes were giving spurious inputs, which would be shown by the logging. You could also try temporarily disabling (unassigning) the reversers to check this. Regards Pete
  8. In the Modules folder, next to the FSUIPC DLL, the INI, the KEY and the Install log files, of course. Pete
  9. Have you, like most other Saitek users, programmed the button on the full back throttle position, to send "Throttle decr" or the F2 key? Because that's the reverse thrust setting. Otherwise it sounds like you have the throttle lever calibrated in the 4 throtles tab in FSUIPC and have set a reverse zone. What does "set the parameters" mean there? What parameters, where, and how assigned? Maybe the Saitek device is sending spurious jitters on the reverser axes when you move the others? You can use Axis logging in FSUIPC to find out. If you want me to check what you are doing show me your INI file. Pete
  10. Ah, you didn't mention that it was the GPS you were using. Ah, so it detects the keystrokes itself. I see, Yes, I understood that. That's what i was asking about -- you want a button push to swap between two modes, you don't want to have to hold the button down for "precise" mode. Right? The latter would need no flags of course. No, all I really needed to know in the first place was whether you wanted two distinct switchable modes, or only a special mode whilst the button was depressed. The latter is easier, involving no flags. Did you understand the point I was making that, with no conditions on the active lines, there's nothing changing in your implementation? The flag messing is entirely seaprate and doing nothing. I hope that was clear? Another question, the answer to which is not clear at all. In this: 0=P1,0,K119,10 1=P1,0,K119,10 3=U1,0,K119,10 4=P1,1,K114,10 5=P1,1,K114,10 6=U1,1,K114,10 You are potentially sending 3 keypresses for each rotary "tick", assuming that the rotary is doing a press then release on each turn. If it isn't, then it appears to give two keystrokes on one turn then only one on the next, alternately. Is this what you intended? Please clarify this else it will be difficult to know how to proceed. In this: 7=CP(F+1,5)(+1,1)1,0,C1005,256 8=CU(F+1,5)(+1,1)1,0,C1005,256 9=CP(F-1,5)(+1,1)1,0,C1005,256 10=CU(F-1,5)(+1,1)1,0,C1005,256 I can't work out what you actually intended. You appear to be using one of the rotary directions (button 1,0) to actively toggle button flag (1,0) on and off or off and on, but you don't test that flag at all, anywhere. Button 1,0 being "pressed" will automatically toggle its flag on and off with alternate presses in any case, so the actual state, at any time, of that flag is really completely indeterminate. BUT you make those actions, toggling that untested flag, depend on button 1,1 being pressed (i.e. the other direction of the dial), and also on the buttonflag for 1,5, which I assume is the mode button -- which isn't actuaslly assigned to do anything in any case, so its flag never changes. If I could understand how you arrived at this mess I would be in a better position to clarify everything for you. At present I'm just bewildered by your attempts. I'd rather explain how to do what you want to do rather than do it for you, as that is more constructive -- for you and any other readers. (That's why I run a Forum for support). Regards Pete
  11. I use EFB with no problems, but I don't have the Citation. I'll need you to show me the FSUIPC4 log file, from the FSX Modules folder, to stand any chance of understanding what might be happening. Until you stated that the Menu bar still had "FSUIPC" in the Add-Ons menu entry (that IS what you meant, was it not?) I'd have assumed that SimConnect was quitting on FSUIPC. Does the Aivlasoft system still carry on okay, connected to FSX? Reproduce the problem then show me the Log. You can paste it into a message here, it is all text. We might need to get a SimConnect log too, but that will be huge, so let's leave that till we know more. Regards Pete
  12. FSUIPC can treat Hats (more technically "POVs" = Point -Of- View controls) as either a set of 4 or 8 buttons (depending on the hat), or as a single Panning controller. For the former program it in Buttons, for the latter, assign it as an axis to PAN VIEW. Answered in any case for others to benefit. Regards Pete
  13. What's "SOL"? Are you planning to only ever fly one aircraft type? If so you could certainly modify the slot on the Saitek quadrant to have little detents made of bits of rubber or flexible plastic. But it's a lot of bother, and generally on the normal retail throttles there's simply not enough range/room to allow enough for some aircraft, like the 737 for example. I'd recommend either simply calibrating a reliable flaps up and full flaps down position, and leave the intevening movement to set by normal feedback, just like steering where yo can't see the wheel angle but know by the effect on the car. Flap positions can be seen on screen. Use such indications to determinate where you are placing the lever. Alternatively, it is actually far easier to use the INC/DEC arrangement for flaps, via a two-pole centre-sprung switch, preferably, or failing that two buttons or two positions on a spare hat. Anyway, it's getting late here and I'm off to bed. I'll check in here in the morning. Regards Pete
  14. Flaps don't have "centres" like ailerons, elevators and rudders. Flaps have angles, set by notches on the lever, and a different number for each aircraft -- eg 9 positions for a 737. Unless you are intending to only fly one aircraft type, it is usually best to either program a two-way switch or two buttons to gibe FLAPS INC and FLAPS DEC controls, or, if you really want an axis, to simply find the right position for each notch by moving the lever a little at a time and seeing it get set on screen, in the flap position indicator or via the graphic version of the lever. FSUIPC does provide a facility to calibrate notches for flaps, but where are you going to put those on your lever? Has it got any? If you want to calibrate a fixed set of notches, for a specific aircraft, you need to follow the instructions given specifically for this in the documentation. Regards Pete
  15. You can do whatever you like in whatever order you like. Obviously you can't calibrate an axis which isn't assigned however, as there's nothing to calibrate. Unless you ask specific questions I can't help further. I've written everything into the documentation. That's what it's for. And what's all this about being old? Whenever's that been an excuse? Older = wiser. I'm 69 this year. Is that so young? Pete
  16. I've deleted the attachment. Never EVER post your confidential key details openly like that! If anyone else picked it up I'd have to invalidate your key! In actual fact, however, looking at the attachment (now deleted) it was only the Install log, which isn't the relevant part. I'd need to see the FSUIPC log file, the one created at run time by FSUIPC. Please find that and paste its contents into a message here. It isn'rt worth attaching. and don't send me my own DLL please. Regards Pete
  17. If it doesn't have an external aerial, and the case is metal, it is bound to suffer -- radio waves don't pass through so easily. It should have an external aerial really. Else try a USB dongle. Some are okay, some not, but they are cheap. Pete
  18. A motherboard bluetooth? Any outside aerial? I would have thought even a USB dongle would have been better than a mobo implementation. Regards Pete
  19. Maybe it's the quality of the bluetooth output from the PC. Are you using one of those tiny cheap USB devices? I've found some of those a bit unreliable. It's likely that your GPS has a better quality device implemented. Sorry, I've no other ideas. Regards Pete
  20. I cannot fix that. It applies to any SimConnect client running inside P3D and is a known bug, introduced by their 1.2 release, which I know has been fixed internally in LM (Tim Gregson found and fixed it), but it seems they are not releasing an interim patch. Ask them. Pete
  21. I would suspect the Bluetooth operation. I have an iPad1 and its Bluetooth output (e.g. to the Bose speaker system or to Bluetooth headsets) is fine, but when a friend and I tried linking our iPads for a two-player game, the connection was so bad (and we were sitting next to each other) that it was impossible. In other words, output from the iPad seems good, but input seems very iffy indeed. I use a variety of programs for FS with the iPad -- AirTrack being a favourite, but also FSXRadar, FsxControl, FSXfollow and WideFSMap. These operate flawlessly, but of course they use the WiFi connection. I don't think playing with any GSPout settings will help -- once you've found the correct NMEA sentences to suit the program, they will be arriving at your set time interval regardless. It must be to do with the connection. Maybe it's interference from other radio devices? Maybe distance? I don't know. Regards Pete
  22. Does the aircraft not accept normal FS controls for this? One thing making things slow, and even unreliable, is using keystrokes as you are doing. The FS controls are VOR1 OBI INC and DEC. None of those lines have any conditions placed on them, so they will always be obeyed. All these lines do is mess about with flags and test them too. They don't actually interact with the simulator in any way. I don't understand your thinking here. Each line is an instruction to FSUIPC to tell it what to do when the said buttons are pressed or released. Think about it like that. Each line is being executed as it is read according to the conditions imposed on that line. There are no conditions on the first ones, the only ones actually doing anything to FS. The ones with complex conditions (why so complex?) are doing nothing but messing with flags. Do you want the button held pressed in to engage slow mode, or do you want the button to toggle between slow and fast whithout ever needing to hold it pressed in? The former is easier -- yuo just make the button being pressed a condition. You only need a flag for the latter mode. But either way, the condition obviously has to be on the action you are trying to change. Let me know which method and we can go further. Regards Pete
  23. Ah, thank you very much for the clarification! Regards Pete
  24. Just a small correction to this. You only need to delete FS assignments (or disable the controllers altogether) if you are ASSIGNING in FSUIPC. the FSUIPC calibration facilities operate on the controls resulting from assignments whether they be in FS or FSUIPC. Regards Pete
  25. It's pretty much the same as 4.761 but has a new Code Signature. Over this weekend I have to replace all of my programs with new releases as the current signature on them expires on Sunday, 12th February 2012. The new signature runs till January 2015. As in ALL major releases, and this is the first since April 2011, the Changes are listed in the History document which is installed for you, as documented in the Installation document. There is therefore no need for a separate 'changes' document for such releases. It's all in the History. 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.