• Content count

  • Joined

  • Last visited

Community Reputation

14 Good

About vitabutch

  • Rank

Recent Profile Visitors

551 profile views
  1. A question regarding Download links

    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
  2. Cant activate ixeg737 in xp11

    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.
  3. Xplane11

    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
  4. Clouds and skycolors of IL-2

    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.
  5. Cockpit Bulders Hope

    FlyInside for X-plane is out. What I can say - IXEG in VR IS ABSOLUTELY AMAZING!!! No more words. Huge thanks to the team!!!
  6. 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!
  7. Cockpit Bulders Hope

    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
  8. Cockpit Bulders Hope

    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.
  9. 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
  10. Cockpit Bulders Hope

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

    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 showinginstruments 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 40in 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
  12. Cockpit Bulders Hope

    Yes I do. There are several ones but I prefer the set of Javatools made by GuGurra from BMS forumtool 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 andboth FMCscreens. 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
  13. Cockpit Bulders Hope

    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