John Dowson

As the documentation states: The options can be any mix of these (add them together):WND_BOLD, WND_ITALIC, WND_UNDER, WND_STRIKE. So it would be: wnd.font(w, WND_ARIAL,64, WND_UNDER, + WND_BOLD) As I have said, can you please consult the documentation before asking such questions. If it doesn't work according to the documentation, then post. That obviously won't work, i don't understand why you would even try that as there is no such function for that second call. Again, please read the documentation. John

Done.

Took a quick look and the problem was a lot easier than I thought - it was just that the global definitions for WND_ITALIC, etc hadn't been defined. Also the globals for the font specification weren't defined, so even font selection wasn't working. I have corrected this in the attached version, 7.3.25d. if you would like to try. John FSUIPC7.exe

But you do have an ACARS program that IS connecting. Why that one and not the others? Have you tried asking the program developers/providers? And if the CEO has told you that his program cannot connect, has he not asked his team/developers to look into this? I can provide other versions of FSUIPC6 but I do not think this will help, as you have already said that it was working with 6.1.9 but is no longer. And there has been no change to the FSUIPC SDK functionality, which all 3-party clients use, for many years. But if you let me know what version you want to try, I can build that for you. There is really nothing else I can do about this. If this was a freeware program, I could download and see if it connects, but even then I cannot do much else. Please hassle your CEO friend about this, not me!

Then ask him to look into this - its his program, not mine... FSUIPC does not distinguish between client apps. If there is an issue with client apps not being able to connect, then I would look into this. But as this issue seems to be with specific ACARS programs only, there is no way I can look into this. You need the ACARS program developers to look into this. You did report that other ACARS programs are working, so this must be a problem with the program, and not FSUIPC. And, as this was previously working, I suspect the issues lies in a change somewhere in your system, but I have no idea what this could be, if it is not privilege related. This seems to be a common issue with ACARS programs, reported many times (check the forum), my answer is always the same. I cannot help with client programs I know nothing about and don't have - you need to contact the developer. What ACARS program are you using? Is this free-ware or payware?

Ah, sorry... From FSUIPC's logging tab - where else?

Ok, I have just checked and none of the font options (bold, italic, under, strike) seem to be working. No idea why this is at the moment. I will look into this when time permits, but it will be a few days before I can get a chance to look into this in detail. John

Also please see this post - there seems to be one ACARS program that requires FSUIPC 7.3.25, which hasn't been released yet: John

This really isn't my problem - you should contact the developers. I don't understand why they are even checking the version. There is currently no planned release date for 7.3.25, but it will probably be next month sometime. For now, the latest beta, 7.3.25c, can be found here: John

Your registration details are in your purchase email, and they are also available from your SimMarket account. If you didn't receive a purchase email, you can ask about this on SimMarket support. But you can still get your details from your account. John

Yes, of course, but if you look at the offset status guide, you will see: 0xA000 512 0xA200 3584 Reserved i.e. there are 512 bytes available starting at offset 0xA000, so 0xA000 - 0xA1FF. The ones you are using are in the reserved area, and I cannot predict the behavior when using such offsets. Please always check the Offset Status document when using offsets. Yes, this is the issue: John

If an FSUIPC client cannot connect, it is usually due to the client being ran at a different privilege level. But if that is not the cause, I cannot really help - you need to contact the support for the ACARS program. You could try logging IPC Reads and Writes. Don't run any other FSUIPC client apps, and see if any activity is logged from the ACARS program.

Did you make any progress with this?

Any feedback Luke? Is it working as expected?

It was clear what your issue was - was my response/previous comment not clear? Your problem can be caused by several things, and so I need to see your log and ini files to determine what the issue is. However, I did notice some issues in the ini you posted, so I corrected those. Therefore you need to try with that updated ini file I attached and then show me your ini and log files with the recommended logging activated.

Why are you using offset 0xA350/0xA358? Those are in an area documented as Reserved. Not sure what that offset area is reserved for without checking, but can first try with offsets free for general use. If you get the same issue, please attach your FSUIPC7.ini and FSUIPC7.log files, the latter generated with WAPI debug level logging activated, as well as offset monitoring for the offsets you are using. Just load the aircraft, list the lvars, then exit.

Of course, but please at least consult the documentation first, and search the forum as your questions may already have been answered. Cheers, John

I have corrected a few things in your ini (missing joystick for your Alpha due to a change in GUID, substrings for profiles) so please try with the attached, although this may not fix your problem - see later): FSUIPC7.ini I see you are also still using the hidBravoButtons.lua script. This was previously needed to recognise the button numbers > 31, but FSUIPC7 now (and for 2 years or so) recognises these buttons natively without this script. You should remove this at some point and update your assignments accordingly, assigning to the actual button numbers rather than the virtual button flags. The same is true of the hidAlphaButtons.lua script, but you don't seem to be using that one anymore. If you get the same issue, please activate logging for Buttons & Keys and Events, and generate a short log file showing your issue, and attach that together with your ini file again. John

The latest official release is 7.3.24. There is a beta in one of the forums for 7.3.25a, 7.3.25b and 7.3.25c, but 7.3.25 has not yet been released. I don't know why it would say that when that version is not yet available. Try using 7.3.24, and if you get issues then try the support of your acars provider. The only changes from 7.3.25 to the latest 7.3.25beta are: - WAPI updated to 1.0.3 to prevent a thread issue that can cause the WAPI to stop functioning (very rare timing isssue) - minor correction to the simconnect re-connect functionality that prevent FSUIPC7 from shutting down in certain situations (again, rare) - updates to the pause states indicator in offset 0x0264 I can see why your acars would need any of these changes. John

Read the section Adding Lvars to Offsets - it is not that complicated, and your use case is verry similar to the example given. As all the lvars you are using hold integers < 255, you can add them all as unsigned bytes, and then use the Offset Byte Set control, giving the offset and value, for your assignments. You should really be using profiles, so if you have a profile for this aircraft (lets call it 'xxx'), then you would add the following to your FSUIPC7.ini: [LvarOffsets.xxx] 1=L:EMB110 BATTERY SWITCH POSITION=UB0xA000 2=L:EMB110 WIPER L POWER SETTING=UB0xA001 3=L:EMB110 WIPER R POWER SETTING=UB0xA002 Then assign your button or key to Offset Byte Set using offset A000 for the battery, A001 for the left wiper, and A002 for the right wiper. If you want to control both wipers with one button/key, you can either overload the assignment or assign one to the press and the other to the release.

The functions provided by Asobo to save and load flights (and also flight plan)s are still not 100% working, and are documented as 'NOTE: The current status of this function is NO ERROR, NO RESPONSE.', So not much can be done about this at the moment i'm afraid. Although the plan should be saved and loaded with the flight, you could try explicitly loading the plan again after loading the flight to see if that works.

For the Battery Master Switch, you can use the lvar EMB110 BATTERY SWITCH POSITION, which takes the values 2 - Bat 1 - Off 0 - External Power (this seems to be momentary, and goes back to the Off position once set) To use this lvar, add it to a free FSUIPC offset (see the Advanced User Guide on how to do this) for both reading and writing/updating. You can then assign a button or key to set the value to the offset (or inc/dec/cycle the value) using the provided offset controls, and this will then change the value of the lvar. For the wipers, you can use the lvars EMB110 WIPER L POWER SETTING and EMB110 WIPER R POWER SETTING, which take the values 0 - Park 1 - Off 2 - On John

Ok, your ini file shows the Rotaries.lua is recognised but you do not have it running. You should add the following to get this lua auto-started: [Auto] 1=Lua Rotaries Once this is running, this will enable "virtual buttons", converting the single button, in each direction, of the rotaries to a slow and fast button. You should remove (delete or clear) your assignments to the original buttons, and assign to the fast/slow virtual buttons. You should use the IgnoreThese ini parameter in your [Buttons] section so that the physical button press is not registered, only the virtual ones. Also, looking at the rotaries script you attached: This cannot be correct - you cannot have button 28 paired with both 29 and 27..... Remember, each pair of entries corresponds to the two buttons, one in each direction, of one rotary encoder.

You need to first check to see if any lvars are available to control these functions. Try listing the lvars (Add-ons->WASM->List Lvars) and see if any look appropriate. You can then change the control (in the VC) and list the lvars again to see if the value has changed. Once you have found the lvar and the values for each position, try changing the value using the provided facilities (Add-ons->WASM->Set Lvar...). If there are no lvars (or custom controls), then things get complicated. You will need to look at the xml code for each switch and try to determine how it is controlled. I don't have this aircraft so I can;t really help with this, but take a look at this tutorial: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ I can see if I can get hold of this aircraft and if so can take a look. John

I am not sure - it has been a long time since I looked at that program - check the available documentation. You don't actually need to use flags - you can have a simple lua script that simply sends the throttle decrement control in an endless loop (with a delay). You then start the lua script on the button release, and kill the lua script on the button press. You should also overload your assignments on the press and also send a throttle cut. Cheers, John