jsmarko3

Whoops. Thanks for the callout. Sorry, first time using InputEvents, so I thought the fact that they were being called out as Float64s in the logging was significant despite the value being only 0-5. I think my biggest holdup with the UBs was the limit; I saw the footnote in the advanced users guide but not any practical examples, but now I understand why when binding it through the UI it would add the /0 to my parameter and why the limit in the .ini file was saying 0 and why it failed to increment. I can move the magnetos up and down at will. I think I'm sorted, thanks again John.

Stumped on the Input Event as Offset route. Adding the Input Event as the Offset was easy enough, but I cannot get it to increment as I would expect it to. Here is a screenshot of the console since it won't let me copy the text: This is what I have in my profile to add the Input Event Offset: [InputEventOffsets] 0=BKSQ_MAGNETOCONTROLLER=F0xA0000 And here is the resulting button binding after trying to use the Float64 Offset Inc/1000 2=PA,7,Cx7C00A000,x00000001 -{offset float64 inc/1000, offset A000 (0.001000)}- In this case, I copied the binding from my second attempt seen in the log, where I enter the parameter as 1 (which I want to increment by). The first attempt had the parameter set to 1000 since it says it is going to divide by 1000 in both the Advanced Guide and the offset name itself. The problem is that I cannot get it to increment by any sensible (to me) value. I have tried all sorts of different values, trying to figure out how to convert floats to hex, etc., and I either get an increment value of 0, which seems to just set the MagnetoController back to 0, or some unholy large number which causes it to shoot all the way to the start position. I need it to increment from 0.0 to 1.0, to 2.0, etc.

I spent well over an hour learning a very valuable lesson on what exactly the leading > before an LVar means and does, but I think I'm well on my way. Need some help from Nick at Black Square about the magnetos not responding appropriately, but once that's solved I think I'm pretty much set with this. That's why I'm surprised the in-sim bindings work, but sending the K events directly does not, but again, a question for Nick.

I did and you are correct, it did not work either. I edited the post a minute or so after I posted it to say this, but yes the Pro has the same named variable with a similar range. That does work. I have asked Nick on the Just Flight forums if he has any insight as to why the magneto K event would not work while I have a handful of other ones I tried that do work. Using the LVar is possible; I could write something right now to set it to a specific value, and I may do that myself in a few days when my button box and key switch arrive, but for an increase/decrease function I would need to get smart on scripting to check what it is set to and where it should go. I will likely put some thought and man-hours into trying to log it as you suggest; someone in a different topic on the JF forums mentioned he used some in-game developer tools to see what variables are changing, so I have a few options to go down that rabbit hole. B events are something I never touched, but I see there are few listed in various Black Square manuals as variables you can manipulate, so I may end up needing or wanting to learn them down the road. EDIT: and as always, thanks for the help.

For the Black Square Bonanza Pro specifically, no, but in the events.txt file I did find one for just MagnetoIncrease#(>K:MAGNETO1_INCR) or named similarly, I don't have it handy in front of me to look. The same LVar does exist in the new one, but I'm not knowledgeable about about scripting with RPN to try to make an increase/decrease function while having to set specific positions. Thanks for the link to the RPN part of the SDK, I'll have a look, and I'll talk more to Nick at Black Square about event implementation.

I have FSUIPC v7.5.4 installed along with MSFS 2024. I am working with someone on the Just Flight forums to help them bind a few things with FSUIPC, and for the life of me I cannot get Magneto1_Incr or Magneto1_Decr to work, at least in the new Black Square Bonanza Pro. I've not yet tried with other aircraft, that's been the one I've been focused on for the past few days. I suppose that's probably the next step. Magneto1_Incr is one of the stock FS Controls offered by FSUIPC, so it should be as simple as binding that to a button, but for some reason the magnetos in the aircraft are not responding. I have tried doing it via the Asobo control binding, and it works if I bind the button to Increase Magneto 1 there, but for this other user's purposes that's not a solution. There is also a Magneto 1 Incr event included in the Mobiflight presets that also does not work, which is probably unsurprising as I'm sure it does the same thing. Since it works via the Asobo bindings I'm very surprised it doesn't work via the FS Controls (I remove any conflicting bindings between tests). Even using Execute Calculator Code with (>K:MAGNETO1_INCR) is not working (again, perhaps unsurprisingly), but I have been able to manipulate other K events through FSUIPC, such as the Kollsman increase/decrease, the battery switch via BATTERY1_SET, so I don't think it's a problem with my technique. Black Square is fantastic about documenting his usage of variables in his manuals, and K:MAGNETO1_INCR is specifically called out for magneto control, along with an LVar for setting it to a specific position instead of just up or down. Since it also works through the Asobo bindings, and I dug through the online SDK to confirm that K:MAGNETO1_INCR is what it should be, I feel pretty confident that calling Magneto1_Incr or the premade event through FSUIPC should also do the trick, and yet it isn't. For both this other fellow to refuses to use anything but FSUIPC for controller bindings, and my own budding understanding of how to do advanced (and perhaps basic) functions in FSUIPC, does anyone have any thoughts on why certain K events are not working? Semi-related: what language or formatting are events written in? I am familiar with the RPN portion for at least math, but my eyes very quickly glaze over when I get to some of the examples with various if statements or even simple things like one that had "near" before the min and max. I assume that's some sort of rounding function, but any pointers to what language or style, or some documentation there of would be appreciated. Thanks!

Yep, that fixed it. I moved the livery names to the right .ini file and everything started as it should. Thanks for the help with all this, I'm on my way now!

Oops, that one is 100% user error. No, FSUIPC didn't do that, I did. It created the profile files but left that in the ini and I said "why is this still here?" and moved it. That would probably explain why it seems like it forgets I have profiles at all. I'll fix that and give it a try. Sorry!

Hi John. Attached is another log file, as well as my adjusted INI file and the MD82 profile I'm working on. The profile is identical to the CRJ one with the exception of the livery name and the specific lua script called. Again, it doesn't seem like FSUIPC is reading the profile INIs with UseProfiles=Files. I am, however, starting FSUIPC after MSFS is running when testing this (mostly). It auto starts with the sim, however as I've been making changes I have been closing it and then restarting it. I do run it as an administrator; I need to run MSFS like that for several add-ons. I assume FSUIPC usually starts as an admin since the sim is launching it, but when I manually close and reopen it, I make sure to choose run as administrator for that reason. I just switched back to my old INI file (and renamed my Profiles folder, otherwise it keeps setting UseProfiles=Files), and it works like a charm, so something about reading profile files is funky for me. The one thing I will remember to do is to set up the profile files again BEFORE I start the sim, I'll let you know if that works so maybe the problem is with me restarting FSUIPC while everything is running. FSUIPC7.ini FSUIPC7.log MD82.ini

Hi John, I was indeed modifying the ini files while it was running, so that could be the cause. I'll give this new version a try and go back to using profiles and see what happens. Is this an installer, or a replacement for the exe?

Thanks for all the help John. I would have thought that using individual files would be the preferred method so as not to clutter up the main ini, but since I don't have much at this point it would be easy to change back over. If you're thinking if deprecating that functionality, I can do that going forward.

John, Sorry for taking up so much of your time with what should have been a simple issue. I believe I have finally solved it. It looks like there might be a problem with UseProfiles=Files, or maybe how I had them formatted. FSUIPC looks like it would create profiles as files ok, and maybe even update them, but it doesn't seem to want to load them when it starts fresh. I was noticing, based on my inability to read that offset I had set and opening the button binding window, that when I would start a fresh instance of FSUIPC it was not loading the CRJ profile. I say fresh instance because when I made changes to the script, ini file, whatever, I would close FSUIPC and reload it, unsure what it does and doesn't auto detect. I promise I wasn't trying to run it multiple times. I have put the few lines that were in the CRJ.ini file in the FSUIPC.ini file and removed UseProfiles=Files and not only can I monitor the offset, but now the simvar is being properly updated as well. Works like a charm and PACX is now registering the proper seatbelt sign values based on the seatbelt sign switch in the VC. I am attaching my files (I can include the log if you would like it, but it's currently still running while I tinker) in case they help debugging UseProfiles=Files, or the more likely case where it's a formatting issue on my end. FSUIPC7.ini CRJSeatbelts.lua CRJ.ini

I think I'm having profile issues for some reason. I've tried monitoring the offset I still have set in my CRJ profile, A000 for the CRJ seatbelt var, and I don't see that being updated despite seeing the LVar change when I repeatedly List LVars. I tried running the calculator code and monitoring offset 341D which was unaffected. PACX did change it when the boarding doors were closed, so that is the correct offset/variable. I have PACX change it automatically during critical portions of the flight until I figure this out, but just in case that was somehow interfering I turned it off. Still no effect. I did try rewriting the lua script using writeOffset instead of execCalcCode, but with the fact that I'm not sure my lua is running and/or having profile troubles, that didn't surprise me. EDIT: Alright, now suddenly the A000 offset for the CRJ seatbelt sign variable is reading appropriately, maybe now the lua script will run. I did have to reinstall the CRJ, maybe the profile was corrupted. EDIT2: Nope, not working again.

I'll give that a try and report back. Last night I did try dropping 1 (>A:CABIN SEATBELTS ALERT SWITCH,bool) into the Exec Calculator Code window under the WASM menu and that didn't have any effect, unsure if that means anything.

Hi John, I took a first crack at a lua script to do the job, but I don't think the lua script is actually running. I have Lua Plugins and Log Lua Separately checked in the Log menu, but I'm not seeing anything other than the standard FSUIPC log. I use the Profiles as Files option instead of having it all in the ini file, so when it didn't seem to work putting [Auto] in the CRJ.ini file I tried putting [Auto.CRJ] in the main ini file, but that didn't seem to work either. I have attached the four relevant files in the hopes that something is obvious to you that it isn't to me. FSUIPC7.log FSUIPC7.ini CRJ.ini CRJSeatbelts.lua

John, Apologies, I believe I might have worded something incorrectly. Just in case this changes the direction I need to go, I am not trying to set anything in the CRJ. I plan on using the switch in the virtual cockpit to toggle the seatbelts, but this does not update the simvar. PACX reads the simvar, and thus cannot tell when I have the seatbelt signs on or off, so I'm looking to read the CRJ switch value and then set the simvar based on that. I am uncertain if it is trying to read the variable or an offset (not that I really understand the difference tbh), the only nugget I have to go on so far is this: https://forums.tfdidesign.com/index.php?/topic/5716-seatbelt-state-question/ To my untrained eye, it looks like he's setting the variable and not an offset, but it wouldn't surprise me if I'm wrong. I assumed I would need to set an offset, as I have tried LVar manipulation in the past (I acknowledge these are different things so the results might not be the same) and not had any results until I started using offsets, so I went digging through the provided offsets and found you have already assigned it 0x341D. I did find the above referenced topic on the A320 parking brake and will read it, and also that there is an example lua for the spoofing function included with FSUIPC. Regarding the documentation, yes, I have the latest version installed, or at least no more than 2-3 weeks out. I was asking specifically about download locations for it since I was hoping to do some reading while away from my PC, but the download link here on the forums here is what is dated January 2021.

Thanks for the pointer John. Oh boy, that's quite the mouthful, but I haven't cracked the lua portion of the manual yet so I'll take a look at that. It's not the aircraft that I want to use the simvar, though, it's an external app called PACX that reads that var to determine the seatbelt sign status. Is there an updated version of the manual available for download anywhere? I'll be away from my PC with my FSUIPC installation for a while but I'd like to start reading up on lua, and the link here on the forums is from January of '21, at least the advanced user guide was.

I've found that a lot of third-party planes for MSFS don't set the standard seatbelt sign variable, so PACX doesn't pick up on it. I'm trying to fix this using FSUIPC as the bridge between the LVars and the simvar, but unfortunately, I'm in way over my head with all of this. I'd like to think I'm a technical guy, being an engineer and all, but I must be lacking some very basic context on how this all works under the hood because I'm not understanding most of the advanced user guide at all. Tthe main problem: I'd like to set CABIN SEATBELTS ALERT SWITCH, a bool, which looks to already have an offset of 0x341D, based on the position of the Aerosoft CRJ seatbelt sign switch. The LVar for that is ASCRJ_OVHD_SEAT_BELTS, and it has three possible values: 2 for On, 1 for Off, 0 for Auto. I have successfully mapped it to an offset (UB0xA000) and I can read it no problem. At this point, though, I'm not sure what my next step would be. I don't want to assign it to a button or an axis, I would like it to update the simvar whenever the LVar is updated. I have had some limited success with other aircraft mapping axes to offsets to control things like oil coolers, but I don't see a way to just update one var from another. I could try assigning ASCRJ_OVHD_SEAT_BELTS just to 0x341D and see what happens, but given that it has values of 0, 1, and 2 I don't expect it to work very well. I have also discovered, from perusing here, the Mobiflight events list that comes with FSUIPC, and there exists a set for the CRJ, including some code for the seatbelt sign: 1 (L:ASCRJ_OVHD_SEAT_BELTS, Number) 0 == if{ 1 (>L:ASCRJ_OVHD_SEAT_BELTS, Number) } els{ (L:ASCRJ_OVHD_SEAT_BELTS, Number) 1 == if{ 2 (>L:ASCRJ_OVHD_SEAT_BELTS, Number) } els{ (L:ASCRJ_OVHD_SEAT_BELTS, Number) 2 == if{ 0 (>L:ASCRJ_OVHD_SEAT_BELTS, Number) } I didn't find the advanced guide very helpful in either deciphering what this does, how to use it, or if events are something I would want to use for this purpose. Given all of that, what path do I want to go down in order to do this seemingly simple task, and where in the documentation should I start? Thanks for any and all pointers. -Joe Markowski