-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
Okay. In that case it's certainly a GFConfg problem or the device itself. What FSUIPC is doing there is simply closing and re-opening its links to GFDev so that it can discover any changes. I think it's time now for you to contact GoFlight support. Regards Pete -
Got them. Thanks. Wow! That's some complicated syatem the LINDA program creates! I was hoping for something i could maybe try here, but I wouldn't know where to begin, and in any case it may depend upon having the same hardware connected as you. I have, however, made yet another test version of FSUIPC. Please download this: FSUIPC4811c Edit the FSUIPC4.INI file, changing the "LogExtras=" line you already have to: LogExtras=x200040 Then reproduce the crash once again. The log file might be quite big -- this traces the execution of the Lua plug-ins. I'm hoping to determine which call causes the problem. If it is a large file, ZIP it as send it as before please. Have you been in touch with LINDA support at all? Regards Pete
-
Eyes, not ears. Please refer to the Lua package installed into your FSUIPC Documents folder. The COM library supplied in the Lua facilities includes facilities for handling HID devices, which might be useful for you if your X-keys looks like one of those. You can check by using HidScanner, available in the Lua thread in the Download Links subforum above. Seems that it does not have the requisite firmware, or it does but it needs the joystick emulating interface enabling somehow. Regards Pete
-
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
And thee's nothing in the INI file that could lead me to nbe suspicious about anything FSUIPC was doing, either. It must be some sort of clash withing the GFConfig program caused by the re-initialisation of Gf devices (rescanning) done via GFDev when you enter the FSUIPC options -- I think you did say that was when the problem occurred, was it not? Ah, yes, you said right at the start "while trying to set a function to Button 0 on the GF46, on my system it crashes FSUIPC every time", though of course there was never any sign of an FSUIPC crash -- what gave you the impression that FSUIPC crashed? If FSUIPC crashes so does FS. I did earlier ask for more details of the circumstances ("Also, a more precise description of the steps you are taking which leads to this 'crash'."), but it seems that got overtaken by the other findings. Rgards Pete -
Newbie to FSUIPC for FSX
Pete Dowson replied to toconce's topic in FSUIPC Support Pete Dowson Modules
Yes, I know the feeling. I'm 69, and in my case it is made worse by my Retinitis Pigmentosa which caused my severe tunnel vision. I don't find anything unless I look stright at it! Okay. That's good. so you ran the Installer from inside the ZIP, following the instructions given in the Installation and Registration guide, which would also have been inside that Zip. Generally there isn't a "changes" document there as well, but I made an exception for 4.81 because there was too little difference from 4.80 to make a revision to the installed manuals. One of the first parts of the Installation document is a list of the files the Installer actually installls for you, and where they are placed. Maybe you skipped over that section? In that case you most certainly did NOT dowmload the proper Installation package from the Schiratti site as you stated, or if you did you NEVER ran the Installer. Otherwise there would certainly be an FSUIPC Documents subforlder AND an Installer log file! There was no Profiles facility in version 4.11 If you ran it it would have, or complained of a failure to find FSX. All the evidence points to it never having been run. You do not need to delete anything, the Installer will cope. If, however, your INI file is in a mess you may wish to delete that so you can start again with the Profiles. I think you'll find it only suggests deleting the INI file, and only if your previous version is very old -- which in fact yours is. And that's only to avoid conusion with your settings. There is never ever ANY need to explicitly delete anything else. FSUIPC's Installer will always replace an older version and never a later one. Regards Pete -
The airline codes are added in the Airport Facilities Data files (AFD's, sometimes known as AFCADs), normally by the add-on scenery designer -- though you can edit them yourself using one of the scenery design programs or AFD editors available. None of the default airports have any codes that I know of, and certainly not for real airlines as FS only comes with fictitious airlines by default. Regards Pete
-
New version causes SB4 tranponder to stay on
Pete Dowson replied to drayton_k's topic in FSUIPC Support Pete Dowson Modules
That parameter isn't needed in FS9 because there is no SimConnect in FS9 and no possible conflict between SB's client data (which can't exist) and other settings. There never was any conflict in FSUIPC3 because it doesn't touch the transponder unless programmed to do so by an assignment. Other programs and add-ons can of course chage SB3's offsets, though, through FSUIPC. But not FSUIPC itself. Regards Pete -
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
And you are also sure it isn't assigned in FSUIPC? Best show me your FSUIPC INI file. Pete -
Newbie to FSUIPC for FSX
Pete Dowson replied to toconce's topic in FSUIPC Support Pete Dowson Modules
Sounds like you are out of date in any case. Profiles have been defaulted on in the last few rleases. make sure you are using a supported version - 3.999 or later for FS9, 4.81 or later for FSX. Unless you are using an extremely old version, before Profiles was even added, the UseProfiles parameter is ALWAYS there. Either you now have two, and the other is being seen instead, or your FSUIPC is well out of date and unsupported! No user manual was EVER installed in the modules folder. Pleease READ the Installation document which is provided in the same ZIP as the FSUIPC Installer. It tells you exactly where all the additional files are installed for you! That's why there is an Installation document, to tell you such things! If you did not run the Installer, you have the wrong FSUIPC entirely. Always start by Installing. Only apply interim updates directly! Pete -
Remove the unnecessary leading zero in the lines: It just wants straight sequence numbers: [Macros] 1=Seiten 1.1=K83,16 1.2=K78,8 1.3=K39,8 1.4=K40,8 1.5=K40,8 1.6=K13,8 1.7=K83,16 1.8=K78,8 1.9=K39,8 1.10=K40,8 1.11=K40,8 1.12=K40,8 1.13=K13,8 I might vchange it is a future update -- no one's done that before! Pete
-
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
There must surely be a wrong signal of something coming from the hardware, though, for a specific button to cause a problem. I mean buttons are buttons are buttons. It should make no difference which or where. It might be worth contacting GF support about it. I assume you already checked that GFConfig wasn't set to use that button for something? Pete -
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
Yes, the second log file also certainly doesn't show anything going wrong in FSUIPC. Are you using the latest GoFlight software? You probably need to use a compatible version of GFDev.DLL. The latest I've seen is available in the Download Links subforum here, but you need to go to the GoFlight website for the full suite and installer. Regards Pete -
Data won't get jumbled using TCP protocol, only UDP -- Windows explorer uses UDP for file transfers. What is this "CTD & ATC.DLL" error? I'm not aware of any such error in FSX. Use the same IP address in the WideClient INI. Add both "ServerIPAddr= ..." and "Protocol=TCP" parameters to the [Config] section of the WideClient.INI file. Regards Pete
-
GF46 Button 0 crashes FSUIPC
Pete Dowson replied to spen25's topic in FSUIPC Support Pete Dowson Modules
The log shows normal FSUIPC termination at the end of the FS session. How exactly are you detecting that FSUIPC is "crashing"? There's no crash in this instance. FSUIPC doesn't differentiate between different buttons on a device, except by number. Are you sure it isn't a Goflight driver which is crashing? Are you running both Goflight software and FSUIPC programming on these devices? I'm afraid I need more information to help fursther -- in particular a log which actually shows a crasah rather than a normal run, and perhaps with Button logging turned on. Also, a more precise description of the steps you are taking which leads to this 'crash'. But first, please update to the current version of FSUIPC: 4.81, or better 4.811 (see the Download Links subforum). That most certainly sounds more like the GoFlight driver crashing. Regards Pete -
FS and therefore FSUIPC only supports Gear Up and Gear down. There's an example of exactly how to do that with a lever in the Axis assignments section of the User Guide. I believe there are special control numbers assigned in the PMDG NGX to get the three positions instead of two. These are documented in the PMDG NGX SDK which was installed for you with their recent update. Let me see ... yes, there are these: #define EVT_GEAR_LEVER (THIRD_PARTY_EVENT_ID_MIN + 455) #define EVT_GEAR_LEVER_OFF (THIRD_PARTY_EVENT_ID_MIN + 4551) #define EVT_GEAR_LEVER_UNLOCK (THIRD_PARTY_EVENT_ID_MIN + 4552) The "THIRD_PARTY_EVENT_ID_MIN" value is defined as #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 which means their "OFF" control is 69632 + 4551 = 74183. You can send such controls via the Lua "ipc.control" function, so you'd need to make a little plug in and assign to that in the axis assignments, right-hand side -- as per the example for Gear Levers in the User Guide. An alternative to Lua plug-ins you might find mouse macros work on the gear lever. Judging from another post recently, I think they did on the FS9 PMDG 747. Examples of both techniques are found in the User Contributions subforum. Regards Pete
-
Ah, but it has trapped at least two crashes, which should help: 126299 ***ERROR C0000005 at 7300A1C3 AxesDeInit ID, Step= [0x00000001, 0x00000002]) 126299 *** Access violation trying to write address 5456F646 126299 *** EAX 09530D70 EBX 09530D9C ECX 5456F646 EDX 00000002 EDI 00080590 ESI 31342D30 126299 *** EIP 7300A1C3 EBP 000CDB64 ESP 000CDB5C 126299 #### Initialising Dlrectinput Axis Scanning ... 126314 joyGetDevCaps for device 0 returned error 165 [000000A5] 126314 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_16C0&PID_27D3\Calibration\0" 126314 Found correct joystick Id 1 126314 ... and a "GUID" value 126314 ***ERROR C0000005 at 7300A02C AxesInit ID, Step= [0x00000001, 0x00000003]) 126314 *** Access violation trying to write address 5456F652 126314 *** EAX 5456F646 EBX 00000000 ECX 005E0E68 EDX 00538004 EDI 00000004 ESI 00000006 126314 *** EIP 7300A02C EBP 000CDF28 ESP 000CDF28 126314 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0763\Calibration\0" 126314 Found correct joystick Id 2 126314 ... and a "GUID" value 126314 Acquire failed, return = 00000001 I'm not sure I'm logging enough data yet, though. i'll check into this now. Oddly, both of those crashes are on device 1=G-Throttles, not on a Bodnar board. Yes, but it shouldn't be able to cause FS to crash. I need to find out why. Is there any chance of getting the LINDA authors to help narrow it down. I could do with knowing what it did last, before each crash. The LINDA entries in the Log seem to finish before the crash. Maybe there's extra they can enable. If LINDA is merely causing some Lua plug-ins to run, could you perhaps wait till the crash occurs, then ZIP up the Lua files from the Modules folder and send them to me at petedowson@btconnect.com ? Regards Pete
-
Yes, of course. Delete the [Profile ...] section for it and any other [....] section with the same aircraft name in it. It will automatically load according to the aircraft name. If you load an aircraft with a name which doesn't include, somewhere in it, and of those names listed in the [Profile...] section, then that profile won't be loaded for that aircraft. It is all fully automatic based on name recognition. If you listed just "737" it would match all 737's (unless of course a 737-800 was entitled "738" instead, as can happen)., Similarly, if you listed "iFly" it would match all aircraft with "iFly" somewhere in their name. And so on. The list of names can be as long as you like, but each must have successive line numbers. For efficiency, FSUIPC stops looking at the list with the first missing line number. When you manually select a Profile for a newly-loaded aircraft, FSUIPC adds the full name to that Profile list. It cannot abbreviate it for you, it doesn't know how. So you can either add each and every different aircraft to one Profile or another as you first load them, or edit the list with your own abbreviations to match them all. Please make sure you are using the latest version of FSUIPC ofr this -- there were some little problems with the mechansim earlier. The latest ones are 3.999g and 4.811. See the Download Links subforum. Regards Pete
-
I don't think power is the relevant factor in a program's ability to "see" switches. FS and FSUIPC can "see" switches and buttons which are on devices which look like "joysticks" to Windows, because both rely on DirectInput to read those switches and buttons. You CAN program Lua plug-ins to read switches on other HID (Human Interface Devices), but this does requires some extra effort and understanding of the devices concerned. The built-in provisions in both FS and FSUIPC rely on standard Windows joystick recognition. I've never heard of an "X-keys matrix board", but from what you said above I must assume that it does come with its own driver software which makes it look visible to Windows (and therefore FS and FSUIPC) as a joystick or keyboard device. Is that right? You didn't really explain that sufficiently for me to understand. This is the case with many add-on devices -- Saitek panels and GoFlight panels, for instance. GoFlight supplied "GFDev.DLL" as the driver supporting their devices and FSUIPC takes advantage of that, but without that they too would need Lua plug-in handling. [LATER] I googled "X-keys matrix board" and found that it, in general is not specifically a joystick device. BUT it did say this: Pi3 Firmware Our new Pi3 firmware offers all the features of our Classic X-keys Matrix Board plus a host of new features including: Hardware Mode programming in Windows 7 and beyond Joystick (game controller) emulation Keyboard and mouse emulation I've highlighted the part relevant here. Maybe your board is out of date and doesn't have the right firmware for joystick emulation? Or perhaps it needs enabling? Does the Windows Game Controllers applet in Control Panel see it? Regards Pete
-
I think you must be a little confused. There's really nothing about such setting up in any manual of mine -- only the important provision of EITHER making sure both PCs were in the same Workgroup, OR, if not, then instead providing the Client program with the name of the Server so it can find it, plus the protocol to be used. WideFS works "out of the box" on a working network with those provisos only. There's nothing else to know really, and certainly I'm not able to teach anything about setting up networks, a subject I know very little of myself. WideFS has no way of distinguishing the route Windows chooses for its interconnections. Not by itself in any case. Having both routes enabled is most unusual in any case, and can result in data getting jumbled as it has two routes it can follow at different speeds! Is there a bit about that? If so it isn't by me -- must be in the section where I collected advice from others, such as in messages in this Forum. Can you point out the FIX, in case I can understand it any better? It should be possible, but I have no idea how you make Windows choose one over the other. WideClient simply asks Windows to connect it to the Server. One thought is that perhaps the wired connection in the Server has a different IP address to the wireless connection. I think that this must be the case unless you explicitly "bridged" them to the same IP address. Didn't you have to specify an IP address for Simconnect? If so, try setting the same IP address in the Client's INI file, plus "Protocol=TCP". I know PFE wont use Simconnect but for some reason I couldnt get AS2012 to use WideClient hence the simconnect option.[/CODE] Active Sky uses WidFS for FS9 and SimConnect for FSX. With ASE you could fool it into using WideFS by telling it that it was connecting to FS9. I don't think AS 2012 supports FS9, does it? Regards Pete
-
Interesting that you got LINDA logging this time, too. The code I put in to catch the crash isn't being triggered, so the crash is evidently NOT occurring when FSUIPC itself is rescanning and initialising the DirectInput devices. I'll have to pt more traps in. If those don't work, I can only think it is somehow related to what LINDA is doing. That's running in its own thread, separately. I've no idea how or why that would be crashing DINPUT.DLL. Did you try with each of your 5 devices unplugged, one at a time, to see if it was definitely associated with just one? If so, what was the result? If not, could you try it please? Please try with this version with more traps in: FSUIPC4811b After that I think we need some assistance in narrowing down what exactly LINDA is doing at the time of the crash. Maybe there's more logging that can be enabled, or that they can add for us. I'm afraid i now nothing about LINDA at all. Can you ask the author(s) for help with this? Don't they have their own website? Pete
-
There are lots of examples, those supplied in the package installed for you in the FSUIPC Documents folder, and those supplied by others in the User Contributions subforum. There is also a lot of information about Lua programming on the Lua website, which is why I provide a link to it in the documentation. There are tutorials there and a reference manual. So why not simply ask me to do it for you? That's what you want, isn't it? You don't really want to do anything for yourself? Any sort of script or program follows a sequence, like English or any other language. If I jumble up all the wodrs I write here in a random fashion, like your attempt at a script, would you be able to understand? Why do you think a computer can understand random stuff put together with no thought? Think about it logically. First, you obviously need to READ the value you wasnt to display BEFORE you display it. You actually formatted the message for display using a variable called "oat" which you'd not set.beforehand. So, reverse those two lines: temp = ipc.readSW(0x0e8c) str = string.format("OAT %2.0fC", oat + 0.5)[/CODE] That's step 1. But now notice that you read the OAT into "temp" but formatted something called "oat". Make the names the same: [CODE]oat = ipc.readSW(0x0e8c) str = string.format("OAT %2.0fC", oat + 0.5)[/CODE] Better? Can you at least see a bit of sense in this yet? (If not I give up). Now you want to actually display it on your window -- you know how to do that already! [CODE]wnd.text(w5, str)[/CODE] You might want to clear the window first, though, or each display will be on a new line, with the old obnes scrolling up. That's it. Almost. Two more things. First, if you'd looked up 0E8C in the offsets list, as you should have, you'd see it isn't in degrees C but 256 times degrees C. So you need to divide it by 256 first. So: [CODE]oat = ipc.readSW(0x0e8c) / 256[/CODE] Second, I assume you really want to keep this updated, not just display it once and terminate? So you need either to loop displaying it at, say, half-second intervals: [CODE]while true do -- says do the following forever (because "true" is always true) oat = ipc.readSW(0x0e8c) / 256 str = string.format("OAT %2.0fC", oat + 0.5) wnd.clear(w5) wnd.text(w5, str) ipc.sleep(500) --delay half a second end -- end of the loop started by the 'while'[/CODE] Alternatively, a more advanced and tidier way is to re-display it when it changes. This is done by using an "event", so: [CODE]function displayoat(off, val) -- says the following is going to be called by something, using the name "displayoat" oat = val / 256 -- val supplies the oat when it changes, don't need to read it again str = string.format("OAT %2.0fC", oat + 0.5) wnd.clear(w5) wnd.text(w5, str) end -- end of the function event.offset(0x0e8c, "SW", "displayoat") -- says execute function "displayoat" when offset 0e8c, which is "SW"-signed word-changes.[/CODE] Now, don't you think you can do others yourself? If not, why? What have I not explained? Oh, yes. One last thing. Look in the log to see if there are errors in the program. I'm not perfect either. I've not tested this here. Pete
-
Spoiler Axis (Saitek) PMDG NGX
Pete Dowson replied to AngeloCosma's topic in FSUIPC Support Pete Dowson Modules
Why are you adding this same question, again, to another thread, when I already answered you when you first posted it? Please see the first answer. I'm not going to keep answerng the same question added to multiple irrelevant threads! Pete -
You could get rid of that by setting 0,0,0,0 for the position and size values in the wnd.open function. What I have tried is shown below and it won't even get the window to display, never mind put any text in it. And as I don't have much hair left these days I can't afford to tear any of it out! w5 = wnd.open("OAT", WND_FIXED) ipc.sleep(5) ext.position("OAT", 43,5,12,2,1) wnd.font(w5, WND_ARIAL, 12.0, WND_BOLD) wnd.backcol(w5, 0xf00) wnd.textcol(w5, 0xfff) wnd.clear(w5) wnd.text(w, "OAT " .. temp .. "C") end[/CODE] What is that "end" the end of? you've not had any beginning to warrant an "end". If you look at the FSUIPC log you will surely see the error message telling you this! If there's an error in the program it cannot compile, but the error message will tell you what the error is and even which line it is in! Have you never looked? [CODE]--str = string.format("OAT %2.0fC", oat + 0.5) temp = ipc.readSW(0x0e8c)[/CODE] What is this intended to do? The first line there is a comment (all lines starting -- are comments). Comments don't do anything except inform the reader of the code. Even if it wasn't a comment, it seems to be trying to make a string "OAT nnC" with a value named "oat" which hasn't been set by anything yet. Then the string, 'str', is never used in any case! Then the next line sets "temp" from the offset 0E8C, yet "temp" is never used for anything before the whole thing suddenly ends. Please explain how you arrived at all this ...? If you are pulling lines at random from other things, then I think you should stop, and tthink a little instead. You can't make programs that work with random lines. Well, you can i suppose but the chances are extremely remote, the same as a roomful of monkeys with typewrites coming up with the works of Shakespeare! ;-) Pete
-
No, no. The above lines create some extra logging in the FSUIPC log, not the Windows log -- it was the FSUIPC log file I needed to see! [LATER] I've now made a special version of FSUIPC which might, hopefully, trap the error and log more useful information. For the time being, without that Log I needed, I've assumed it is occurring durng one of the specific initialisation DirectInput calls. If it does, this version should catch it: FSUIPC4811a Please try it and let me know. Remember, it is the FSUIPC4 log I need to see. Regards Pete