Hi Jonathan,

I think the FP callback is the preferred way – plugins are already using it for one-time graphics prep, so we have to keep supporting it, and it has no fine print abotu when it is called. The cost of a callback is usually cheap compared to the cost of what you do in it. (And if you already have a FL CB you can reuse it.)

For phase objects, I’d say this: the original API as shown in the headers describes x-plane 6 – it’s pretty much impossible to even pretend the abstraction makes sense. So all we can do for now is document what really happens and provide a narrow set of best practices that work in an understandable way. Since the object callback phase provides none of the benefits that it used to in v6 (and none compared to airplanes), I say do all 3-d drawing from airplanes – it’s the closest thing to the API we do want for now.

(In the long term we’ll make a newer API that better maps to what we have, but since it will only be usable in newer sims, the awkward procedure we have now is not just ‘what we have now’ but also the only way to span v9 and v10.)

cheers
Ben

I do not recommend ANY per-frame calls in drawing callbacks – use the flight loop CB – you’ll actually get called once per frame. 🙂I guess my thinking was that I’ve already registered a draw callback, so why add the overhead of also registering a flightloop callback? But happy to move per-frame calculations into the flight loop if that’s the preferred way.

I don’t recommend using xplm_Phase_Objects at all.Not even for drawing ground-level scenery-type stuff?

All true. I should add sample code, it would clarify. Other notes:

– I do not recommend ANY per-frame calls in drawing callbacks – use the flight loop CB – you’ll actually get called once per frame. 🙂
– I don’t recommend using xplm_Phase_Objects at all.

cheers
ben

In practice, every frame, your ‘draw’ callback is called:
– Once for drawing reflections (if you’ve called XPLMEnableFeature(“XPLM_WANTS_REFLECTIONS”, 1) and reflections are turned on in the user’s preferences). During the callback sim/graphics/view/world_render_type == 1.
– One or more times for drawing shadows (if shadows are turned on in the user’s preferences under X-Plane 10). During the callback sim/graphics/view/world_render_type == 3.
– Finally, once for drawing the actual object normally. During the callback sim/graphics/view/world_render_type == 0.
(The is is what happens if you register your callback for xplm_Phase_Objects – haven’t tried with other phases).

If you have complex calculations that you want to perform every frame, then it’s a good idea to check the value of the sim/time/total_running_time_sec in your callback, and only perform those calculations when that value changes (i.e. when you’re on to the next frame).

I see Skymaxx Pro as taking a very different approach to clouds than what we use – we looked at multiple third party cloud engines during v10 dev and picked the solution we ship now. That decision was partly a technical and business decision, but it’s also partly aesthetic.

Therefore it doesn’t surprise me that we get two very different responses on weather. Some users love our weather and don’t see any value to SkyMaxx Pro. Other users love Skymaxx Pro, were never happy with our weather, and now consider what we did obsolete.

So I don’t see Skymaxx Pro as taking the pressure off of us to fix bugs in our own weather system; rather I see them reaching an audience that didn’t like the ‘what’ of what we coded, not the ‘how’.

The “fog bug”* is different – it can only be fixed inside X-Plane – that’s on us, and there’s a fix in progress.

For the ATC networks, I think it’s a question of immersion…at some point an AI ATC is never going to be as immersive as having real live humans with VoIP.

Cheers
Ben

* Is the fog bug a bug, or just a limited (and unsatisfactory design)? Turns out it’s both; I am working on fixing the bugs in the lighting model that make the fog bug worse _and_ increasing the visibility range with more DSFs, something we have had in the road map for a long time that requires 64-bit.

Hi Eric,

I have not heard anything about horizon-cloud visibility, so I cannot comment on this.

But I hate how the clouds aren’t visible on the horizon when you approach a line of clouds. They blame is on XPX. Hopefully there is a solution in the near future ? !

It did make me wonder though, does LR take into account the availability of add-ons when deciding where to focus future development? For example, a lot of commenters on your (excellent, informative and insightful!) blog have bemoaned the lack of towering cumulus and poorly implemented fog. I recall that you have stated on a number of occasions that the fog problem is one which you guys are intending to address at some stage. But when there’s a high quality third party add-on readily available, which, by the sound of it, does a particular job better than the existing inbuilt solution, does that dissuade you at all from spending time on further development for that part of the sim?

Same with the inbuilt ATC vs online ATC networks etc?

I’m just curious because the SkyMaxx Pro developers, on their blog, have said that they have worked closely with you on the product.