Jump to content
The simFlight Network Forums

CrazyKidJack

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by CrazyKidJack

  1. 5 minutes ago, John Dowson said:

    So yes, you are correct.

    I think the simplest solution in your situation would be for you to temporarily give your user account admin privileges (uninstall first). Then re-install, then remove the admin rights.
    I have put this on my list to look into, but this will take quite a while as it is low priority.

    Yes by my understanding, this could work. Might be more elegant if there was a way to determine the "actual user" instead of the "effective user" in the installation process. If not, then maybe just allowing the user to select to which folders they want things installed?

    In my personal development, I try to avoid the user-specific folders as much as possible for this very reason. I pretty much only put things in user-specific folders during runtime of the application, and only if the user requested it (like having different settings for each user on the computer). So during installation my apps will basically install everything into "Program Files/myProg" or "Program Files (x86)/myProg" depending on whether it's 32 or 64-bit compiled, and then at run-time I'll save user-configs in user-specific folders... but everything done at install-time happens in "Program Files". And even at run-time, I will often give the users the option to save config files "for every user" (which really just means in the installation directory instead of the user-specific folder.

     

    I don't know if my approach is the "proper" way to do it... but I find that I avoid a lot of problems by handling it that way.

    I have also considered taking your approach, but using the "Shared" folder system instead of the user-specific ones... I have not actually done this before but I've considered it

  2. 7 minutes ago, John Dowson said:

    But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before.....

    I would be happy to hop on a video call with you to show you what I'm doing and how my accounts are set up so you can understand the problem.
    You can almost certainly replicate it yourself if you create an account on your modern Windows computer *without* privileged access, and fresh-install FSUIPC.

    What should happen is you get a Windows UAC prompt asking you to type in the password for one of the privileged accounts on the machine. Whichever privileged account you select and type the password for, all of the data that FSUIPC installs will install under that user. So when you try to run FSUIPC as the non-privileged user (or even a *different* privileged one), things will not work as expected.

  3. Just now, John Dowson said:

    But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before.....

    Like I said... I think most people give their personal accounts privileged access (this is actually the default in Windows) and so they wouldn't run into this problem.

    For those that *don't* have privileged personal user accounts on their computer, they may have simply never reported it because users that have the knowledge to know to *disable* privileged access on their accounts are typically more technical and so
    #1 probably deal with this often from other applications as well (as I have)
    #2 because they deal with it often, probably know how to fix it in most cases (manually copy/paste config files from the Admin user to their actual user)

  4. 6 minutes ago, John Dowson said:

    Try running the uninstaller manually (from the FSUIPC7 installation folder or the Windows App management panel) and re-install again, to see if it picks up your correct Documents folder.
    And show me the new InstallFSUIPC7.log file please. Your Documents folder is taken from the registry for a fresh install, using the HKCU Personal key under "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"

    I can try uninstalling/reinstalling like you are saying... but I'm fairly certain I will get the same behavior for the reason I specified above (the installer is using the "Effective user" to determine folder/file locations)
     

    7 minutes ago, John Dowson said:

    Due to these errors, there may be some other empty folders that have been created that you may want to move:
       Create folder: \fsuipc-lvar-module
       Create folder: \fsuipc-lvar-module
    although those may have failed....

    It looks like these failed because I can't find them

  5. 3 minutes ago, John Dowson said:

    Not sure why thiis is either. Did you install the first time as admin?

    No but see the edit to my previous comment. Specifically this part:

     

    34 minutes ago, CrazyKidJack said:

    However, on my system (and I'm sure some other people's and probably yours... though I think we are in the minority) my user account is not called "Admin" and does not have Admin privileges. So when FSUIPC (and many other programs) install themselves, they ask for Admin privileges via Windows UAC. The problem comes when the installer uses the "Effective user" of the installer process instead of the "actual user". When it asks for admin privilege via UAC, the effective user changes to "Admin" even though I'm really installing it on MY account (jackp). But since the installer process is using the "effective user" to figure out things like where the %appdata% folder is... it always resolves to the Admin user's folders/files... when really it should be using the "actual user" information to resolve that correctly.

    So I didn't install as admin... but the installer process *thought* it was running as admin because it requested privileged access via UAC

  6. 1 hour ago, John Dowson said:

    Anyway, here's the WASM. Just extract into your Community folder and it will be recognised by FSUIPC:
    fsuipc-lvar-module.zip

    The other issue you will have though is that FSUIPC will not autostart with MSFS as it cannot find the location of your EXE.xml. Did you not notice this? Is it a problem?

    I almost didn't realize the detail in this comment.

    #1 Thanks for the module zip. I have extracted it as you said and the new Add-on menu item shows up now (yay!)

    #2 I didn't notice it wasn't auto-starting because I was using the "Desktop shortcut" batch file that your installer gives and I modified (as mentioned before). But with the EXE.xml file you gave me, it is now starting with MSFS 2020 no problem and with no need for the batch file! Thank you! 🙂

  7. 26 minutes ago, John Dowson said:

    Looks to be a space between your t and a (e.g 'AppDat a' as opposed to 'AppData', but maybe thats just your image/my eyes...

    Yah, I checked again just now. That space isn't real (but good eye for pointing that out!). For some reason that just how cmd is displaying it when I type it in.

     

     

    26 minutes ago, John Dowson said:

    Other than that. I have no idea why its not determining the correct location. It works for everyone else...very strange....

    I'm still thinking it's because FSUIPC is looking for things in the Admin user folders but all of my stuff is not there...
    For example, I think FSUIPC installed the documentation in the Admin user folders. I'm not 100% if it does anything else in the Admin user folder or if so, *what* it does... but I think this is probably the root of the problem. I think the majority of users don't have a separate Admin account. So while their account is not called "Admin" it does have Admin privilieges and so the FSUIPC installer doesn't have a problem and just uses their user's folders/files. However, on my system (and I'm sure some other people's and probably yours... though I think we are in the minority) my user account is not called "Admin" and does not have Admin privileges. So when FSUIPC (and many other programs) install themselves, they ask for Admin privileges via Windows UAC. The problem comes when the installer uses the "Effective user" of the installer process instead of the "actual user". When it asks for admin privilege via UAC, the effective user changes to "Admin" even though I'm really installing it on MY account (jackp). But since the installer process is using the "effective user" to figure out things like where the %appdata% folder is... it always resolves to the Admin user's folders/files... when really it should be using the "actual user" information to resolve that correctly.

     

    I'll do some trouble shooting later to confirm... but this happens for *many* programs that don't have a large user base. Programs from large development firms (like direct from Microsoft, or Steam, etc) don't have this problem and have figured out how to use the "actual user" instead of the "effective one" but most "smaller" applications have this problem.

     

     

    26 minutes ago, John Dowson said:

    Then I have no idea why this test is failing:

    
    
    
    IfFileExists "$APPDATA\Microsoft Flight Simulator\UserCfg.opt" steamUserCfg
        nsArray::Set LogMessagesArray "Determing Community folder for MS Store install"
    ...
        steamUserCfg:
          nsArray::Set LogMessagesArray "Determing Community folder for Steam install"

    Where are those lines of code? I do not see them in the MSFS.bat file that gets installed when the "Desktop Shortcut" option is selected in the FSUIPC installer

  8. 1 minute ago, John Dowson said:

    The problem, for your installation, looks to be that your APPDATA environment variable is not set correctly and the installer cannot find your UserCfg.opt file location. Can you check what this is set to? Should be 'C:\Users\jackp\AppData\Roaming'.

    My %appdata% variable is set correctly. In fact, that is how I access the Microsoft Flight Simulator folder every time because it takes too long to navigate to it from the top level

  9. 18 minutes ago, John Dowson said:

    You don't need the mobiflight wasm if using FSUIUPC, but you can use the mobiflight events instead of the fsuipc facilities if you prefer. You image shows that the FSUIPC WASM module was not installed. Looking at yout log file, it shows this:

    Quote

    ...
    Determing Community folder for MS Store install
    **** Cannot determine location of UserCfg.opt: Cannot install WASM module ****
    ...
    Updating EXE.XML for MS Store install
    **** Cannot determine location of EXE.xml: FSUIPC7 will not start automatically with MSFS ****
     

    Do you have an MS Store install or a Steam install? Do you know the location of your MSFS UserCfg.opt file?

    #1 I have the steam version. It is NOT installed as Admin which I think is the root of the problem.
    #2 My UserCfg.opt file is located at "C:\Users\jackp\AppData\Roaming\Microsoft Flight Simulator" which the is correct and default location. Again, I did not install MSFS 2020 as Admin and I do not run FSUIPC as Admin

  10. 13 minutes ago, John Dowson said:

    Offset area 03C0 is what FSUIPC maintains for button presses. You can/should  NOT wtite to it, by any means, either directly. You cannot set a button flag on a joystick tat doesn't exist. Please just forget this offset for your issue.

    Again, I am NOT writing to those offsets.
    But setting button flags on a no-existent joystick worked great if I wasn't trying to use an offset condition. See the following lines:
     

    [Keys]
    16=50,8,1003,3842 ;set flag 2   -{2: Press=: Joy 15 Button 2 }-
    110=88,8,1003,3848 ;set flag 8 (Xpndr)  -{X: Press=: Joy 15 Button 8 }-

     

    [Buttons]
    95
    =CP(F+15,8)(F+15,2)64,12,C65652,0 ;xpndr flag, flag 2, incr   -{XPNDR_100_INC}-

    In these examples, I'm setting the button flags for joystick 15 buttons 2 and 8 and reading those flags using button conditions (there is no devices assigned to joystick 15 in the [JoyNames] section. It only doesn't work with offset conditions.

  11. 1 hour ago, John Dowson said:

    Sorry, I wasn't going to, but I would also like to comment on this:

    8 hours ago, CrazyKidJack said:

    Because I know that you always complain when people do not *thoroughly* read the documentation and forums... I

    I think that is far too strong. We provide documentation to hopefully reduce the time spent on support, which takes away from development, bug-fixing, and other activities that are more productive and useful (and also more interesting) than repeating things said many times and also documented. We don't expect a *thorough* reading (who has time for that with all the software/hardware you need to install these days!), but a quick look to know what's available and a review of the user' manual is always a good idea. Then, use then as needed to help you, depending on your knowledge of flight sims and maybe earlier versions of FSUIPC. And if you have an issue or need more specific information, you should consult the Advanced guide or the specific guides for using lua, PMDG aircraft or offset use. If you can't find anything there, then try a quick search of the forums, and maybe look in the FAQ section, or User Contributions if something extra thats not provided. All we ask is that you try to help yourself first, using the provided resources, before asking. The answer may be deep in the documentation somewhere and not easily found - it is far from perfect I'm afraid....!

    8 hours ago, CrazyKidJack said:

     I also know you prefer to help people that have a solid technical understanding, so I wanted to let you know I have over a decade in software development, a Bachelor's in Comp Sci, and am OSCP certified.

    I have no preference whatsoever on the technical understanding level of the people who post for help. Many people who post here have a far better and deeper understanding of aircraft and aircraft subsytems than I do (or probably ever will), and there are far better lua programmers/experts on here as well. I would certainly never judge a persons technical understanding on what they post, as they are often posting to learn anyway, regardless of ability or previous experience, and am not interested in any qualifications, technical or not, of any poster.

    I wasn't trying to "come at you". I just noticed through reading the forum on my own as a user and paying customer of your product, that there were several posts with what I understood to be passive aggression toward people who, in your opinion,

    1) Were having trouble understanding your responses due to a lack of technical proficiency and/or
    2) Had not spent "enough" time reading through the documentation.

     

    Since I noticed this, I felt uncomfortable using the forum which is why I waited so many days to reach out in the first place.
    And then when I did finally post here, I wanted to quickly and decisively put your concerns to rest. I don't expect you to care about my credentials, I just didn't want you to feel that I wasn't qualified to understand or use your product.

    Additionally, while I spent a lot of time reading the docs... I think it should be noted that the documentation itself is quite technical (if you don't have a technical background) and I could understand how, presented with literally hundreds of pages of documentation, a tech-novice would give up quite quickly and look for a "simple stupid" answer from a human on the forum instead of trying to decipher the documentation.

  12. 35 minutes ago, John Dowson said:

    Your offset conditions are not correct:

    14=DA000&200 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

    You need to add the condition. To check the bit is set, use:
        14=DA000&200!0 49,8,66502,1 

    i.e. check the flag is set:
     

    Quote

    <condition> is one of:
        =value for equality
        !value for inequality
        <value for less than
        >value for greater than
    and the “value” here is
    decimal unless preceded by an x (or X) in which case it is hexadecimal like the offset and mask. FSUIPC will output hexadecimal where a mask is used, otherwise decimal. All values are treated as unsigned.
     

    The optional mask facility is useful for testing specific bits, as in the case of the light switches in offset 0D0C or the
    radio reception details in offset 3300. For example, the offset condition:
    W3300&0040!0
    is TRUE when the currently tuned NAV1 is for an ILS.

     

    Expand  

    And here:

         14=D66C0 49,8,66502,1 ;vor flag&setting flag 1     -{1: Press=AP_NAV_SELECT_SET }-
    As documented, the format is:
      

    Quote

    The format of the condition is:
        <size><offset><mask><condition>

    You have the '<size><offset>', but not the '<mask><condition>'

    According to the documentation  (and indeed also the automatic re-writing of the .ini file when FSUIPC is started) I think you may be mistake (though you obviously know more about it than me so please correct me if I'm wrong.
    Here's a screen shot from the documentation talking about how the mask and condition are optionalhttps://prnt.sc/12kyqf3

    The documentation says that the condition will default to "!0" if it is omitted... this is the exact behavior I want... in fact, if I actually type out "!0" FSUIPC re-writes the .ini file on startup and REMOVES my handwritten condition

     

    Additionally, the mask would be important if I were writing to any other offset in the DWord, but I'm not. Now... I did try to use the mask... but as I was running into problems I tried to remove as much as possible from the condition for troubleshooting... since then I got the 66C0 offset working (as I stated) and because it was working, I added the mask back in (though I still can't add the condition because FSUIPC will just over-write it anyways)

  13. 5 hours ago, John Dowson said:
    8 hours ago, CrazyKidJack said:

    With that said, if you think the beta will actually add functionality that will help me with my goal here, please let me know.

    Yes, you should use that. Not just for the 128 buttons, but also for the lvar/functionality. It is pretty much complete - I just need to update the documentation (and add a minor fix to event.button for buttons > 32) and will release this officially soon, hopefully at the weekend.

    5 hours ago, John Dowson said:

    Note also that all MF events are based upon activating hvars or setting lvars, which you can do now directly in FSUIPC7 with the FSUIPC WASM module installed. You can install both WASMs (MF + FSUIPC WASMs) if you like and try both methods to see which works for you.

    6 hours ago, CrazyKidJack said:

    Nevertheless, according to this post once that is all installed, I should have a new entry in the "Add-ons" menu in FSUIPC for LVar accesss... but I don't see it. What am I missing?

    You should have a WASM entry under the Add-ons menu, where you first need to activate the WASM functionality (you do this once).
    Did you select to install the WASM during installation?
    If so and its not there, please show me your InstallFSUIPC7.log file.
    Also check your MSFS community folder. FSUIPC7 only adds the Add-ons ->WASM entry if it can see the FSUIPC WASM folder fsuipc-lvar-module in your MSFS Community folder.

    I did select "to install the WASM" during installation of FSUIPC.
    I also installed MobiFlight Connector, enabled beta updates, updated, and moved the "mobiflight-event-module" folder into the Packages>Community folder of MSFS 2020 as seen in this screenshot: https://prnt.sc/12ky7du (I would have just attached the image file instead of giving you a link that you might not trust, but it the forum said it was too big)

    Despite installing both of these, I don't have the "WASM entry under the Add-ons menu".

    I have attached the InstallFSUIPC7.log here...
    Now that I am looking through the file myself, it seems that FSUIPC assumes it should install things in the Admin user folders... Now that I think about it... I think I did have to rectify that situation when I originally installed FSUIPC (remember that I just installed the beta version last night... so perhaps my problem regarding the WASM Add-on menu is simply because I haven't moved the files to the appropriate non-Admin user folders... though it would be a nice feature add if FSUIPC didn't assume everyone wanted to run everything as Admin 😕 This is a common problem I see with a lot of applications that the more security conscious of us have to deal with... I will try to move those files/folders to the appropriate non-Admin user directories and see what happens

     

    InstallFSUIPC7.log

  14. In regards to offset A000 and your comment 

    37 minutes ago, John Dowson said:

    Sorry, was confused by this in my previous response (with another support request...). Yes. that offset should be working. I'll check your ini....
    Could you also supply a log file please, with only buttons & keys + Events logged.

    I will get you the log file asap. Though be advised that it will be very long if you want me to log events. The HC send continuous input for many of it's buttons so any of those buttons that are mapped to a control constantly register events. I found that opening the log file in a text-editor with regex based searching (like Notepad++) can easily filter out the lines of the log that you don't want though...

    Log file coming ASAP (though I'm working so probably a few hours)

  15. 4 hours ago, John Dowson said:

    Yes, but that is for reading. If you check the FSUIPC Offset status document (and column L of the spreadsheet), you will see these offsets are read only and cannot be written to (No in last column):

    Perhaps I should have been more clear. I'm not trying to set the value of the 03C0 offsets directly. If you look closelier at the .ini line I used, I'm not setting that offset directly, I'm simply pressing the associated button (actually... I'm using the control to set that buttons flag... 1003). By my understanding that should change the offset to reflect that the button was pushed except for this:

    4 hours ago, John Dowson said:

    Note also that those offsets are only populated for a joystick if/when there is at least one assignment to that joystick,

    Again in my initial questions I said:

    8 hours ago, CrazyKidJack said:

    it seems that FSUIPC only updates those offsets if there is an actual device assigned to the joystick whose offset I'm trying to read

    I couldn't tell exactly from this post 

    whether or not "when there is at least one assignment to that joystick" means "when there is an actual device in the [JoyNames] section mapped to joystick number matching the offset I'm trying to read... OR if it means "when there is an entry in the [Buttons] section that uses that joystick as the trigger". Since I wasn't sure and I can't force a particular device to be assigned to joystick number 15 (or at least, I don't know how to force that assignment) I tried to add an entry in the [Buttons] section for with joystick 15, button 9 as a trigger with the "no-op" control and it still didn't work. Because of this, I assumed that you must've meant "when there is a [JoyNames] assignment" as opposed to a "[Buttons] entry". Perhaps you could verify that I'm correct about this.

     

  16. Another update:
    #1 I installed the latest beta of FSUIPC (v7.1.0f), the mobiflight stuff, and created a .evt file for the G1000 events from mobiflight. The events show up as possible selections. Great! However, I also discovered through the event logs how to change the CDI in the G1000 to whichever indicator I want using non-mobiflight events... 🤦‍♂️

     

    #2 Nevertheless, according to this post once that is all installed, I should have a new entry in the "Add-ons" menu in FSUIPC for LVar accesss... but I don't see it. What am I missing?

     


    #3 Regardless of any of that... the A000 offset is still an issue and I'm wondering why it wasn't working for me still

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