Jump to content
The simFlight Network Forums

Alpin-Flier

Members
  • Posts

    62
  • Joined

  • Last visited

  • Days Won

    1

Alpin-Flier last won the day on October 20 2022

Alpin-Flier had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Untersiggenthal

Recent Profile Visitors

874 profile views

Alpin-Flier's Achievements

Apprentice

Apprentice (3/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare

Recent Badges

2

Reputation

  1. Thank you very much for your fast and most informative answer. The conclusion therefore is: "You just need to move the hardware lever to its initial position before starting MSFS/FSUIPC. " and touch it again only after some delay. I can live with that. All the best Urs
  2. Hi John Thanks to FSUIPC I could realise a really fine working homecockpit with MSFS and PMDG B737-800. But there is a small problem I could not find a solution for. I would like to synchronise the SW flaps lever at program start with the HW lever in my homecockpit. Lets assume that the SW lever is on any position, when FSUIPC starts. It goes always to 0 after about 14 sec. It then takes over the HW position only after the first HW lever move. During the 14 secs any HW lever move is not recognised. The HW lever is working on the flaps axis in FSUIPC (see FSUIPC.ini joined). I tried to find some info in the FSUIPC.log file (joined) and can see, that ca. 14 sec after PSUIPC start WAPI is started and Lvars/Hvars are received. I don't understand them really, but the solution could be there. How can I proceed? Of course, flaps lever should always be on 0 after leaving the cockpit. But under simulation conditions this may not be granted. Thanks for any help and best regards Urs FSUIPC7.ini FSUIPC7.log
  3. Hi John Ok, no chance therefore. I agree, that there are several options to access events. I am using some (also presets) successfully. The problem arises, when there is a missing link to an event due to a bug in the airplane code. In such cases mouse macros where the only way to get around, because mouse operations worked always. Just to explain my request: My actual (of course small) problem is the TimeCompression control in the PMDG B737. The offset is there, but no way to influence it. Only the mouse is able to activate it, the rest not. I made a ticket to PMDG and was told to wait for a new update. All clear for now, thank you very much. BR Urs
  4. Hi John Mouse macros were a very nice FSUIPC feature for otherwise unreachable functions in the past, but not available any more for MSFS. However, with the new interface capabilities of MSFS, is there a chance to get this functionality back in a near future? This would be really a highlight in the desert of missing MSFS functions ... Thanks for any infos. BR Urs
  5. Hi John I am on final with my homecockpit conversion to MSFS. Actually one problem remains. I would like to synchronise my SW PMDG B737-800 at program start with the HW of my cockpit. Nearly everything is fine, switches are synchronised, but not the axes. So the flaps lever in the sim is only updated at the first move. With FSInterrogate I can see, that axes values are 0 after starting FSUIPC, independent from the real HW position. Is there a way to get the real values, so that the sim can follow these without the need for moving them? Thanks for any infos and best regards Urs
  6. Hi John I have some issue with the "Key Press & Release" command. To select a customer view in MSFS, I use keys ALT-1 and ALT-2 as given in MSFS. To operate these keys from an external program I would like to use WriteFSUIPC($3114,4,4145); // Select Captain camera, ALT+1 WriteFSUIPC($3110,4,1070); // Push & Release key and WriteFSUIPC($3114,4,4146); // Select Copis camera, ALT+2 WriteFSUIPC($3110,4,1070); // Push & Release key Unfortunately this doesn't work reliable. Sometimes the command is recognised, sometimes not. Could this be a timing problem? Perhaps MSFS does not read the press command before it disappears by the release command. Can this time be influenced somewhere, i.e. make the time between press and release longer? By the way, as a workaround, when I separate press and release commands by using 1071 and 1072, it's ok. Thanks for info, all the best for the new year and best regards Urs
  7. Hi John Ok, understood. And in fact, it works this way 😊. So I am confident, that I can adapt my script accordingly. Many thanks for your patience and best regards Urs Edit: Just saw your second answer. Thank you also for your testing. All fine now.
  8. Hi John Thank you so much for these infos. I can understand the mechanism much better now. For testing I use two buttons again, defined as follows (3 and 4 only for comparison): [Buttons] PollInterval=25 ButtonRepeat=20,10 1=PB,4,C65604,0 -{THROTTLE_CUT}- 2=RB,5,C65602,0 -{THROTTLE_DECR}- 3=PB,14,K49,24 -{Key press: lalt+1}- 4=PB,15,K50,24 -{Key press: lalt+2}- 5=PB,18,C78100,4145 -{Custom control: <78100>}- 6=PB,18,C78096,1070 -{Custom control: <78096>}- 7=PB,19,C78100,4146 -{Custom control: <78100>}- 8=PB,19,C78096,1070 -{Custom control: <78096>}- I tried with all three parameter pairs you proposed, but there is no reaction at all. Is my test arrangement faulty? Urs
  9. Hi John Sorry to get back to you, but I am still in trouble. I tried a lot but without success. The only thing I get working is the control via buttons. The working button definitions in the .ini file are: 1=PB,14,K49,24 -{Key press: lalt+1}- 2=PB,15,K50,24 -{Key press: lalt+2}- When I look to the log-file I can see some actions, somehow cryptic: 1485500 Button changed: bRef=0, Joy=1 (B), Btn=14, Pressed 1485500 [Buttons] 10=PB,14,K49,24 1485500 SendKeyToFS(00010031=[lalt+1], KEYDOWN) ctr=0 1485516 Sending WM_KEYDOWN, Key=164 (LAlt) (Scan code 56), Ctr=4 1485531 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=3 1485547 Ignoring EV_KEYDOWN received as was sent to FS: 0x31 (1) 1485547 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=2 1485578 Sending WM_KEYUP, Key=164 (LAlt) (Scan code 56), Ctr=1 1485625 Button changed: bRef=0, Joy=1 (B), Btn=14, Released 1485625 [Buttons] 10=PB,14,K49,24 1486609 Button changed: bRef=0, Joy=1 (B), Btn=15, Pressed 1486609 [Buttons] 11=PB,15,K50,24 1486609 SendKeyToFS(00010032=[lalt+2], KEYDOWN) ctr=0 1486625 Sending WM_KEYDOWN, Key=164 (LAlt) (Scan code 56), Ctr=4 1486641 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=3 1486641 Ignoring EV_KEYDOWN received as was sent to FS: 0x32 (2) 1486656 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=2 1486672 Sending WM_KEYUP, Key=164 (LAlt) (Scan code 56), Ctr=1 1486734 Button changed: bRef=0, Joy=1 (B), Btn=15, Released 1486734 [Buttons] 11=PB,15,K50,24 But I still don't know how to achieve the same result by filling offsets with controls and parameters. I tried to fill x3200, x3204 and x3208 with 1070, 49 and 24 in different ways. Then I tried to write 1070 to x3110, but I didn't know how the parameters 49 and 24 should be filled in x3114. Please, please let me know the correct procedure. Many thanks in advance. Best regards Urs Meyer
  10. Thank you very, very much for this incredibly fast and promising answer. Now I know where I have to look at. I feel good (again)... Have a nice evening and best regards Urs
  11. Hi John I have nearly finished installing MSFS to my B737-800 homepit. Many issues could be solved thanks to FSUIPC7 😊. But since a day I am squeezing my brain to solve the following problem. Perhaps I don't see the wood for the trees any more... Tried to find the solution in the normal and the advanced user guide without success. I want to switch the visual between two modes: Captain and 1.Off view. They are defined with MSFS customer views on ALT-1 and ALT-2 and then selected via the keyboard. Then I have programmed two buttons in FSUIPC to send these key presses, all working fine. But now I should trigger the view selection from an external program, that can write to FSUIPC offsets. But how can I link two free offsets in FSUIPC, that will trigger the key commands at changes? Your help would be most welcome. Best regards Urs Meyer
  12. Hi John Thank you very much for answering. I think I should be more precise. Some values are output from PMDG resp. Simconnect as Float32 resp. Float64. When you need the values for calculations and/or displays, it is very difficult to convert them to integers in a program like SC-Pascal. The following vars are concerned in the PMDG B737: Offset Mapping for PMDG 737-700 6474 4 FLT32 FUEL_FuelTempNeedle 64E8 4 FLT32 APU_EGTNeedle 6548 8 FLT32 x 2 AIR_DuctPress[2] PSI 6550 8 FLT32 x 2 AIR_DuctPressNeedle[2] Value - PSI 6558 4 FLT32 AIR_CabinAltNeedle Value - ft 655C 4 FLT32 AIR_CabinDPNeedle Value - PSI 6560 4 FLT32 AIR_CabinVSNeedle Value - ft/min 6564 4 FLT32 AIR_CabinValveNeedle Value - 0(closed) .. 1(open) 65C4 4 FLT32 MCP_IASMach Mach if < 10.0 660C 8 FLT32 x 2 MAIN_TEFlapsNeedle[2] 661C 4 FLT32 MAIN_BrakePressNeedle General offsets 02CC 8 FLT64 WISKEY COMPASS INDICATION Other interesting values as the AC/DC voltages and currents (see Ramons question) With the FSInterrogate tool I can see the correct values in the FLT32 resp. FLT64 columns. It would be very helpful, if these values could be duplicated to new offsets as integers. Let's take the Wiskey Compass as an exemple: Take the FLT64 from 02CC (0 to 359,xxxx..°)and multiply it by 100 => 0 to 35999 This value is then output with a 2-byte integer. The user can divide it by 100 (possible with every program) and display 0.00 to 359.99 . Similar with Flaps controlling servos. Just an idea, possibly helping also other users of FSUIPC. Thank you very much for attention and best regards Urs
  13. Hi John I have the same problem as Ramon. SC-Pascal has a very limited function range and is not able by itself to convert Float64 to e.g. a 2-Byte word. In my case it is the heading at $02D0,4 I need it for my WetCompass. I read only the upper nibbles of this value to simplify conversion, but it is still very complicate. Is there a chance, that all Float values can be converted to reasonable Bytes/Words to be used in further script calculations resp. displays? Best regards Urs
  14. Let me confirm it also here: John did a very good (and fast) job, thanks a lot. Since the 7.3.12 published today, PMDG events work perfectly, writing parameters to the known PMDG offsets like in the good old P3D times 😎. Existing scripts may be used again. Forget the "Rotorbrake" botch. John, you made my day. Urs
  15. Hi John This is just to confirm to you, that the new FSUIPC7 v7.3.12 is working perfectly 😊. Finally I can send again events with parameters to the well known PMDG offsets. This allows me to reuse most of my scripts made for P3D. I think (and hope), we can forget now the strange and confusing "Rotorbrake" story 😁 Thank you very, very much for your effective and fast service. All the best Urs
×
×
  • 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.