John Dowson

I would hope that most people understand what is meant by add ....the comma is used there as this is the list of options that can be used. The meaning is perfectly clear and I see no reason to change this. John

If you are developing using the FSUIPC SDK, then using WideClient will provide the same (server) functionality as FSUIPC. To read/write lvars and hvars, and to use calculator code or presets. you would have to use the offset facilities provided. If you are using the WAPI (or anything that uses the WAPI, such as Paul's ,Net dll), then this uses SimConnect to talk to the FSUIPC WASM module, not FSUIPC itself, so you would have to configure network access for SimConnect to use these facilities. Note that you can also run FSUIPC7 in client-mode on a client PC, which will save you having to purchase a WideFS license. To run FSUIPC7 on a client PC, see the appendix in the Advanced User guide. John

Licenses sent.

Yes, and I quoted it in my previous comment....again: The options can be any mix of these (add them together):WND_BOLD, WND_ITALIC, WND_UNDER, WND_STRIKE. Of course that doesn't work. As stated in the document, the signature for this function (when using options) is: bool = wnd.font(w, face, size, options) and not bool = wnd.font(w, face, size, option, option) which is what you were trying. That doesn't exist.

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.