Jump to content

vitabutch

Members
  • Posts

    21
  • Joined

  • Last visited

  • Days Won

    2

vitabutch last won the day on April 27 2018

vitabutch had the most liked content!

Recent Profile Visitors

1,717 profile views

vitabutch's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

18

Reputation

  1. 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.
  2. 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?
  3. 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
  4. 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!
  5. 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
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. FlyInside for X-plane is out. What I can say - IXEG in VR IS ABSOLUTELY AMAZING!!! No more words. Huge thanks to the team!!!
  11. 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!
  12. 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
  13. 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.
  14. 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
  15. 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.
×
×
  • Create New...