tkyler

Towards that end, we are changing a lot of our manipulators to 'more modern ones' that are VR friendly. Several of these more modern manipulators were implemented after we assembled our cockpit, and many of them simply doing what we were doing in our own code already. The good news is that these will still work the same for non-VR users, but will allow the VR features of X-Plane to still work without a new cockpit.obj file. J NOTE, this is our first go-round with making a VR friendly setup natively and Jan is checking most everything and having good succes, but once this goes out, as usual, feedback is welcome.

Tweaked...speedbrake lever too

The only RW25 in the fix database (both old Aerosoft and latest Navigraph) is in EL SALVADOR, which is more then 3000 miles from EGAA. As mentioned elsewhere, we cull the global database for only those waypoints that are within range of the aircraft when its loaded. If we did not do that, then it would have loaded that fix, but it would have been the wrong fix anyhow and you wouldn't have seen it on the EHSI, which would probably have been even more confusing. This culing technique saves quite a bit of memory and allows us to search the database much faster, avoiding potential pauses. The fix page reads the fix database of the navdata. I can't say if runway ends could be input in the older version of FMS we simulated, but I wouldn't be opposed to it, in the sense that even FMS software can be updated. Its simply a matter of decideding if its a realistic feature for this simulation. Jan? The FMS manual we used only says, "valid navaid or wpt" and goes on to specifcally say, "the FIX"....so we only implemented those navaids/fixes, which didn't include runway ends. -tkyler

I think he may be referring to the manipulator drag length. i.e. dragging a very short distance on screen results in a large movement of the lever and a very small number of screen pixels you have to hit to land on a detent. I agree this should be tweaked. -tkyler

We have been very clear and forthcoming about our lack of updates and the reasonings behind, as well as stating the nature of this 1.3 update, so if you had high hopes, then you simply didn't come across our postings on the nature of the update before it was released...perhaps we should come up with more formal press release mechanism for IXEG....anyhow, whether or not any of us likes the situation or fallout thereof is irrelevant to the time still required to do the work. If given the choice to lament and say, "yea, its lacking, lets just stop working on it, or "keep going", I'll choose the latter, and once chosen, refrain from bitching about the past and keep pressing. I know folks need to vent their frustration, heck I do it all the time, so vent away, but it won't change our development process, only instantiate contention...its a predictable human thing. Re the cargo doors, they were implemented because they're easier and faster to model. You said the IXEG is (was) one of your favorites...this is because we obsess over details that take a long time to develop, and why we have a reputation as one of the most immersive environments ....and I have yet to see cabin doors that are really accurate and detailed as I know they can be, cause the shapes are so darn tough, and we have a few cool ideas we also want to implement that nobody else is doing...again taking time....but IXEG wants to do it right for that immersion factor. I can't do cabin doors and VNAV and holds at the same time, nor pay for a army of folks to do it (who still may not do it right)...so if I take a month to work on vnav and holds, someone will inevitably come back with, "what...you couldn't get the cabin doors done in a month"?" To be fair, we expect huffing and puffing, you sign up for that when you make products for the public.....but we have not abandoned it, despite appearances. We're back and bringing our attention to detail to the very things that made you like it in the first place. You can choose to be happy we're doing that and encourge the efforts, or keep venting. I myself am happy we've landed on the conditions that allow to work on it full time again and finish what we started. My hope is you can find that also. -tkyler

its restored for the next update. As usual, a victim of our 3D asset reorganization. Thx for catching and reporting. -tkyler

...however..in a pinch, here's a much subdued inlet reflection.... slap this image into your objects folder and overwrite the previous one. In addition, duplicate this file and change the word "left" in the filename to "right" to get the same thing on your right engine.

I do have a paint kit about 95% in the works......that has 3 layer options for "shiny, nearly shiny and dull" for the engine inlet. If you can hold off a bit, I'd like to polish it up a bit more (the photoshop file and instructions, not the inlet) -tkyler

Fixed for next update. A few Blender export script idiosyncracies for "vertical axis" drag situations that I had to figure out. -tkyler

mousewheel direction has been fixed for next patch. the V/S wheel also has scrollwheel support, as does the ASI knobs. I'm locking this topic so I don't have to spend time reviewing posts of known issues.

scroll wheel direction has already been reversed on all the relevant manips for the next update. (and VS wheel also) -tkyler

The current Holds situation is what it is. It has been well known and discussed and is near the top of our short-term todo list. This is the simply the path we must take to get it done, regardless of what has been in the past. We'll get the holds in and won't ask 1 dollar more when we do. -tkyler

that is a user created waypoint, which we do not support.....YET. See the following...

I do like the idea of making this a preference of some type. I have written animation code that allows you to set the "time to switch 2 way switches"...usually in fractions of a second, so folks can tune it to their liking (for click manipulation, not drag); however, its not implemented here in this product. Two way switches typically "snap" position very quickly, and so slow animating switches can look funny. More prefs to tune this is probably the best solution; however, it complicates the cockpit setup as we'd have to keep track of multiple sets of manipulators...doable...just more overhead -tkyler

good catch; however, its stroboscopic effect on the perimeter of the knob, not incorrect turn direction, you'll note the center symbol goes in the expected direction, so the knob is turning in the correct direction, it just doesn't appear to; however, we will adjust it to "look more natural" as the ALT knob. -tkyler

This is a preference IMO. A two way switch, exhibiting "binary state" is well represented by clicking to toggle between the binary states, its very common in lots of planes. This doesn't work for 3-way switches clearly, but does for two-way. While I get what you're saying about the dragging of two way switches for newbies, I'd also say that like anything, once you've done it a few times, it doesn't become an issue and is very intutive...we have a few million clicks by users who have never thought twice about it. Regarding your picture...does what have to be like what? If you mean, "the smoke"....its default x-plane, not us....I don't like it either. .you may have your runway conditions set to 'wet" in your weather settings. You should make sure that setting is consistent with the rest of your weather settings. -tkyler

58W14 is shown as "negative 58º"...which means southern hemisphere. The plane couldn't reach that waypoint from anywhere in Canada without refueling. Great circle distance from +49 latitude (southern border of Canada...ish) to -58 latitude is nearly 4200 NM. The FMC caches waypoints within range of the aircrafts starting location...so we don't end up loading a gazillion waypoints that you can't fly to nonstop anyhow. The range is a circle about 3000 miles from the aircraft location. 5814N is "positive 58º" and in the northern hemisphere, therefore, "in range" if you're in northern Canada and therefore in the database and loads. 58W14 isn't in range and so isn't loaded. -tkyler

I'm glad other folks are seeing it, there is no more frustrating bug than one that can't be reproduced. I think TomS is onto something and I'll be on it first thing in the morning GMT-6. This one really has me curious. -tkyler

I will say, I was VERY close to squeezing in custom waypoints to this release...indeed it was one of the features I wanted to have some success on....so that folks will know we are workingon FMS improvements. We are bugfixing for the next release asap...and I will AGAIN try to get these in. I have lots of code added for these already, but just need to weave it into the flight plan data. -tkyler

Chi, we are not saying its not happening, but there are a very large number of factors that it could be and unfortunately, we are not on your system to debug them. We tool feel intense frustration when debugging ourselves and I can tell you firstand, its always something we've overlooked that is off-nominal. Keeping in mind that we have 1000s of installs of this aircraft and dozens of thousands of hours of flight time that have borne out the plane does not normally exhibit this type of behavior in 99.9% of cases, which is a pretty good statistical indicator of the reliability of this particular codebase (trim). Since the update, I have been recouperating, I have 85 year old parents that I was tending to while working on this and my old body just needs a day or two to relax......give us a few days, Jan and I will talk it over, run a few tests and see if we can gain any insight to your issue. At the very least, make darn sure your mouse is perfectly centered in the white box before actuating any autopilot / autothrottle stuffs in the meantime...its bitten me in the arse on more than a few occasions. -tkyler

the issue isn't with the flap lever...when these gizmo errors arise, they tend to kill lots of other interactive functionality. That error message pertains to the VNAV descent calculation code and is one of the areas in need of refinement, indeed very high on our list of things to address (the entire VNAV algorithm). Our goal is to fix all the really stupid bugs (like mousewheel reversal), get some stability (outside of VNAV), and then go after the VNAV and holds aggressively to get these working as expected. -tkyler

I run both, but indeed, was probably running v18 at the time, as its more stable at handling errors, so I use it for development and Jan uses V20 for teting.....I will try both (tomorrow that is......I'm quite fatigued atm) ...awesome catch! Fingers crossed for debugging. -tkyler

without a doubt, our most cryptic bug to date. we'll keep looking at it. QUESTION....like Jan, does it connect the first time you use the GPU? -tkyler

Chi, I think you have something more sinister going on. There are many factors that influence the controls and typical culprits in such super strange behavior as you're describing would be other plugin or hardware interference/settings of some kind and would be a suitable starting point for diagnostic debugging. Also, you might try the experimental flight model in 11.5b as another data point in your troubleshooting efforts. As of now, unfortunately, you are quite alone in seeing this kind of behavior. I'd start by clearing out plugins, backing out to just your mouse possibly (remove all hardware), even going so far as reinstalling the 737 (less you had some miniscule file corruption on install), etc....and finally restarting the computer after all those changes, etc. I know debugging isn't fun, we do it daily, trying to find source of issues...but I think a bit it in order here. As Jan mentioned, we'll want to start with the Log.txt file. -tkyler

Thx mmrelles. we'll add to list and keep moving. We did expect sharp eyes to catch some things. -tkyler