Leaderboard

I second what Tom says - we have made big strides and I don´t see any obstacle to providing a good VR experience with our next update. Jan

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

Hi Andreas, I am happy with the way it is - in fact I feel that it often is a bit too reluctant to move. But I have only flown the plane for 10 years, so what do I know Cheers, Jan

Hi Martheson, thank you very much for the work you did for the previous version! I know it has been a godsend for the VR users of our aircraft - in absence of us providing the necessary files ourselves. I will certainly look for your input and assistance down the road when tweaking the VRconfig.txt for this aircraft, and hopefully we can implement this in the very near future for everyone out of the box. Thanks again to you and Joe (and whoever helped make the previous version VR compatible), Jan

Hi guys, Matheson from SimVRLabs here. My colleague Joe made the original SimVRLabs mod for the IXEG 737 1.21, but I would like to explain some things regarding the latest 1.3 update. The SimVRLabs mod originally made for 1.21 will NOT work in 1.3 as many of you know. The reason for this is that IXEG overhauled the cockpit.OBJ in 1.3. For those of you who do not know, the cockpit.OBJ of any aircraft is a 3D model that XPlane uses which you mostly do not see. This 3D model contains information about how the user interacts with the aircraft. A good way to show how this affects each aircraft is by comparing some aircraft. For example, some aircraft use the mouse scroll wheel to interact with knobs and switches, others may require you to drag your mouse up and down or side to side, or some may use a combination of both. The cockpit.OBJ is responsible for dictating this behaviour. Each knob, switch, button, and anything you can physically interact with in an aircraft is called a manipulator. These are inside the cockpit.OBJ. Some manipulators work better than others in VR, but may not be the best for 2D users. While making a VR mod for an aircraft we always need to ensure that VR users have the best possible experience but without compromising the 2D user's functionality. This is a delicate balance and is the reason why there will never be an XPlane aircraft that works flawlessly in both modes, but we can make it pretty close. Because of this, we must change some manipulators that don't work well in VR to a more VR friendly type. This is why we include cockpit.OBJ files. You may be wondering how this relates to a VR_Config.TXT. All that file does is allow us to tune manipulator sensitivity (how much you need to move your controller for the manip to work), and change SOME (very few) manipulators into other manipulator types. Because we can only convert some types using the VR_Config, we have to do the rest in the cockpit.OBJ. We ALWAYS try to use the VR_Config.TXT FIRST before editing the cockpit.OBJ, simply because the VR_Config.TXT only applies the changes and settings when a user loads VR. It does not affect 2D pilots whatsoever. In the case of the IXEG 737, Joe had to make changes to the cockpit.OBJ as some manipulators were not suitable for VR users. When IXEG released version 1.3 with an overhauled cockpit.OBJ, this rendered our mod broken in 1.3 and useless. This is not the fault of IXEG. They made their product better than it was before, so they should be praised for their continued development and quality of life improvements. Jan has said that VR support is planned for the near future. We can't wait to see what's in store for VR users and to possibly lend a hand with that task if needed. I hope this clears up confusion about our mod and 1.3. If you have any questions, feel free to tag me in a response here or shoot me a message. Cheers, Matheson SimVRLabs.com

These files work fine for me. Sent from my SM-G960F using Tapatalk

I would never say never Cheers, Jan

Hi all, I need XPUIPC for my CFY motorized throttle. Somewhere i have an old version and will instal it to test it. Tregards

things are not the same as in the past....updates will be much quicker than in the past and more frequent. This won't be a long wait I assure you. The mousewheel issue practically demands we update asap. -tkyler

Yeah, Gone of the 300 days....Just press Vnav now and drink my tea. Although it did work until you wound up the missed approach alt

I can agree on that, every -300 I’ve flown had the ability to put the runway fix in the fmc fix page, we usually do this In order to put our VDP ring for non precision approaches and therefore adjust a more precise vertical speed during the approach. (Make the altitude range arc appear on top of the ring arc on the ehsi, having set our MDA in the MCP obviously).

I'll give them a try.

Hi Jan, yes, understand, but in the moment it works again perfect many thanks! Viele Grüße, Jürgen

But then, we will be distracted. Anyhow, the existing lua script does a nice job.

I will have one of my pretty young lady copilots do the voiceover for you guys...

and after the years, it is still working great... unfortunately it is not @Litjan 's voice, but hey, he's no standard Flaps Operator

I will check it out, thanks!

Yes! There is a LUA script out there for speed callouts.

I know on all of FMC's on the 300's we could put a runway fix in. I would always use it for putting range rings for some SA on approach. I Just get around it in the IXEG by using the Aerodrome in the fix instead. Regards Craig

I looked so hard for a button and there it's sticking out like a sore thumb. Got it. Many many thanks

oooooh yes, that looks really good, I will probably never put a flap wrong again what a support and you are so quick and helpful thank you very much!

Just wanted to let you know that this is fixed for the next update. Cheers, Jan

Caused much confusion after the initial release. You are late to the party.

woops I think i flown this plane only one time without the winglets. Than sorry for confusing people

They did, but only without the winglets. That´s because the logo lights are part of the wingtip. They where not integrated in the winglets.

yes it does integrate to xplane. You install the app in your iphone/ipad and you do all the weight and balance programming there over a graphical interface. You configure passengers, payload, fuel, etc. and the app will configure xplane/aircraft when you hit load. it also offers several other nice features for the flight

@3rdwatch In order to make the IXEG 1.3 work under VR i had to do 2 things: 1. Create a new vrconfig.txt file from scratch to accomodates their newer manipulators 2. but it didin't work still, after further debugging i realized the ixeg cockpit_281.obj file contains quite a bit of trash characters most likely coming from issues on the laminar's blender exporting tool. So i cleared them up and got it working nicely I will share my findings with IXEG team for their testing/evaluation, maybe this helps out to save some time/effort to start providing their bird vr ready Please find attached 2 files, both should be placed on the 733 root folder (make a backup first of their original B737_cockpit_281.obj for safety/rollback if required) This is the list of things i already covered (tried to cover the most critical), please test them for some feedback and i will continue to cover the rest of the manipulators on the cockpit -Both Course selectors -Heading bug and BANK angle -IAS -ALT & VS -Pilot Copilot & stby Altimeters -Auto Brake knob -Nav1 & 2 -Comm 1 & 2 -Pilot & Copilot DHs -EHSI Mode & Range selectors for both pilot & copilot -IRS system. left, right modes & display selector -Left & Right engine start knobs B733_vrconfig.txt B733_cockpit_281.obj

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

Sorry, I didn’t think you guys would assume I’m a liar & be so abrupt in your responses before actually asking me to verify the aircraft I was using. I apologize that I didn’t know there was a rule not to use a picture of the gauge not from the 3D cockpit. I could have not even posted a picture but I thought it would help. I feel like I’m getting told off for something I couldn’t have known by someone I’ve bought something off. As a customer I’m shocked.

No one said anything about an update being released.

Darran, You have several plugins installed, and you are using external hardware. My suspicion is that one of these is the problem. The correct way to diagnose this is to unplug ALL your hardware, remove ALL your plugins except Gizmo, PluginAdmin, and any whose name begins with XP. Then launch the sim and test. Another option would be to download the X-Plane demo, install the Saab, and test. If the problem is gone, you know it was either a plugin or hardware causing the issue. Place your plugins back in one at a time and test each time. If the problem returns you know which plugin is causing issues. Do the same with your hardware, plug each item in one at a time and test. Report your findings back here so we can determine your next step.