Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,332
  • Joined

  • Last visited

  • Days Won

    273

Everything posted by John Dowson

  1. To do this, you need to detect when the drone camera is being used and add an offset condition to your assignments. I don't think that there is anything available that can determine the camera that is in use, but you could detect when switching between drone/cockpit cameras either by - assigning the ins key (the default MSFS key assignment that switches from drone to cockpit view and back) in FSUIPC7 to update a user offset flag, so the flag shows 1 when using the drone camera and 0 otherwise. If you do that, you can then add an offset condition to your assignments so that they are only sent when not in drone cam mode - you could have a lua script to intercept the VIEW_MODE control/event, and again update/toggle a free user offset when such an event is received
  2. For all aircraft or for a specific a/c? Please let me know which a/c you have tried and I will take a look. The TRANSPONDER STATE simvar is documented as working in the MSFS documentation.
  3. Check your MSFS assignments for the buttons that you are having issues with. If assigning in FSUIPC, we recommend initially starting with an empty profile for your controllers (except mouse and keyboard) in MSFS.
  4. When the assignments window is open, no controls are sent to the sim. Therefore it looks like you have the buttons also assigned in MSFS. After an MSFS update, you need to check your MSFS assignments as it can re-install the default profiles for your controllers. So please check your MSFS assignments.
  5. Then something must be configured to send those controls. Are you using the Honeycomb configuration software? If so, try disabling that. Otherwise you could try activating logging for Buttons & Keys as well as Events (non-axis controls) in FSUIPC4, to see what is logged when you activate those buttons. You can attached your FSUIPC4.log and FSUIPC4.ini files and I can take a look to see/confirm that they aren't coming from FSUIPC4.
  6. I've just taken a look and assigning to Axis Throttle1 Set (Or just Axis Throttle Set, or simply Throttle) moves the throttle in the FS, so I'm not sure what you are doing. Could you activate logging for Axis Controls, load the TBM 930 and move your throttle axis through its full range, then shutdown MSFS/FSUIPC7 and show me your FSUIPC7.log and FSUIPC7.ini files. You can also try assigning to Throttle1 Set, or Throttle Set.
  7. No - its a signed number not unsigned, so 0xC001 is -16383. I wouldn't worry about it.
  8. Not anymore. Commercial licenses used to be necessary, but ended up being a bit of a mess to administrate, so we do not do this anymore. So you are free to include whatever products we offer (as long as that doesn't include a license, of course!). We appreciate of being notified of such use, and maybe a free license for your software, and, if your profits allow, also a contribution via purchasing a license or two, if you consider that appropriate - but up to you. John Later: sorry, in your case, i.e .for hardware, just go ahead. No charge or license necessary. Just make sure you include any relevant documentation. I do not want to be the first port of call for issues with your customers!
  9. Try FLT32. S32 is for a signed 32-bit integer. Please see P13 of Advanced User manual. John P.S. For future reference, please also check 'Normal log file' in the offsets monitoring log panel, so I can see what it is logging in the FSUIPC7.log files that you show me. Better and easier than a screenshot.
  10. Ok, sounds like a good plan. But, trim control via 2 buttons (up/down) is quite a common issue. I am sure there are various solutions posted somewhere in this forum, maybe in User Contributions or from similar support requests in the main forum. I should probably add trim control assignments to the FAQ...I'll make a note to add something on this... John
  11. I don't think so - which post are you referring to? Setting up trim depends on the type of button/switch/rotary/wheel you are using. I have posted various times on this for different set-ups - 1 or 2 button wheel or rotaries usually... Your ini has: Your log shows that you only clicked buttons 4 and 5: So at no point did you activate the buttons for which you have the larger delta (256) assigned, buttons 6 and 7. So, I think you copied something that maybe doesn't apply. Note that I also use a lua script that converts my 2-button trim wheel (up/down) to 4 virtual buttons (slow up, slow down, fat up, fast down). The easiest way to control the trim via buttons is how you previously had it, assigning to the trim offset with a suitable inc/dec and on repeat. If you want the trim delta to change depending upon the button repeat (or how long you are holding the button), you would have to do this using lua. For example, you could adapt the 'generic triple use lua for buttons' script (available in the User Contributions section) to have a slow inc/dec on a single button press, a larger (repeated) one on a long button press. Alternatively, some folks like to use compound conditions, so that the delta is small (128) when you click the buttons on their own, but increases if you click when you have another button (or key) pressed, then this triggers the same control but with a larger delta (i.e. 256). You can do it this way using compound assignments, explained in the Advanced User guide.
  12. I'm not sure why it adds that again, as you don't have any assignments anywhere to a device A. You can try deleting it again, although it may/probably re-appear. Its nothing to worry about. These are due to some invalid registry entries for both your Razer Tartarus and Orbweaver. If everything is working. I wouldn't worry about it too much. If you want to try and resolve, you would need to disconnect the devices, remove all the registry entries for those devices and then re-connect and re-install. However, if you did this, your ini may need correcting again (if the GUIDS change), but hopefully not.... John
  13. Your log shows the lvars having the same values as the sim shows, except for ASCRJ_VAR_AP_SELHDG: 113766 [INFO]: ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000 113766 [INFO]: ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000 113766 [INFO]: ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000 113766 [INFO]: ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000 113766 [INFO]: ID=1557 ASCRJ_VAR_AP_SELHDG = 0.000000 113766 [INFO]: ID=1558 ASCRJ_VAR_AP_SPDTREND = 0.000000 That looks to have the correct value in the log you showed. I don't understand how the sim can be showing a different value for ASCRJ_VAR_AP_SELHDG (assuming the screenshot was taken at the same time you listed the lvars)- FSUIPC treats all lvars the same, it just receives the name and value from the WASM, so if the value is 0 that is what the FS is sending. I also don't know why I don't see those lvars in the CRJ700 - I'll take another look next week.
  14. Please show me your FSUIPC7.ini and FSUIPC7.log file, showing me your issue, i.e. with the LvarOffset section populating offsets for the lvars you say are always 0, together with your monitoring. Also, please issue a Add-ons->WASM->Log Lvars command, so I can see what lvars are available. I've just taken a look at the AS CRJ 550ER and I get 1752 lvars, and in the AS CRJ700ER I also get 1752 lvars, but I cannot see the lvars L:ASCRJ_VAR_AP_SELHDG or ASCRJ_VAR_AP_SELIAS in either aircraft. Are you sure they exist? If they don't exist, your FSUIPC7.log should show an error when trying to access them. John
  15. I don't know where you got that impression from. It is quite clear on SimMarket, in the download forums here and on www.fsuipc.com which product is for which FS. You can also download and try-before-you-buy. There is a strict no refunds policy (SimMarket) as we do not do on-line license validation, so once a license has been issued it cannot be revoked. It is not possible to transfer a license. However, if you let me know your order number, I will verify your purchase and generate you a complimentary license for FSUIPC7. This may take a few days. In the mean-time, you can use the trial license, available here: John
  16. Yes thre is. For anything relating to lvar access, set the loglevel ini parameter to Debug or Trace. You can also activate different logging levels in the WASM if you so wish. Other logging (i.e. FSUIPC) is controlled by the FSUIPC log flags. All software has bugs....I'm sure there are some in the I/F I have provided, but certainly not anything related to anything you have so far posted... I don't understand this rant. I really don't understand what your current issue is, it seems to vary from post-to-post. Maybe you could clarify. But, as I keep saying. I know nothing about the c# client dll, that should really be your first contact for support if that is where you have issues. If its with the lvars-to-offsets, then please post in this forum, but do not confuse the two completely separate pieces of functionality.
  17. I don't understand this so cannot advise. As I keep telling you, for anything related to c#, use Paul's sub-forum. Yes, if you omit the size, it defaults to an 8-byte double. But are you sure that is a valid lvar? i.e. is it listed when you log the lvars? It doesn't appear in the MF spreadsheet in the ASCRJ tab... Note also that some lvars are read-only, so you cannot change their value. You seem to be keep coming back with more issues when the topic for this issue is now closed as far as I can see. Can I lock this topic now? If you have any other issues, you can create a new topic for that issue. John
  18. Yes, you can do that. However, there is a limit on the index number, so be aware of that. I think it should be ok up to 2099... As a side note, I have been thinking about this issue for a while now. I am thinking of implementing an 'include' directive. So, you could do something like: [Buttons] (or [Buttons.<profile name>] Include=G1000 1=/// ... [Include.G1000] 1=... However, if/when I implement this, it will still be a manual process to: - create the include section. Basically, once you have assigned all functions to a specific item, you would need to manually remove these and create the include section yourself - You would then need to manually edit your profile section to add the include directive And I need to consider how to handle conflicts - should they augment or replace? And more complicated when you consider the general sections + profile sections (currently axes assignments replace, button + key assignments augment). There is also an issue with lvars - they really should be a/c specific, not profile specific. I will also add a mechanism so that lvars can be a/c specific, so that different LvarOffsets sections can be used for different a/c within the same profile. However, please note, I am not doing any development at the moment. I am on a holiday at the moment (or sort of...). I am only covering support and implementing bug-fixes. I am leaving any new development until mid-September . I will advise if/when I get around to looking at this in detail. Cheers, John
  19. All offset addresses map to a physical memory area. Well, in most cases. There are a few offsets that are ghosted, i.e. mapped to a different memory area. However, this is only for a couple of specific offsets and does not apply to the free user offsets. These ghosted offsets are used when the offset size has increased but there is no space left in the standard offset area to increase the size.
  20. Yes, of course. You have to do this for 2 reasons: - if you used A001, for example, then you would be overwriting the 4bytes set in A000 - 4-byte values must be aligned to a 4-byte boundary Yes, it matters. If it didn't, you wouldn't have to specify (and everything would be 8-byte doubles). You don't need to specify if its an 8-byte double, as that is the default. John
  21. Those switches are outside the 32 button limit (0-31) supported by FSUIPC4. To use these, you need to use lua. Please see Hard-programmed how? If you've disabled controllers in FSX it can't be in FSX. If assigned in FSUIPC, you can clear them. However, note that if you have multiple assignments to those switches, they cannot be cleared by using the UI. You need to edit the FSUIPC4.ini file directly to remove the assignments. John
  22. Try changing your[JoyNames] section to the following: Also, please update to the latest FSUIPC6 version, v6.1.4.
  23. No, they are normal and can be ignored. They are messages from the WASM interface (WAPI) produced when trying to close down the connection to the FS gracefully by clearing the simconnect client data areas (CDAs), but the FS (and simconnect connection) is already closed/killed.
  24. Yes, that would have been the issue. However, I'm surprised that there were no FLAPS_INCR or FLAPS_DECR controls logged as well, coming from FSUIPC, which is why I asked for the additional logging. However, if its now working then there is no need, but still strange... John
×
×
  • 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.