-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
FSUIPC dont read LUA file
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
FSX really hasn't got much to do with FSUIPC loading and running a Lua plug-in. All you've told me so far is that FSUIPC is not reading your Lua file. Can you tell me how you know it isn't reading it? What ways are you using to test this? Have you any log files? Is your Lua plug-in writing any log entries so you can check? I've got very little information to work on in order to help you -- only that you have an [Auto] entry, and a matching Lua file in the right place with the right name, and that you say it isn't being read. Regards Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Did you try my code on the default 738? Oh, you mean the complete software stuff to drive GF modules with GF software? Hmm. Don't want all that. It should be in the SDK, but the thing labelled SDK is not, its the FSX driver, and the SDK down the bottom of the page seems to be very very old (version 1.40). Regards Pete -
I know, and i explained it in my previous message, to which I refer you now. Your message actually contradicts itself, but if your PC is actually hanging instead of crashing to an error message, then it is most certainly a driver or hardware fault, as there is nothing in either FS or FSUIPC which has sufficient privilege to cause such a thing. I already pointed out that it is probably a video driver problem, and that tends to confirm it. Pete
-
Axis assigning failed
Pete Dowson replied to Ahmed Y. Hamad's topic in FSUIPC Support Pete Dowson Modules
Well, one obvious mistake is shown clearly here: 0=1T,3074,D,25,25,0,0 You have set a Delta of 3074, which means no change less than 3074 will have any affect. Why have you changed the default? Do you understand the Delta facility? If not, never ever mess with it! Try 0=1T,256,D,25,25,0,0 Another possible problem lies with your Throttle calibrations: Throttle1=-16256,-16256,-16256,16256 Throttle2=-16256,-16256,-16256,16256 Reverse cannot engage unless the main throttles are reduced completely to zero (idle). Those "16256" values look suspiciously like the actual minimum and maximum values supplied by the levers. If so, you cannot guarantee to reach the FS zero throttle and max throttle values because you've left no leeway. If you simply follow the numbered steps to calibration in the FSUIPC user manual, and leave a small unused zone at either extreme, you'll get better, more consistent results. BTW I see the same in your Airbus-specific settings: Throttle1=-16256,-512,512,16185/32 Throttle2=-16256,-16256,-512,16220/32 and 0=1T,1446,D,25,0,0,0 Why a Delta of 1446? Why mess with it? Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Your later reply crossed with my results summary. I'm afraid I cannot reproduce any block without a very fast independently running display update, and even then it is hard to reproduce -- I can only just about twiddle the dial fast enough, and then only by doing it back and forth like mad. Whatever is causing the block it is at some lower level than I can handle I'm afraid. I'm wondering if the specific hardware module you have is faulty. Or maybe it's down to the USB ocnnection route. This GFMCPPRO was plugged into a 2-USB hub on my monitor, not onto the PC directly nor onto one of the larger 7- or 8-port ones often used with GF stuff. To eliminate GFDev.dLL as a possible suspect you could consider programming using the HID facilities in the Lua COM library. The GFD library uses GFDev.DLL, but the COM library goes direct to the port functions themselves. Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Where is that from? My latest is 2.0.0.1 dated earlier the same month. I can't seem to find it on the GF website -- what purports to be "GFDevSDK.exe" is actually their driver "GFDevFSX.exe". I'm using 4.727. I can manage to reproduce what you get, but only if I do silly things. I'm not testing on the PMDG but the default FSX 738. This code works fine (I've only done CRS1 on the MCP Pro): function GFAPDisplaysCRS1(off,val) gfd.SetDisplay(GFAPM,GFAPU, GFAPDCRS1, string.format("%03s", val)) end local function changeCRS1(mod, id, speed) if speed > 0 then for x=1, speed, 1 do ipc.control(65663, 1) end elseif speed < 0 then for x=-1, speed, -1 do ipc.control(65662, 1) end end end function GFAPEvent(mod, id) gfd.GetValues(mod, id) x = gfd.dial(0) if x ~= 0 then changeCRS1(mod, id, x) end end function GFAPDisplaysCRS1(off,val) gfd.SetDisplay(GFMCPPRO, 0, 0, string.format("%03s", val)) end event.gfd(GFMCPPRO, 0, "GFAPEvent") event.offset(0x0C4E, "SW" , "GFAPDisplaysCRS1") That's about as simple as you can get it for the one display and dial. It would be even more fail-safe and efficient if, as I suggested, the dial processing also updated the display and set a time to make the display updater stop updating as well when the knob is turning, but even without that i couldn't get it to fail. However, the PMDG aircraft is a different matter and if that is overloading things a little too it would be worth adding that extra code -- but note, this way, you really should have a separate timer value for each dial (though i suppose it wouldn't matter as you are unlikely to turn more than one at a time, are you?). To force an overload I changed it to function GFAPDisplaysCRS1(off,val) gfd.SetDisplay(GFAPM,GFAPU, GFAPDCRS1, string.format("%03s", val)) end local function changeCRS1(mod, id, speed) if speed > 0 then for x=1, speed, 1 do ipc.control(65663, 1) end elseif speed < 0 then for x=-1, speed, -1 do ipc.control(65662, 1) end end end function GFAPEvent(mod, id) gfd.GetValues(mod, id) x = gfd.dial(0) if x ~= 0 then changeCRS1(mod, id, x) end end function GFAPDisplaysCRS1( ) gfd.SetDisplay(GFMCPPRO, 0, 0, string.format("%03s", ipc.readSW("0C4E"))) end event.gfd(GFMCPPRO, 0, "GFAPEvent") event.timer(10, "GFAPDisplaysCRS1") which is more like your original, except probably with a much faster Timer update of the display -- 100 times per second. That does exhibit the block you see. However, if i change that time to 100 instead of 10, for 10 updates per second, it still didn't fail! As far as I can tell, this block is not happening inside my code, but deeper. I couldn't really get into it very closely. When I use the USB logging tool it is MUCH harder to cause the block to occur, even with a very fast update rate. So it is definitely some overload and timing dependent. The USB transfers never stop -- the windows driver level is certainly polling continuously at 30 mSec intervals. By stopping the logging as soon as possible after noticing that the display had stopped changing I see that the USB packets were still actually changing at about the same rate as before, so now i am very suspicious that it is the device which chokes -- i.e. the firmware processing of the frames and display changes -- rather than something in the PC. However, in this case you'd expect things to be better with the PMDG aircraft than the default PROVIDED that you only update the display when the value changes, as in my first example above. Note that such a conclusion does not conflict with your earlier result, here: because in this case the device is not also dealing with the dial turning and updated data sent o the PC as a result. Anyway, I think I've taken this as far as I can. Try changing the code as shown above, so you only update the display when the relevant offset changes, and maybe also add the turning-timeout protection (but not large numbers like your 2000: A second (100) or even less (500) should suffice. Regards Pete -
Pushback & FSUIPC Offset
Pete Dowson replied to kbumbaz's topic in FSUIPC Support Pete Dowson Modules
You can move an aircraft by writing to the Latitude and Longitude (and Altitude) offsets, and turn it using the Heading offset. In FSX all those work fine, in FS9 you might have to engage pause or slew for the heading, but I'm not sure. Try without first. Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
I was just reviewing this so I could determine whast I needed to do to work out what is going on, when I noticed that part, :"updates the displays at a set interval". Why are you doing that, and what is the "set interval value"? Generally it is better to only ever update displays when they need updating. maybe an occasional refresh is in order in case something glitched, but usually it isn't needed. By updating then at a regular interval independently of them being changed i reckon you are more likely to get into a clash situation, even if such shouldn't be detrimental. The proper way to keep displays up to date is to use the "event.offset" function, to tell you when the offset from which the display is derived has changed. So, instead of: function GFAPDisplaysEvent() if ipc.elapsedtime() - TLCBM > DELAY then gfd.SetDisplay(GFAPM,GFAPU, GFAPDCRS1, string.format("%03s", ipc.readSW("0C4E"))) gfd.SetDisplay(GFAPM,GFAPU, GFAPDCRS2, string.format("%03s", ipc.readSW("0C5E"))) end end event.timer(DISPLAYPOLL, "GFAPDisplaysEvent") -- Start updating displays you ideally want a separate display function for each display and a separate event.offset for it. Like function GFAPDisplaysCRS1(off,val) gfd.SetDisplay(GFAPM,GFAPU, GFAPDCRS1, string.format("%03s", val)) end event.offset(0x0C4E, "SW" , "GFAPDisplaysCRS1") and similarly for CRS2. Of course, if you then also need the delay whilst the user's turning the knob, that must be added, but you'd then need some extra code to "catch up" after the 'safety' time. Try without first. Regards Pete -
Shouldn't that be just AFTER the "up" detente? Otherwise you are not guaranteed any value sent for "up"? Okay, that's okay. But when doing all this please watch the numbers. The "IN" number must change. THere is no point setting any values closer than 2 or 3 apart because that level of accuracy is not possible to achieve with analogue inputs with any consistency. It sounds exactly as if the ranges you are allowing are simply not wide enough for the readings to consistently tell FSUIPC which detente is being selected with a jittery or variable input. The quality of components used in these things is just not consistent enough to rely on small ranges. Try making the boundaries much closer to each other than to the detentes. "Just B4" and "Just after" is probably not providing anywhere near enough are large enough range to be seen consistently. If you like, show me the JoystickCalibration section of the FSUIPC4.INI file, the one with the Flaps detente values showing, and I'll explain using the numbers. Diagrammatically, think of your calibration like this, where * are the hardware detente positions and Up, 1-7, Dn are the calib positions: UP .*................ 1..*..1.................2.*.2...................3.*.3............... etc ............... DN..*.. whereas you need something like: ..*..........UP..1.......*...........1..2.......*..........2..3..........*.........3..4.......etc......7..DN.......*.. Do you see? This way almost every position BELONGS to one detente or the other, whereas in yours the calibrations are so narrow that through jitter, inaccuracy, timing (from polling intervals) etc, some might be missed altogether -- and also will act differently going down from going up. As I said, that can ONLY happen when you try to set a higher position with a lower "IN" number, and certainly indicates some bad inconsistencies in the axis input. Watch the numbers and just avoid setting lower ones. The poorer the quality of input, the wider the detente calibrations need to be, as do the areas reserved for "Nin" and "Max" (Up and Down). If you had high quality levers your method would work better -- the PFC throttle quadrant, for instance, only has an input range of 0-127 at most (whereas I think Saitek's are either 0-255 or0-1024), but the PFC one is much more consistent than Saitek. A wider input range range not equate to better unfortunately. If you can't do it, but manage to get all positions at least set, show me the lines from the INI file and we'll adjust them manually to give wider ranges. But you should be able to do this the way you are doing it if you think differently, as suggested above. Regards Pete
-
Have you tried Cockpitsonic support? I don't have such a device here so I don't know what they do. If you want to see what they do in FSUIPC just enable IPC logging. But be sure you don't have any other FSUIPC-using applications, as else the Log will be impossible to analyse for that one program. Regards Pete
-
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Hmm. That's weird. It can't actually be the event call, because that is still calling the function because, as you say, the VC updates correctly. So somehow the call made to update the GF display woorks when called one way but not another, seemingly identical way. The only difference is that, in the former code example, where there's no event and, in fact, no knob turning, the display updates, whilst when the GF device is providing continual inputs and dealing with outputs at the same time, it, or the USB driver or GFDev, kludges. Seems to be some sort of mess occurring because it needs to do lots of inputs and outputs at the same time. I won't have time for a few days, but if i can reproduce it I'll try using a USB monitor on it so I can see what happens. If it is at that sort of level I'm not sure there is an answer, really, except possibly report it as a suspected GFDev bug and hope it gets fixed. BTW could you tell me the exact version number of the GFDev you are using? Regards Pete -
RadarContact Rwy assignment
Pete Dowson replied to chris198's topic in FSUIPC Support Pete Dowson Modules
Is there? with FSX or FS9? In FSX we dealt with that last year some time. FSUIPC4 reads weather on behalf of programs like RC, when they ask for it, direct from ASE if it is running. You need at least ASE SP2 (SP3 is just out). You would be better off asking about RC in the RC Support Forum. Pete -
You need to calibrate more carefully. The gaps are must less important than the widths of each position, because the increments may often skip smaller settings. don't line up with what? you have hardware detentes? It only allows the number of positions supported by the currently loaded aircraft. You need no more. Flaps up is detente 0, which is minimum, and full flpas is maximum. set those first BEFORE entering flap detente setting mode. The "beep" only occurs when you try to set a value out of order. They must always increase, left to right, detente to detente. It's nothing to do with 'range'. Pete
-
How reading the correct Compass Value - VB?
Pete Dowson replied to friedrich's topic in FSUIPC Support Pete Dowson Modules
If you want the heading, as showing on the AI, then just compute it from the True Heading and the Mag Var. But note that of the values you list above only 02CC is actually a Dounble. The others are all integers of 32 or 16 bits (4 or 2 bytes). Please re-read the details in the offsets list. You need always to take care to read and interpret data in the correct way. Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Right -- and the offsets are uopdating okay. So it's got to be something in GFDev or deeper in GF's drivers. Maybe you have to limit the real time display calls so you don't send one more often than n mSecs. It'll still catch up at the end. Otherwise you'd have to limit the pace at which you read the dial. It might be over the top to use "speed". Try just doing one change per click regardless of speed. Pete -
PFC Jetliner and PMDG 737NGX
Pete Dowson replied to bellah1w's topic in FSUIPC Support Pete Dowson Modules
So you have had the PFC driver set for that console before, not the Cirrus which you say is selected now? Can you check the PFCFSX.INI file inthe modules folder for being marked "read only"? Is it getting updated when you change the console selection? In the consoles tab, you can actually have both Cirrus and Jetliner console selections both enabled -- the driver then accepts codes which emanate from both. If they are both still checked then all that is happening is that it displays the Cirrus one first because it happens to be first. If you only want the 737NG selection then you uncheck the Cirrus one as well as checking the 737NG one. Are you checking another when unchecking that? At least one must be checked or it will automatically re-select the most suitable. If you want no assignments then enable a blank User config. The operating system you use makes no difference at all to this program. Regards Pete -
PFC Jetliner and PMDG 737NGX
Pete Dowson replied to bellah1w's topic in FSUIPC Support Pete Dowson Modules
It sounds like you haven't actually ticked that setting as being usable, or you have the cirrus console selected elsewhere. Have you only just acquired the JetLiner? Else, how have you managed before -- and what does this have to do with the PMDG addon? Which "quadrant enabled" box? I'm lost. I need to know a bit more. Are you only just starting out with PFC equipmernt? If so, i suspect you need to sort things out BEFORE trying a complex add-on like the PMDG aircraft. If not, can you tell me wehat you've been using before? The PFC driver is designed to be automatic as much as possible, but it sounds as if you have prior selections overriding all else. Regards Pete -
How reading the correct Compass Value - VB?
Pete Dowson replied to friedrich's topic in FSUIPC Support Pete Dowson Modules
You can't. That compass floats, and only reads accurately when flying straight and level. That's one reason why other aids were invented. Regards Pete -
Go Flight MCP PRO Displays for PMDG NGX
Pete Dowson replied to Steve38's topic in FSUIPC Support Pete Dowson Modules
Without examining your code (sorry, not much time at the moment), i would guess that you are updating the value in FS separately from updating the display. I've found in numerous hardware implementations, starting with EPIC-driven radio and A/P stacks made by FlightLink in the 90's , through all the PFC devices and more recently VRI and GoFlight, that this is always the sort problem that results. What I find works best is this: 1. Yes, turning a dial updates FS, but also updates the display directly, not via FS, AND sets a time value = "time last changed by me" (say "TLCBM") 2. FS changing values are allowed to update the display but only after an elapsed time of X msecs after time "TLCBM". The elapsed time is just a value above which you are pretty sure that the user has stopped turning the dial. This overcomes the latency which is the cause of the build-up and apparent hang. Update dials locally when you know the value, only update from FS when the user isn't twiddling. Try it and see. Regards Pete -
There is no reason why anything written to interface to FSUIPC is "incompatible" with any later version than the one it was written for. Great care is taken to ensure continuing compatibility for everything. Why says it isn't compatible? What is your problem? I sincerely hope not, and I'd delete one if posted. Reverting to old unsupported versions should NEVER be warranted. Let's sort your problem out, not try for wrong and probably non-working solutions! Pete
-
Unexpected Value from Gyro Heading
Pete Dowson replied to Skittles's topic in FSUIPC Support Pete Dowson Modules
The latitude and longitudes are actually 64 bit integers, so a 64-bit "Long" suits them perfectly. I think the Currency examples date to the version of VB where the Long was 32 bits -- or maybe it depends whether you are using a 64-bit or 32-bit compiler. Ah. "Double" will be the 64-bit floating point -- in C/C++ it is called "double" too, just no capital. You really need any number which contains fractions as floating point, because integers cannot contain them. No, that is still completely wrong. no amount of messing with that will get it right! 64-bit floating point numbers are NOT integers x 10000. They have a sign bit, an exponent field and a mantissa field. Any other way of interpreting them will always be wrong! Now you've found the VB 64-bit floating point variable name, why not simply declare the variable as double? Then you'll get it in degrees with no calculation needed whatsoever! I'm sure you can look these things up in some VB reference somewhere. If you program in VB you should surely at least become wise about the different number formats it supports? The Intel and AMD processors support 32-bit and 64-bit processors in their mult-div sections. I'm pretty sure that all languages compiling for such processors support those types. In C/C++ they are "float" and "double" respectively. Pete -
FSUIPC dont read LUA file
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
So, your [Auto] line should read 1=Lua mapmad then? You don't need to "start" an FSUIPC log. One is produced every time you run FS with FSUIPC installed! Please don't go into the Logging tab and press one of its buttons -- those are only for separating logs into sessions for diagnosis of complex situations demanding lots of data logging. BTW I also always need the VERSION number of the FSUIPC you are using. If it isn't at least 3.99 or 4.70 please update first. Also note that there are much later versions of both in the Download Links subforum. Regards Pete -
FSUIPC dont read LUA file
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
Is there a filed named "filename.lua" in the FS modules folder? Does the FSUIPC log file show an error message, perhaps? Pete -
Unexpected Value from Gyro Heading
Pete Dowson replied to Skittles's topic in FSUIPC Support Pete Dowson Modules
I don't think "Long" is a 64-bit floating point value, but a 64-bit integer instead. I just googled it and came up with this: Use the Long data type to contain integer numbers that are too large to fit in the Integer data type. which certainly seems to confirm it. Don't you have any VB references you can use to look up data types you don't know? I'm not surprised since integer types cannot hold fractions at all. You are misinterpreting it altogether. Surely you have some sort of help or documentation for VB? Otherwise how else do you manage to program it? Regards Pete -
FSUIPC does not know anything about ALT TAB and wouldn't be able to provide such a message. It sounds like the ALT TAB is causing FS to crash -- one typical symptom I seem to remember of video driver problems -- and it is getting automatically restarted whilst some of its threads, like FSUIPC, are still running and in memory. When FS crashes it sometimes loses al of its Windows but it still actually lurking in the background. The FSUIPC still left in memory cannot coexist with one being reloaded. You have to use the Windows Task Manager to forcibly terminate the crashed FS. If you are trying to use ALT TAB whilst FS is running in full screen mode, I think this is certainly the problem. FS is quite precarious in that mode. Try running it in maximised Windows mode if you have need to occasionally switch to other applications. Regards Pete