John Dowson

No problem, easy to miss. As long as its working how you would like it to work you should be fine. No time wasted, cheers, John

Have you added any .hvar files to the WASM installation for the aircraft that you are using? If so, I also need to see your FSUIPC_WASM.log file (with Debug logging enabled). If not, please see the Advanced User guide on how to access/use hvars. Some hvar files are provided, in a subfolder called HvarFiles, under your FSUIPC7 installation folder. However, you need to move these to the correct location, and also rename for the aircraft that you want to use them with. Btw, I moved your post to the FSUIPC7/MSFS support sub-forum. Also, you are using an old version of FSUIPC7, v7.2.2. Please update to the latest version, v7.2.8. Only the latest version is supported.

Hi Reinhard, that does look strange, but I need to see the full log, not just an extract. Can you a;ways attach the full log as well in future please (and keep logging for Buttons & Keys, Events and Lua Plugins active, as well as monitoring the offsets to which you have attached an event.offset call). Also useful if you attach the actual lua script (so the logged line numbers correspond). Not sure I understand that log extract - could the button have been triggered (did you have button logging activated)? Again, please attach your full .log file. Did you test with just running this one module? If not, try to do that (i.e. exclude other modules for now) and, if the problem still persists when running just the one module it should be easier to track down. I'll do some tests here with multiple button and offset events registered in a lua (using one of my GF devices as well), to see if I can replicate any of this behavior. John

Yes, that makes sense as it also needs to initialise with the current value, as with event.offset, although it isn't mentioned in the documentation. I will update when I get a chance. Cheers, John

But this should not happen with event.button, only event.offset. Not sure what you mean by this...I will wait for your post in the other thread... If it is, it should be documented as such. event.button should not initialise, I haven't checked the others. Cheers, John

The event.offset function is documented as such in the FSUIPC Lua Library.pdf: So this is intended behavior. John

I'm not sure its by intent, and if it is it should be documented as such. I'll take a look at this later and get back to you. John

I'm not sure I fully understand...Do you mean on your physical throttle? So you would like to calibrate to use only the forward range on your throttle? If so, you can calibrate your axis value in a similar way as you would reverse them - see the section Additional parameters to scale input axis values in the Advanced User Guide (P38). Do you mean this thread: ? If so, I also mention this there. If this is not your issue, could you clarify please. In fact, it may be better to use that previous thread, as this may (hopefully) attract other DC-6 owners/users. Its also good to keep info about DC-6 throttle set-up in one thread.

That implies that you are not using a registered version. Re-install, and make sure you click the Register button towards the end of the installation process, after you have entered your registration details. John

No problem. Note that there is also documentation in French, but for FSUIPC4 (inly) - most (or a lot) of it should be applicable, but some things not. Available from the Downlinks -> Documentation section: John

There is a separate document for Profiles in Separate Files - this is the relevant part: Oh - and do not manually update the [LuaFiles] section - that is maintained by FSUIPC from scanning the installation folder. John

You are using UseProfiles=Files i.e. profiles in separate file. Your [Auto] section should therefore be in your FLYBYWIRE.ini file, and called [Auto] and not [Auto.FLYBYWIRE]. John

To determine where your Community folder is in a steam installation, you need to look in your MSFS UserCfg.opt file, which for steam installs is under YOUR USER ACCOUNT\AppData\Roaming\Microsoft Flight Simulator\UsrCfg.opt Look for the last line, which is your InstalledPackagesPath - the Community folder sit under there. If you are using FSUIPC7, it is also logged in your FSUIPC7.log file, at the beginning as the FS (or FS UNC) path. John

I have moved your post from the .net client dll support forum as it seems your questions are more related to FSUIPC offsets than anything to do with the .net client. To find an offset, please use the Offset status spreadsheet, included in the FSUIPC7 download zip. In that, you can find the brake left and brake right position in offsets 0x0BC4 and 0x0BC6 respectively, as well as various other offsets (e.g. 0x3416 & 0x3418 for axes input values) I don't think this is available. Check to see if held in any lvars, or if using the FBW A320, maybe ask about this on their support/discord channel.

Ok, but I've just released 7.2,8 with a few memory fixes, so you should update to that - includes an update to the WASM as well. Yes, good idea - I will do the same! Yes, looks an interesting beast, although I'm not sure when I'm going to find time to understand and fly this a/c proficiently - I get very little time for recreational flying these days... Cheers, John

No problem. There are still possible memory corruption issues in that version due to excessively long lvar names (>56 chars). I've corrected this now (currently testing) and will release a full version (including a WASM update) later today. This will be the official 7.2.8 release. There will be some issues accessing lvars/hvars with more than 56 characters, and I'm not too sure how to handle this yet, so further work will be required. I will update the Advanced User guide with details.

The Assignments tab is only available in registered versions - you are running an unregistered version. You need to re-register (using the installer) to generate your .key file. If you don't have a license, there is a time-limited trial license available at the top of this forum. Not sure what you mean by this, but you also need to register your WideFS7 license during the FSUIPC7 installation process. So, re-run the installer and don't forget to register your license at the end of the installation process, by entering your license details and pressing the Register button. John

Looks like I messed up the UB conversion in that version - please try the attached: FSUIPC7.exe

What does not work? Please provide more information, i.e. is the offset populated and you just cannot update, or is the value not even populated? And please show me your log and ini files - required for any issue really. John

Asobo CJ4 or the Working Title mod? Have you tried logging events (with console window open) to see what events are used when you start the engine manually via the UI? Have you looked at available lvars (and maybe hvars) to see if any seem relevant, and the values they hold when you start via the UI? Let me know which version of the CJ4 you are using and I can take a look later - or probably tomorrow, as I have an urgent issue I need to look into today. John

The OPs issue must be with the code, as updating the offset does send the correct control (SPEED_SLOT_INDEX_SET), and it does have an effect - when the engines are running, as the related simvar (AUTOPILOT SPEED SLOT INDEX) is updated and the new value received and populated in offset 0x0298. If it was not possible to do this due to the aircraft state, the control would still be sent but would have no affect, i.e. the AUTOPILOT SPEED SLOT INDEX simvar would not be updated and no change in value would be seen in offset 0x0298. John

Found the issue. There was a memory issue as there are some lvars in the FBW A320 that exceed the maximum configured length of 56 characters, e.g. this one has 85: A32NX_ADIRS_ADR_1_INTERNATIONAL_STANDARD_ATMOSPHERE_DELTA32NX_ADIRS_IR_1_GROUND_SPEED i have corrected one issue that this causes (and you were experiencing) in the attached version, v7.2.8b, so please try this. However, such long lvar names may cause memory issues elsewhere, as I would expect such long lvar names to be truncated to the configured value, which they are not. I will therefore look into this further. John FSUIPC7.exe

Also not that using lvars directly, you can open the door with the canopy still closed, which you can't actually do in the UI. If you wanted to replicate this behavior, you would have to use a lua script to check the lvar AIRFRAME_CanopySlider (and maybe AIRFRAME_CanopySliderTarget ) to see if the canopy is open before trying to set the lvar to open (or unlock) the door.

I don't fly VR, but those Authenkits do look interesting though, thanks for the link. Anyway, I've found the problem - I hadn't update the lvar write code to recognise the new 'F' flag, and there were some dodgy type conversions when setting using doubles/8-bytes. This has been corrected in the attached version. With this, you can control as previously advised, by adding L:AIRFRAME_DOOR to an offset (either as a float or double) and then using the Offset Float32 Set/1000 (or Offset Float64 Set/1000) control. John FSUIPC7.exe

Can you show me your FSUIPC log file please, from when this occurs.