Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I don't think the default FSX Baron has any Mouse Macro capable switches or buttons -- certainly not many anyway. I don't think any of the default FS (FS9 or FSX) aircraft have such gauges. You have to have add-on aircraft with gauges made using the FS C/C++ gauge SDK for Mouse macros to work. All those are standard assignable FS controls. If you enable the Event logging in FSUIPC you'll see their names. Otherwise look up the nmbers in the "List of FSX controls" in your FSUIPC Documents folder. Just assign your buttons or keypresses to the correct controls. Pete
  2. It can only be done by programming a plug-in. The Lua package is installed in your FSUIPC Documents subfolder. It sounds like it may be beyond you though if you can only handle simple english. Sorry. You asked if it was possible, and it is, but maybe you should stick to glovepie if that works. Pete
  3. Okay. Then, in that case, one of those other lines is diverting the BARO knob. So it's a process of elimination. There's only 13 lines there, and the culprit is one of the other 12, so try removing the last 6. If that makes BARO work, then the last 3, and so on, zeroing in on the culprit. Once i know that i can zero in direct on the relevant code. Hmm. Okay, so an empty file doesn't satisfy. And the CUB macro file was still there? Did the CUB macros affect other aircraft or not, you don't say. Not your problem too? These aspects of the PFCHID program must have been like this for several years. I don't deal with PFC devices these days, but I'm surprosd PFC haven't tested the software I did for them -- after all they had all the hardware. nonetheless, since i wrote it I like to make sure it works correctly. It's just difficult without access. I might need more tests done tomorrow, maybe with some logging. Regards Pete
  4. No no no! I don't care about that. It was obviously one of those unlisted controls. I've moved on to your other problem, about why the CUB macros are being used for other aircraft! Yes yes yes. Create a PFC.MCRO file to see if the problem is that without a default MCRO file the DLL was retaining the CUB assignments. The two tests were, to repeat myself, create a PFC.mcro file with only [Macros] in it, no actual macros only the heading. Run FSX, see if your CUB macros then operate in other aircraft. If so, repeat with test after adding one line of assignment to the PFC.MCRO file. Let me know the results. What isn't clear? But I didn't say delete the CUB.mcro file and edit the INI file!!! That defeats the object altogether, don't you see? For the switches you want to do nothing? Of course. Haven't you done that yet? I didn't understand why you assigned different "do nothing" (as you thjought) contorl numbers to each switch in the first place. What was the point opf that? Did you think different "no things" were better than all the same 2do nothings"? Pete
  5. Which is what you wanted, right? So using a real "do nothing" control like that you can make all the other switches do nothing also, right? But the questions are really about the BARO knob aren't they? Have you tested that? Why no comment about that? And what about the other test, to find out why the A2A assignments affect all aircraft? you seem to have stopped prematurely. You've changed "CUB" to "PFC"? did you make a "PFC.mcro" file? This is getting more and more confusing. You seem to leak a little information each time. It's going to take a while! ... ;-) Regards Pete
  6. Okay. You said earlier: Where did you look? In the axis assignments? In the button/switches tab? Because quite honestly i can see nothing which will stop FSUIPC seeing them -- unless perhaps you instlled Saitek's own software? Does FSX see them? FSUIPC4 uses EXACTLY the same process as FSX. The FSUIPC4.LOg file you show was NOT after a closed FSX as I asked, by the way, so I can't check a couple of things. There is an assignment already to airleron: This does appear to use default values, but implies maybe that the INI file was retained from your previous install. Could you try renaming it or deleting it (it doesn't appear to contain anything useful). I see you said I'm not sure what is really meant by a "clean reinstall", but to be so drastic for one button seems a bit, er, oever the top? So far all things look fine, however. Pete
  7. Why using the loader? In general it isn't a good idea, it is just a last resort. Version number of FSUIPC4 please? If not 4.91, please first try that. Show me the FSUIPC4.INI and FSUIPC4 log files please. Close FSX down first. You can paste them into a message. Pete
  8. Okay. This certainly implies that one of the unlisted controls you used does something stopping the BARO action. Maybe, if oyu had time, you could find the actual entry that does this. In my confusion earlier, I still didn't understand whether it was ONLY the BARO on the A2A aircraft not working, or on any aircraft with that adjustment? You said at one point which I now realise i didn't fully understand. All aircraft I know of are capable of adjusting the altimeter to accord with current QNH, and this is done via a BARO know adjustment. The display is called the "Kollsman widow" because it was a window in an altimeter first invented by the German Kollsman company, but all aircraft with altimeters need to allow this adjustment. Well, I don't know whether they do or not. They are simply not given any names in the FS CONTROLS.DLL tables. They might be used internally between parts of FS. Additionally many add-ons do make use of controls for their own purposes. The PMDG add-ons use hundreds of them, but usually in a range far higher than the FS default ones. I think some aircraft may be using ones unlisted in FS, and it could be one of those you happened to use is actually used internally in the A2A aircraft. Oh dear. "Innocuous" is an English word meaning something like "having no ill effect". It isn't a specific command, it is up to you to choose one which, in the action it is described as doing, has no ill effect. If you refer back you will see that I did actually suggest a way to choose one. did you miss that? There is, however, actually an FSUIPC added control called "Nothing: no action" which you could use. It is number 1126 (listed in the added controls list in the Advanced User's guide). I'd certainly hope so! Perhaps you could please do another test for me so I know where to look. Create a dummy PFC.mcro file for me, first with only the one line in it [Macros] then with at least one innocuous macro entry in it. Please let me know the results with both tests. Pete
  9. I thought RC saved them automatically. AutoSave can't save RC stuff, RC is a separate program. Don't you simply have to tell RC to reload from one of its autosaved files after loading FS up from the AutoSaved files? If this is not what you were asking, have you asked in the RC support forum? Pete
  10. Oh, that's odd. The [Config.A2A Piper Cub] section should only be operational for an aircraft by that name. I must assume that you DO actually mean that the switches are working as if the macros were assigned, and not simply that the macros are listed in FSUIPC's drop-downs for assignment. Please tell me immediately if this assumption is wrong. Even if it has no entries? Or one entry? Or a different one entry? I understand that. You seem to misunderstand what i need to diagnose and fix things. I don't have easy access to the hardware with which to test it here, and I certainly don't have any A2A aircraft. I am trying to get closer to where the problem might be by asking questions. This might then lead to asking for some logging to be done so I can track it further. If this is annoying for you, and you aren't bothered if it isn't fixed, then I'll desist. But I do like to fix things if they are broken. That is not actually true. You appear to have assigned them all to unlisted controls, ones without names, but each of those when sent to FS may actually do something. You should NEVER use a control number without actually knowing. If you want an innocuous one which does nothing useful, then find one which is explicitly like that, at least on all the aircraft you use. For instance, something for a 4th engine when you never have that many. Perhaps you could tell me why you are actually assigning all these (different) unknown controls, please? I don't understand what it is you are intending by it. Pete
  11. Er ... I can't see any reference to A2A before it appears in the INI file you posted!? I am also now confused. You say it works for the A2A and also for all other planes. So ... it doesn't work for what, exactly? What is not included in "all other planes"? Going back to the original report you said Is this "J3 Cub" the same aircraft as the "A2A Piper Cub"? If so, I assume I was expected to know that? Sorry if that was it. I don't know all add-ons for FS, far from it. If this is what you mean, is the Macro file you posted (after I had read and quoted your original posting, BTW) the one entitled "CUB.mcro" or the other one? Either way, could you post the other one too, if it exists? Also, do you mean that just the act of having a macro file stops the BARO action, or that there is a specific macro within the Macro file which stops it? It wasn't there when I hit the "Quote" button to reply. Pete
  12. Reference please? I expect I advised that merely as a test to see if it was a driver/registry problem. Did they ever come back for a follow up? In that case I would most certainly like more information so I could investigate, because without details I can't really fix things now, can I? If you want to make it issue a control, like the added FSUIPC PTT control, just sent the appropriate control number to offset 3110. What else were you looking for? Or use the virtual buttons so that it can be programmed in FSUIPC instead. If the crash refers to WinMM or another DirectInput module then it wouln't be anything to do with USB, but device drivers and/or registry. Pete
  13. Well, that's not the macro file, is it? Looks like you have a default file referenced, "PFC.mcro" and a specific one "CUB.mcro" for just the A2A Piper Cub. So the A2A one is okay, i it? If you'd like to show me the macro file as originally asked for, I can take a look, but as it is .... Pete
  14. Wow! Not heard of anything like that before! Sounds like a bad driver. I think you should try uninstalling each device and its driver, and reinstalling so that the driver and its registry data are refreshed. Such an application would probably meet with same crash, though, as it would need to call the same APIs. Pete
  15. I don't see how programming some switches via macros affects others --as in fact you observed with the Magnetos. Are you sure there's nothing in the macro file relating to the Baro knob? Maybe you should show me the file contents. I find it difficult to help in a vaccum. Pete
  16. WideFS can do this for you. With WideFS you can assign buttons in FSUIPC from any network connected PC running WideClient. Pete
  17. It isn't hard to find the version number. It is shown on the main options screen in FS, it is logged in the first line of the LOG file and withing the parameter file 9.INI), and it is shown in the DLL properties if you right click on the DLL and select "Properties-Version". If by "not working" you mean the key is stated to be invalid, then the most likely thing is that you are making a mistake. All three fields -- name, email/address and key must be correct and as originally used. As Ian says, you can check your details in your SimMarket account. Pete
  18. The current version of the Lua library package includes both Mouse control, and Mouse monitoring through a comprehensive set of events. You could use "event.mouseleft" to activate a virtual button. Pete
  19. The normal assignments are direct to FS controls, and FS doesn't offer such things. You could do it with a Lua plug in which reads the frequency, changes the appropriate digit and writes it back again. There's no way without doing a bit of programming like that. Pete
  20. The CAPS LOCK key an be assigned to a yoke button in FSUIPC. If the software doesn't recognise it then it will be because it is programmed using diret keyboard state API calls into Windows, which interrogate the real keyboard almost directly. FSUIPC and other normal programs can only induce the effects of key presses, not simulate the state of the real keyboard. There's no way to do that without a low level driver. And FSUIPC has no relationship at all, no impact either, on anything multiplayer. Pete
  21. What has FS2004 got to do with FSX and the 737NGX? There is no connection there. The NGX is no way anything like the old PMDG 737 for FS2004. FSUIPC ins't supplied with any macros, in fact nothing at all for the NGX. If you want to use macros you need to make them or install someone else's. I think there are quite a few suggestions in the User Contributions subforum. Pete
  22. There is absolutely no way anything regarding FSUIPC3 can affect anything regarding FSUIPC4 -- or vice versa They are uttely and absolutely independent of each other, just as your FS2004 and FSX installations are. Pete
  23. Those are non-standard terms. See if they are defined on "interfaceIT" documentation. The 16 bit unsigned one might be Word or ShortInt or SmallInt. It isn't possible to guess between these. As mgh said, there are 4 conditions, and you want the light to be lit as follows: Left off/right off -> light off Left off/right on -> light on Left on/right off -> light on Left on/right on -> light off In other words, you want the light on when the two offsets are different, and off when the two offsets are the same. Now how you "program" that using the facilities you have I have no idea. You would need to consult the InterfaceIT documentation again. Pete
  24. FSUIPC will only see it as a Game Controller if it is installed as a Game Controller -- same as Windows. FSUIPC only ses the Game Controllers windows does. Maybe that can be accomplished with a different driver or installation package, like an "inf", but if nothing was ever done for anything later than XP you are probably out of luck. HID devices are handled quite well by the COM library in FSUIPC's Lua plug-in facilities. It would mean writing a small Lua plug-in to convert the HID buttons into FSUIPC virtual buttons for assignment. Regards Pete
  25. So, FSUIPC4 definitely is not being loaded. So it is likely that your DLL.XML file is bad. It is a text file. Load it into a text editor rthen paste it into a message here. 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.