Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Not sure I understand you here. Why would that make any difference? Most of the examples in User Contributions do it with each button assigned to the same Lua plug-in but with a different parameter for each function, You still only need maybe just one plug-in for each different aircraft. What sort of problems are you thinking you'll get? I don't know of any. No. Plug-ins loaded for a specific aircraft are killed off when that aircraft is no longer loaded. Yes, by executing the macro using the ipc.macro function. You still need them defined in a .mcro file. Regards Pete
  2. Sophisticated add-on aircraft like iFly and PMDG hardly use any of the default stuff. They all do their own systems. Check the User Contributions subforum -- I expect there are answers for iFly. There is also an addon which provides offsets for iFly; Why? Are you using some extermal Lua DLLs or writing your own? The Lua packages you normally need for FSUIPC, supporting all the libraries documented for FSUIPC, are built into FSUIPC already. Regards Pete
  3. Two questions: 1. Is the window you want to position actually available to be moved? i.e. is it already undocked? The facility can only work on existing top-level windows -- it cannot actually create them. FS actually creates a new window when you undock. (I wish I could ffind a way of undocking them automatically, but I can't). 2. If so, do you have the name correct? "Main Panel" is the name normally given to the main 2D instrument panel. I think the window you want is called "Virtual Cockpt - View 00". Try that. It works here. Pete
  4. This is okay, but because you are provided with the value of offset 0D0C as the parameter "value" it would be more efficient to use it, so: TL = logic.And(value, ... BTW you need to put a space before your final ")" to stop the Forum software turning things into emoticon faces! ;-) Regards Pete
  5. I suspect that the PMDG aircraft has its own control or keystroke for operating the A/T. You don't say whether this is the FS9 or FSX version, but please check the User Contributions subforum for the answers. As far as I can see, for the FSX version, the A/T Arm action can be controlled by a mouse macro assignment. Regards Pete
  6. I used to use Speech Buddy long ago and had no problems. I seem to recall you can only program it to send keystrokes. Whether you need FSUIPC as well depends on how much of your aircraft you want to control this way and whether there are keystrokes for those controls. All FSUIPC can do for it is catch the keystrokes and allow you to program them accordingly. Don't forget that FS must have the keyboard focus for it (and FSUIPC) to see and respond to keystrokes. I now use "Its Your Plane", which supports a good range of aircraft. There's also "Multi-Crew Experience" which some folks prefer. Regards Pete
  7. What Flight Simulstyor version? What FSUIPC version? Which aircraft? You are switching it off first, then on? Why? If you are talking about the default 738 in FSX, then the "off" takes a second or two to switch the APU off when it is on. Have you programmed your switch the wrong way around, perhaps? The controls are most certainly being sent to FS, and they do work with the defalut 738. I don't know about any other aircraft. Aha, so it is FSX. The controls APU STARTER and APU OFF SWITCH can be assigned to button or switch or keypress and wotrk fine here, 100%. Here is the log you should see with both Button and Event logging enabled. This is on my own T8 module, third button from left, with APU off in the upper position (switch acually "on" or "pressed") and the "on" in the lower, or "off" position. 901718 Button changed: bRef=0, Joy=109, Btn=2, Released 901718 [Buttons] 506=U109,2,C66704,0 901718 FS Control Sent: Ctrl=66704, Param=0 901734 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 000000fb} 901734 *** EVENT: Cntrl= 66704 (0x00010490), Param= 0 (0x00000000) APU_STARTER 905531 Button changed: bRef=0, Joy=109, Btn=2, Pressed 905531 [Buttons] 505=P109,2,C66705,0 905531 FS Control Sent: Ctrl=66705, Param=0 905546 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 000000ff} 905546 *** EVENT: Cntrl= 66705 (0x00010491), Param= 0 (0x00000000) APU_OFF_SWITCH[/CODE] The "STARTER" action is immediate in effect on the visible panel switch, but the "OFF" action is delayed by about 2 seconds. Your test above has the OFF first, and the ON only just over [i]half a second[/i] later, so perhaps that's why you see no change? Pete
  8. Yes. it is limited because there are only 7 bits available to encode it into the Windows WM_COMMAND format. If I have to extend this format it would be a major re-write. FSUIPC has been developed incrementatlly, with Lua facilities being bolted onto Macro facilities which were bolted onto the normal FS/Windows command system. One macro file can contain an almost unlimited number of macros. For Lua programming you can also use the Parameter value to select among any number of different programmed actions. Please review some of the User Contributions in the subforum of that nmame. There are lots of good examples to follow. Regards Pete
  9. Sorry, I don't quite understand. Are you saying it does not work, even after saying "My problem has been solved with your sugestion."? I am away now till Sunday, so apologies for any delay in a further response. Pete
  10. As Paul says, it must be TacPack doing it. FSUIPC itself doesn't touchit at all -- only its Installer amends the DLL.XML file, and that always puts FSUIPC4 last. Try making the DLL.XML read-only. That may work, or it may just make the failure change its reported cause. If you do this and it works, remember to temporarily change it back when installing other add-ons which may want to update it. Regards Pete
  11. I don't understand how you can tell that F12 is being used on the client just by programming a button on the Server? In fact it isn't, nopt at all, because your Wideclient parameters are wrong: First, why are your comments to do with CTRL key? nothing in the parameters deals with the CTRL key! Second, you are using a full stop (.) instead of a comma (,). Why? Please check the documentation. The correct lines would be: Keysend1 = 123,16 ;means Press F12 Keysend2 = 123,24 ;means Release F12 Regards Pete
  12. Nothing in FSUIPc changes -- sounds like you either have conflicting controls or you have your settings saved for a Profile or Aircraft you are not actually using. BTW I almost missed your question altogether. What on Earth has it got to do with this thread, entitled "SOLVED - Set Aircraft Specific Realism Settings via FSUIPC"?" Please do not post additional messages on completely irrelevant threads! If it's a new querstion, start a new thread with an approporate title. Pete
  13. Sounds like you are trying to set the minimum value (i.e. max reverse thrust) to a higher value than the maximum value (idle in this case). Don't forget bnegative numbers are LOWER than zero and positive numbers. FSUIPC calibration always works left lowest to right highest! Full reverse thrust is lower than idle! Pete
  14. Sorry, but i don't often update all the source code itself, only the documentation. I'll update the C one now ready for the next release, but all of the example source stuff is supplied by volunteers. However, the value of 10 for P3D has been defined in the both the "FSUIPC for Programmers" and the "FSUIPC4 Offsets Status" documents for a while now. As well as the documents mentioned above, the README.TXT included in the SDK says this: Sorry if this is not clear enough. I'll change the .h file for C/C++ now. At least I really doubt there'll ever be any other version numbers to be added! But maybe the programmer of the XPUIPC version for X-Plane uses the "reserved" value (5), which was for X-Plane originally before I decided against it, or maybe he's purloined 9 or 10? Best Regards Pete
  15. Either your key really is illegal, or the date on your PC is set to one BEFORE your purchase, making it look illegal. I can't check it here in any case as you don't give the order number and date. And I need the FSUIPC version number -- if it isn't at least 3.999 please update. Don't post any other details. Regards Pete
  16. The earliest current supported version is 4.853, and there's a 4.858 version now available too. 4.84 certainly isn't "current" I'm afraid. I don't know if it does. If the panel is not a standard joystick type device, it won't. And I'm afraid i cannot support Saitek devices. You'll need to narrow your searches then. There are very specific contributions for the NGX, including by PMDG themselves in the NGX SDK. I expect there are some for Saitek panels too. I have even less time than you, especially for Saitek. Sorry. Regards Pete
  17. Thanks for helping. Looks like Eric has re-used an area already assigned to pmSystems, so I hope no one wants to use both at the same time! Shame, really, as he only needed to apply for a dedicated non-conflicting area. Regards Pete
  18. Actually, it wasn't a bug in the logging area -- the logging actions merely exacerbated it. The problem turned out to be that LuaValue controls were immediately changing the Lua parameter "ipcPARAM" on the plug-in's stack whilst that plug-in was runnnig, without any regard to what sort of things might also be going on in that thread and on that stack! A real silly mistake, and lucky not to have been causing more widespread problems! Fixed now in FSUIPC 4.858 and 3.999x, both available in the Download Links subforum. The ipcPARAM value is now only set when an event occurs and its function is called, or during an ipc.sleep (where it cannot do any harm). Thanks for the report which led to this fix! Regards Pete
  19. I really couldn't hazard a guess, but find it very worrying for you that you'd get G3D.DLL crashes with initial default flight loading. One possibility is that you have a bad memory (RAM) stick in the PC. If you have enough memory you might be able to try without one of the sticks in tirn to see if you can eliminate this as a possibility, though, of ocurse, if it was bad memory then it could have conceivably corrupted something during installation -- everything passes through memory. An easier thing to try before that is probably to find and rename your FSX.CFG file so that next time FSX loads it makes a new one with all the options defaulted. If that helps then it might be a case of simply determining what options, what settings, and causing the grief and thereby perhaps pointing to the culprit parts. In case it is a corrupted add-on scenery element, you could rename your current SCENERY.CFG file (in C:\ProgramData\Microsoft\FSX usually), and copy over the defalt one from the main FSX folder. This will revert the scenery loading to just the default layers (excepting some changes I think some of your add-ons make to default textures). Finally, of the above listed add-ons only Ultimate Traffic 2 and ActiveSky X are loading up active elements initially, with PMDG also loading some DLLs which shouldn't then be doing anything. See if not running those makes a difference. In fact, find the DLL.XML and EXE.XML files (in the same folder as your FSX.CFG file) and rename those too -- this will stop UT2 and the PMDG modules loading -- just as a test. FSUIPC4 also won't load then, so after an initial test you'd need to re-run the FSUIPC4 installer to try just with FSUIPC4 running. All these ways of testing are non-destructive. You can restore each and all, so it isn't a re-installing everything problem at this time. You need to determine the root cause, and elimination is the only way without a complete restart. Regards Pete
  20. You don't need to use Lua to program buttons to send keystrokes! Just assign them in the Button assignments options, left-hand side. Please see the User Guide section on button assignments. Pete
  21. I seem to have answered this already in another thread. Why are you appending the same question to multiple threads? Wouldn't it be better to create a new one for a new subject. I will only answer once, so please see your earlier version. Pete
  22. Sorry, I don't understand. Do you mean you've identified the correct controls by using FSUIPC event logging , but you don't know how to assign? That seems surprising. The log shows both the name of the control and the parameter value, if used. What is the problem in assigning? There are actually many anti-ice controls: Anti ice on Anti ice off Anti ice set Anti ice toggle Anti ice toggle eng1 Anti ice toggle eng2 Anti ice toggle eng3 Anti ice toggle eng4 Anti ice set eng1 Anti ice set eng2 Anti ice set eng3 Anti ice set eng4 Toggle propeller deice Toggle structural deice I don't know if all these work, and some will no doubt need a parameter value -- the "Set" controls will normally have parameters 1 for 'on' and 0 for 'off. The non-engine specific ones may or may not take the engine number as a parameter, with '0' meaning 'all engines'. You see, apart from interpreting the results of logging, which it sounds like you've already done, there's a really good choice in the assignments list. Regards Pete
  23. Right. And Lua files need actually creating or copying in the folder -- there are many examples in your FSUIPC Documents folder, Zipped up. Regards Pete
  24. Yes, exactly. I was using a lever on a Saitek quadrant for testing. It appears to have a fairly low resolution -- a Delta of about 128, so there aren't that many values between full trim up and full down. Your wheel is less sensitive in this regard (or, rather, more precise -- probably a better way of describing it -- "sensitivity" is ambiguous because it depends on whether you are considering cause or effect). If they are only using half the trim range, maybe the parameter needs to be 8192 or -8192, depending which half? Or try the other control, "elevator trim set". Maybe you have to send a single trim up or down command too, as you found was needed in the Lua plg-in? You could even have a small macro for that -- or even replace the Axis setting control with an Offset Word Set control for the trim offset and whichever is the correct parameter for centred trim. Regards Pete
  25. Everything to do with FSUIPC operation is contained in the FS Modules folder and any subfolders therein. All the settings made in FSUIPC are stored in the one file, the INI file (FSUIPC.INI for FSUIPC3 and FSUIPC4.INI for FSUIPC4). You'll find it in the FS Modules folder. The format of most of the stuff inside the file is the subject of the FSUIPC Advanced User's manual. If there are Macros and Lua plug-ins in use you need to also save those -- the files with type .MCRO and .LUA, also in the Modules folder. Finally, you should also backup your registration which is in the FSUIPC.KEY or FSUIPC4.KEY file. 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.