vitabutch

I didn't manage to fine tune manipulators (i needed MCP rotaries the most, but all of the them are drag_XY type). However for the ones who like to have normal default seating position in VR I would recommend to create B733_vrconfig.txt file in the aircraft folder with the following content: A 1100 VRCONFIG ################################ #TELEPORT HOTSPOTS ################################ BEGIN_TELEPORT_HOTSPOT SITTING Pilot's Seat AABB -1.5 0.0 -17.0 0.0 2.0 -10.3 PRESET_XYZ -0.512 1.59 -12.8 PRESET_PSI 0.0 PRESET_THE 0.0 PRESET_PHI 0.0 END_TELEPORT_HOTSPOT So you will no longer find yourself right and behind the proper pilot position in VR. Most probably I will not experiment further with this file so I hope VR ready IXEG release will be coming soon EDIT: After some time I figured out that I sit too high. I corrected position for height from 1.69 to 1.59 for more realistic view.

I have been reading a nice article on Xplane site regarding special definitions for VR views and controls https://developer.x-plane.com/?article=aircraft-vr-configuration-_vrconfig-txt-file-format-specification. The file is in plain text format. Apart from the custom views I see very important part is Manipulator customization (you can read details by the link above). Since manipulators are present in IXEG 733 I think it could be possible to create this file to make at least MCP manipulators to work correctly. Currently its almost impossible to dial MCP encoders precisely using Oculus touch. I wonder if anyone already tried those dark waters or I am the first one here?

Thats a very good idea! Current default settings didnt work well on both of my rigs in VR. Just I wild idea about this info to be announced to the users maybe by splash screen during installation of updates? Not all of them reads forum and I also can miss this information. The garbage collector settings affects performance a lot. Now I can fly with VR and traffic (Xlife) shitched on. Many thanks again for the great product and for your help here

You have made my day, Cameron! Now I am back in 737CL seat! You mentioned Gizmo garbage collector, right? It didnt cure the issue completely but made this stutter effect MUCH-MUCH less! I tried smooth fps setting and it has made it worth, but setting both parameters ~200 made the stutters showing once a several second and almost unnoticable. Do you know any webpage to read about both parameters in Gizmo64 garbage collector to tune it in more educated way? Many thanks in advance!

Hi guys, being a long fan of IXEG let me share some not so nice experience in native VR. Since I do not use falt screen any longer its important to me. IXEG is unflyable in VR due to the poor programming techniques. You definitely needs to revise your code since it generates periodical (every 0.7 sec - 1sec) stutters. Its not noticable in 2D but VR is more demanding to the CPU usage, so occuping CPU every second is no go. I though it was a problem of my rig that was not top notch, but few days back I finally get i7-8700K and it suffers the same problem. I can live with massive hanging when FMC activate the route, but the issue I described above is a showstopper. Other products doesnt cause such a problems. Again I am not talking about overall CPU load, its ok for this type of complexity, but something in your code runs approximately every half a second and occupying CPU too much. Please consider to balance the load over the time. Thanks! Cheers, Vitaly

What stops you from saving your installer in the local drive? Xaviation makes activation in online mode anyway. I don't know frankly speaking why do they limit the number of downloads from the site since it doesn't protect the product from piracy anyways. But just making regular users life a bit more complex. However if you save somewhere your installer it will make your life easier. I don't have any problems because of this limitation even though my downloads expired by the date and I had to reinstall 737 several times trying to make it work with X11. It made few automatic online activation requests and X aviation activated it with no problem without the need of support from help desk. Cheers, V

This is because you have installed it in your xplane 10 folder and copied the files to X11 folder after. Looks like activator writes down you activation data back into X10 folder. If you use installation from beginning pointing to X11 folder there will be no such problem. P.S. Use cumulative 1.7 file patch to update to the latest version (published by X-av here on the forum). Hot fix gizmo based codes doesn't work from X11.

Our beloved greedy Jardesign wants 20 bucks fee for upgrading their A330 for X11. And they didnt say anything yet abiut A320 upgrade. Looks like A320 is an abandoned project since they sold it out to most of the potential users. I decided not to buy an official upgrade yet for A330 and using my X10 version in X11. It works in general but with some bugs. I can say it's FPS unfriendly in X11 though. IXEG 737 works quite well and shows decent FPS performance. But IXEG team promised a free update to all their X10 users. P.S. I am flying X11 in Oculus VR only and it's amazing! Old X10 add-ons also shines in X11 so I jumped away from X10 regardless of the incompatibility issues I have with the priloducts at the moment. Cheers, V

Not at all. Il2 battle of Stalingrad has nothing in common in regard of graphics engine neither with il2 nor il2 CloD. It has absolutely new engine made from scratch. It's not perfect in terms of performance though but weather representation is spectacular indeed.

FlyInside for X-plane is out. What I can say - IXEG in VR IS ABSOLUTELY AMAZING!!! No more words. Huge thanks to the team!!!

Finally it happens. I remember you told me Lufthansa decided to migrate from 737s. Now it is done. This plane is a very great thing of course, but people are the most important. Thank you very much for your passion with 737 and your efforts to bring us a part of this beauty with IXEG product. I am a very lucky person to get to know you. All the best to you and your family! Cheer up!

Nice memories, Jan! Was it 8 years back already or more? As for the interview, the link above its not the one I have mentioned. I will try to find the proper link. Its where Austin is flying chopper on FSX or Prepared with Oculus and almost literally saying that its unusable crap You have to see this, especially the owners of the helmets who have tried FlyInside

I have to say that in the world of VR my proposal of this feature is getting obsolete. As well as X-Plane in general. I reverted back to prepar3d because of fantastic Flyinside VR support. If you have seen recent "VR review" from Austin you will realize that Xplane will fall behind. Instead of catching the modern tech he puts his criticism all over to protect the his baby from development. And he started to loose his followers and I am among the first ones. Even a beautiful IXEG will not keep me on the ancient flatscreen when I can go VR with prepared/FSX.

Dear IXEG team, I am interfacing my Opencockpits gear with the beauty. For this purpose I am using my own SIOC<>X-plane interfacing plugin (very fast and optimized for no-delay data exchange). For example there is no issue when I use standard X-plane dataref for MCP altitude (sim/cockpit2/autopilot/altitude_dial_ft). But when I try to use ixeg/733/MCP/mcp_alt_target_act it crashes X-plane. However custom datarefs works fine with another IOCP plugin - UICPX. UICPX works with approximate 3Hz rate of updating X-plane datarefs. It way too slow! This huge delay issue was exactly the reason not to use UICPX, but to create my own plugin. My plugin is wortking as a thread process within a plugin and writing datarefs immediately after recieving it. I thought there is something wrong with my own code. But debugger shows exception call in in Gizmo plugin. And it works with no issues with standard datarefs. Could you please take a look if fast continious writing to the mentioned datareft creates a problem? Maybe you have some recommendation for the solution apart from writing to the standard cockpit2 datarefs or creating a timeouts between the write cycles? P.S. I am writing datarefs using standard XPLMSetDataf call. P.P.S. More testing on my system revealed that more or less frequent writes to any of IXEG custon MCP dataref causes X-plane crash triggered by exception in Gizmo plugin. So now I have to use IXEG MCP datarefs to read-only and write only to X-plane standard datarefs. I will be trying to simulate MCP buttons via joystick button presses. I have another application written to sumilate DX joystick via SIOC that I used for Falcon. It have a nice use here as well P.P.P.S. All above doesnt change my opinion about 737 IXEG to be the best plane created for X-plane so far . Pretty sure we will make it more cockpit builder friendly over the time

In theory its possible to replicate most of EFIS and EHSI logic using the datarefs. I started this project while in 2009 and had a working prototype (screen is on the picture). But I quit this development when IXEG 737 was announced. EADI replication via datarefs is not so complicated, but EHSI is an issue, since flightpath, navdata and weather radar replication will be very challenging.

Many thanks Ben for looking into it! I can post here some of my research results. I use two PC setup: one PC for simulation and another PC for instruments screen (and additional small screens planned for the future development as well). So I investigate heavily the topic of showing instruments on the second screen or second PS. I think there is no need to talk about MSFS, it was giving the possibility to open different 2D panels in separate windows so users could position it over the second (3rd, 4th, etc…) monitors of the same PC. I don’t know about FSX/P3D capabilities, since I left MSFS towards X-plane quite many years back. DCS (Digital Combat Simulator) It uses the concept of the viewports. So user can edit lua file defining a size and position of the main 3D screen as well as instruments viewports. In the multi monitor configuration it gives a bit of a flexibility, but its very bad from performance point of view. DSC is DirectX application so performance is degraded if user uses more than one screen: they cannot use full screen mode of the graphic adapter. There is another solution to this – SoftTH. This is a DirectX wrapper that creates a virtual video adapter space for 3D rendering that user can split later on the several 2D screens without performance impact. Anyway I don’t use it and prefer a solution with transmissions of the displays over the network to another PC. DCS used to have this feature in early development of the Flaming Cliffs (exporting display textures as a block of memory) but they quit supporting it now days. Falcon BMS Since Falcon4 has been rebuilt by BMS team it had cockpit builder’s interfaces. They decided to use the concept of shared memory. They published C++ .h files with shared memory definitions so any external application could catch it. In the shared memory there were several sections: 1) Binary data containing several information like status of the lights/annunciators, status of the systems, any other useful variables (of course we use datarefs for this purpose in X-plane, so no need to bother with it) 2) Blocks of memory containing bitmaps of the displays. I bet they just do memory copy to the shared RAM section before writing it into the texture memory of the graphics adapter. Copying blocks of memory (even large ones) is almost resource free for CPU. Using this API some people created different client/server applications capable of sending flight variables as well as instrument screens over the LAN specific to FalconBMS: (Lightning MFCDE, GiGurra GPT). I prefer GPT for open code, simplicity and performance. Wrapper tricks There was a very interesting thread by some time ago in DCS forum by the guy who experimented with the DirectX wrapper trying to locate the textures they used in A10 MFD’s. He succeeded but with one exception that ruined the approach – DCS A10 used shaders to post process MFD screens, so no “as is” texture extractions were possible. Screen replicators Some people tend to use screen replicators to display information on the other PC’s. There are many such applications available using different technology, but it makes no sense to use it since they read video adapter buffer memory to replicate it later on over the network. Memory controllers are optimized to write data from RAM to VRAM but no vice versa. So in case we need to export the instruments bitmaps we need to share the bitmap just BEFORE it went to VRAM. As far as I understand X-plane acf file concept – there are predefined blocks for any dynamic texture we want to see in 3D cockpit. What I don’t understand is why it cannot be shared the same way as DataRefs for plugins. Two years back I asked about such sharing option of the Xplane forum, but nobody cared. So that’s pretty much were we are today… P.S. Once more many thanks to IXEG team to make 737 classic possible. That’s my most beloved civil bird before the era of iPad-alike planes. P.P.S. My best regards to Jan! Long time passed since the day he landed 737 with the jammed flaps 40 in Kiev. That was nice days! P.P.P.S. My pair of 737 yokes, pedals and seats are waiting for it’s time. Even though one of the seats temporary serving as ACESII

Yes I do. There are several ones but I prefer the set of Java tools made by GuGurra from BMS forum tool thread link There is a simple program (display transmiter) on the host machine to catch shared memory segment. It uses turbojpeg library to quickly compress every frame and send to another PC (or the same PC) where another application recieves the compressed frames and shows it in the several windows with user configured sizes and positions on the PC screen. Performance impact of this set of tools is close to zero - I have 1-2 fps impact on Falcon BMS. Several F16 displays is extracted over the LAN with no delay (two MFD's and also RWR). I believe the same can be done with EADI, EHSI and both FMC screens. Displays texture memory sharing feature will have the product priceless for 737 cockpit builders and the users who likes to use a second monitor/PC. Source code of the tools is also available on the project page https://github.com/GiGurra/gpt/releases

Dear IXEG team, can you please think about exporting EADI & EHSI displays content to show on the second screen/second PC? This neat feature exists in DCS and in Falcon BMS for quite some time already so maybe you can do this as well in your product. In my mind the best option to do it is to copy displays textures in the shared memory like its done in Falcon BMS. And we as cockpit builders can use the same replication software as we already use for BMS. I understand this feature to be welcomed by small number of users, but the option to have at least EADI and EHSI on the second PC (laptop) will attract a lot of users. Thanks! Cheers, V