There is currently a limit on the number of bingmap displayed in the cockpit.
Some instruments may have 2, 3 or 4 maps and you could have 4 instruments in the cockpit.
See attachment: the toolbar panel bingmap layer is not displayed because of this limitation.
It would be nice to extend the limit.
Currently, the limit is 10 bingmaps in the cockpit.
If you consider the picture above (Sting S4), you may have a G3X MFD (4 maps), a G3X PFD (4 maps), a GTN750 (2 maps), a GTN750 panel (2 maps), the VFR map (1 map).
The great total is 13.
So pushing the limit to 13 should cover most cases without affecting too much the memory.
Yes we wholeheartedly agree. Please increase the limit. 
It is also very easy to lose a map on something which does not enable re-use of that bing ID. So even though 10 maps concurrently visible sounds like a lot, it’s likely that the user is going to actually hit the limit while working in the cockpit but never actually be showing close to 10 at a time.
This indeed represents a problem, below a picture with the real aircraft configuration showing 2xPFD + 1 x MFD (another configuration offered with my product besides the GTN 750):
That’s how TL-Ultralight sells the aircraft and requires me to show case it in MSFS exactly like that, with the previous G3X we never got a problem it seems the limits were fine, however with the new G3X implemented with SU15 the limit is being hit very quickly and my beta test users are ended with no maps in the units in many occasions, so I think increasing it to 15 would be ideal.
As I understand, with the new G3X each unit uses 4 maps, so to represent 2xPFD + 1 MFD we are already above the 10 limit… 4x3 = 12.
Regards,
Raul
FSReborn
I agree and think this needs to be addressed.
Hello everyone,
Unfortunately, this limitation is there for stability and performance reasons and this is unlikely to change.
Working Title is trying to address this by adding more configurability to their instrument.
I will update this post when I can give a more detailed insight.
Regards,
Sylvain
Hello everyone,
Here’s the documentation for the option that was added to the G3X to address this limitation, available with 1.37.8.0:
G3X Touch Instrument Setup | MSFS Avionics Frameworks and Instruments (microsoft.github.io)
Regards,
Sylvain
That’s indicated in the documentation.
1 per option and per GDU instance as far as I can tell.
Regards,
Sylvain
Many thanks Sylvain @FlyingRaccoon,
I am a bit confused thought, as I understand each G3X PFD GDU is apparently using 4 bing maps, so why disabling the maps options would only reduces 1 bing map? I would thought this should give you at least 2 back… leaving the synthetic vision intact with 1 bing map for it?
if indeed we can only reduce 2x maps by disabling everything, I think is safer then to mirror the second PFD as we do with the WT G1000 units because disabling the synthetic vision would make users unhappy, and disabling the inset on PFD 2 would barely bring down the usage for aircraft with 3 x GDUs like the Sting S4.
Any advise of what is the best method to mirror the second PFD so we can save x4 bing maps instead?
Many thanks to you, Asobo and the working title team for implementing methods to alleviate the problem,
All the best,
Raul
I’m not very familiar with that instrument yet but I assume some maps were already shared by menus that are exclusive.
For mirroring, we do this by using the same material for both PFDs.
That way the target texture name provided in the VCockpit config ends up being applied on both PFDs.
Regards,
Sylvain
Since the limit cannot be changed there are still potential strategies to improve the situation:
We’ve accumulated a lot of naive html/js code in MSFS that simply updates on each call to Update(). The built-in MSFS support for html/js omitted any ‘standardised’ way of reducing update rates on a per-function basis, and alternative methods (like reducing the calls to the instrument Update() from outside the gauge) miss out on all the real opportunity for optimisation inside the gauge.
Here’s the generic code I use to limit the update frequency within my instrument class:
// Performance optimisation - return true if function 'fn_name' was not called within past period_ms milliseconds
DoUpdate(fn_name, period_ms) {
if (this.Updated_timestamps == null) {
this.Updated_timestamps = {};
}
let now_ms = performance.now();
let prev_ms = this.Updated_timestamps[fn_name];
if (prev_ms == null || now_ms - prev_ms > period_ms) {
this.Updated_timestamps[fn_name] = now_ms;
return true;
}
return false;
}
And then within sub-functions in the gauge:
update_page_horizon(instrument) {
if (!instrument.DoUpdate("update_page_horizon",33)) return;
...
}
This code could be optimised further (e.g. not using string keys) but compared to the raft of unoptimised html/js gauge code out there it’s a radical improvement that any external Update() frequency tweaking is never going to match. This method is best leaving Update() at the native frequency, but ensuring each call it makes is optimised.
A moving map update can be optimised including the zoom level.
But I do think a general capability such as this should be a core part of the html/js support and included in the html/js gauge samples.
Your reply seems to be unrelated in any way to the topic (which is about the number of BingMap instances the sim supports). Perhaps you meant to post elsewhere? That being said, the map framework within the MSFS Avionics Framework (recommended) already includes many options for adjusting the update rate and triggers for many different map layers.
If not, I would open a new topic with your question or suggestions, thanks!
-Matt
As indicated in the documentation, each option eliminates one map usage. One option removes the inset map, and one option removes SVT. We did not add options to remove the main map (the other two BingMap instances, one for the terrain layer and one for the nexrad layer) as we felt it did not make sense to have a G3X with no moving map at all.
Therefore the most instances you can remove is 2 from each GDU.
I would do what many of the default planes do and just have the one PFD instrument render to two textures via panel.cfg (good example is the Caravan) if that’s the route you want to go.
Views actually do release their bing IDs when destroyed, but the issue is instrument views aren’t destroyed until the flight is ended. In almost all cases, having views be able to unbind BingMaps would not help, as there is always the potential to use them depending on what the user is doing.
In other words, all of our instruments already share IDs all over, but for the G3X it is possible for a user to have the inset map, SVT, main moving map, and the waypoint map up at the same time, thus even with ID sharing the number of maps bound cannot be reduced under that number without explicitly disabling features.
-Matt