MSFS20 Mouse zone or objects in background which are selectable

[Lagaffe]

Hello guys,

My problem is the following:
On the current aircraft I develop I have several mouse zone or clickable objects distributed on the Y axis while being placed on the X and Z axis
The problem is that when I am in the cockpit trying to click on an object that is located on the main panel, it happens that the mouse selects an object that is placed behind what breaks the immersion.

For example, on the propeller I created a mouse zone to be able to make "pull through" via the propeller or make start the engine as "hand start" but in the VC, trying to click on another mouse zone attached to a gauge for example, if the mouse move a few pixels select the mouse area of the propeller and have its tooltip that displays what I would not like if possible.

I use Blender 2.83.19 with the Blender2MSFS plugin in version 0.41.4

I placed a plane with an MSFS Collision material right in front of the main panel thinking that it would mask clickable objects placed behind the pilot’s point of view but it didn’t do what I thought
Of course there is also a cube all around the fuselage with an Occluder materialbut this one is supposed to prevent the external elements (rain, snow or grass, etc) to enter the cockpit

Concretely when I try to activate a mouse zone placed just in front of a gauge (before the collision planes), in some cases, the mouse zone on the propellers is activated ...
How can this not happen?
Is the pluggin version too old and buggy on this technical point or is it my plans/ volume that are poorly placed or too small?

Thanks for your advices.

 

[=rk=]

It sounds like you need an EFB and curious about collision planes because they are supposed to constrain mouse clicks to the visible side of the panel. Presumably you are trying to reach over the panel plane, but hotspots affect the entire mesh, which is the entire propeller. Realistically, no one is going to reach out over the cowl to spin a propeller anyway, right? The hotspot is representational of the pilot signalling for someone to crank his engine for him, or getting out and doing so himself. Therefore, if you had a nice hand painted sign that says "please crank my engine" in a cockpit side pocket that your mouse drag/slide deftly snatched and held up, it would be a cool animation, not intersect other hotspots and also crank the engine.

 

[Lagaffe]

Perhaps I misspoke so I will give more information:
1- I already have an EFB that works very well
2 - the manual is very explicit on the hand start since it requires to use a specific camera to move outside the aircraft and the click on the blades (the camera is OK and functional)
3 - when I write that when I want to select the hotspot on the gauge to have an action available or the tooltip of this gauge displayed, I have the tooltip of the propeller which is also displayed quite simply, I do not seek to activate the hand start.
To express myself differently: in the cockpit I would like to be able to click only the selectable objects which are physically in the cockpit and not those that are 5 m behind.

On the next screen, I am in the cockpit and my mouse is over the left pedal but the tiedowns tooltip can be displayed ... but the tiedowns are not displayed because: they are behind the fuselage.

These objects behave as if the fuselage was transparent and my mouse had X-ray

In the current state of the SDK, one cannot interact with objects defined in the Exterior model, simply with those in the Interior model.
These objects and mouse zone are all in the Interior model which does not prevent to comply with reality to move virtually with the cameras to go in front of the propeller and operate the "hand start".

So actually does the plane with the collision material hide clickable objects behind the plane or did I make a mistake in the meaning of the properties of this material.
I must not be the only one to have this kind of inconvenience but maybe it’s an asobo bug

 

[=rk=]

So actually does the plane with the collision material hide clickable objects behind the plane or did I make a mistake in the meaning of the properties of this material. I must not be the only one to have this kind of inconvenience but maybe it’s an asobo bug

Actually you might be and I wouldn't be so quick to blame Asobo, unless you want to sound like me. The stated purpose for the collision plane in the SDK is to prevent the mouse from intersecting the panel, it is not defined to prevent the mouse from clicking co linear but not coplanar hotspots. Your assumption isn't really supported, nor do I interpret it to be a bug, if perhaps a deficiency.

PANEL_COLLISION​

This refers to the collision mesh that only exists around the different instruments and that is roughly approximate to the shape and design of those instruments - essentially the geometry must simply stay at the average position of the instruments (overlaying the panels is fine). This prevents the simulation from having strange behaviors when moving the mouse around the instruments where the mouse can switch between colliding with an instrument and colliding with the cockpit panel. It is mandatory to have this mesh to have good collision behavior around the instruments. Also for now the depth when colliding with a virtual cockpit is retrieved thanks to the mesh it is on, so no collision mesh means bad interaction with virtual cockpits.

On the next screen, I am in the cockpit and my mouse is over the left pedal but the tiedowns tooltip can be displayed ... but the tiedowns are not displayed because: they are behind the fuselage.

Right, presumably because the left pedal is not in line with other hotspots. I think it would be more practical to replace the propeller hotspot with a checkbox in the EFB. If not, another idea is that you could place an invisible mesh above and beyond your panel collision plane, about where the tip of a propeller would be and attach your hotspot to that.

 

[Lagaffe]

Ok, so despite having reread the SDK several timesI understand that I imagined things that are not with this notion of "Panel Collision" (mea culpa but english isn't my native language)

Having noticed that these mouse zones did not pose any problems in the Tiger Moth of Ants, I allowed myself to redo a test of this aircraft with MSFS and then to look carefully at the XML codes.
I discovered two things:
1 - the mouses zones are no longer reserved for the Interior model since I found some of them in the Exterior model that allow to open the side doors of the engine compartment (by linking them to camera predifined)
2 - it is possible to make mouse zone invisible as you do with ordinary objects (why not think about it earlier because it is the simplest solution )

By putting the will, we learn new things every day, I think I have found the answer to my questions, so I have to review the XML code already written taking into account these three elements of answer.

Thank you for your participation .

 

[=rk=]

Very cool, thank you about the hint for exterior hotspots, I have an engine compartment I want to include and this sounds more elegant than a switch on the panel. The Simple Aircraft sample project has a hotspot on the front landing gear steering hub that used to catch my cursor in the cockpit while I was using that xml argument. That model uses the combined exterior/interior "normal" and I believe the hotspot may be there to include the front landing gear on the checklist, which requires tooltips, which require click spots.

 

[Anthony31]

Very cool, thank you about the hint for exterior hotspots, I have an engine compartment I want to include and this sounds more elegant than a switch on the panel. The Simple Aircraft sample project has a hotspot on the front landing gear steering hub that used to catch my cursor in the cockpit while I was using that xml argument. That model uses the combined exterior/interior "normal" and I believe the hotspot may be there to include the front landing gear on the checklist, which requires tooltips, which require click spots.

View attachment 92284

Is "Appoach" how it's spelled on the real aircraft?

Yes, I used the NodesToHide function in the camera.cfg to hide clickspots in certain camera views. I think I've written about it somewhere here before but essentially the NodesToHide is a list of L:Vars that get set to 1 when the cameradefinition they are used in is active. It's also a great way to hide/show pilots/passengers/yokes/etc depending on the view.

As I understand it the Panel Collision is mostly a VR thing as it helps the VR "focus" on the cockpit but I may be mistaken about that.

 

[=rk=]

Is "Appoach" how it's spelled on the real aircraft?

I've been looking at it for a year now and publishing videos and no one's said a thing so I'm going to have to say "yes." I must thank you for your kindness however, you could have waited for me to publish and really gotten a good laugh.

 

[Lagaffe]

Indeed, I had also noted this function NodesToHide but according to last SDKs, it becomes deprecated and is replaced by VarToggle.
If this last function simply replaces the first one it will avoid headaches to try to understand .

Usage of VarToggle in the camera.cfg:

VarToggle: This parameter functions as a simple toggle for local variables. You supply one (or more) L: Vars and then when the camera is active the variable will be toggled to 1 (TRUE) and when it is deactivated it will be toggled to 0 (FALSE). This is useful, in particular when using different model behaviours - for example using the visibility template to to hide the yoke when a specific camera that is viewing an instrument. Note that this toggle of the L: var will only happen if it's value is less than one when the camera is selected. If it is already 1 (or greater) then the toggle will not happen, and that includes it being set to 0 on switching away from the camera. To add a new L: var you can click the + button then give the name of the node that you want to hide. You can remove any of the L: vars by selecting it then clicking the x button.