-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
Help - ASE SP2 ATIS delay to RC
Pete Dowson replied to jordanal's topic in FSUIPC Support Pete Dowson Modules
I would expect the time to double -- 2 secs to, sa,y 4, because there are twice as many interactions involved. But to get to as long as 12 seconds it sounds like something in your specific setup is stopping one of the several processes involved actually running for several seconds at a time, or at least denying it processor time for such a time. What on Earth are you doing asking for ATIS on final approach? You should get that 60-80 miles out!!! Once FSUIPC has got the weather for the destination is simply keeps it updated automatically unless someone requests weather for someplace different. THAT would certainly cause a longer delay, especially if the other requester was keeping RC locked out for the timeout (12 seconds!). If you have something else running which is asking FSUIPC for weather for a different location that would most certainly explain delays no matter what ASE was doing. Otherwise, once the weather has been requested by RC for a specific place there is no difference to RC whether FSUIPC is getting it from ASE or where, because RC will just retrieve the weather FSUIPC last obtained at any time before. RC does NOT need to get the METAR weather for an airport except to answer ATIS requests (which you don't do on finals), and possibly to determine runway in use should its requests for runway data being used by AI traffic not provide that data. It will certainly NEVER EVER need to get the METAR weather for the airport you are on final approach to. All it is reading then is current wind and pressure data which is available to read directly in standard offsets which have been the same since FS98 days. Add lines to the [General] section of the INI file: LogExtras=x8000 TestOptions=x2000 Debug=Please The first line will log all the requests for weather at a station and at Lat/Lons, and the results. The initial request is logged with a line starting ### NWIR ### Weather Read Req. The second line will also log the exchanges with ASE. Regards Pete -
fatal error with 4.645
Pete Dowson replied to seiermax's topic in FSUIPC Support Pete Dowson Modules
If FSUIPC 4.60 was properly "trusted", then so would 4.645 be, and SimConnect would not go through the precarious trust checking which is the usual bug stopping a DLL from being loaded. So if this is the case your problem is likely to be completely different. Evidently missing in your message. But I don't want to see it in any case. I only want the details extracted, please. The reported Module name, the error code, and the address. So, it sounds like something different and related to one of the options in your earlier INI file. So, I'd need to see that, and also for you to conduct a process of elimination on the differences. Additionally, if it is getting as far as reading the INI file or creating a new one, it must be creating a Log file. So please show me that! That, though, again sounds like a symptom of the SimConnect bug. However, it only happens once. After SimConnect is happy with the trust it doesn't go through the same machinations again. Additionally that sort of error occurs before FSUIPC is even entered, so there's no difference for INI files and no Log produced. If it happens no more, how is it frustrating, or am I misunderstanding what you've said above? I thought you just said you had done? I can't really offer any further advice without information. Certainly whether it produces a Log is most significant, and the contents of it is so! Regards Pete -
Saitek Pro Multi Panel
Pete Dowson replied to Royal Eagle's topic in FSUIPC Support Pete Dowson Modules
Thank you. You too (at least the Happy New Year part ;-) ) Okay. Regards Pete -
This sounds very much like a fault in the drivers, not the SST software, provided by Saitek. With the Properties dialog open they are obviously following a slightly different path internally. There's really not anything I can do -- the interface allows me to read the set of axes and button settings as a single data structure. There's really no variations apart from "raw" mode as opposed to "calibrated", and that only affects axes. Has anyone tried SPAD which I believe must be reading and interpreting the USB data itself. Or doesn't that apply to those devices? FSUIPC's Lua facilities now contain USB device access via the COM library, but you'd need some sort of USB monitor program to see what the protocols were before venturing into that sort of programming. If Saitek had not reneged on their agreement, and paid the licence fee they promised and I invoiced, I would have worked on this as I did for VRI devices, but I am certainly not interested in supporting them further in the circumstances. Regards Pete
-
Phidget led64 and fsuipc
Pete Dowson replied to Tarzan737's topic in FSUIPC Support Pete Dowson Modules
I've seen mention of a program by Alan Dyer called FS2phidgets. Search for that in your browser. I think it gives you the link between the Phidgets cards and FSUIPC. Regards Pete -
FSX can't see/find FSUIPC4 Registered in win 7
Pete Dowson replied to gearup's topic in FSUIPC Support Pete Dowson Modules
No, no limit on installs or number of PC you use it on. And it doesn't even have to be registered to be present in the Add-Ons menu. If it isn't appearing there then either it isn't installed correctly, or, more usually, there's a problem with SimConnect. I need to see the Install log which you should find in the FSX Modules folder. Also look to see if there's a normal FSUIPC4.LOG file. Both are ordinary text files -- just paste them into a message here. Regards Pete -
Thank you! You too! Pete
-
If it is assigned and operating as a normal throttle in FS9 then, yes, it can be calibrated in FSUIPC. Make sure the sliders in FS9 are set for max sensitivity (full right) and zero null zone (full left). Regards Pete
-
I think once you are in such a Window the focus is then on the window, and either FSUIPC doesn't see the keystroke or the command becomes irrelevant in any case. You could possibly do it by invoking a Lua plug-in which used the ipc.keypressplus function to send the keypresses themselves, as they would be done in a separate thread and therefore hopefully not get stopped. Regards Pete
-
Assign two function for one button
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
This is precisely what the example Lua provided with FSUIPC does -- check TripleUse.lua in the Lua plugin examples in your FSUIPC Documents folder. This uses one short click, a double click, and a longer press, for three different things. Regards Pete -
There is a later version (4.645) in the Download Links subforum, but I doubt it would make any difference. No. FSUIPC4 uses DirectInput for its buttons and switch inputs and that supports 32 buttons of which FSUIPC sees all. That's DirectX8. Maybe DirectX9 or 10 or 11 supports more, but I doubt whether Saitek requires anything so recent as it would have limited their market. It sounds instead as if that switch is either interpreted internally, or only by their driver. FSX itself wouldn't see it either. FSUIPC only sees what FSX can see. There is a program called SPAD (see the Download Links subforum for a reference) which might be able to read it. It operates the USB protocol. Win7 makes no difference whatsoever. Regards Pete
-
Phidget led64 and fsuipc
Pete Dowson replied to Tarzan737's topic in FSUIPC Support Pete Dowson Modules
Nothing at all I'm afraid. I think they come with their own SDK though? If you can talk to them on a serial (COM) port or USB port, then, yes, as FSUIPC's COM library sports both. But you'd need to refer to the SDK to find the correct protocols. [LATER] See also my next message ... Regards Pete -
Yes, perfectly. There is an FSUIPC offset (x8320) which tells you the view mode of the currently selected window. if you only have one view window open, like normal, this would be usable for what you want to do. The value of the 1 byte offset (in FS9) is 1=2D cockpit, 2=virtual cockpit, 3=tower, 4=spot, 5=top down You'd have to assign the POV to the pan controls when the offset is 2 (and maybe some of the others, depending what you wanted) and the view controls when the offset is 1. Yes, you'd have to do it in the INI file, and the Advanced User's document is where to look. you need the offset conditional methods -- there's a section on that. Regards Pete
-
No, no offense I assure you. Just trying to sort out the confusion a bit. There's lots of documentation, and accessories, installed for you, automatically. PLEASE READ AT LEAST A LITTLE OF THE INSTALLATION and REGISTRATION document. Right near the top there's a list of everything you get and where to find it! i.e in the FSUIPC documents folder, in the Modules folder which it creates and installs into. It SAYS this is English. Maybe that's the problem? You don't understand English too well? :-( Pete
-
Of course not! It's copying the one throttle input to all engine throttle inputs. How can it know about any differences? It's for use by people with only one throttle lever! Pete
-
I don't actually have a website, only this Forum. Enrico Schiratti kindly hosts my main release files. His "dowson" page contains 4.60a at present. The installer always overwrites old versions with new ones, just not the other way round. Yes, of course. That's what it is for. However, you could equally just assign to the default generic throttle instead of throttle1, saving copying the same axis to all 4 inputs. If you assign to individual throttle calibration in FSUIPC, by default it provides reverse thrust for a portion of the travel -- that portion is the part you calibrate between the "minimum" set button and the two "centre" or "idle" set buttons. The documentation explains all this. If you don't want reverse controlled that way you need to check the "NRZ" ("no reverse zone") checkbox. All this is covered in the documentation. It certainly seems you are not referring to it? It would be quicker than posting here for questions answered there, honestly. The one labelled "Filter" you mean? That operates the filter. The documentation describes what it does! It's really intended for use in places where the power supply varies so much the joysticks get the jitters. It smooths jitters a bit at the cost of a bit less responsiveness. Pete
-
Yes, that's all correct. The FSUIPC assignments tab is completely independent to what you do in FSX. You must surely be looking at the wrong entry? There is really no way I know that can happen. So almost nothing has changed. Evidently something significant has. If not software it must be hardware, by a process of elimination. but narrowing down where sounds likely to be the main problem. Er ... the plot suddenly thickens. Didn't you think that was worth mentioning before, at all? Not relevant? It is starting to sound like a system error, maybe a corrupted file in Windows, possibly caused by hardware or a bad update download. Try reverting to before the last Vista update. Or, much better, try upgrading to Windows 7 -- it is MUCH better than Vista. It doesn't sound like it is worthwhile sending me anything. There is nothing logical for me to pursue at my end. Apart from trying a slower poll rate as I suggested Still pointing to timing then, as that's the only real difference. Regards Pete
-
SimMarket don't supply the program, only the Registration keys. And version 4.57 is too old and not supported. As said, the oldest supported version is 4.60a. Please update first. And I'd like to know where you recently got 4.57 from as it isn't on any official sites! On the assignments page or the Calibration page? If the IN values don't change it is something in the way your joystick driver is set or its calibration software. If it is only the OUT value, in calibration, it is your calibration in error. Please get reasonably up to date with FSUIPC before continuing. Pete
-
What IS the version number of FSUIPC4, please? Saying the "latest" doesn't help. Folks have said that and been using a year old version. The version number is easy enough to find -- it is on screen, in the Options main page, it is written in the Logs, and it is found in the Properties of the DLL itself. The latest official release and the earliest supported is 4.60a. The current true latest, available here in the download links subforum, is 4.645. I understood you were trying ot use FSUIPC for calibration, which does not necessarily involve using it for assignments too. If you use it for assignments you MUST stop FSX assigning too. Usually the easiest and most reliable way to do that is disabling the joystick completely in FS. But this is mostly done by those wishing to have different assignments for different aircraft. If you assign in FS, follow the instructions in the FSUIPC for the FS sliders -- sensitivity to max (full right) and null zone to min (full left). If you assign in FSUIPC you have to decide whether to assign "direct" to FSUIPC, avoiding FS's own controls, or to FS controls. The former is more efficient but will make the axes unworkable for some add-on aircraft. As for "sensitivity" in FSUIPC assignments, it is scanning axes at 100 times per second compared to nearer 10 for FS. It eliminates trivial changes by way of a "delta" value, settable in the axis assignments tab. The default is fine and set for 128 distinctly discernible points on a fully Windows-calibrated device. You can change it if you have a non-standard device giving higher or lower precision, but it works fine for all known commercial devices provided they are calibrated correctly in the Windows Game Controllers. If you have areas of no response in the Axes tab then you have something set wrong on your device or their drivers, because the INput value there shows the value coming from the DirectInput part of windows at 100 times per second. If you mean after calibration (the OUT value for the assigned function in the calibration tab) then you have calibrated incorrectly or not at all. Follow the numbered steps in the User Guide. Regards Pete
-
Switch between COM1 and COM2
Pete Dowson replied to liazkam's topic in FSUIPC Support Pete Dowson Modules
Ah, right. Good. NOW I understand! ;-) I'll put the "COM1/2 TX switch" control on my list. Thank you. You too! Best Regards Pete -
Assign two function for one button
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
How are you assigning mouse buttons? It isn't a facility offered by FSUIPC. Regards Pete -
Switch between COM1 and COM2
Pete Dowson replied to liazkam's topic in FSUIPC Support Pete Dowson Modules
Only COM2? If so what do you transmit on COM1? Regards Pete -
Switch between COM1 and COM2
Pete Dowson replied to liazkam's topic in FSUIPC Support Pete Dowson Modules
I wasn't saying I wouldn't add it, it just seemed odd to me too. You say it is useful, and I wondered why. I've never flown on-line. So I assume you mean that VATSIM supports transmission on COM2 as well as COM1? Is that the reason? Does it listen to both all the time? Pete -
Switch between COM1 and COM2
Pete Dowson replied to liazkam's topic in FSUIPC Support Pete Dowson Modules
That wouldn't be so relevant for transmission, surely, and reception works on both simultaneously in any case? This is why I asked about the use of a COM1/COM2 transmit swapping control. Regards Pete -
Okay. FSX uses a much slower poll rate. So by magic with no axes assigned in FSUIPC and FSX the controls still work in FSX? That makes absolutely no sense. You can't have unassigned them! Try disabling the controller in FSX instead. No. You need to narrow down where the problem lies. it is sounding more and more like hardware. Have you bothered to follow my suggestion and tried a much lower poll rate? If not, why not? I don't see any point in your posting more details but ignoring suggestions. BTW, the way the DirectInput is used provides ALL axes and buttons and POVs in one data bundle every time the joystick is polled. Since some of those axes and values (buttons for example) are not giving you any problems but the others are, it points to corruption in that data but in a specific area of that data. So, it even more suggests a corrupted driver, or bad hardware. Even a failing memory module, but if that was happening you'd expect it to be different on different loads. Seems more likely to be USB or device. To eliminate USB try different USB ports. Since USB is a serial medium, a byte missing in an exchange will get following bytes shifted. I'll check the data structure for you to see where the "bad stuff" lies, relatively ... ... Hmm. Interestingly the order is: X, Y, Z, V, R, U, S, T, P, Q, M, N and then the 32 buttons. So a USB corruption, whilst still possible, looks less likely than a hardware problem in the device. I asked, but you never said whether you'd used this device before or bought it second-hand and only just started with it. If it is 3 years old, what happened before you started getting this problem? Regards Pete