Jump to content
The simFlight Network Forums

activex

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    1

activex last won the day on August 12

activex had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

activex's Achievements

Contributor

Contributor (5/14)

  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare

Recent Badges

2

Reputation

  1. So I tried it, there's quite noticeable response improvement, when I write the values into the CRJ (as I rotate the encoder and watch the display change in the CRJ cockpit, in the sim), I would say pretty comparable to writing standard offsets. The important thing here is that when benchmarking I should be observing the changes inside the CRJ cockpit, not on my MCP hardware since that is affected by the hard-coded encoder delay (in my code) explained below. I am stating this because initially I was looking at the hardware displays when turning the encoders. Quick question: How much of a performance hit to my FPS is there if I use the setting LvarUpdateFrequency=Frame (as opposed to other settings)? In my case, I only have like 30 offsets total that are mapped to lvars. Are these only offsets that get monitored (my/user defined offsets), or internally there are other offsets? I haven't noticed any FPS degradation, but I thought I ask. I noticed in your ini file acronym "CDA", what does that stand for, what is it used for? So that fixes that, one still remaining item that I have on my list is to see if I can find some writeable offsets for hdg/speed/alt/vs so I don't have to simulate encoder turns. To turn an encoder in the CRJ, I have to set the lvar to 1, put a small delay, and reset it back to 0 (simulate a push button hold/release). That delay has to be long enough so that CRJ can detect the release. 10ms works best (best trade-off between performance and CRJ seeing the reset). Thanks for the help.
  2. I did not mention that for encoders only: When I change a dataref (Xplane) or offset (MSFS), I read the value from the sim immediately and update the MCP display immediately. I do this for both sims, Xplane and MSFS. As long as I have direct access to the offset (or dataref) it is very responsive. The timer is used more for LEDs on buttons and if state changes in the sim (for example, turning off FD, turn's of other modes) or even changing hdg/alt/speed in the sim (not via hardware) I sync those changes back to the hardware. 500ms in this setup works fine. Not using WASM monitoring, I explicitly read the offsets using my own timer. Unless, the offsets I read are being populated by WASM monitoring this will not make any difference. I can try though. My bet is still on the fact that I cannot write CRJ offsets and have to trigger a change using an offset for an encoder (which requires you to simulate a button press, set it to 1, then reset it back to 0, and the reset action needs a delay otherwise it will not work).
  3. I am using a polling timer (every 500ms) and I am reading the lvar mapped offsets + standard offsets (using the same timer, the offsets are sitting in the same collection). The mapped offsets seem to take longer to get populated or it could be a side-effect if writing of the offsets is slow. I do observe when I write the offsets (lvar mapped + standard offsets) that the changes in the CRJ aircraft (like displayed hdg) appear slightly slower when changing an lvar mapped offset compared to standard offset. In summary: Same code, same polling timer that iterates over 2 different types of offsets (standard, vs lvar mapped) sitting in the same collection, lvar mapped offsets are slower to read/write. Maybe it is the CRJ code that's slow receiving/updating itself or something else..., I would decrease my polling timer interval but I don't think I will see the difference since the standard offsets respond fast, so I am thinking the problem is somewhere else. UPDATE There's 1 major difference that I do differently when writing standard offset vs lvar mapped offset: Since the CRJ lvars are mostly read-only, I have to use the encoder (knob) on the mcp to trigger the change and then I read the changed value back (in the lvar offset) and update the display on my MCP. For the standard offsets, I write them directly with the actual value. That's probably why it works faster.
  4. Update/ FYI I will not be using the "MSFSVariableServices" class for now since it crashes with the CRJ but to update you, John has fixed the FSUIPC code and it works fine with the mapped offsets (to lvars) using ini file. I noticed that reading the mapped offsets (that are mapped to lvars) is quite slower compared to reading standard offsets. This is not much of an issue with the buttons/LEDs (not as noticeable) but you notice the slowness when I am refreshing the hdg/speed/alt displays on my Goflight hardware, it is so sluggish. Also, turning the encoders is kind of sluggish when sending data back to the CRJ (ie updating the lvars). I wonder if this is because of WASM.
  5. I tested the new FSUIPC executable, and works now as expected. I also used the new "F" specifier and it works correctly. All the CRJ lvars I am interacting with now work. Just one question: I noticed that reading of the lvars (via mapped offsets) is quite slow, like 5 times (or more) slower than using standard offsets (which are read instantaneously). Is this something that has to do with WASM? I know WASM technology, and the byte code should execute quite fast, but is there maybe marshalling or IPC involved? Can I do something about it, to increase speed? Btw, the attached zipped file of the FSUIPC and the executable inside it did not trigger windows defender. Not sure what changed but it just works.
  6. Are you doing this on a windows box? Is it Windows 10 updated with recent updates? I want to try it, but this should be more concerning to you, if I am getting it, so will other Windows users. I am going to retry the system and try to download it again. Re-started my system, same problem, please advise on your environment. Can you post it zipped, I want to see what happens if I try downloading the archive. If same thing happens, it might be good to confirm with Microsoft that is false positive for your customers. Also, interestingly, your current version of FSUIPC doesn't trigger windows defender.
  7. Sorry, I am cautious ... This is my work machine. Did you scan the executable on your system? If yes, what software did you use. Cleary, if Windows Defender flags it as a severe thread (trojan),- it has reason for it. It found virus signature in that executable, and I don't think that's by chance. Maybe rebuild the executable again?
  8. I did, I simply reported trying using FLT64 and my results. Is this executable infected (it has trojan, is your computer infected)? See attachment
  9. Still doesn't work, Lvar is discovered in FSUIPC, but doesn't see changes in the offset. Attached logs, and model behavior window screenshot. I did try reload function and tried again, doesn't make a difference. [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=0xA000 I used the reload function when making changes to the ini file, does the reload function reload just the Lvars or also settings in the ini file (for example, when I change data type on my mapped offset and would like to use it without restarting the sim)? FSUIPC7.ini FSUIPC7.log
  10. It doesn't work even using FLT32 but ... I did get the following offset log below when I moved the dial initially (for the first time): 137953 Monitor IPC:A000 (FLT32) = 39780386527510528.00000000 138110 Monitor IPC:A000 (FLT32) = 0.00000000 After that, moving the dial has no effect. I also discovered this (when testing the offset as FLT32) (not sure if that was a fluke): If you start your CRJ cold & dark, FSUIPC will be missing some of the Lvars (including the ones I reported). NOTE: Lvars are missing only in FSUIPC, they are still there in the sim (I can view them using Model Behaviors/Local Variables window). FSUIPC will not see Lvars even if you change the state of the aircraft from cold & dark => ready for taxi. To get the lvars in FSUIPC, your aircraft must start in state ready for taxi. (I did not bother testing the other aircraft states). That probably explains why you can't see the Lvars. Definitely something wrong with FSUIPC not being able to discover all CRJ.
  11. Dang it ... It is hard to get it to crash in other aircrafts ... seems like there's something with the CRJ that makes it crash. I'll let you know if I find a better test case.
  12. Can you install the FBW a320 and try some functions on that? This aircraft is more complex and has lots of lvars.
  13. Okay, not too familiar with FSUIPC options, FSUIPC is really new software that I started using. I will do that.
  14. Okay, ... I think I got it to crash on a stock aircraft. Select the "Cessna CJ4" (the one that comes with the sim, not the FBW one. Use my code that I have provided in previous post (On changed event should iterate over all Lvars not (LVarsChanged) collection, just like posted in my sample. Then, .. in the CJ4 cockpit, under lights there's a "Panel Lighting Brightness" knob (center knob, under dimming labelled "Panel"), start turning it left and right (from min to max), keep doing it until you get a crash. If it is not crashing, stop the app (not the sim), and start it again and repeat the process. Sometimes the crash is not induced. If that doesn't work, try an aircraft with lots of lvars, maybe a320 by FBW. Then try changing switches back and forth, those that are mapped to lvars and in rapid succession. Since this is a memory thing, it might hard to reproduce, but if you can get the CRJ, it should happens for sure since that's what happens to me. UPDATE: My observation is that the crash is induced as the Lvars are changed constantly and therefore changing any controls that read/write LVars will cause/may cause a crash.
  15. John, the screenshot was taken after the log, so I went back and did this test in the right order, and yes, the screenshot values match what's in the log. I included also the ASCRJ_FCP_xxx_INFO offsets for HDG/SPEED (IAS) since they mirror the other offsets. ID=1535 ASCRJ_FCP_SPEED_INFO = 40.000000 174625 [INFO]: ID=1536 ASCRJ_FCP_SPEED_MODE = 0.000000 174625 [INFO]: ID=1537 ASCRJ_FCP_HDG_INFO = 220.000000 174625 [INFO]: ID=1538 ASCRJ_FCP_ALT_INFO = 10000.000000 174625 [INFO]: ID=1539 ASCRJ_FCP_WHEEL_INFO = -2.116344 174625 [INFO]: ID=1540 ASCRJ_FCP_WHEEL_MODE = 0.000000 174625 [INFO]: ID=1541 ASCRJ_MCDU_KYBD_TOGGLE = 0.000000 174625 [INFO]: ID=1542 ASCRJ_MCDU2_KYBD_TOGGLE = 0.000000 174625 [INFO]: ID=1543 ASCRJ_VAR_AP_LAT_ACTIVE = 5.000000 174625 [INFO]: ID=1544 ASCRJ_VAR_AP_LAT_ARMED = 0.000000 174625 [INFO]: ID=1545 ASCRJ_VAR_AP_VERT_ACTIVE = 2.000000 174625 [INFO]: ID=1546 ASCRJ_VAR_AP_VERT_ARMED = 0.000000 174625 [INFO]: ID=1547 ASCRJ_VAR_AP_VERT_ARMED_2 = 0.000000 174625 [INFO]: ID=1548 ASCRJ_VAR_AP_LOC_CAPTURE = 0.000000 174625 [INFO]: ID=1549 ASCRJ_VAR_AP_GS_CAPTURE = 0.000000 174625 [INFO]: ID=1550 ASCRJ_VAR_AP_ALT_HOLD = 0.000000 174625 [INFO]: ID=1551 ASCRJ_VAR_AP_ALT_CAPTURE = 0.000000 174625 [INFO]: ID=1552 ASCRJ_VAR_AP_USE_MACH = 0.000000 174625 [INFO]: ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000 174625 [INFO]: ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000 174625 [INFO]: ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000 174625 [INFO]: ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000 174625 [INFO]: ID=1557 ASCRJ_VAR_AP_SELHDG = 220.000000 That out of the way, why is it that the FSUIPC software using the mapped offset doesn't display the correct value in the title bar, it is always zero (see attached images). The title bar always displays zero. Maybe it is datatype issue, if yes, can you tell me what datatype to try (the short form of the datatype to use in ini file and monitor offset screen, which one to select)? [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000
×
×
  • 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.