[Application reacting to the simulator?]

Yes, if you don't like the blocking behaviour on the main UI thread.

 

The DLL was first written about 9 years ago against the .NET 2 framework. Back then multi-threading and async was not as easy as it is now in .NET 4.

 

I'm considering dropping .NET 2 support for the next version. If I do, I can make 'asnyc' versions the IO methods so that it doesn't block the UI thread and you'll be able to use a 'callback' model if you prefer this.

 

But for now, if you're using .NET 2 or above you can use the BackgroundWorker class to call Open() and Process() etc. If you're using .NET 4.0 or above then you can also use the new Task class.

 

The other thing you can do is design your application to minimise the time spent doing things that will potentially block the thread. For example, having a button or menu option that the user can use to connect to FS, rather than having your program automatically looking for a connection until if finds one.

 

Paul

 

Hi Paul,

 

Thanks a lot. Got it working!

[Application reacting to the simulator?]

I apologise for my lack of knowledge with this type of stuff, and so if anyone can point me in the right direction, that'd be great.

 

I am currently having the problem with FSUIPC and this DLL that, whenever opening the simulator, or the simulator crashing, it also affects my application - for example, during startup of the simulator, I am unable to move the application window around, like it's "hanging" waiting for the simulator.

 

Is there a way to fix this? Do I need to run the "connection" in a seperate thread?

[FSUIPC fails to recognise buttons pushed on my Saitek Throttle, but does recognise my Stick]

Gdscei,

 

How are you? I have had the same problem. This worked for me.

Download JoyIDs here http://airgroup51.net/forum/index.php?topic=2435.0

Install the program then run it. You should see Id#1 X-55 Rhino Stick and Id#2 Rhino Throttle.

 

Double click on the throttle (should highlight green and click on Id#3 to move it there

Repeat the same procedure to assign the stick to Id#2

 

Restart P3D or FSX and hopefully that will fix your issue. Best of luck and I hope that helped...

 

Take Care...

 

Hello Will,

 

I apologise for the late response - haven't been simming that much lately.

This fix worked for me! Thank you very much!

[FSUIPC fails to recognise buttons pushed on my Saitek Throttle, but does recognise my Stick]

It has been working fine for months now, but yesterday, it started having the problem where my Saitek X55 throttle quadrant buttons and axes just aren't seen by FSUIPC. I've tried connecting the USB in another USB port, but that doesn't seem to fix the problem. In my Saitek drivers, it recognises the buttons, and in my Prepar3D options, it recognises them as well.

I've tried renaming my FSUIPC4.ini to FSUIPC4.ini.bkp to let it create a new ini, but I'm still having the same issue.

 

This is my FSUIPC4.ini atm:

[General]
UpdatedByVersion=4938a
History=NMQ0JLP5PX0Q9YQYDWPAF
InitDelayDevicesToo=No
NewInterceptTextMenu=No
UseSystemTime=No
UseMidMouseBtn=Yes
MouseWheelMove=No
MouseWheelTrim=No
MouseWheelTrimSpeed=1
JoystickTimeout=20
PollGFTQ6=Yes
BlankDisplays=No
FixControlAccel=No
FixMachSpeedBug=No
DeleteVehiclesForAES=Yes
AutoScanDevices=Yes
VisibilityOptions=No
OneCloudLayer=No
CloudTurbulence=No
CloudIcing=No
GenerateCirrus=No
SuppressCloudTurbulence=No
MaxIce=-4
MinIce=-4
UpperWindGusts=No
SuppressWindTurbulence=No
SuppressWindVariance=No
WindTurbulence=No
TurbulenceRate=1.0,5.0
TurbulenceDivisor=20,20,40,40
SuppressAllGusts=No
MaxSurfaceWind=0
WindLimitLevel=200
WindDiscardLevel=400
WindAjustAltitude=No
WindAjustAltitudeBy=2000
SmoothBySimTime=No
WindSmoothing=No
WindSmoothness=2
WindSmoothAirborneOnly=Yes
PressureSmoothness=0
TemperatureSmoothness=0
DisconnTrimForAP=No
ZeroElevForAPAlt=No
ThrottleSyncAll=No
WhiteMessages=No
ShowPMcontrols=No
SpoilerIncrement=512
MagicBattery=No
RudderSpikeRemoval=No
ElevatorSpikeRemoval=No
AileronSpikeRemoval=No
ReversedElevatorTrim=No
ClockSync=No
ClockSyncMins=5
ClearWeatherDynamics=No
OwnWeatherChanges=No
TimeForSelect=4
LoadFlightMenu=No
LoadPlanMenu=No
PauseAfterCrash=No
BrakeReleaseThreshold=75
SaveDataWithFlights=No
ZapSound=firework
ShortAircraftNameOk=Substring
UseProfiles=Yes
EnableMouseLook=No
DelayedMouseLookZoom=No
AxesWrongRange=No
TCASid=Flight
TCASrange=40
AxisCalibration=No
DirectAxesToCalibs=No
ShowMultilineWindow=Yes
SuppressSingleline=No
SuppressMultilineFS=No
AxisIntercepts=No
DontResetAxes=No
InitDelay=0
GetNearestAirports=No
OOMcheck=Yes
WeatherReadFactor=2
WeatherRewriteSeconds=1
CustomWeatherModify=No
SimConnectStallTime=1
InitialStallTime=10
NormalStallTime=1
LuaRerunDelay=66
Console=No
FSVersionUsed="Lockheed Martin® Prepar3D® v2",2.4.11570.0
SimConnectUsed=2.4.0.0

[JoyNames]
AutoAssignLetters=No
0=Saitek Pro Flight X-55 Rhino Stick
0.GUID={8E11F2C0-9446-11E4-8001-444553540000}
1=Saitek Pro Flight X-55 Rhino Throttle
1.GUID={8E11F2C0-9446-11E4-8002-444553540000}

[Axes]
PollInterval=10
RangeRepeatRate=10

[Buttons]
PollInterval=25
ButtonRepeat=20,10

[LuaFiles]
1=BBSA330
2=rdvacarsng

[AutoSave]
Next=1
Interval=60
Files=10
SaveOnGround=No
AutoSaveEnabled=No

[GPSout]
GPSoutEnabled=No

[GPSout2]
GPSoutEnabled=No

[WideServer]
WideFSenabled=Yes

[Sounds]
Path=G:\Prepar3D\Sound\
Device1=Primary Sound Driver
Device2=SPDIF Interface (2- FiiO USB DAC-E07K)
Device3=Digital Audio (S/PDIF) (High Definition Audio Device)
Device4=Speakers (High Definition Audio Device)

[Incorrect data given by FSUIPC]

Thanks Paul!

 

I was able to figure it out, and succesfully was able to get the correct taxi light value I need.

If anyone else needs it, the LUA script is quite easy:

while 1 do
  taxi = ipc.readLvar("L:AB_TAXI_LT")
  if taxi == nil then
    break
  end
  ipc.writeUB(0x66C9,taxi)
  ipc.sleep(100);
end

[Incorrect data given by FSUIPC]

You are right, there is no offset or any feature in FSUIPC to transfer data to or from lua.

There are spare offsets you can use in FSUIPC, I think called user offsets or free offsets in the docs. Sorry for being vague but I am away at the moment with no access to the docs. You can have your lua program copy the LVAR data into these offsets and read them from your program in the normal way. If your program is being released to the public then it is advisable to ask Pete for some allocated offsets for this purpose instead of using the free block.

Another way would be writing the data to a local file in lua and then reading it from your program.

Or you can open a local tcpip socket connection using the libraries in lua and .net and have the two program's communicating over that connection.

I think those are your options.

Paul

 

Hello Paul,

 

Thanks you very much for the info. I think I'll go with writing to offsets to keep consistency across my application. 

I'll see what I can get done and have a chat with Pete if necessary for the offsets.

[Incorrect data given by FSUIPC]

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim.

 

Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately.

 

The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies.

 

If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula.

 

Paul

 

Hello Paul,

 

How would you recommend I read the values in my application from the LUA script that gets the LVars? I believe there is no offset available to just read whatever LUA outputs, right?

[Incorrect data given by FSUIPC]

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim.

 

Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately.

 

The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies.

 

If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula.

 

Paul

 

Hello Paul,

 

Thanks for the information. I guess I will have to look up what Aerosoft can offer me in terms of SDK. Other aircraft, probably will just have to make exceptions for it.

 

In terms of my declaration for the 030C offset...

private readonly Offset<int> _landingRate = new Offset<int>(0x030C);

I am pretty sure that's alright. Thanks for the information on the landing rate, that can explain the strange behaviour. I will probably indeed have to make my own logic. I might post it here if I can make it work!

[Incorrect data given by FSUIPC]

I am currently using Paul Henty's .NET client DLL. I have multiple users reporting two main issues with the data:

- Taxi lights on Aerosoft's AXE. Probably because of the 3-state taxi light switch, when the taxi light is in the TO position, it is still registered "on" (which is true technically, but not really useful if you are trying to figure out if the nose light is on).

- Landing rate. This seems to be quite inconsistent, and sometimes even over the top with landing rates above 1000 fpm.

 

If you have any info on either of these, if they are known, if they're are fixable, that would be awesome. Thanks! :)

[Ground type]

You could give your users a button or menu options for 'Rebuild Scenery Data" or something. Then run Makerwys.exe from inside your application. This is what commercial programs like Radar Contact do.

 

I assume you are using .net since you are posting here, so you can use the System.Diagnostics.Process class to start the Makerwys.exe and wait for it to finish. You'll need the path to the Flight Sim install folder which you can either ask the user for, or get from the registry: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Games\Flight Simulator\<version no>

 

It's more complicated if your users use your application over wideFS. Then you'll need to get them to run your ACARS on the flight sim PC first to do the scenery data rebuild, or resort to getting them to manually run the Makerwys.exe.

 

Paul

 

Hi Paul,

 

Sorry for the late reply. Thanks for the information! I will look into it further.

 

Edit: also, it seems like Makerwys is not supplied with FSUIPC (at least, not when I installed it). Is this correct, and if so, am I allowed to package it with my application?

[Ground type]

Not without comparing the aircraft's location against a database of runways, such as that produced by my MakeRunways utility.

 

BTW you posted in a subforum which is specifically concerned with support for Paul Henty's .Net client DLL programming.  General support questions should be directed to the main support forum, please.

 

Pete

 

Thanks for the information! I would like to run the MakeRunways utility, problem for me is personally: I am working on ACARS software for a VA, and so this is a distributed program... So I would have to ask my users to run the utility before they run the ACARS software.

[Ground type]

I've read through the docs, and I see there is a ground type offset - but it's not exactly what I need.

Is there a way to specifically check if a plane is on a taxiway or if he is on a runway?