That works, but the older Wiki site did not require that. We would have one more step to research something, and time is valuable. Why there was any need to change the look of the information is beyond me. Developers don’t give 2 cents about how pretty a site is, only how quickly they can drive to the answers they need. Get a graphics guy involved and… 😉

Good idea to resolve the code display problem.

We have these beautiful widescreen displays these days, and they’re a boon to use, as long as practical decisions are made. The SDK site only uses half of the available width.

Yeah, the use of the declaration with no buffer overrun conventions is definitely a mistake – one that dates back to the original API. In the modern extensions we’ve used callbacks, so that no one is ever filling in someone else’s buffer.

This kind of thing is hard to fix – a wise person once told me (one blog commment ago 😉 that amongst the golden rules of API design are to not introduce incompatible changes.

Hi,

I humbly suggest to add a button, before the code example, to allow to display the code in a popup window where all the width assets will be used. If it will be colored too then great.

My 2 cents, if LR doesn’t want to invest in this, just copy paste the code to your editor, that’s what I have done.

Cheers

Steps 2) and 3) could be one if you define exact rules what is allowed, and everything that is no allowed is forbidden then (telling what is allowed, and what is forbidden, amy leave some grey zone behind).

At the moment, some specs are rather “thin”, like https:/sdk/xplm_Phase_Objects/ 😉

Ah, I see what you mean now…I was thinking on a much smaller scale.

For non-2-d rendering, put the sim into “2-d panel only” mode – we’ll bypass stuff in the rendering engine that you can’t get at via the SDK.

1. That’s disappointing, since there is a use model for disabling non-2D rendering on X-Plane slave systems used only for instrumentation.

2. Please reconsider your second, or perhaps third guess, my friend, if you would! 😉

Really, try this on for size and see if you think it’s a sane way to present a code example:

https:/code-sample/draw-terrain-object/

Do *you* use the SDK website for code examples and the like? 😉

Graphics designers apparently do not fully consider long term utility these days. I respect their skills, but if you honestly think that only using less than the full available width of a 16:10 screen is wise for documents that are far more likely to be used by desktop deployments, I can only agree to disagree. 🙂

If nothing else, the code window should be resizable for those of us that don’t refer to the SDK website on a smartphone. 😀 Graphics designers, just as much as we code pushers, can err. And I’m both, for what little that is worth! (So I guess I get twice as many chances to mess up. Aren’t I lucky!)

Re: the SDK layout, there’s one case where I agree with you: cases where the table of contents sidebar would be empty. (This applies only to a few of the sample code pages.) I’ve rolled out a fix for that now.

Hi Steve,

1. Draw disabling is going to get deprecated. The notion that plugins can go in and sanely remove pieces of our rendering pipeline is totally crazy, and even now the support for it is deteriorating because the actual structure of the rendering engine is NOTHING like the set of enums we declared in 2001.

At this point it’s only safe to use a small subset of the draw callbacks, and disabling them is a bad idea.

In the future I expect to publish some guidance as to which callbacks to use, and that guidance will be to never disable things.

2. I think at default page size the paragraph width is acceptable – it could be slightly wider but since it was done by an actual graphic designer and not a programmer, I’m not looking to second guess it.