Paul Henty
-
Posts
1,648 -
Joined
-
Days Won
74
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Paul Henty
-
-
1 hour ago, Metall4You said:
How can I establish a FSUIPC connection without WideClient?
The only way without WideClient is to run the app on the same PC as the simulator.
Paul
-
Hi Ramon,
It doesn't look like focus is the problem then.
I afraid I can't suggest anything else. I can't see any reason that your program reading some data would stop your CDU working.
Quoteshould I switch to the FSUIPC client version?
I'm not sure what you mean by this. If you're running your software on a different machine that the flight sim then you have to use WideClient. If you want it to talk directly to FSUIPC you need to run it on the flight sim machine. You don't need to make any change your software to do this. It will automatically detect either FSUIPC or WideClient.
Paul
-
Hi Ramon
I not sure what the problem could be. There should be no problem having multiple software programs using the same Wideclient connection.
I don't know how your CDU and the software works. Does the software need to have focus to work? If the CDU hardware is just seen as a keyboard then it probably needs to be the focused application. Having your own software in focus would stop it working.
If that's not the problem, you'll need to think about what your software is doing that could be interfering with the CDU software, or the communication with the CDU hardware. E.g. if the CDUs are on a COM port, is your software also using COM ports? The same one?
I may have some more ideas if you can let me know more about what your software does and how the CDUs are connected and communicate with Prosim.
Paul
-
The top 4 errors are because Windows has flagged the files as coming from the internet. If you right click them in the File Explorer and select properties you'll find an option to unblock them. It might be better to unblock the ZIP file and then unzip it again.
The 6 warning should resolve when you build the project for the first time and the NuGet components get automatically downloaded and installed.
Paul
-
Hi David,
You should just choose the update option here and let VS re-target to the 4.8 framework. It will work fine.
The example projects target 4.6.2 because that is the earliest version that Microsoft still support at the moment.
Paul
-
Hi Jason.
You'll need to ask John Dowson about this in the MSFS (FSUIPC7) support forum.
Paul
-
Hi,
You are getting the warnings because my DLL depends on the Win32 API and the WinForms library . Those are not included in the .NET Standard 2.0 specification.
It's telling you that if you use my library, your application will no longer be .NET Standard 2.0 compatible. e.g. It won't run on Linux.
Running it on a Windows .NET 8 machine will be fine because that platform does include the Win32 API and the WinForms library.
Since my DLL cannot work on any platform except Windows I cannot make it target a cross-platform specification like .NET Standard 2.0. Even the .NET versions I do target have to be the specific 'windows' versions. e.g. net6.0-windows not net6.0.
If you must use Standard 2.0, the only thing you can do is tell VS to suppress the warning, but your app will not really be compatible with Standard 2.0.
Paul
-
Hi Kees,
This forum is for .NET programming; your questions seems to be about Lua so this isn't really the best place to get help with that.
However, you'll probably get better performance by using the lua event system for LVars:
event.Lvar("lvarname", interval, "function-name")
This will call the specified function when the value of the LVar changes. That function can then set the value in the offset. I think this will reduce the processing from the current situation where you are reading the writing every LVAR every 100ms.
I don't really know lua that well, so If you want more information about this, please ask John Downson in the main FSUIPC forum (not any of the sub-forums) at the link below.
https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/
Paul
-
My DLL has no way to access SimConnect variables.
I know FSUIPC7 has a way to map a simconnect variable to an unused offset, but I'm not sure if this works with a whole structure, or if it works with earlier versions of FSUIPC.
@John Dowson will be able to tell you if it's possible to access this simconnect data via offsets. If he doesn't see this and reply here, please ask him directly in the main FSUIPC support forum.
Paul
-
Hi Robert,
I don't know anything about the P3D shared cockpit feature, but it sounds like these particular variables are not getting shared between the copies of P3D. I guess P3D can't share everything due to bandwidth, especially if you're using third-party aircraft.
QuoteWould I have to store each value in a seperate offset then have a client app to read it and process the LVARs on the individual computers?
FSUIPC itself doesn't do any cockpit sharing so offset values will also not be shared unless they are backed by P3D data that is shared. So writing to spare offsets on one copy of P3D will not be seen on the other.
I don't think there's an easy way to do this. You'll need to come up with a way to pass the data between the two PCs yourself.
The obvious way is probably to use a TCP link between your application running on the the server and the client(s) and pass the LVAR data between them. .NET has a TcpClient and TcpListener class. Your application can then exchange the LVAR data over the TCP link and update the local copies of the LVARs using FSUIPC.
There might be some .net libraries that make data exchange easier than writing your own networking code, but I've never looked into this.
Paul
-
Hi,
I think you've posted in the wrong sub-forum. This is for questions about programming FSUIPC applications in .NET languages.
I recommend reposting in the main FSUIPC support forum. Follow this link, scroll down a bit and find the [Start New Topic] button.
https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/
Paul
-
The NAV offsets are stored in hexadecimal, not decimal like the COM offsets.
To convert the value, you must convert it to a string using hexadecimal format. Then you need to add the 1 at the front and the decimal point in the middle...
string nav1String = nav1offset.Value.ToString("X4"); // Convert to hex - exactly 4 digits nav1String = "1" + nav1String.Substring(0, 2) + "." + nav1String.Substring(2, 2);
In your example you got the value 4176. In hexadecimal this is 1050. Which represents the frequency 110.50
Paul
-
1
-
-
Great! Glad it's all sorted. It was baffling me for sure. I hadn't considered you were using the untyped Offset class.
I've reproduced the error here and I've made a small change to the DLL so that it gives a much better exception than "index out of range":
FSUIPC.FSUIPCException: 'FSUIPC Error #999: FSUIPC_ERR_WRITE_OVERFLOW. Offset 66C0 is declared with length of 9 Bytes. The data you are trying to write is different from this. (8 bytes)'
Version 3.3.9 is now on NuGet.
Paul
-
That line number doesn't really help unfortunately. Can you make sure FSUIPCConnection.DLLVersion is reporting 3.3.8?
Also some of this info might help:
1. are you using any named offset groups anywhere in your application? Or are you just using the blank default group?
2. is there any multi-threading in your application? Or is everything run on the main UI thread?
Paul
-
Okay - here's the file. Copy it to your application folder (along side the fsuipcClient.DLL).
When you get the stack trace it should give you the line number in my Process() method where it's failing.
Paul
-
The pdb files don't seem to be in the latest packages either. I'll have to sort that out. But at least I can attach a copy for the latest version. I'll need to know which framework version you're using though - 4, 5, 6 or 7.
Paul
-
That's a very old version (about 4 years). Back then I was not shipping the pdb files in the package. The pdb files are specific to each build of the DLL so I can't generate one for an old version.
I can only really suggest updating to the latest version. There could be a few breaking changes however, depending on what features you're using.
Also, the earliest framework supported is now .NET Framework 4.6.2. If you're using an earlier framework and don't want to upgrade your project to a new framework, let me know what version you're targeting. I might be able to suggest an alternative version of the DLL that supports the framework you're using.
Paul
-
Hi Robert,
It's difficult to tell from that error.
What version of the DLL are you using?
Can you make sure you have the fsuipcClient.pdb file in the folder you run your application from. This should make it so the line number from my DLL is reported in the stack trace. That would help a lot. Visual Studio usually copies the pdb file to the build folder (e.g. bin/release).
Paul
-
Hi Andy,
In the PMDG_737_NGX_Offsets class there is:
ICE_TestProbeHeatSw[2]
In the PMDG SDK this data is called ICE_ProbeHeatSw.
My DLL takes the names from John's FSUIPC Documentation for the PMDG Offsets, not from the PMDG SDK. I don't know why the FSUIPC name is different in this case.
Paul
-
Quote
as i do not want to poll in milliseconds for the last 100ft or the approach.
Polling can't be avoided with FSUIPC because the protocol is based on polling. Applications that use FSUIPC are meant to constantly poll for look for changes.
As John says, my Websocket Server does have an event-driven model, but it has to use polling in the background to monitor for changed values. The developer can choose the polling rate.
My C# DLL does not have an event model for offsets (only LVars which uses John's LVar WAPI server and not FSUIPC).
If you're comfortable using the Node.JS SDK for FSUIPC then you should probably stick with that and just use polling. FSUIPC can comfortably handle requests every 40ms, maybe faster on modern hardware.
The only reason I can see to use another SDK is if the Node.JS wrapper is too slow to manage this rate of polling for some reason.
Paul
-
1
-
-
Check which altitude you are reading. FSUIPC offers a few different offsets, giving different altitudes . e.g.:
The actual altitude is given by offsets 0x6020 and 0x0570.
The indicated altitude (i.e. what the altimeter in the aircraft is showing) is found at 0x3324. This reading is dependent on the barometer setting in the aircraft. Below 18,000ft the player should set this to the local air pressure as set by the weather. Above 18,000ft the player should set this to standard pressure (1013mb or 29.92inHG).
You need to know which one your application is reading and what your altimeter in the aircraft is showing (i.e. what pressure is set).
You're likely seeing a problem because you're either mixing up the two values, or the altimeter in the aircraft is showing the wrong altitude because the barometer is not set to the correct pressure.
If you don't use any weather the default air pressure is 1013mb which is also the default setting on the barometer. You won't see any problems until you use weather which changes the local air pressure.
Paul
-
Quote
Is there anyway i can get or read the ui_createdby line?
Not from FSUIPC directly. You'll need to open the file in code and read through it until you find that line.
You can find the path to the aircraft.cfg file in offset 0x3C00 (Also string * 256).
In FSUIPC3 to 6, this contains the full path to the .air file. The aircraft.cfg will be in the same folder you just need to get the folder from the path and substitute the file name.
In FSUIPC7 the offset list seems to suggest this will be the aircraft.cfg instead, so you can probably just use it directly.
Paul
-
1
-
-
You can get the 'title' of the aircraft (as specified in the aircraft.cfg file) from offset 0x3D00 (String of size 256).
That will probably give you enough info to differentiate aircraft from different developers.
Paul
-
Hi,
All of these offsets are only 1 byte in length. This can be seen from the FSUIPC Offsets document: e,g,0x3101
By declaring these offsets with type <int> you are reading 4 bytes instead of 1. For offset 0x3101 you are also reading 3102, 3103 and 3104 into one variable.
You must declare these offsets to be an integer of length 1. The C# type for this is either byte (unsigned: + values only) or sbyte (signed: + and - values).
Since the possible values for these offsets are only 0 and 1, just use <byte> like this:
private Offset<byte> alternatoroffset = new Offset<byte>("alternator", 0x3101); private Offset<byte> masterbatteryoffset = new Offset<byte>("masterbattery", 0x3102); private Offset<byte> avionpwrofset = new Offset<byte>("avionicspower", 0x3103);
For more information on which C# type to use with different size offsets, please see the "Offset Types Chart" in the downloads section of the website:
http://fsuipc.paulhenty.com/#downloads
Paul
FSUIPC. DLL for .NET with SIOC Direct and WideClient
in FSUIPC Client DLL for .NET
Posted
These module are only for reading and writing LVars and HVars with the MSFS flight sim. They are not for any other sim (e.g. P3D) and cannot be used for reading/writing offsets.
If you're using MSFS and the aircraft you are using provides LVars for the data you need (e.g. flaps position) you could rewrite your app to use LVARs. You will need to use the MSFSVariableServices class in my DLL.
There is more info and an example project here:
http://fsuipc.paulhenty.com/#downloads
The example project will let you read LVars so you can check that you can get all the data you need before you start coding.
(Note that the WASM module is installed with FSUIPC7. The FSUIPC_WAPID.dll needs to be downloaded and placed in your project. It should be set to be copied to the output folder when the project builds.
Paul