Paul Henty
-
Posts
1,729 -
Joined
-
Days Won
78
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Paul Henty
-
-
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
-
The only thing I can think of is that your virus checker is seeing it as a false-positive and quarenteening it. You can probably check to see if that's happened and add an exception.
You could also try renaming the .nupkg to .zip, then you can unzip it and find the DLL under \lib\net6.0-windows7.0
Paul
-
Hi Matt,
I haven't provided any alternatives to NuGet, but I've attached the NuGet package here.
You can copy this to your NuGet 'local store' which you can select in the 'package source' dropdown:
If you don't have one, or don't know the path, you can view and create stores with the cog icon.
Once you have the nuget file in the local store you can install it as normal.
The DLL takes a dependency on protobuf-net so I've also included that package.
Paul
-
Quote
Presumably the .net client has access to this function, but Paul should confirm.
Yes, just set the property before calling Init()
MSFSVariableServices.SimConfigConnection = 1; // Use config 1. Default is 0 MSFSVariableServices.Init(); // Initialise
Paul
-
Yes, that's how WideFS and WideClient work. You run WideClient on the notebook and any FSUIPC Client software you run (or develop) will see it as FSUIPC and connect.
The only thing I'm not sure about it the new WASM module to read/write LVars, HVars and run calculator code. @John Dowson will be able to tell you if you can use that on the remote PC. This is separate from the normal FSUIPC protocol and so I don't think it is handled by WideFS7.
Paul
-
Hi Robert,
26 minutes ago, AirPanther said:but when I look at the FSUIPC console log, it appears that the offset only gets rewritten to 1 after it changes to 0 (hence the split second change). It is as if all my offsets will only resend if they change even though I call .process() each time.
That's correct. By default, all offsets will be read on process() except when you have changed the value, in which case the new value is written. They then go back to reading again.
If you want an offset to only be written (even when the value hasn't changed) you need to mark it as WriteOnly by setting the parameter in the constructor:
public Offset<BitArray> ControlInhibit = new Offset<BitArray>(0x310A, 1, true); // Write only
That will make the DLL write the current value every time you call process.
You could also consider putting this offset in a named group so you can process() this at a different time from other offsets you might be using. Here's how you would do that...
public Offset<BitArray> ControlInhibit = new Offset<BitArray>("inhibit", 0x310A, 1, true);
FSUIPCConnection.Process("inhibit");
... but it's not required.
Paul
-
Quote
The reason I've chosen just Calculator Code is, If I'm not mistaken, LVars and HVars have to be accompanied by a file associated with a particular aircraft to be directly linked?
I believe HVars need a file to be accessed directly by the WASM module. LVars don't need the file.
Quoteinstead of the method above where it just blindly tries to send the calculator code and executes it, if the program can?
I think that's also correct.
Quotedoes 'Legacy' events just send SimConnect events Via FSUIPC?
Probably yes. FSUIPC4 and above uses SimConnect in the background for most things. @John Dowson will be able to confirm.
Paul
-
Quote
In the event this process is blowing out my memory, is there another way that isn't as resource intence
Yes, I've upload a new version for you to try: 3.3.8-beta.
I've reduced the memory overhead to about 12% of what it was.
Remember to tick "Show Pre-Release" in the NuGet package manager to see this beta version.
Please let me know how it goes.
Thanks,
Paul
-
Thanks,
Work fine here with your code and those files. The rebuild took 20 seconds to run on my rather old machine.
Can you try logging the progress output from the RebuildDatabase method? This will tell us how far it's getting/where it's stopping.
The code will be something like this...
if (db.MakeRunwaysFilesExist) { Progress<string> progress = new Progress<string>(); progress.ProgressChanged += (o,s) => logger.Info(s); await db.RebuildDatabaseAsync(progress); db.Load();
I'll look at this again tomorrow morning.
Paul
-
I wonder if it's something to do with the data in the MakeRunways files.
Can you send me your makerunways output files? I can try running them here and see if there's something my code isn't handling. (I don't have MSFS).
They should zip down pretty small - I only need:
Runways.xml
F5.csv
R5.csv
G5.csv
Helipads.csv
T5.csvThanks,
Paul
-
Quote
db = FSUIPCConnection.AirportsDatabase fails,
I'm not sure what you mean by 'fails' if there are no exceptions or errors. What are you seeing to make you believe it has failed?
If you step through this method does it continue past this line, or does the method just return, or does the whole application just stop?
Paul
-
Hi Brandon,
Quotehow/what is the best way to send this information to the flight simulator. is Calculator code the best way to send not only standard events but also L/Hvars? or as mentioned by John in this thread is the use of Presets the better option.
Presets are just containers for calculator code, so they end up executing calculator code eventually. They are useful in the FSUIPC front-end, but if you are using code then it's just an extra step. Also the way you call presets from code via FSUIPC is not very efficient.
If you're using code I would stick to either sending calculator code or using the HVars/LVars directly using the MSFSVariableServices class in my DLL. Which you choose is down to personal preference/convenience/situation. For example, if you're just wanting to read/write a single LVar or activate a single HVar then using the direct method might be easier:
MSFSVariableServices.HVars["MyHVar"].Set();
However, if you've found some complicated calculator code on the web, or in a preset, then you might not want to decode what it's doing and replicated the logic yourself. In this instance it would be easier just to copy the code into your application and send it via MSFSVariableServices.ExecuteCalculateCode()
For aircraft where LVars/HVars are not available you may need to fall back on 'legacy' methods like Events (aka Controls) and Offsets. In this case you need an FSUIPC Connection.
Events/Controls perform actions in the aircraft (Like HVars). Use the FSUIPCConnection.SendControlToFS() feature.
To read data use the Offsets. Some offsets can also be written to.
QuoteAs for presets, how are they supposed to be typed into the C# code or is there a txt file that needs to be placed somewhere specific and then references in C#?
I don't recommend executing presets themselves from code. It's best to just take the underlying calculator code from the preset and execute that. You can copy it directly into your source code. Alternatively, you can have your application read it from your own text file if you want to be able to modify/add calculator code without recompiling your application.
QuoteHow is this sent to the simulator and could you please give me a C# example of this?
If you have not already downloaded the MSFSVariableServices example code project please get it from here:
http://fsuipc.paulhenty.com/#downloads
It doesn't have an example for calculator code but it will show you how to make a connection and use LVars/Hvars directly.
In this thread I give an example of executing calculator code as well as using the same HVar directly. There is also a link to a good website where you can find the underlying calculator code for all the presets.
Feel free to ask further questions. It's a bit confusing if you're coming into this new because there are two systems in use for MSFS: The legacy Events/Controls/Offsets system and the newer LVars/HVars/Calculator code system.
Paul
-
Hi Andy,
Copying files is an easy thing to do in .NET, so I can't see that I'd be adding much value to the DLL, or significant time-saving to coders, by including this.
Paul
-
Hi Andy,
This was a bug on my side. I've just uploaded 3.3.7 to NuGet which fixes this.
Also note that you'll need to load the database after you rebuild it, or you'll get 0 airports:
await db.RebuildDatabaseAsync(); db.Load(); System.Windows.MessageBox.Show($"MSFS airports build successfully. Total {db.Airports.Count}"); logger.Info($"MSFS airports build successfully. Total {db.Airports.Count}");
Paul
-
You've still got the declarations the wrong way round. 3114 must be declared first, then 3110. Please see the code I pasted in my last reply.
QuoteDon't think I need the Disconnect() and DeleteGroup() call,
You don't need the Disconnect(), but you definitely need to delete the group if you declare (recreate) the offsets each time you send them.
Quotebut I can't use the Offsets declared globally (threaded application). I must declare them at each use (which is strange).
The DLL is thread-safe and (by default) offsets can be declared on one thread and set/processed on another.
QuoteIf I don't call Process() the same event is sent over and over, irrespective of what the value of the Event Offsets are (so they don't update)
If this is the case then either:
1. Another application is sending these events.
2. Your application is sending these events from elsewhere in the code. Make sure you haven't declared these offsets somewhere else in another group (or in the default, empty group).
Also, if you are using a version of my DLL before 3.1.6 you'll need to update as the write-only offsets were buggy before that.
Paul
-
In the code you've posted you're still declaring the offsets in the wrong order. You need to declare 3114 then 3110.
I noticed you have swapped the order you set the values, but that doesn't matter. It should be this:
Do Until myEventQueue.IsEmpty Dim mySimEventParams As New Offset(Of Integer)("SendControl", &H3114, True) Dim mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True) Dim myEvent As SimEvents myEventQueue.TryDequeue(myEvent) mySimEventParams.SetValue(myEvent.MouseID) mySimEvent.SetValue(myEvent.EventID) SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID) FSUIPCConnection.Process("SendControl") FSUIPCConnection.DeleteGroup("SendControl") Thread.Sleep(1000) Loop
However, this might not solve the problem since your examples are always sending the same parameter value. It would only make a difference on the first ever call. But, you should fix the order in case you ever need to send a different parameter value.
Other things you might try:
- Turn on the Event (control) logging in FSUIPC and output to the console. Check that FSUIPC is receiving what you think the code is sending. And you'll be able to see if anything else is writing that control.
- Try with a non-mouse parameter. I think some of the PMDG controls can also take direct values like 0/1 for open/close.
Paul
-
Quote
Private Shared ReadOnly mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True) Private Shared ReadOnly mySimParams As New Offset(Of Integer)("SendControl", &H3114, True)The order of these offsets matters. FSUIPC sends the control to the sim as soon as you write 3110. So that's before you've written the new parameter - the offsets are written in the order they are declared.
If you reverse the order of these two lines (declare 3114 first, then 3110) it should work as expected.
Paul
-
Hi Tony,
The new offsets for COM frequencies start at 0x05C4. These are just normal 4-byte 'int' offsets that store the frequency in Hz. To convert to/from the normal MHz value just multiply/divide by 1,000,000.
These offsets are read/write in P3D, however the Offset Status document for FSUIPC7 (MSFS) says that writing to these offsets does not work yet. It's worth trying though.
Also, some third-party aircraft may use their own coding for com frequencies and so these offset won't work at all for those aircraft.
Paul
-
Quote
Is there something I should have done initially to get access to HVars?
It sounds like the WASM module isn't seeing the HVars. I don't have MSFS so I can't really help with that.
@John Dowson will be able to help with getting the HVars recognised by the WASM module.
Hopefully he will see this and reply here. If not, please ask John directly in the MSFS sub-forum: https://forum.simflight.com/forum/183-fsuipc7-msfs/
Paul
-
Hi,
If you go to this site you can look up all the MSFS presets and find out how they work:
https://hubhop.mobiflight.com/presets/
(Make sure you select MSFS and not XPlane in the top left).
If you search for 'AS1000_MFD_RANGE_INC' and expand one of the results you will see the 'code' field. This is the 'calculator code' that get executed when you run the preset:
(>H:AS1000_MFD_RANGE_INC)
This is just setting an HVar (not LVar) called AS1000_MFD_RANGE_INC.
You have two choices to do this with the Client DLL:
1. Use MSFSVariableServices to execute this exact calculator code:
string incMFDRange = "(>H:AS1000_MFD_RANGE_INC)"; MSFSVariableServices.ExecuteCalculatorCode(incMFDRange);
2. Use MSFSVariableServices to set the HVar directly:
FsHVar mdfRange = MSFSVariableServices.HVars["AS1000_MFD_RANGE_INC"]; if (mdfRange != null) { mdfRange.Set(); }
When you are looking for controls for an aircraft, be sure to check HVars as well as LVars. Many controls are done with HVars when no values need to be set or read.
Paul
-
1
-
PMDG 737 in MSFS missing probe heat switches
in FSUIPC Client DLL for .NET
Posted
Hi Andy,
In the PMDG_737_NGX_Offsets class there is:
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