twinfan / xpmp2 Goto Github PK
View Code? Open in Web Editor NEWMultiplayer library for X-Plane 11/12 with instancing, TCAS override, and sound
Home Page: https://twinfan.github.io/XPMP2/
License: Other
Multiplayer library for X-Plane 11/12 with instancing, TCAS override, and sound
Home Page: https://twinfan.github.io/XPMP2/
License: Other
Current Situation / Problem
Only one X-Plane plugin can take control of TCAS targets at a time. This is a X-Plane design limitation. See Overriding TCAS and XPLMAcquirePlanes.
Suggested Solution
A separate plugin, a TCAS concentrator, acts as kind of a proxy in that it is the plugin to actually have control of X-Plane's TCAS targets, receives plane positions from collaborating plugins which draw planes (like LiveTraffic, xPilot and the like), orders these planes by distance and forwards the first 63 to X-Plane's TCAS target system.
Design Approach
Collaborating Plugin
TCAS Concentrator
size
fieldXPMP2
XPMPMultiplayerEnable
should
Benefits
The planes of more than one multiplayer plugin can appear on TCAS systems and can be made available to 3rd party plugins reading this data (like map or camera tools).
Additional context
The idea has also been formulated by Kuroneko.
Current Situation / Problem
3rd party plugins cannot find out which model a rendered plane uses.
There is a use case at least for the camera plugin ABC, which asks for a value similar to what LTAPI returns through LTAPIAircraft::getCslModel()
.
Suggested Solution
Extend the already existing set of shared dataRefs:
sim/multiplayer/position/plane#_cslModel
filled with XPMP2::Aircraft::GetModelName()
Benefits
Use cases are probably limited...but at least ABC has what it asks for. It somehow uses it to fine-tune the camera per displayed model.
Additional context
Discussed in a support thread in the context of the Remote Client. The solution will be generic for XPMP2, however, ie. for any plugin based on XPMP2.
Current Situation / Problem
See TwinFan/LiveTraffic#188
Distance up to which labels are drawn is hard coded to 5,000m at the moment. Some people like to see labels earlier.
Also, labels are cut off at X-Plane's reported visibility.
Suggested Solution
Provide a configuration option for maxLabelDist
, either in the configuration callbacks or as a separate function, or as addition to the existing XPMPEnableAircraftLabels()
call.
Benefits
Allows plugins to offer the user to chose when to show labels.
Additional context
TwinFan/LiveTraffic#188
Current Situation / Problem
In a networked multi-PC setup several only loosely coupled instances of X-Plane run in parallel, usually to drive different screens. Running LiveTraffic or any other XPMP2-based plugin will not guarantee that all planes are always fully aligned and placed at the exact same location. This will look ugly when planes move across screens driven by different PCs.
Suggested Solution
Synchronize plane objects across the network, driven by a master.
Basic design ideas:
Resources/XPMP2.example.prf
Benefits
Better looking support for a networked setup
Additional context
Originally discussed as issue TwinFan/LiveTraffic#126, but now decided to be solved centrally in XPMP2 and hence moved here.
XP12 replaces some multiplayer
dataRefs, resulting in Log.txt
output like
Line 210: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
Line 212: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
Line 214: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.
That dataRef names always had that spelling mistake...and now they get replaced by array(!) dataRefs, which is unfortunately a totally different naming concept:
sim/multiplayer/controls/yoke_pitch_ratio float[20] y [-1..1] The deflection of the axis controlling pitch.
sim/multiplayer/controls/yoke_roll_ratio float[20] y [-1..1] The deflection of the axis controlling roll.
sim/multiplayer/controls/yoke_heading_ratio float[20] y [-1..1] The deflection of the axis controlling yaw.
So instead of requesting plane%i_yolk_pitch
for 20 different names we would now in XP12 need to deal with a (proper) array dataRef. So this is way more of a coding change than just replace one string by another. To make matters worse, most multiplayer
dataRefs stay the old system (plane%i_...
) while only those 3 change to a float array type.
For a plugin that runs under both XP11 and XP12, we would now need version-specific processing during runtime. I am actually considering to drop support for multiplayer/.../yoke...
in XP12 altogether: TCAS override is always available in XP12, so there would be no need to provide yoke details via the old multiplayer
dataRefs. To be verified.
Run under XP12.
No deprecation messages in log or to user.
Here output from a DEBUG version, in which even the error callback is informed...though this appears to be in no way fatal:
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_pitch' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_pitch' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_roll' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_roll' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_yaw' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_yaw' has been replaced. Please use the new name.
Current Situation / Problem
Many, if not all, models require some additional work to unlock all features with XPMP2. They might not use correct dataRefs for all features or use unsupported parameters like passing textures as parameters.
The Python script CSL2XSB has been created to correct these issues. Documentation of what the script does is there. This requires an additional setup step by users.
Suggested Solution
Instead of having the user run a spearate script let XPMP2 do the conversions on the fly while reading the .obj
models but in a lasting way:
.xpmp2.obj
files for each texture parameter (allows usage of X-CSL models)xsb_aircraft.txt
format of OBJ8
parameters as now the 2 texture parameters are recognized againAlternatives
Have the user run the Python script as of now.
Benefits
All users, also less experienced not willing to fiddle with Python, benefit from feature like rotating props and a larger choice of models.
Additional context
LiveTraffic's documentation of the CSL2XSB script
Describe the bug
The multiplayer idx returned to the calling plugin is now zero-based.
To Reproduce / Source Code Example
Check XPMPPlanePosition_t::multiIdx
returned for any aircraft and compare with multiplayer idx of dataRefs, it's always one too small.
Expected behavior
Should be 1-based as 0 is the user's aircraft.
Version
Additional context
Report on the support forum.
Current Situation / Problem
XPMP2-Remote by default displays aircraft labels. It is neither synched with the feeding applications nor can it be configured on the client side.
Suggested Solution
Provide a 3-way switch via menu:
Benefits
Have control over the display of labels at the remote clients.
Additional context
Mentioned a bit hidden in a review.
Hello, I'm working to change your version of libxplanemp for your new XPMP2 for my FF2Play project.
It works fine on win and linux.
On macos , the cmake try to find ../Info.plist on build folder.
Because my project use XPMP2 as a git submodule and CMakeList.txt use add_subdirectory and link directly to the XPMP2 lib.
I success to build by replacing "../Info.plist" by ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist in your CMakeList.txt
anyway many thanks for yours works, the lib works fine with the last Xplane beta ;-)
Sorry for posting this as an issue, it's more of a question.
On this repo you say we need to run the CSL2XSB.py script to convert X-CSL models to get all functionality, but on the CSL2XSB xplane forum page, you write that it is unnecessary.
So, I understand I can use XPMP2-based plugins without the python script, but will I have full functionality?
Thanks!
Describe the bug
the labels only appear for the planes showing on my central monitor (main monitor). Those on the 2 side monitors have no labels, but acquire them as they cross into the middle one.
Also, users consistently report (for ages already) that in VR labels are seen in one eye only. Assuming that the second eye is technically provided as a second screen, this issue is actually the same.
To Reproduce / Source Code Example
Need 2 or monitor setup. Enable Labels.
Watch labels for planes on secondary monitor.
Expected behavior
All planes have labels on all monitors.
Version
Additional context
Reported in Discord's beta channel.
Current Situation / Problem
Currently, to understand how XPMP2 works and what it offers, several places need to be read.
Suggested Solution
Consolidate developer's documentation here as GitHub pages:
xsb_aircraft.txt
(this is currently scattered across kuroneko's wiki)Benefits
Easier for developers to use (all features of) XPMP2.
Describe the bug
Engines don't rotate in the sample plugin code. I am on XP 11.5 with Vulkan.
To Reproduce / Source Code Example
Build Sample plugin and install in XP 11.5 and set it to Vulkan drivers.
Expected behavior
Engines/Props would rotate on the aircraft in front of me doing circles.
Version
Current Situation / Problem
Not being singed/notarized makes running plugins on Mac difficult...users have to apply manual solution allowing XPMP2 Remote Client through Gatekeeper
Suggested Solution
Code sign / notarize.
There's a thread on X-Plane.org explaining the essence, including a script used by Laminar, which allows doing all that from within deployment scripts.
Benefits
Plugins "just work" on Mac.
Describe the bug
XP 11.50 Beta 9 introduced a bug that made X-Plane crash as soon as the map is moved a certain distance, ie. the projection parameters changed.
I could reproduce the problem with a slightly changed sample map plugin and filed a bug with Laminar. It was accepted as XPD-10825.
As a workaround XPMP2 disabled the internal map layer. Instead, X-Plane now draws some standard icons into the map for the first 63 planes.
Expected behavior
This issue is entered to remind myself to reactivate the internal map layer once XPD-10825 gets fixed and the fix published in a XP (beta) release.
Version
Up to XP11, planes driven by TCAS dataRefs did not produce wake turbulences. With XP12, a solution is provided:
https://developer.x-plane.com/article/plugin-traffic-wake-turbulence/
Support the newly provided sim/cockpit2/tcas/targets/wake
dataRefs. A few new attributes in the XPMP2::Aircraft
will be required and linked to those dataRefs.
sim/cockpit2/tcas/targets/wake/wing_span_m float[64] y meter wing span of the aircraft creating wake turbulence
sim/cockpit2/tcas/targets/wake/wing_area_m2 float[64] y meter wing area (total area of both wings combined) of the aircraft creating wake turbulence
sim/cockpit2/tcas/targets/wake/wake_cat int[64] y enum wake category of the aircraft. This is for information purposes only and is not used to calculate the actual strength of the turbulence. 0 = Light, 1 = Medium, 2 = Heavy, 3 = Super
sim/cockpit2/tcas/targets/wake/mass_kg float[64] y kg actual mass of the aircraft creating the wake
sim/cockpit2/tcas/targets/wake/aoa float[64] y degrees angle of attack of the wing creating the wake
sim/cockpit2/tcas/targets/wake/lift_N float[64] y Newton instantaneous lift force of the whole wing generated right now, in Newtons
From this post by Philipp, after asking which dataRefs really require being written to:
All of them, for an accurate wake size and strength and lifetime duration estimate. That's why they are there! The wing area, span, t/o weight are public data for all aircraft types (maybe not all military ones), so you should be able to build a lookup table for ICAO type A320 to 123sqm of wing area and 34m of wing span. The weight you could use a certain percentage of MTOW, which would also be a lookup by type. Maybe you could change the weight based on the departure/destination airports if they are known, so that a long range flight weighs closer to maximum than a short range flight.
The lift force in Newtons is weight times 9.81 almost all of the time. You set it to 0 once the weight is carried by the wheels, so you don't leave a wake when taxiing on the ground so you don't blow people of the taxi way. During takeoff you can phase it in when approaching lift-off speed. During flight, lift force should equal weight times g, otherwise the plane wouldn't fly. If you wanted to be super accurate, you could calculate the acceleration vector along a trajectory of the aircraft of a few seconds to determine turning forces (i.e. calculate the g the pilot is pulling to achieve the turn radius given the speed). But for airplanes other than military or aerobatic I don't think the difference from 1g will ever be significant.
XPMP2 is aware of a plane's wake turbulence category (WTC) from Doc8643 data: L
, L/M
, M
, H
, and J
. So the idea is to provide some default data per WTC value.
In case of no change, X-Plane will always apply a default assumed plane size matching a 10t business jet (see above developer article).
Wake turbulences...so don't fly close to the generated traffic!
There is a long-standing issue TwinFan/LiveTraffic#59.
Current Situation / Problem
Currently, XPMP2 treats the "id" of a CSL model as defined in the OBJ8_AIRCRAFT
line, as unique across all models:
EXPORT_NAME __Bluebell_Airbus
OBJ8_AIRCRAFT A320_DLH
Strictly speaking this violates the xsb_aircraft.txt
specification, which "only" stipulates that the id must be unique within a package, which is defined by the EXPORT_NAME
line.
Currently, if another package also defines a model named A320_DLH
it will be ignored.
Suggested Solution
The other package's A320_DLH
shall also be read and be available.
If now an A320 of DLH is requested, then XPMP2 will find 2 models matching the request and will pick one of them randomly.
Technically, this can probably be easily achieved by changing the definition of CSLModel::cslId
from that name after OBJ(_AIRCRAFT
only to a combination of EXPORT_NAME
and OBJ8_AIRCRAFT
name, like __Bluebell_Airbus/A320_DLH
in the above example, which then would be different from, say, A320/A320_DLH
as used by the X-CSL package.
Benefits
More models will be used.
Will certainly make debugging matching even more complex...
Current Situation / Problem
Each CSL model definition comes with one ICAO
/AIRLINE
/LIVERY
/MATCHES
line. Or, if there were multiple of these lines, then the last definition would win.
Suggested Solution
Allow the use of multiple such lines to define multiple matching criteria for which the model would be a match. While this will rarely make sense for different airline liveries, it can make sense to more easily allow the assignment of special liveries to a limited set of airframes.
Would look like this:
OBJ8_AIRCRAFT A320_DLH_StarAlliance
OBJ8 SOLID YES __Bluebell_Airbus/A320/A320_DLH_SA.obj
VERT_OFFSET 3.5
LIVERY A320 DLH D-AIQD
LIVERY A320 DLH D-AIQW
LIVERY A320 DLH D-AIUD
**Alternatives**
Currently, the full set of all 4 lines would need to be repeated per airframe.
**Benefits**
Makes it easier to define special liveries for a limited set of airframes.
**Additional context**
Idea came up when writing [this forum comment](https://forums.x-plane.org/index.php?/forums/topic/212454-adding-new-texture/&do=findComment&comment=1918245).
Describe the bug
CTD in the call to XPLMInstanceSetPosition
:
void Aircraft::DoMove ()
{
// Only for visible planes
if (bVisible) {
// Already have instances? Or succeeded in now creating them?
if (!listInst.empty() || CreateInstances()) {
// Move the instances (this is probably the single most important line of code ;-) )
for (XPLMInstanceRef hInst: listInst)
XPLMInstanceSetPosition(hInst, &drawInfo, v.data());
}
}
}
According to log situation seems to be:
0:53:34.341 LiveTraffic WARN LTFlightData.cpp:2343/DetermineAcModel: Tracking data for 'A8FA3F' (man 'Cessna', mdl '402C') lacks ICAO a/c type code, but derived C402 from mdl text
0:53:34.341 LT/XPMP2 INFO CSLModels.cpp:1085/CSLFindMatch: MATCH INPUT: Type=C402 (WTC=L,Class=L2P,Related=131), Airline=KAP, Livery=N678JG
0:53:34.341 LT/XPMP2 INFO CSLModels.cpp:1191/CSLFindMatch: MATCH FOUND: Type=C421 (WTC=L,Class=L2P,Related=131), Airline=BGM, Livery= / Quality = 16 -> BB_GA C421_BGM
0:53:34.341 LiveTraffic INFO LTAircraft.cpp:1191/LTAircraft: Added aircraft A8FA3F (C402 9K331), operator '', a/c model 'BB_GA C421_BGM', flight model [GA], bearing 125, distance 5.7nm, from channel OpenSky Live Online
.obj
got successfully loaded0:53:34.366 LT/XPMP2 DEBUG CSLModels.cpp:177/Load: Async load starting for __Bluebell_GA/C421_BGM from Resources/plugins/LiveTraffic/Resources/CSL/BB/BB_GA/C421/C421_BGM.obj
0:53:36.622 LT/XPMP2 DEBUG CSLModels.cpp:234/XPObjLoadedCB: Async load succeeded for __Bluebell_GA/C421_BGM from Resources/plugins/LiveTraffic/Resources/CSL/BB/BB_GA/C421/C421_BGM.obj
if
statement):0:53:36.648 LT/XPMP2 DEBUG Aircraft.cpp:484/CreateInstances: Aircraft 0xA8FA3F: Instance created
--=={This application has crashed because of the plugin: LiveTraffic}==--
(Art controls are modified.)
Note the fact that art controls are modified...but in this case it looks rather like a lame excuse.
To Reproduce
Yet unclear
Expected behavior
No crash
Technical Info:
Log.txt
When used in a master client configuration with external views (each running XPMP2-Remote), LiveTraffic (Master) sends out the position data for the remote clients on the first NIC listed in windows. When first NIC is disabled, traffic is seen on clients.
Send multicast data over same nic used for external view configuration. Or have a drop down selection for which NIC to use for sending data.
Current Situation / Problem
Let's assume we have:
With the current matching, the B739_DAL model would be picked because of the exactly matching aircraft type. However, in this scenario, the B738_AUI would visually look better.
Suggested Solution
We need to raise importance of livery. But it cannot be raised fully above aircraft type, there must be a limit.
The limit should be related.txt
. So the rule could probably be:
Benefits
Looks better if "related" models with matching livery are available.
Additional context
First that based on this support thread.
Current Situation / Problem
No value for flight_id
is currently transferred to the Remote Client.
Therefore, the dataRef sim/cockpit2/tcas/targets/flight_id
is not populated.
Suggested Solution
flight_id
is populated with what the virtual function XPMP2::Aircraft::GetFlightId()
returns. Transfer this value via message to the Remote Client in a new field. That requires a new version of the RemoteAcDetailTy
message and therefore handling and testing of cross-version scenarios.
On the remote side, the value can then just be stored in XPMP2::Aircraft::acInfoTexts.flightNum
, from where it will automatically be used for populating the dataRef sim/cockpit2/tcas/targets/flight_id
.
Benefits
dataRef sim/cockpit2/tcas/targets/flight_id
filled in instances where TCAS/AI is controlled by the Remote Client.
Additional context
Thread on X-Plane.org.
Current Situation / Problem
Subsidiary airlines operate under their own airline code but use liveries (or even actual planes) of their mother companies. These often new subsidiary airlines codes aren't mentioned in the often older xsb_aircraft.txt
files. As a result, planes of the subsidiary airline are rendered with a random livery although probably a matching livery for the mother company would be available.
Suggested Solution
Provide a way to match subsidiary and mother company, similar to what happens to aircraft type codes in the related.txt
file, just for airline codes, like
; Aer Lingus
EIN EUK
; Ryan Air
RYR RUK
Alternatives
Lots of fiddling right in the xsb_aircraft.txt
file to add AIRLINE
lines under each EIN
model to also allow matching for EUK
.
Benefits
Better livery matching for subsidiary airlines.
Additional context
Suggested in a forum post.
Describe the bug
User report: X-Plane froze, last line in log is
LT/XPMP2 ERROR Sound.cpp:835/SoundUpdatesDone: FMOD Error 36 - 'The vectors passed in are not unit length, or perpendicular.' in FMOD_System_Set3DListenerAttributes
To Reproduce / Source Code Example
Unclear.
But can probably be forced in debugger by sending wrong coordinates into FMOD_System_Set3DListenerAttributes
.
Expected behavior
Version
Log.txt
Log-Snd_Freeze.txt
Additional context
Original user report is a comment to LiveTraffic.
More discussion then tracked in a support thread.
Hello,
I'm having some troubles with this implementation. I have sub-classed the XPMP2::Aircraft
class through MyAirplane
class.
class MyAirplane : public Aircraft
{
public:
MyAirplane(const std::string& _icaoType,
const std::string& _icaoAirline,
const std::string& _livery,
const std::string& _modelName = "") :
Aircraft(_icaoType, _icaoAirline, _livery, _modelName)
{
}
virtual void UpdatePosition()
{
SetLocation(Position.lat, Position.lon, Position.elevation);
drawInfo.heading = Position.heading;
drawInfo.pitch = Position.pitch;
drawInfo.roll = Position.roll;
}
XPMPPlanePosition_t Position;
};
Currently, I'm using a std::map
to hold the MyAirplane
objects. The issue I'm having is that any object that is inserted into my map is almost immediately destructed through the within XPMP2::Aircraft
. I am able to see this because I implemented the CBPlaneNotifier
and each aircraft object is created and then destroyed.
Am I going about this the wrong way? If so, what is the best way to keep a collection of planes so that I can update them?
std::map<std::string, MyAirplane*> m_Planes;
MyAirplane *aircraft = new MyAirplane(typeCode, airlineIcao, liveryStr, modelStr);
m_Planes.emplace(key, aircraft); // key is the aircraft's callsign/tailnumber
Current Situation / Problem
Currently, XPMP2 Remote Client has a menu item in the Plugins menu that shows "Active"/inactive state, but that also serves as a toggle (i.e., which users can click on to change the state to inactivate the concentrator, while leaving the plugin enabled).
In fact, the only way to toggle the plugin's "active" state, is to use the menu. (There is no command or other way to trigger this functionality otherwise.)
This results in several (albeit minor) problems:
Suggested Solution
XPMP2_Remote_Client/Aircrafts/Display
" (analog to version in LT).
XPLMAppendMenuItem
invocation for activate/deactivate toggle, with XPLMAppendMenuItemWithCommand
referencing the new command registered above.Alternatives
Benefits
Additional context
(None; this is scoped only to the XPMP2 Remote Client plugin.)
Understanding this is a slippery slope that could lead to extra work that I do not intend, such as persistent settings and other commands -- this is very low-hanging fruit and is really all I think users need. Therefore, I believe a lot could be accomplished using this suggested behavior, for very little work (registering a command, changing the current toggle to be inside a command handler, and changing XPLMAppendMenuItem
to ...WithCommand
.
Thanks for considering this.
Describe the bug
XPMP2 does set a number of TCAS target-related dataRefs, but not
sim/cockpit2/tcas/targets/position/weight_on_wheels
This should be set to true
when the plane is on the ground.
Currently, though, XPMP2 does not generically know when a plane is on the ground. This will require a new interface function Aircraft::SetOnGnd()
for plugins to inform XPMP2 about a plane being on the ground.
As an additional service, this new function can be coupled with Aircraft::SetTouchDown()
, which currently only directly controls the libxplanemp/misc/touch_down
animation dataRef, which typically causes CSL objects to emit tire smoke. XPMP2 could offer to automatically control SetTouchDown
, like in
Aircraft::SetOnGnd (bool bOnGnd, float fSetTochDownTime = NAN);
with fSetTouchDownTime
being an optional parameter denoting for how long the touch_down
animation dataRaf is set to true
.
Todos
Aircaft::Is/SetOnGround()
sim/cockpit2/tcas/targets/position/weight_on_wheels
TCAS target dataRefSetOnGround()
with SetTouchDown()
To Reproduce / Source Code Example
Updating this dataRef is missing in AIUpdateTCASTargets()
.
Expected behavior
sim/cockpit2/tcas/targets/position/weight_on_wheels
should be set to true
when plane is in the ground.
Version
Additional context
First reported and locally implemented for xPilot in xpilot-project/xpilot#34.
Problem
This has been reported to Laminar and accepted as XPD-10727:
On Mac OS, in XP 11.50, at least Betas 3+4, and in OpenGL-mode only, X-Plane crashes after a plugin set a user's aircraft model via a call to XPLMSetAircraftModel.
Current Situation in XPMP2
XPMP2 currently includes a safeguard against this crash in form of the config item XPMP_CFG_ITM_SKIP_NOPLANE = "skip_assign_noplane"
. This is on most cases by default false
, only in case of Mac + OpenGL this defaults to true
. As a standard config item it can be overwritten by the calling application in the configuration callback.
This config item controls globs.bSkipAssignNoPlane
, which in turn in function AIInitPlanes
controls if the call to XPLMSetAircraftModel
is actually performed.
If the call is not performed, then X-Plane's AI/multiplayer planes will be shown as configured in X-Plane's aircraft settings. If the user configured standard planes there, then they will show in the 3D world overlaid on the XPMP2 planes. Same goes for the map: Two icons stacked over each other.
Workaround: On Mac (and others if he likes) the user could copy NoPlane.acf
into the Aircraft
folder and then directly assign as an AI plane type. Then again would X-Plane not draw anything into "our" 3D world.
Next Steps
This issue is to track XPD-10727. If it got fixed all the code related to XPMP_CFG_ITM_SKIP_NOPLANE
/bSkipAssignNoPlane
can probably be removed again.
Describe the bug
After a long (2.5h) LiveTraffic session with lots of traffic, a couple of reference counters don't reach 0 during shutdown. The cars combined even stay at 8:
2:30:32.287 LT/XPMP2 DEBUG CSLModels.cpp:197/Unload: Object __XCSL_CARS/CARS_FollowMe / Resources/plugins/LiveTraffic/Resources/ShippedCSL/XCSL_CARS/ZZZC2.obj unloaded
2:30:32.287 LT/XPMP2 WARN CSLModels.cpp:348/~CSLModel: Reference counter is 3 while object is being destroyed for __XCSL_CARS/CARS_FollowMe
2:30:32.287 LT/XPMP2 DEBUG CSLModels.cpp:197/Unload: Object CARS/CARS_ZZZC / Resources/plugins/LiveTraffic/Resources/CSL/X-CSL/CARS/ZZZC2_ZZZC2.obj unloaded
2:30:32.287 LT/XPMP2 WARN CSLModels.cpp:348/~CSLModel: Reference counter is 5 while object is being destroyed for CARS/CARS_ZZZC
To Reproduce / Source Code Example
One way to make it very likely to happen is in LiveTraffic:
Re-load an already loaded CSL package. That will ask all flying planes to re-assess their models, but as no actually new models are available many planes will pick the very same model once again, which causes the invalid reference counter handling, see below.
Expected behavior
No such messages, reference counter should reach zero in all cases.
Version
Log.txt
Log_RefCnt.txt.zip
Additional context
Discussed on Discord, but I have seen such messages in xPilot logs before but had at that time attributed to wrong implementation there. Unclear, as I don't know their implementation.
Current Situation / Problem
XPMP2 has built-in support for a set of shared dataRefs to provide textual aircraft information. This pre-dates the TCAS Override approach and hence uses an older and more cumbersome model of naming the dataRefs...but, hey, it's there.
The Remote Client cannot currently populate reasonable values there.
Suggested Solution
Transfer necessary values to the Remote Client, likely by extending the existing RemoteAcDetailTy
message. (Alternative would be to use a new message...but that triggers follow-up issue for how to create new planes and how to synch starting Remote Clients.)
RemoteAcDetailTy
message, requiring a new version of that messageBenefits
More info to the world, also for the remote instances. FSTramp does use it already.
Additional context
Lacking support noted when entering issue #26.
If XPMP2 matches to a different ICAO type code than what was requested it would be good for the client code to see what it matched to. I could use this to play the appropriate engine audio files.
There is currently and accessor for the model name that was matched but not for the icao type code.
Alternatives
A fully defined pointer to the cslModel would work too. Unfortunately that is just a forward declare in the end user header files
Benefits
See above
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.