Leaderboard

Hi Daniel. there is some variation between airlines, but most common use for takeoff would be: 1st bug to 80kts, second bug to V1, third bug Vr, set speed cursor to V2, fourth bug to V2+15 (this is the speed that is minimum for going over 15 deg bank), fifth bug to 170 (for flaps 5 and 15 takeoffs), this is the speed to retract 5 to 1. For landing we set 1st bug to Vref, speed cursor to target speed, second bug to Vref + 15 (min speed for going over 15 deg bank) and i often set another bug right next to the second one if planning a flaps40 approach (as a reminder). Cheers, Jan

Please for god's sake make it a paid upgrade, if only to get you guys to be more financially motivated in your work. The IXEG has been languishing for years, and I've seen addons from other developers being released at an unfinished state, and those devs lose interest as sales slow to a trickle. I loved the 737 Classic and I would love to throw money at you guys if I can get a fully featured (i.e. proper VNAV and holding), fully functioning addon. I also want the -400 and -500 if you want to make paid extensions as well, like what PMDG is doing. Also some Brunner force feedback yoke support would be nice.....

I have not officially begun to test / port the MU-2 to X-Plane 12; HOWEVER, I have been testing it regularly in X-Plane 12 and the good news is that it seems at first glance....to be mostly functional....FOR.....daytime flight. I say this because the biggest change in X-Plane 12 is the new atmospheric and lighting engine..and this requires new "directive commands" for lighting that were not present in X-Plane 11. The nightlighting is practically non-existent until I make the required changes. Also I have to make some notable changes to take advantage of the rain effects....so the V11 version "in V12" will not have the new windshield effects. So....daytime and dry seems to be mostly OK using the V11 version in V12. I know there are some turbine engine changes also I have yet to test...so unsure what their effect will be. The plan is to get the next release patch, 2.0.3 out for V11 (relatively imminent), and then begin the official port / testing process for V12. Probably will begin the work next Monday. I do not expect it to be terribly long. Chances are XP12 will go through some growing pains anyhow and I'll be right there alongside the process testing/tweaking the Moo. Experienced XP users should know to keep their XP11 versions around until they're fully happy with V12. Here's a few screenshots of the Moo in V12. Not terribly bad, but I may tweak it after I get going. Things tend to look a little bit shinier in V12...but also brighter, which is good.

Hello all. Those who have followed know that the IXEG 737 develoment has been stagnant for a long time while I've worked on my MU-2 project and stabilize it after the release. That stabilization phase is nearly done. XP12 is imminent and I'll be porting the MU2 to XP12 beginning next week...and it should not be terribly long (I hope). After that, the 733 will move back into rotation as the primary focus of development with the port to v12 being the first priority. The IXEG is minimally operable in V12, but that's all we can say. We obviously had to make it baseline flyable in order to test/develop it with all the XP12 changes, which have yet to be addressed. As such, our official position for those who wish to try the V11 IXEG in V12 is "VFR joyriding only". I expect we'll set up a 'volunteer forum' where folks can give feedback as to their V12 observations as its better to have more eyes on this stuff; however, we request that nobody report any shortcomings of the V11 733 in V12. We are keenly aware of a lot of things that have to be changed....so we'll want to wait until we believe we've caught all we can find before other folks chime in; otherwise we'll end up with a massive stack of the same reports. So, certainly keep XP11 around if you wish to fly the IXEG seriously until we get it ported over. I've always kept "old version / new versions" side by side on my computer for these transitions. Long-time XP users know that after a major release to X-Plane, there is an inevitable debug period that goes on for some time, though many other devs have begun already, we're behind. ....but nice to have the process underway.....Below screenshot shows what the cockpit looks like in V12 daytime. -TomK

We've waited for XP12 since the announcement. Thankfully it's finally here. Here are my initial thoughts. X-Plane is, and will continue to be, my sim of choice. When it first loaded up, other than the trees, I could see little difference between it and XP11. However, I noticed immediately that I was getting more FPS. BUT (there's always a but, right?), I did not have any plugins installed. Everything was/is default. VISUALS: X-Plane is not MSFS. The graphics will (probably) never match MSFS. I'm personally OK with that. However, I was a little disappointed that LR did not address the ground textures. But hey, they never said they would. I suspect the ground textures will improve over time. The airports are obviously the same as XP11. XP12 is supposed to have many more assets that can comprise buildings, cars, etc. With the 1000's upon 1000's of airports, perhaps LR is leaving it to the community to improve airports. However, it would have been nice to have improved airports out of the box. The trees look great. There's just not enough of them. Again, left to the community? Bear in mind that much of what's left to the community might come at additional cost. The cloud textures are fantastic. While they don't look exactly like MSFS's they are doable for me. There is room for improvement though. Polygons: LR talked about getting rid of the straight lines around lakes, beaches, etc. Perhaps this has yet to be implemented? There's a lot more I could say about the visuals but at the moment I prefer my XP11 textures with all its add-ons. I expect that XP12 add-ons will eat into FPS as I add them. I know there's a lot I didn't mention, like wet runways, and changing seasons. I'm delighted to see this stuff implemented. I'm hoping for undiscovered gems. AIRCRAFT: I haven't spent a lot of time here. I can say that I loved the Citation X. I have the payware version of the SR22 so it's hard to draw a comparison that's objective. I can say that the default SR22 lacks the depth of payware SR22. That's to be expected. The Evolution is a blast to fly. If Austin's Evolution performs like this one then I can see why he enjoys flying it. I'm not an airline guy. However, I heard that the flight computer on the Airbus is a big disappointment. I think the additional default aircraft more than justify the price of XP12. I've been spending so much time in the XP11 - CL650 (recently purchased) that I just haven't explored much of XP12's aircraft. FLIGHT DYNAMICS: This is where XP12 is suppose to shine. Quite frankly, I haven't been able to discern much difference from XP11 - yet. LR has devoted a lot of time explaining how 1st principles apply to XP12. I thought much of the same principles applied to XP11. There is a developers blog that talks about this flight modeling and Austin has talked extensively about it in interviews. I tend to think of flight dynamics as under-the-hood stuff. Its power will be revealed when needed. WEATHER: Two words: Love it. I hope LR will keep developing it. SUMMARY: XP is my sim of choice. During this beta period I'll continue to fly XP11 for the most part and build XP12 as add-ons and version updates become available. I'd hoped to see graphics and visuals closer to MSFS but LR is not Goliath. I trust that the sim only get better, graphically, with time. I don't feel like I wasted any money getting XP12; I believe LR has a long way to go, given that MSFS is a thing. What are your thoughts?

At this time the CG is essentially fixed based on fuel load (IIRC), and payload has no effect on it. This is because a more complete simulation of passengers (and potentially a flight attendant) is still on the drawing board. X-Plane 12 provides a more sophisticated load station simulation so this feature will likely find its way up the priority list.

This is the Nvidia graphics driver crashing so not something that Hot Start can troubleshoot unfortunately. Sorry.

I am pasting in a link to a video that demonstrates the visual approach with automation assist in the Challenger. Taking off from KMBS (Saginaw, MI), very short flight south to Flint, MI, enter downwind and use NAV+VNAV as an automation assist with a 4nm RX (runway extension) from the FMS to aid with the approach. I hope this is of value for the community.

There are many changes in XP12 that need to be incorporated into the Saab. Whether that happens in the Saab v1 or v2 remains a question, but it will happen at some point.

It is with great joy that I’m announcing the release of XMidiCtrl Version 1.00! I started this project around one year ago. The initial commit was on the 4th May 2021 and I’m honestly rather proud how well it turned out. Since the release of the first version on 1st November 2021 I have received many nice messages from people all around the world. Within the last few months, the plugin evolved even more, thanks to the many suggestions and ideas I received from you. Together we succeeded to enable support of various MIDI devices and not just the Behringer X-Touch Mini. The release of the Hot Start Challenger 650 was another milestone in the young history of XMidiCtrl. Thanks to the great help of Graeme from Reflected Reality Simulations, I was able to offer support for this amazing aircraft from day one. Recently I did some major refactoring and added some ideas I had for a long time. With all the work done and some extensive testing from quite a few people, I’m confident to label the current version as 1.00. I hope this will be a clear sign to new users, that we are talking about a stable and feature complete plugin. Development will not stop here, of course! But all the initial ideas I had are finally implemented. Okay, let’s have a look at the new features: Support for all MIDI message types In order to support all kind of MIDI devices, it was necessary to implement support for all MIDI message types. Initially the plugin was able to send and receive Control Change messages, only. With the new version of can send and receive: Control Change Note on/off Pitch Bend Program Change New logging system I was never happy with the logging system. It was still the initial implementation from the first prototype. I wanted an improved system which shows the user exactly the information she/he needs to see without the need to search an extensive log file. First of all, there are no log levels anymore to choose from in the settings window. You can enable a debug mode if required, but otherwise all warnings and info messages are being logged. There are not many of them anyway and most get raised when loading an aircraft profile. In addition, there is a new tab page in the profile window. It shows you all errors and warnings for the current aircraft profile: When you open the new messages window and change to the MIDI Message tab page, you will see quite a few changes, as well: As you can see, I added some icons instead of text. Most icons provide a tooltip with additional information. This allows you to see all mappings and log messages related a specific MIDI message. However, all messages are still logged to the common log file, if you prefer to monitor the plugin this way. Log entries related to a MIDI message: Mapping used for a MIDI message: Enhanced Mappings I added some additional mapping parameters to allow more advanced mappings. Most notable additions are: Encoders – value_min and value_max Allows you to specify minimum and maximum values for the mapping. Example: { ch = 11, cc = 8, type = "enc", dataref = "AirbusFBW/XPDRPower", modifier_up = 1, modifier_down = -1, value_min = 0, value_max = 4 } Dataref support for Push&Pull So far it was only possible to specify commands for push and pull. With this version you can also modify Datarefs directly. It’s even possible to mix commands and Datarefs, such as have a push command and modify a Dataref for the pull event. Examples: { ch = 11, cc = 9, type = "pnp", dataref_push = "AirbusFBW/BaroStdCapt", values_push = ['0', '1'], dataref_pull = "AirbusFBW/BaroUnitCapt", values_pull = ['0', '1'] } { ch = 11, cc = 9, type = "pnp", command_push = "AirbusFBW/Toggle_BaroStdCapt", dataref_pull = "AirbusFBW/BaroUnitCapt", values_pull = ['0', '1'] } Labels This is one of my most favourite additions. Labels allow you to display display a text when a mapping event takes place. Lets assume you have a mapping to change the transponder mode using a knob on your MIDI device. The mapping would probably look similar to this one: { ch = 11, cc = 8, type = "enc", label = "xpdr", dataref = "AirbusFBW/XPDRPower", modifier_up = 1, modifier_down = -1, value_min = 0, value_max = 4 } That will work rather nicely, but often the transponder mode knob is between the pilot seats. If you want to check the current setting you must look down and that annoyed me. In order to display labels, you have to define the label in the aircraft profile: [xpdr] text = "Transponder Mode:" values = [ { value = "0", text = "STBY" }, { value = "1", text = "ALT RPTG OFF" }, { value = "2", text = "XPNDR" }, { value = "3", text = "TA ONLY" }, { value = "4", text = "TA/RA" } ] In this case I created a new label with the id xpdr. In addition, I specified a text to be displayed each time the mapping gets executed and some labels for the different values. Finally, you have to bind the label to your mapping: { ch = 11, cc = 8, type = "enc", label = "xpdr", dataref = "AirbusFBW/XPDRPower", modifier_up = 1, modifier_down = -1, value_min = 0, value_max = 4 } Whenever you change the transponder mode using the MIDI device, the label for current value will be displayed. If no label value has been defined, the Dataref value will be shown. The new settings dialog allows you to modify the position where the label text will be displayed: Init Mappings This new mapping option allows you to send some MIDI messages to the device just after the aircraft has been loaded. It can be useful when using the Behringer X-Touch Mini to initialise the behaviour or the encoder lights. Example: [[device]] name = "Behringer X-Touch Mini" port_in = 0 port_out = 1 mapping_init = [ # Encoder Lights # 0 = Single # 1 = Pan # 2 = Fan # 3 = Spread # 4 = Trim { ch = 1, cc = 1, velocity = 1 }, { ch = 1, cc = 2, velocity = 2 }, { ch = 1, cc = 3, velocity = 3 }, { ch = 1, cc = 4, velocity = 4 }, { ch = 1, cc = 5, velocity = 4 }, { ch = 1, cc = 6, velocity = 3 }, { ch = 1, cc = 7, velocity = 2 }, { ch = 1, cc = 8, velocity = 1 } ] New Examples The new version comes with some additional example mappings: Updated version for the ToLiss A321 iniBuilds A310 Felis Boeing 747-200 I hope you enjoy the new version as much as I do and please let me know if you have any questions. Thanks, Marco