Jump to content
The simFlight Network Forums

svenks

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by svenks

  1. 1 minute ago, svenks said:

    But the smaller the child widow is, the less movement you have in the main window. So the main window does move, but it can only move within the size of the child window. Therefore, it is really annoying to see this on an MCDU (where it's impossible to move away from a close-up of the headrest), but if it's the overhead panel causing it, you have almost free movement.

    Cancel that, I just tried with an undocked Overhead Panel (which I moved to another screen) and got the stupid headrest I cannot move away from until I click it first.

    Sorry about that,

    Sven

  2. Hmmm, regarding 1127 and 1128.

    Even if I assign Mouse Look On and Mouse Look Off directly in FSUIPC, they don't do anything - UNLESS I also enable Mouse look in FSUIPC's Misc section.

    And If I do that, well, as I said it does behave weird and sluggish probably due to the conflict I have mentioned earlier.

    So that was the explanation for 1127 and 1128...

    On the focus related and original problem, I found out a small detail, which might provide an extra clue: All child window, docked or undocked, causes this behaviour, once they have had focus (provided you don't click in the main window afterwards). But the smaller the child widow is, the less movement you have in the main window. So the main window does move, but it can only move within the size of the child window. Therefore, it is really annoying to see this on an MCDU (where it's impossible to move away from a close-up of the headrest), but if it's the overhead panel causing it, you have almost free movement.

    BRGDS

    Sven

  3. 4 hours ago, John Dowson said:

    They should and I have checked this here (via button assignments though, not lua) and they seem to work as expected. Why do you think they are not working?

    Hi John

    Yes, they should - but they don't do anything when used from LUA. I even created a small section in LINDA user modules for A320 and assigned FIRE1.Press to do ipc.control(1127) and FIRE1.Rlse to do ipc.control(1128). Nothing happens.

    I'm attaching a partial FSUIPC.LOG. In the first part, I am using ipc.control(1127) and (1128) from my MousTrap.lua script. Then I changed the script and loaded The Mooney Bravo, so now it's using ipc.control(1071, 32) and (1072, 32). As you can see, this DOES invoke Mouse Look.

    BRGDS

    Sven

    fsuipc.log

  4. Hi John

    Mouse Look, of course! But I accidentally enabled Mouse Move, and this caused the weird movements I saw. But it is true that enabling Mouse Look in FSUIPC and having controls enabled in P3D will cause erratic behaviour.

    2 hours ago, John Dowson said:

    Why don't you move it to a corner rather than the centre, i.e. use mouse.move(0, 0, 2). There should not be any switch in that position.

    You cannot know. If I have used Mouse Look, I could easily have a switch right under any coordinates, unless of course 0,0 is in the title bar.

    Tried it - it's the menu bar, and so Scenario is selected 🙂

    Isn't there really no other way than a click to move the focus? I'm beginning to think this is not doable with the tools at hand.

    Again, thanks for your efforts,

    BRGDS

    Sven

  5. Hi John

    Thanks for a quick reply.

    Advanced controls are set OFF, as it will cause another sort of movement than mouse look using the middle/wheel button - sideways panning etc. Manually pressing spacebar still give you mouse look, but does not solve the problem.

    ext.setfocus doesn't APPEAR to do anything in this case, but on the other hand FS still sems to have focus - it just resides with the MCDU window.

    FSUIPC documentation for Mouse.Move states "...be sure not to have it enabled if you do have controllers enabled in P3D as the two facilities will clash". And it does behave weird...

    ipc.control(1125) doesn't change anything....

    Now, if only I could remember to click the main window each time I want to use mouse.look - but...

    BRGDS

    Sven

     

  6. Hi all

    I'm trying to do something simple, yet it turns out to be quite a bit more complicated than I thought...

    I'm using P3Dv5 and most I fly FSlabs A320. I have a button on my joustick assigned to Captains view and another to FO view. And I can pan aound just fine using the hat switch.

    But I would like to be able to use the Mouse to look around also - easy peasy, right? WRONG!

    The problem is not to get Mouse Look working, I can do that by assigning Spacebar to a mousebutton, or I can trap the middle mouse button. But however I do it, I run into trouble because I usually undock the 2 MCDU's and this confuses Mouselook. I usually wind up looking straight back into the headrest - UNLESS I remember to click in the main window BEFORE a try to use Mouse Look.

    It seems to me that is is probably due the MCDU window getting the focus, and since that is a flat 2D instument, Mouselook gets confused.

    I have tried lots of things, but the only thing that seems to work is to have my LUA script move the cursor and issue a click. But that is too risky, since I cannot know if a crucial switch is at the center of the screen, when I do this. None of the ways I have tried to set the focus to the main FS window seems to work (ext.focus etc). And as for ext.gethandle using the window title: it MIGHT work, but it is a long title, and it changes according to number of attached wideclients. 

    It might also be possible to use FSUIPC Mousewheel MOVE, but using my Thrustmaster A320 Throttle and sidestick with FSlabs A320 apparently demands that the joysticks be enabled in P3D.  

    Any ideas? I'm attaching the script I'm using to trap the middle mouse wheel.

    BRGDS 

    Sven Sorensen, EKCH

    MousTrap.lua

  7. Hi Peter

    It is NOT a problem! Please don't take my suggestion as a complaint or anything.

    I merily suggested something that to me seemed logical, but is a "feature“ of FS, not FSUIPC. And you must admit, it is somewhat redundant for FS to have both an arm zone as well as an arm key!

    Hence my confusion - and my suggestion.

    Brgds 

    Sven

  8. Hi Peter and Thomas

    Thanks for your replies

    I had already calibrated my axis thus. But what you are saying is, that whenever you name an axis as spoiler, that behavior is what you get from FS/P3D? I must confess, that is news to me. Maybe it shouldn't be, but this is the first time I've dug so deep into FSUIPC.

    Well, live and learn...

    Cheers, Sven

  9. Hi Peter 🙂

    Well, I'm still at it with my X52 Pro LEDs, and actually it's going very well, and I almost have a working setup for PMDG 747 QOTSII - almost.

    I thought I would do the spoilers last, as they seemed very simple to do - just a copy of the flaps section. However, there is one thing, I'm unable to do: Setting a LED when spoilers are armed.

    The reason is primarily that PMDG has obscured that setting pretty well - but another issue is the fact that FSUIPC insists on having a part of the spoiler travel range set to be an ARM SPOILER zone.

    Of course, if you don't want to use a keystroke (default: shift+/) or a button to arm them, then it's a good thing - but I would rather use a button or rather, move a lever on my Saitek Quadrant out of scale (below the lower, hard detent),  as that is defined as a button: Toggle Arm spoiler on entry, and toggle again on exit. PMDG understands this very well, and even the animation is correct!

    I have seen other people a long time ago wondering about this arm zone, and so I would like to humbly suggest a checkmark for "No Arm Zone" for the spoiler axis, the same way as you have done for the throttle axes? Possible?

    BRGDS

    Sven Sorensen, EKCH

  10. Just by being there...😁

    It 2 things: 1) The error msg was totally misleading. I did have a valid 64 bit DLL, but 2) the dependant LUA DLL had a slightly different name, lua5.1.dll instead of lua51.dll...

    Thus, the passerelle DLL wouldn't load, and so I got "Not a valid win32 application".

    I also began using package.load to load the DLL - though require should have worked.

    Brgds Sven

  11. Ok, I've had it!

    How hard can it be to create a valid 64-bit DLL???

    And I haven't got a clue as to what (if anything) I'm doing wrong.

    In desperation I installed Lua for Windows (5.1.4) on my gaming PC. Copied passerelle/32bit to its clibs folder.

    Tried Require("passerelle") => unable to load module from file / module not found. OK, at least it didn't say "Not a valid Win32 app"

    Now, the SAME passerelle DLL on my VirtualBox testrig, also copied to LFW 5.1.4\clibs: Require("passerelle") - and it works!

    Same DLL - Same LUA environment - two different outcomes.

    I need a break...

    /Sven

  12. HI Pete, thanks for the answer!

    Yes, I am testing on P3Dv4.5 and FSUIPC5.

    But there must be more at play here. I have the DLL in both a 32 and a 64 bit version. Both produce the same

        44734 *** LUA Error: error loading module 'passerelle' from file 'D:\P3D\modules\lua\passerelle.dll':
        %1 is not a valid Win32 application.

    Surely, this must must be close to the most stupid error text, when I am actuallly running a 32-bit DLL (only to be outdone by "keyboard not found - hit F1")

    But it may also have to do with the LUA version. Running the 32-bit passerelle under LUA 5.1/32-bit works, 64-bit passerelle under 5.1/64-bit gives the error above. 

    Running the passerelle/32 under LUA5.3/32 chrashes LUA. Running passerelle/64 under LUA5.3/64 gives the error above. NOTE: I can only build passerelle with LUA 5.1 libs and the chrash occurs in LUA 5.1 DLL.

    What LUA version is FSUIPC actually running? 

    BRGDS

    Sven

  13. This is only a little step for mankind, but a giant leap for me....

    See the yellow LED? I made that...

    But I do need to figure out how to load a C DLL from FSUIPC (or LUA or P3D) so I can call it from a LUA Script. I thought it would be a matter of just having a LUA script with a REQUIRE in it, but apparently not 😞

    It is a DLL called "passerelle" and it is an interface between LUA and the SAITEK drivers. I only got it working in a debugger attached to a LUA window. But still, even a small victory is a victory,

    Pete, as for SPADNext, they haven't got around to the X52 yet.

    BRGDS

    Sven 

    Yellow_LED.jpg

  14. Heureka!!!

    There is something called x52luaout, made by erkswede. It does exactly what I want it to do, see this Youtube link

    Alas! It is for X-plane only, but the name suggests to me that it should be possible to port it to P3D & FSX.

    Unfortunately, I cannot seem to find anywhere where I can download it. I will try to contact erkswede.

    This holds more promise than my attempts today with an USB sniffer...

    BRGDS

    Sven

     

    • Upvote 1
  15. Hi

    Thanks for the reply, both of you. I've seen SPAD mentioned, but actually thought it was some hardware box. I'll certainly give it at go.

    As for Process Monitor, I think that it would be very hard to identify those bits having to do with the LEDs. That's why I tried readfeature, but I can't be sure that the LEDs are even a feature, nor that Saitek has followed the USB Bible.

    Other than that, all is well!

    Brgds Sven

  16. Hi Peter

    As hinted in another, older thread, I have begun looking at the possibility of using the LED's on the Saitek X52 Pro to provide some useful information. For example, if I turn off the autopilot via a joystick button, change the color of that button (or turn it off). If I can get it to work, I would even change that LED on AP turn on/off regardless of whether I used the button or not.

    I have been looking at HIDdemo as well as this LINKthis LINK and not least this LINK. The last one actually deals with setting LED's on a Saitek Unit. Unfortunately, it deals with the Saitek Switch panel, not the X52. And the FSUIPC LUA COM library is not concerned with LED,s except that the last link above does use com.writefeature to set the 3 LED's on the Switch panel.

    But I really have no clue on how to proceed with the X52. It has a lot of LEDs and many of them can be set to 3 colors. I tried to use com.readfeature to see if I could see something change in the output from that, if I let it run and then changed one of the LEDs via the driver/calibration software. But either I'm doing it wrong, or the X52 does not support com.readfeature, or it doesn't have "features" per se. In any case, the return value is 0, meaning that the call failed.

    So I'm stuck in the water. If you, Peter or anyone can give me a clue on how to proceed, it would be much appreciated.

    BRGDS

    Sven Sorensen, EKCH

    HidFeature.lua.txt

  17. Hi all

    Sorry to revive an old thread, but yesterday I had an idea...

    What if I could use my Saitek X52 Pro joystick to give me a visual clue as to what switches or functions are on/off/armed by manipulating the LED's on the stick?

    I have changed HidRadio to give me something of a prototype, and I can see that I am talking to the joystick. However, the problem is that I have no clue which value I should push to the joystick to turn a LED say, amber, and if I actually can use com.writefeature to do it.

    If anyone has dabbled with the same idea and perhaps even succeded, please give me a holler.

    BRGDS

    Sven Sorensen

    EKCH

  18. Hi Guys

    Once again, I'm overwhelmed at what FSUIPC can do for you and over your great and continuous work over the years! A heartfelt THANK YOU!

    However, there is one snake in the grass: In FSUIPC6, the ability to keep profiles in separate files seems to be broken. I have changed "UseProfiles" to Yes, but no Profiles folder appears

    and all profiles are indeed still in FSUIPC6.INI. It is no biggie, but I find it easier to work with separate files.

    BRGDS

    Sven Sorensen

    EKCH 

    FSUIPC6.ini

  19. 17 hours ago, fyrakoto said:

    hello ladies and gentlemen,

    I am a newbie with fslabs and trying to make throttle manager to work. I followed the tutorial at the begining of this thread and my throtlle are not going back into reverse mode, instead it moved forward. any help is much appreciated.

    Thank you

     

    Hi there

    This is what the script actually do. But in case of Airbus, you really don't want the throttles to move forward but rather backwards. Therefore you cannot use the script as it is.

    I can tell you, it works great with FSlabs Concorde in FSX.

    BRGDS

    Sven Sorensen, Denmark

×
×
  • 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.