This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent. if the knob is being driven by a custom manipulator or command or some internal plugin path. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would. The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000. the autopilot VVI and altitude) to a fixed grid every frame. X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales. The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. I’m hoping to have beta 16 out Monday or Tuesday. (Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!) From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance. I also made some progress on cloud tuning last night I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy. If we don’t fix cloud perf, the build isn’t useful. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. You can see where this is going – those things are totally at odds with each other.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |