Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Yes, but I don't understand those words and you didn't show the error log entries. Hmmm. Interesting. Well, I'm not really a newbie, but I don't know anything about all that either. But checking the reference you provided, this part: basically points to the diagnosis that an important system file somehow became corrupted. Maybe you had a complete system crash at some pooint, or sudden loss of power? Those are the usual occasions you get sudden file corruption, when it coincides with some disk write action. Anyway, having seen exactly what can happen in FSUIPC, I've taken steps in my code to prevent an FS crash in the circumstances you encountered. As I said, I even managed to reproduce it once -- but without your three "DWORD - LoadPerf" errors. The next interim update for FSUIPC will be "crashproof" in this regard. Regards Pete
  2. That is sounding very much like a corrupted installation or a bad video driver, or even hardware problems. Nothing in FSX or any of my software can make monitors turn orange! I think you are looking at some serious problem which may require some amount of re-installation at minimum. If you still think it must be FSUIPC (which is really impossible), show me the FSUIPC4.LOG file from the FSX modules folder -- one produced by the last time you attempted to run FSX. If there isn't one there, then it hasn't even been run yet asnd it is certainly an FSX or simConnect problem. If there is one, you can paste it into a message here. Pete
  3. I'm a bit lost now as to what you are doing. I thought you were assigning in FSUIPC? The only axis assigned there is this one, from the PFC throttle quadrant: [Axes] 0=17X,512,D,22,0,0,0 which is a direct assignment to FSUIPC calibration for the spoilers. I think 17X is the left-most lever, which would be appropriate for a spoiler. And it is sort-of calibrated, at least in your pmdg737 Profile: Spoilers=-16380,-14320/24 However, those calibration values will probably mean you get full spoiler deflection wherever that lever is: -16380 to -14320 is simply wrong. You'd expect something very positive for the maximum figure. You also have Filtering enabled, which will make it a little less precise -- you shouldn't need that with a good axis like the PFC and a reasonably stable power supply. You need to either leave spoiler control to the PFC driver or calibrate it properly, preferably without filtering. It is also set as if calibrated in the generic calibrations, but evidently not with any specific calibration, but at least with the default one which may work a little better -- which is why you don't see the same effect on other aircraft. Spoilers=-16380,16380/16 Incidentally, if you change: ShortAircraftNameOk=No to ShortAircraftNameOk=Substring and [Profile.pmdg737] 1=Boeing 737-924 United Airlines (Merger) Winglets to, say, [Profile.pmdg737] 1=Boeing 737 then the pmdg737 profile will apply automatically to any other variation you may use in future. Regards Pete
  4. To Rob, not From -- I was replying to his post in that part. Sorry, I shouldn't have combined the replies.. Correct for FS9 or before, but I assume you mean PFCFSX.DLL? Your FSUIPC4.INI and log file would be useful too, please. It still looks like the spoilers are activating if the aircraft won't accelerate enough under ful power. Either that or your brakes. I don't understand why it only affects the NGX though, unless it's because of the aircraft-specific or Profile settings limiting it to that aircraft, which seems likely now i think of it. Pete
  5. So something else is slowing it -- maybe the spoilers are being raised? Evidently the throttles are okay. It sounds like axes are being assigned automatically. FSUIPC does this for the PFCHid.DLL -- do you have that installed as well? And if so why? (But the latest interim update for FSUIPC does not do the automatic assignment if PFCFSX is also loaded -- or at least it doesn't here. I have both PFCFSX and PFCHid running because my cockpit has a mixture of PFC serial port and USB devices). Please show me your FSUIPC4.INI file, and the latest log using the latest updated FSUIPC please. You can paste them into a message here. Regards Pete
  6. I'm just having a quick look at my code for macro file finalisation before I go to bed. The only extra information I think I need from you is the NAME of the macro file you ask for, and some examples of the names of the macros you are attempting to create. I've a strong feeling it's to do with the naming. [LATER] No, it isn't naming as far as I can tell. I managed to reproduce it only once, but i did manage it. it seems to be timing. There's a delay after selecting "End macro making" and the macro name entry window being cleared. It's hardly noticeable here, but if you catch it before it disappears, then you get the problem. If your disk system is slow to check and update the files being manipulated it will probably give more time for this to happen, and the complexity and continual activity of the NGX exaggerates this. I can put safeguards in to stop this, and will do so. Meanwhile could you simply wait a while after selecting End macro in the Options, stay in the options for a few more seconds, then, when exiting to flight mode, wait a few more seconds. This is just as a test. Let me know if it still occurs even then, please. Regards Pete
  7. So, is this from the original file? because this also seems to show it ran okay, at least insofar as recognising those device connections? If they are from the original file, please delete that section AND the debug section and try again. [LATER] I've just tried running GFDisplay with your GFDisplay.txt (renamed as INI) and it loads okay. But if I remove GFDev.DLL it does exactly the same as yours. I'm positive this is the reason. I know you said you thought it was finding it, but I don't think so. You are probably being miseld by the old lines from the INI file you copied. You simply need to copy GFDev.DLL into the same folder. BTW, I just looked at the GFDisplay ZIP I provided, and the example GFDisplay.INI in there contains PM support for the GFMCP including all the displays. I'm sure adding the extra bits for the Pro wouldn't have been too hard. Trouble is I don't remember much of it now! ;-) Regards Pete
  8. Hmmm. Very strange. I can't see the same here, with the exact same quadrant (not in the Jetliner, but the same controller board mounted in a box for testing). BTW can you not report the SPEED, which isn't too helpful, but the actual throttle position reached. You don't even need to start the engines. Just look at the throttle quadrant in the sim whilst moving the throttle levers. Do they move to a maximum position of 50% approx? If so then I think you are assigning to the wrong controls. Regards Pete
  9. Could you try the latest versions of both of those, please -- from the Download Links subforum. Regards Pete
  10. Hmm. Thanks. Error 0xC0000417 is "STATUS_INVALID_CRUNTIME_PARAMETER #An invalid parameter was passed to a C runtime function." which is interesting. A worry, though, is the address: 0x00082008, which cannot be in FSUIPC4 -- that's part of FSX.EXE I think (I'll check). FSUIPC loads at "Module base=61000000", so possibly it means 61082008. I'll see if that's feasible. I'll get back to you if i need more information, but it won't be until tomorrow now. Regards Pete
  11. I'm pretty sure there's nothing stopping it running on Vista. Are you sure it's simply not a case of no installed GFDev.DLL? [LATER] I just spotted your TXT file attachment. I don't remember much about GFDisplay these days, but that seems to contain a debug log which does eventually show things happening with three devices. What do you expect GFdisplay to "open". It isn't a visual program, it just runs quietly in the background. Well the reason I abandoned that in favour of the Lua route was that GFDisplay's parameters are complex and arcane and inflexible, contrasting with the near- English programming capabilities of Lua, its infinite flexibility, and extremely good documentation (available free on the Internet, or in book form if you make a habit of it). The ipc library contains a range of reads and writes to read and write any type of offset. The Library documentation doesn't only cover the gfd library but also all of those added to FSUIPC and WideClient. There are also lots of Lua examples provided with the Lua package and in the User Contributions subforum. None may do exactly what you want, but will certainly show sufficiently appropriate examples you can adapt. On top of that, when trying you can ask specific questions here and i or others will answer. I'm only against writing the whole thing for folks -- I prefer to help them write their own. Not specifically, because that's one possible application out of an almost infinite number. Lua is too flexible to provide examples of everything it can do. You need to adapt from other examples or just try things. It's worth it in the end as you find other things you'd like to be able to do. Regards Pete
  12. No, all the "virtual buttons" are seen in the dialogue too. Well, it isn't only in the manual, it is on the screen in front of you too. There are two places to get the assignment dropdown and make your assignments, one for "Press" and the other, just below, for "Release". I did tell you this earlier. "On" for a Toggle is the same as pressing a button, "off" is the same as releasing it. FSUIPC has always offered programming capability for both events. I'm surprised you've never noticed. Perhaps what is confusing you is that the dialogue only recognises the "on" or "press" event to display the button. That's to avoid a double call and problems with some rotary types. But you can always (always) program both press/on and release/off when the button is shown. Regards Pete
  13. Did you not calibrate the axis afterwards? The values from a trim axis should be sufficiently fine, or it's a pretty bad device. As far as I know most Saitek axis devices have a resolution of about 1024 positions, which is a lot more than the 128 on my expensive PFC device and the latter is still pretty good at getting the trim just right. did you first try assigning in FS itself? Doesn't Saitek provide any calibration suitable? Not a good idea to try to write directly to offsets from an axis. You could try writing a Lua plug-in to compute a desirable trim value from the axis input, but it really shouldn't be needed. If Saitek has produced a trim wheel which isn't suitable for use as a trim wheel with FS I'd return it for a refund. Regards Pete
  14. No. Use one button, defined as a Toggle, but program both the "on" (press) and "off" (release) actions. So, assuming you must have meant offset 0D0C not 01DC (the latter not being anything at all related to lights): 100=P64,0,Cx05000D0C,02 101=U64,1,Cx09000D0C,02 though you really would find it easier to do this in FSUIPC's assignments screen rather than editing the INI file. The WideClient INI entry would simply be: 00=T"Beacon lights" Once synchronized (by using it once) it will show RED for on, GREEN for off. It won't necessarily start off showing correctly because it isn't actually reading the status/offset. Regards Pete
  15. It sounds like it is nothing to do with the installing part, but a bug in SimConnect. To work out where it is happening, please check the FSX Modules folder for an FSUIPC4.LOG file. If there is not one there then FSUIPC4 has not been run. If there is one, check the date on it and make sure it is from the last run of FSX you had. Then paste its contents here for me to check for you. If there's no log being produced then FSUIPC is being run and the bug is in SimConnect or FSX. Please see the thread in the FAQ subforum entitled "FSX fails to run after FSUIPC4 first installed ". Regards Pete
  16. No, I don't use any GF equipment. All my stuff is PFC except the overhead which is Cockpitsonic. I do, however, have some GF stuff here which was supplied for testing. The GF MCPPro sits here unused at present. Ah. I've never used the GF software at all, only the interface, GFDev.DLL, which FSUIPC and WideClient use to talk to the GF units. The PM commands in FSUIPC can be assigned to operate PM's MCP. That's not a problem. You can also use FSUIPC or WideClient Lua plug-ins to drive the displays on any GF device. It isn't too hard, but you would need a list of the Project Magenta offsets from which to derive the way to get the information to display. If you do this you cannot also use the GF software. The GF driver does not cooperate with others using the same hardware. In your second message: No, GFDisplay.lua is only a test program and example of using Lua to drive GoFlight devices. It isn't a flight-time utility. When you start it, it simply does a series of display tests on all your connected GF devices, and then sits responding and displaying button or switch turning details. You need a Lua program specifically designed to take PM values and modes and use them to set the displays and indicators on the MCP. That's good. That's half the job. Well, I'm pretty sure the GFMCP2k2.dll must be for FS2002 and GFMCP2k4.dll for FS2004, so I shouldn't think they should both be there in any case. Maybe this was the reason for your original problem, if GF purport to support PM? For a Lua plug-in driver for the MCP you are right to remove both though. I don't know what Leveld.dll is, but I suspect it's an essential part of a LevelD aircraft systems logic? If PM.DLL is GF's PM driver, then, yes, you wouldn't want that if you are writing your own Lua plug-in driver. The "GFD library" in FSUIPC's Lua plug-in support is merely a library of functions which can be used by a Lua plug-in program. The library is a resource, not a companent active in its own right. It knows nothing about any specific GoFlight device, it simply obeys calls from your program to read buttons and write indicators and displays. The GFDisplay lua program was provided as an example. Regards Pete
  17. You appear to have three such devices. The Vendor and Product names or numbers are defined at the beginning of the Lua program, strangely enough in variables which reflect this, i.e: Vendor = ... Product = ... If you use the names, then they are strings and need to be in "", as: Vendor = "PoLabs" Product = "Virtual Joystick" Alternatively you can use the hex numbers instead if you wish: Vendor=0x1DC3 Product=0x1001 Because you have three you will also need to be sure to select the cirrect device using: this line: Device = 0 -- Multiple devices of the same name need increasing Device numbers The three will be numbered 0, 1 and 2 respectively. On your second message: Can't see why. What did you do to the later one? I really don't have enough information to be able to advise I'm afraid. Are those the only buttons connected? If not what of the others? It is near impossible to debug from afar an interface between hardware I do not have and a program I have not seen. If you add some logging lines to the Lua coding you should be able to find out what is happening. You can log information simply by inserting, temporarily, lines like: ipc.log("This is the value of x: " .. x) Of course you don't need to be so verbose, and could log several values in each line, so: ipc.log("x =" .. x .. " y=" .. y .. " z=" .. z) The ".." parts just join things together. Regards Pete
  18. No, security settings will have no effect whatsoever on COM port access. If only COM3 is opening with WideClient then you aren't establishing the pair correctly with VSPE or MixW -- both ports in the pair should be openable (providing you aren't already running the FliteMap software), so you should find two possible assignable ports in WideClient. You need to check the status of the pair you are trying to set up in VSPE itself. WideClient supports the full Lua plug-in facilities that FSUIPC does, less a few parts only. The "initial.lua" file is an optional plug-in which will run, if present, as soon as WideClient is started -- other Lua files are only run after connection. The message is there to show you that it looked and didn't find the optional file, so it wasn't run. This obviously doesn't matter if you are not using the facilities, same as the message about IPX/SPX if you aren't using that protocol. Pete
  19. Going into FSUIPC options and exiting doesn't cause any change in any serially connected devices because FSUIPC doesn't control them. It will rescan the standard Joystick connections (those recognised by Windows as joysticks), in case they've changed, but that cannot affect anything handled completely outside of FSUIPC, like a serail device handled, presumably, by my PFC driver. So, I think more information is needed. Is this Jetliner console the floor standing device with radios, throttle quadrant and so on? If so how have you got the throttle quadrant set up? Are you sure the direct control from the PFC driver is disabled if you are assigning in FSUIPC -- or vice versa? Is this problem only with the NGX? Please also state version numbers of FSUIPC4 and PFCFSX. Regards Pete
  20. Neither Radar contact nor FSUIPC can have any such effect. Hmmm. Maybe a little bit hasty considering FSUIPC does nothing to FS in any case if unregistered. I've never heard of a problem like that, but before trying to find out what is happening, could you please tell me what actual version of FSUIPC you are talking about ("latest version" is ambiguous, unfortunately -- I need the number), and also please try installing the true latest interim update (4.726) from the Download Links subforum, in case it makes a difference. If there's still no success please paste here the content of any Log files (Instal log and possibly an FSUIPC4 log) from the FS modules folder. Regards Pete
  21. The assignable commands in those lists are added by "Macro" files, The JS41 commands you see are only there because you placed a macro file into the FS Modules folder. FSUIPC reads all such files and adds the macro names for you. If you look in the Modules folder you should find the file responsible -- it will have a file type of .mcro. It is an ordinary text file, but in the same format as INI and CFG files, as used by both FSUIPC and FS. Read it into notepad and you'll see where those command names come from. In the User Contributions subforum you will find lots of other examples, and maybe some to suit the other aircraft you want to use. Regards Pete
  22. I don't think Ezdok can interfere with any of this. But I need more information in order to help. What exactly do you mean by these statements please? 1. "sitting in the cockpit after writing the macro's name, if I press Return, FSX crashes." What sort of "crash? What actually happens? Is there an error message from anything? 2. "I already tried to reinstall a previous fsuipc version without success." What previous version, and by "without success" do you mean exactly the same thing happened? 3. "I can start my macro.....but impossible to save it. As soon as I'm back in the FSUIPC menu, ending the macro (FSUIPC stated that the macro is ended).....I cannot find my new macro in the listing. And when I return in the cockpit, there is still the green window, and the white text, waiting/monitoring for any inputs. Back to FSUIPC menu, I can only start a new macro." If FSX crashes as soon as you press Return in order to name the last macro, how do you get as far as re-entering FSUIPC options? This one seems to conflict with #1 above. Please also show me an FSUIPC log file, using the latest update. Regards Pete
  23. That problem was fixed. Try the latest FSUIPC4 update in the Download Links subforum. Please also check the other threads on the PMDG 737NGX -- folks have been posting solutions using mouse Macros already. For instance see this thread PMDG 737 NGX and FSUIPC Also be warned that as PMDG issue updates, the mouse macros will need re-making. Regards Pete
  24. 4.20! :-( That's nearly FOUR years old and totally unsupportable! The earliest supported version at the moment is 4.70, and there's a later version in the Download Links subforum. But who actually makes these aircraft? They are evidently not default FS aircraft! Have you tried their forum? Sorry, but I cannot support other people's software: I have enough to do with my own! It's nothing to do with the thread -- It's the Forum. You need to go to the support forum for the aircraft which isn't working! GAUge files are nothing to do with FSUIPC. That's probably your answer, then. If it's an FS9 aircraft I doubt if it will work properly in FSX in any case. Sorry, but you are in the wrong place entirely. If you want help with FSUIPC at all (which most certainly isn't apparent at present), you MUST update to the current version first. Regards Pete
  25. Who makes that aircraft? Does it even use FSUIPC? Is this in FS98, FS2000, FS2002, FS2004 or FSX? Which version of FSUIPC is installed (the actual version number)? I'm not sure why you are asking here -- shouldn't you check with the aircraft maker's support in the first instance? Those gauge files aren't part of anything I make or support. 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.