Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Er ... that makes no sense. "Repeating" at intervals of 3 seconds is just lke not having repeat enabled and instead operating the button every three seconds. Either you didn't understand me correctly, or you don't know how Saitek functions? Yes, I know, I have a couple of Saitek quadrants lying around here someplace. Yes, but holding it to make it repeat is NOT the same as holding it and later releasing it. If the aircraft code really wants it held and later released it must be looking for a "button release" indication. How is it getting that? Or are you really saying that it MUST be the F2 key and the aircraft is reading the keyboard, not processing the throttle decrement controls? No, I think it is wanting repeats, and you can certainly repeat it manually, by simply causing it to be pressed more than once. I'm sure that isn't a difficult thing to do at intervals like 3 seconds? So you do not land it yourself, you use autoland? Why would you not repeat it? I don't understand your problem at all, evidently. Whatever FSUIPC can do for you, you can do for yourself. A button is a button no matter where it is mounted. No, it is exactly for unique and obscure and strange needs that I added the Lua plug-in facilities for, to avoid further overcomplicating the main FSUIPC code. It would need to be a very generally used and sensible option, which so far this does not strike me as, to warrant being added as a built-in facility. Sorry. Regards Pete
  2. Well, how strange. The PMDG code must be using that otherwise non-applicable control for something internal! I'll check that here. But, I must ask, what has happened recently to make this happen? It cannot be the release of FSUIPC 4.80. maybe it is something changed by the SP1b update? Thanks for identifying this for other users, but thankfully it is likely not to be a common occurrence in most user's INI files. Of course if you want a CowlFlaps control you'd tend to have it only operating for aircraft which have such things. [LATER] Okay, by enabling Axis Event logging in FSUIPC4, I see that, in VC mode only, the NGX uses the COWLFLAPS1_SET control when the mouse is used on the dials. However, here the mere calibration setting for that axis in FSUIPC doesn't stop it working. Maybe in your case it was actually also assigned, though? There's not a lot i can do about this, as the Cowl Flaps 1 axis is a proper FSX axis for that use. I will simply have to remember this oddit of the NGX in case others ask. Regards Pete
  3. Hmm. I don't understand how calibration can affect mouse clicking. With Axis assignments, or still without? All those calibration entries are with default calibration, BTW. You've not actually set max/min/centre points at all. Okay. Let me know. It'll be tomorrow now before I can get to this again. Regards Pete
  4. How weird! You don't want an automatic repeat action for something like that. Just uncheck the repeat, and pull the throttle back against the switch 2-3 seconds later. Surely with such a repeat rate that isn't a hardship? i would think it more inconvenient to have to hold it back all the time! Simulating the lowering of the reverser shroud, presumably. Still, it shouldn't go wrong just because there are extra controls in the meanwhile. No, the button repeat rate is universal, and in any case you couldn't specify a repeat rate of 0.33 presses per second, it only allows whole numbers! I think you should simply uncheck repeat. it makes no sense in that case. Pete
  5. The "F2" key is just assigned in FSX to "THROTTLE DECR". It's the same as "THROTTLE1_DECR and THROTTLE2_DECR" ertc but operates on all selected engines instead of the specified one. I don't really understand what you mean by "activate" it. Nor, actually, do i understand why having to use manual throttle control means you need long runways. (Most pilots do takeoffs and landings manually in any case, it's the fun part of flying airliners! ;-) ) Regards Pete
  6. Never heard of a problem like that! One whole second? How weird! You'd need to use a Lua plug-in unless you wanted such a slow repeat rate for all buttons. in the latter case you'd only need to change the parameter in the [buttons] section of the INI file , Pete
  7. Okay. thank you. There is nothing in the settings themselves that could have any affect on this. The main difference is of course that the new one isn't loading "LINDA"., and doesn't have a load of Axis assignments, Calibrations and Keys, along with a load of Profiles. There's nothing else there which is different. Certainly nothing I can test here. So it's now neexessary for you to start with the original INI and remove things until you find which is doing it. Start by not running Linda, as that's the only major part for which I've no idea what it is doing. You can't really mix and match the two files. By starting afresh you've lost all the connections between the macro and Lua file numbers and the assignments to keys 9and Buttons, though you have almost none of those assigned here). Regards Pete
  8. Okay, that gives me "COM8" which I can assign, and view in my port monitor, but nothing comes out on it. What worries me is that "Incoming (device initiates the connection)". In this case it is the PC initiating things. So, i tried the other, the "Outgoing" selection, and had to choose my HP Inkjet printer -- my only other bluetooth device, a mobile earpiece, was refused on the grounds that it had no serial service. Then Windows asked for the code to pair the device -- I guessed 0000 as I had no idea. That worked, though. When I loaded FSX and enabled its GPSout (same as yours but built into FSUIPC4), the printer actually printed the NMEA sentences I'd selected! RMA, RMC and GGA. BUT it only did it twice (6 lines), after first connection. Thereafter nothing ... even after a re-load of FSX. And neither monitor, Portmon or the AGGSoft one, shows anything. I think there's a lot more to it than simply stuffing data out, as is the case with normal serial connections. Regards Pete
  9. Found one, plugged it in -- it's a USB device, but i can't see it as a COM port in anything, not in Device manager, or PortMon or my Advanced Serial Port Monitor. I guess bluetooth drivers are not compatible with those types, at least not with this adapter. I've no idea how Pc programs link to Bluetooth devices. Regards Pete
  10. No. It should most certainly not be necessary. Folks have a lot invested in their assignments in the INI file. I need more information as to why this can make any difference, please. I'd like to know exactly why, though. I hope one of you has the old copy for me to look at? Or both old and new to compare? Regards Pete
  11. Interesting. Have you tried using that name in GPSout instead of COM7? I don't know, sorry. It may be that the Bluetooth software needs some different handling comprared to COM and USB ports -- both of the latter certainly respond correctly to normal serial input output commands through Windows. Not "tons", just the NMEA lines at the interval requested. I'm not sure how you can proceed from here. I don't have any PCs with Bluetooth on the motherboard -- I think it is quite rare, probably because of the metal shilelding problems without an external aerial. But I'll see if I can find a bluetooth USB device (I did have one someplace ...) and try that here. [LATER] Sorry, i saw that after! ;-) Regards Pete
  12. Oh dear. look: it's actually better than an "example", it is the correct format and it tells you to add it as it is, i.e. [GPSout] Port=COMn Speed=n [/CODE] All you needed to do was copy it and just change the values to suit your setup! Surely that's explanation enough, and better than a specific example which might not be at all applicable and need changing in any case? It's certainly not scuppered anyone before to my knowledge! Pete
  13. Sorry, I've no idea what difference PMDG makes between normal autothrottle and its control of throttle for TOGA. The latter should simply push the throttles to the set N1% as far as I know, just like any other autothrottle change. So I'll assume you mean A/T cuts out anyway. The only way FSUIPC can provide a reverse zone on a throttle axis is by using the THROTTLEn_SET controls -- because there are no other controls with such a facility. If the PMDG cannot operate its autothrottle correctly when such FS controls are used then the only likely way is to revert to the normal AXIS controls with no reverse zone, and use separate reversers. However, you should be able to get away with simply parking your throttle levers in a well-defined stable zone (eg a good well defined idle zone or a max thrust 'dead zone' at the top end) when engaging A/T. FSUIPC does not send anything from the axes to FS when the value isn't changing. Any jitter however will result in values being sent. Regards Pete
  14. Ah, so it is only something in the very latest update. I was concerned because my last two flights have suffered Out Of Memory (OOM) errors on approaching London. This is with a standard test flight I've flown many many times, never before with an OOM. In fact I've never before experienced an OOM with Windows 7-64. I am trying to track it down this weekend, by a process of elimination, and your experience does suggest EFB as being a possible canddate. However, I was using 1.3.1- SP5 when I get the first OOM and 1.3.2 when I got the second. Regards Pete
  15. But unless you selected one of the two (three in 4.801) mouse options in the Miscellaneous tab in FSUIPC options, FSUIPC doesn't touch the mouse. There must be something else happening, some other program reliant on FSUIPc and inactive when FSUIPC isn't running. I just loaded up the PMDG 737NGX (recently updated to SP1b level) and used the mouse fine on the MCP -- keft and right buttons operate the dial decrement and increment actions etc. In fact it works with all three FSUIPC mouse options enabled or without, so there really should be no problems. I think perhaps you need to do a more thorough process of elimination on your system. I really don't know how i can help -- as I say, the involvement of FSUIPC in mouse actions is minimal, even with the few mouse options it includes enabled, and zero without. By all means, enable event logging in FSUIPC and see what the mouse maybe doing in the NGX. I think the aircraft uses a lot of FS control numbers in high ranges, unrecognised by FSUIPC ad logged as "unknown". Have you only recently started using the NGX, or maybe it's recent update? Note: apart from the change to add Mouse Move mode, in 4.801, there was no change in mouse facilities in 4.80 and not for a long time before. The Mouse look option has been in for about six months or so, and the mousewheel trim has been in since as long ago as version 4.26. Regards Pete
  16. Why do you say that? You haven't even enabled the GPSout function to start with (can't you see that, above?), and you've left it sending to serial port COM1. Please go to the GPSout settings in FSUIPC Options in FSX, and read the FSUIPC4 User Guide chapter on how to set it up! What's "Port 1"? Serial ports have names, like "COM1"! Just as documented!!! Seems you are not actually referring to any documentation before you start? BTW WidevieW is a totally different program by a different author! :-( Pete
  17. What's that 'Bthmodem0'? It sounds like you aren't even managing to specify the correct port name. I thought you said it was COM7? Maybe the Bluetooth software in Windows simply doesn't support its use as a normal serial port? Sorry, I'm lost. All GPSout does is open the serial port, with the name you provide, and chuck the stuff out. It has no feedback to tell it whether it gets anywhere. I've never heard of PortMon not seeing it. Try it on COM1, see what it says. Pete
  18. Ouch! I just updated from 1.3.1-5 to 1.3.2. Does that mean I'll start to get problems, I wonder? When you've narrowed it does please do report it to Aivlasoft. Regards Pete
  19. What was your previous version of FSUIPC? There's been no change which will affect that. Unless you've selected options such as mouse macro making mode, FSUIPC doesn't touch the mouse. How are you 'disabling' FSUIPC? Pete
  20. The ones which are loading automatically are doing so because of entries in the DLL.XML and EXE.XML files, located in the same folder as your FSX.CFG file. You can disable them individually be changing a "disabled" parameter from FALSE to TRUE. For example, here is one section in the DLL.XML file: <Launch.Addon> <Name>Addon Manager</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>bglmanx.dll</Path> </Launch.Addon>[/CODE] If that <Disabled>False</Disabled> line read <Disabled>True</Disabled> instead, it wouldn't load. Save copies of those files first in case you make a mistake. Regards Pete
  21. From your recent results, partially received via email, it does more and more look like some sort of memory corruption. The problems with memory corruption are really completely unpredictable. All I wanted that full FSUIPC log for was to see if it was still receiving messages from SimConnect – because the previous log most certainly showed it was still receiving them, and logging them, from the aircraft. If it stops receiving messages from SimConnect it should log the fact and reconnect, which it didn’t, so I wanted to see why. But possibly it is receiving messages from SimConnect but SimConnect is not receiving them from FSUIPC – that could explain why EFB still gets the user aircraft position, but not AI aircraft updates. It would be notified of existing AI aircraft data at the time SimConnect stopped working correctly, and it would be notified of additions and removals, but its requests for data on additions wouldn’t reach SimConnect. This is the only explanation I can come up with – I just needed the FSUIPC log to verify. If you can’t send it all just send the last part, whatever size you can manage. It will show what was happening in the last minutes. I am taking a look to see if there’s any way I can detect whether SimConnect receives my requests, and log those failures too, and maybe try reconnecting. I’ll let you know – but it would be a waste of effort if the log shows not receipts. I’d have to look elsewhere. Either way it looks like there’s no solution except to avoid the combination of add-ons which is resulting in the corruption. Maybe you could try disabling some of those additional SimConnect users I listed. You could also see if Prepar3D suffers from the same problem, but you’d need to subscribe to it. Regards Pete
  22. I assume you set the receiving program to read at 9600 as well? Most true GPS's default to the NMEA standard 4800. I use the advanced serial port monitor by AggSoft (see their website). You can use it free for atrial period. Otherwise you might try "PortMon" which is free. http://technet.microsoft.com/en-us/sysinternals/bb896644 Pete
  23. If you've installed a PMDG aircraft, Squawkbox and IVAP, their modules are always loaded. They are running all the time whether you decide to use them or not. They are not like Gauges, loaded with the aircraft. They probably don't do a lot whilst their targets aren't enabled, but they are interfacing to Simconnect. That's all I meant. You did when you did the last test, as IPC writes were logged, as I requested. In the [General] section, anywhere in there, but no where else. Regards Pete
  24. 3.988f? I don't think I released one of those. 3.988 was May 2010 and 3.989 replaced it in June 2010. both are very old especially with respect to Lua developments. Please update. The oldest supported release now is 3.999. I've tested your plug-in here with that and FS9.1 and it works everytime -- I even repeated it over 20 times, fast and slow. No sign of any problem. What mouse software? If you have the facility you want, why are you changing it? 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.