Leaderboard

I never get tired of looking at XP's lighting. It's just so realistic! Not sure if I counted them correct, but the 737 has about 18 (!) different lightsources inside the cockpit that you individually can adjust to your liking. Great way to waist time during a long cruise at night

It is not lost on use to simulate every little "effect" due to every possible input by every possible system, but the thing here is simply the "volume" of things to be dealt with. Being this is our first product, in order to be competitive, we really have to achieve the same technical level as a 17+ year old company with more resources and experience and well....that is just taking a while, especially given that we're a 4 man team working in our spare time. This is a testament to using Gizmo and its vastly reduced compilation time. It is our belief; however, that once we get this initial tech on the market, we can then expand upon the smaller details and try and capture as much of the real thing as possible. Rome wasn't build in a day, nor in 5 years. In time, we'll refine the 737 and eventually, get to that vision we have. Its enough for now just to get a really robust FMS / AP implementation, which is priority 1. -tkyler

Hi, You can watch the movies we did (I mention and show the effect of airflow sounds changing on a few occasions, iirc.) to see how we modulate cockpit sounds. Since the 737 has no pneumatically driven "demand pumps", driving the flaps in the same situation will not have an audible effect, though. You would see a spike in EGT - as the electrically driven hydraulic pump B has to struggle to satisfy hydraulic power demand, and therefore the APU has to generate more electricity. At the same time you could see a marked drop in hyd B pressure - with flaps driving a lot slower than on EDPs. Cheers, Jan

There is no such thing as a perfect plane! There are bad planes, good planes and very good planes. Unfinished planes, half done planes and mostly done planes.

please stop playing big brother for the IXEG team... They might actually be willing to shed some light on it (as tkyler did a few posts later) I notice that I'm getting more and more irritated by the attitude you are showing from time to time... Most of the time questions like 'is it ready yet, when will it be released, how much will it cost' will sort out themselves. just save your moderator powers for when discussions really get out of hand. and for the IXEG Team: Keep it up guys, nearly there... I'll be cheering at the finish for you ! just my 2 cents

I look forward to seeing your perfect plane on the market sometime before 2021, although you might want to work on your people skills if you want to make any money from it.

So Morten, you provide us real cockpit images in night now? I rather see IXEG cockpit

I wasn't relating my post solely to the post you singled out... I'm not trying to moderate anything. and what did I do to receive this remark ? "Further discussion on this will NOT be had, and that's definitely my warning to you." *edit: feel free to respond in a private message, so we can keep the unrelated and non IXEG stuff to a minimum here

Flying the JS32 from EKBI to EDDL

Ok, here's a real report. In the last few days, we have seen very, very few gizmo crashes (from my bad programming) with regards to FMS work. There are a few fringe cases, but they are getting very tough to reproduce and usually come about when you start punching buttons like that kid in the movie, Airplane 2. ...stuff most of you would not do. In prep for the final steps before letting beta folks test it, I have refactored (programmer speak for "cleaned up") the code to be more user friendly towards VNAV predictions and debugging VNAV performance values......and that is what we are currently working on. If you don't plan to use VNAV, well I'm sorry, the FMS was ready for you a long time ago....but once you do learn it, and it actually works as expected, its quite satisfying and fun to experience....hence our efforts to really make it work. So tomorrow I'll be flying some test routes to fine tune the descent code....and if all goes well, we want to let the beta testing folks have a hand at it asap. I think Jan is planning a "full flight" preview, but no promises, I can't speak for him, he may not have plans for that. (no micro-management here). Now I know most folks automatically assume that once a closed 'beta' begins, that will uncover a slew of other bugs, which adds to the development time, but I have to tell you now...that I have NEVER seen a tester like Captain Jan Vogel! (He IS that kid from Airplane 2), except with 100x the knowledge (very dangerous). This guy finds stuff that nobody will EVER try. and when this guy says, "its good for V1.0", then I will challenge the beta guys to find something we don't already know about. Now note I said, "know about". We know there's holes in the FMS, but feel its getting to the point to handle a good 90+% (or better) of use cases. If you are that super hard-core simmer that likes to explore the fringes of FMS usage....well...I'd say, "fly some normal routes first or wait". Work continues daily! -tkyler

My point was that you shouldn't need a "workaround". If this is a wide-spread issue we will certainly look into it.

If you read back, you will see Tkyler explain what you want. His quote at the end of his comment is "wouldn't it be great to have this plane is 5-6 weeks?" You will understand what that means if you go back and read it. Also, you should know that these guys were doing this project on their spare time. 5 years may seem a lot, but with what we have seen, we can see why it takes this long with the circumstances.

I have come to understand why most developers simply do not engage with community forums.

It should be noted that when Tom says "Gizmo Crashes" what he actually means is that "My Lua scripts made gizmo display an error message bout my bugs." Gizmo is NOT crashing to desktop. It is merely showing Tom the location of his bug. A subtle point but one that would enormously affect the quality of the end product if Gizmo was "crashing". It doesn't.

Okay fine that is good news for the new device but I still say go to FlyWithLua support forum and talk about it there.. there might be someone that can help.. as yes I know 0 to 1 is a bit pain full as it is a small range.. but hardware output is 1 thing and another is the simulator (0 <-> 1)

Hallo, I, have who was the the first to start this topic must object to the discussion above about Linux, addons and so on: The topic was: are there any problems with Windows 10 + X-plane? Please keep to the subject! If you want to discuss something else, start a new topic! Thank you.

i move them to min and leave them there, this is a workaround i found to get consistent thrust in beta mode after reverse. In the real thing it doesn't matter. You can taxi having them in max or min because you are in beta mode. turboprops per their engine nature have several seconds lag to respond to throttle adjustment changes (5-6 secs aprox). this make them very inconvenient for taxing and general ground operations. in response, engineers creates beta mode, the throttle range goes from GROUND IDLE to MAX GROUND IDLE (just before you enter FLIGHT IDLE) under beta mode, the engines are held constant by around 1100 rpm by electronics (do not remember the exact value) and moving the throttles within the beta range you are actually only controlling the blade pitch 0 to +10 degree. Being in GND IDLE you have a 0 degree blade pitch no air gets pushed, moving it forward you add blade pitch and air gets pushed. Blade pitch changes are almost instant and rpms are held constant by the electronics watching fuel flow. Thus you get a predictable thrust for ground operations. note: Condition levers MIN to MAX position allow you to set your desired engine RPM for torque vs speed at different passes of flight while the throttles are in the flight range (FLIGHT IDLE and forward)

Thank you all for the replies. I just landed after a flight and the same thing occurred, only this time it seemed that normal power only got restored a minute or two after landing, no matter how much I juggled the throttles. Before takeoff, the Saab on the ground is very fast and can creep up to 30kts+ if I'm not careful, but this time after landing it wouldn't get over 13kts (power levers at flt idle, conditions at MAX). Flight was 100% normal otherwise. Interesting! +1 to LES for realism. Could you ask them what the procedure was to smoothly transition from reverse to normal taxi thrust without stopping? There must be a way as I highly doubt the A models just hang out on the runway after landing. Do you then move them back to MAX for the rest of the taxi after you leave the runway and are in beta?

I've been following this project for a couple of years now, and you keep to blow me away every time. This will definitely be a game changer. Just a quick question/suggestion regarding the way you handle the flap lever. I personally use an axis to control my flaps, and sometimes (not to say everytime) it can be quite painful to set this axis just right (usually it's slightly off, so I get flaps 15,3 instead of flaps 15). You stated in a previous topic that you are not focusing on anything too complicated for V1 (regarding hardware interaction), but I certainly hope that you will take a closer on how to handle the flap lever with an axis once you get all the hot stuff out of your way. I think you could tackle this by implementing some sort of "flaps intervals" : if the axis is between 100 and 95% then it's flaps 0, if it's 95 and 85 flaps 1, etc... I've been thinking about developing a standalone plugin like that myself, but I don't know if it's even possible ?

Well in the video Jan did the SWA livery is N654SW. So I will spend my first day doing what the real aircraft is doing. As an example N654SW's routing tomorrow 2016-03-16 WN4472 Phoenix (PHX) Little Rock (LIT) 17:20 PM MST - 21:45 PM CDT Estimated departure. 17:30 PM 2016-03-16 WN3027 Austin (AUS) Phoenix (PHX) 16:05 PM CDT - 16:40 PM MST Estimated departure. 16:15 PM 2016-03-16 WN3027 Dallas (DAL) Austin (AUS) 14:35 PM CDT - 15:30 PM CDT Estimated departure. 14:45 PM 2016-03-16 WN28 Houston (HOU) Dallas (DAL) 13:00 PM CDT - 14:00 PM CDT Estimated departure. 13:10 PM 2016-03-16 WN17 Dallas (DAL) Houston (HOU) 11:00 AM CDT - 12:05 PM CDT Estimated departure. 11:10 AM 2016-03-16 WN373 Austin (AUS) Dallas (DAL) 09:25 AM CDT - 10:25 AM CDT Estimated departure. 09:35 AM 2016-03-16 WN372 Dallas (DAL) Austin (AUS) 08:00 AM CDT - 08:55 AM CDT Estimated departure. 08:10 AM

Thank you for the enthusiasm! We are encountering problems at every step but learning and coming out ahead with every failure. I'm glad someone is looking forward to Molokai as much as I am! The cliffs are mind blowing and without the UHD mesh they aren't work even looking at. Cheers

a.) Not for 1.0 This is something that real airline pilots use very rarely, well, except for adding the fix "HOME" so they can input the coordinates of their house. Complex missed-approaches are part of the database, or can be made with conditional waypoints (PBD). But for 1.0 we won´t have conditional waypoints, but you can use the FIX page to "visualize" maneuvers that are off the normal FIXES. b.) not sure what exactly you mean - the acceleration altitude is the altitude at wich the plane should start to accelerate, this has nothing to do with the thrust rating. Thrust is reduced (usually from TO or R-TO to CLB) at the thrust-reduction altitude. This altitude can be set on the TAKEOFF REF page (it defaults to 1500AGL). If you push the N1 button below this altitude, then the autothrust will set the current thrust limit (which will be R-TO or TO). You can change the thrust limit manually on the N1 LIMIT page, though. c.) Yes, of course. But - as in the real plane - you must be at a different altitude than the one set in the altitude window. So you can´t be at 3000 feet, have the altitude window set to 3000 and then expect to engage V/S. It is not allowed (technically the aircraft intercepts the 3000´ again before you even start to gain any vertical speed). To start a final approach descent in V/S just put the MCP ALT to something suffiicently "high", then dial it down to missed approach altitude when you have safely descended from it. Jan

Just see his new signature " Author of Gizmo64 for X-Plane. “If it can be destroyed by the truth, it deserves to be destroyed by the truth.” - Carl Sagan 30%+ more work for ~1% more customers. -Linux. " .... if in a normal company someone does this he would be fired instantly .... but small people ....

An excellent suggestion. It's be lovely if all the Linux users could simply keep their expert opinions to themselves.

Then your post had absolutely no business being in this topic. Back on topic, please. To all others: We have a pretty awesome product to discuss here! Let's keep it clean and on topic. Further posts like A121017's will be removed from the topic so as to keep this thread what it's really about. Nice screenshot Morten!

The guy has asked me on Skype, in private message, and on here, as well as to other team members. He was told politely many times we were not seeking more beta testers. He's not asking for a progress update. I (or anyone) really didn't need you to chime back. No one was "moderated". I asked him to "please stop asking." Simple request. Don't blow this up. I'm now going to politely ask you to please discontinue any attempt to moderate or derail this topic. Further discussion on this will NOT be had, and that's definitely my warning to you.

I'm not even sure what argument you are trying to make here? What, linux users don't pay for things? Can you clarify your position? Seems to me, I've paid for numerous pay aircraft, plugins and xplane itself. I think the point the poster above was making is that most of us linux users are forced to run windows to use a good deal of products because add on companies don't know how to use cross compilers, or are to lazy to do so. I don't see how running linux at all implies that linux users are not willing to pay for payware products. Your comments here seem misinformed, or ignorant. Not sure which. Please clarify your position. I am going to suggest that the add on developers for any and all flight sim related products start reading articles like this: http://betanews.com/2016/03/04/windows-10-universal-windows-platform-monopoly/ Microsoft is working on taking 30% of your GM from you. In nitch markets like flight simming this is going to push a lot of you guys out of business. You might want to consider starting to support platforms that are not looking at shutting you out of the marketplace. Because if you think Microsoft or Apple aren't closing the door on you, you need to open your eyes. Of course, unless you want to take a 30% pay cut, and be subservient to the Microsoft's of the world.

Ben, I am not sure what you are implying by that only a small fraction of linux user will buy your addon? Is it of all the people in the world who use linux but are not sim enthusiasts? And is it the word pirate that comes into mind? Because of all linux xplane users all interested in jets will buy it, I don't know other way and that may be a few hundreds linux xplane users. If you imply pirating, then this is very ugly. Usually windows type of people come to ask for help with a pirated addons and it is very shameful when they share their logs ... Anyway, your words are so greedy and offensive that I just decided that will not buy ixeg737 though I have windows10 installed, not until it becomes crossplatform as the the xplane itself. I have lived until now without it, not big deal, we are not even sure how good it is, only advertisements and insults .... Sent from my iPad using Tapatalk

I am speechless. The Preacher. Sent from my iPad using Tapatalk

As a programmer, who has programmed both games, and mods for games, although, not specifically for x-plane, I think your basis for the argument that it would cost you as much development time for the support of additional OSs, as it did to develop the base product is incorrect. You should not be redoing the bulk of your development, in both art assets and programming assets for each platform. If you are redoing everything completely from scratch, you are clearly doing it very, very wrong. But, you answered my question. Your comment, while crude, was to point out that you do not believe developing product for linux, and apparently OSX, is worth the money to you. It's a fair judgment call to make. I understand why you might make that call. Your public relations on the other hand leave a lot to be desired.

Long term, I think x-plugins.com position may change. There is a lot going on in terms of what Microsoft wants to do with their software distribution. There have been plenty of rumblings about MS closing off software updates and forcing them through their store. We have already seen them kabash XBox Projects (Dust 514) because they would not agree to allow updates to flow through without MS getting their 30% cut. With Microsoft moving to the free OS distribution model, you will see them put the squeeze on software developers. Guys like x-plugins.com will end up paying a 30% royalty to MS for distribution rights. This will either squeeze guys like x-plugins.com out of business, or you will adapt, or hard core PC gaming will move away from Microsoft. What Microsoft is doing here is transferring the revenue stream. Rather than having the end user pay directly for it, they will force software developers to pay for it, and pass the cost on to the consumer through them. Really, it is brilliant, and a complete win for Microsoft. Apple, believe it or not, has a bit softer attitude about this, but I wouldn't look to the holy grail to be produced by them. Google, they aren't even in this market yet. In the very unscientific sample of my groups of friends, whom are all IT guys in one way or another, and whom tend to buy more "hardcore" types of games, and therefore are somewhat more representative of the more serious gaming crowd, a few of them have moved to linux primarily, and a few of them have gotten macs here in the past couple of years. The reason they are able to do this is because of the efforts of Valve. Valve has over the past 2 made linux and mac gaming a possibility. Therefore the Mac and Linux gaming communities have grown substantially. Several of the commercial producers on this site are very focused on Windows now. Like I said earlier, it makes sense, if you look at the past of the market. But, markets like everything else change. They are changing. I for one believe that what Microsoft is doing is putting nitch gaming at risk. These small time developers are most likely going to go out of business, because they do not have the capability for strategic foresight, largely due to their small size, and based on the statements from the above posts some ignorance in what is happening in the IT market. Times are changing, and the market will speak. Hopefully our hobby will survive.

I am beginning to understand why this community was forced to separate from x-plane.org. I'm a bit ashamed I've spent money at the store here.

Please stop asking. You've already been told no.

it was ironic. I only think that 5 years are too much, also for a perfect plane. I know what it takes to develop a perfect plane, just beacause i am doing it. The most is fmc programming, but it request a specialist and this is what i needed for my plane, until i decided to develop a citation. "The plane is coming" I am sure about that, sure and faithful to the developers, but they shouldn't give us "release dates" like in the end of december... This is my only critic

I think i am waiting for a plane that doesn't exists... Always same escuses like "few things to be solved", "Gizmo crashes" and so on for 3-4 months. This is not a correct behavior, you should work instead of post screenshots. Altough It will be a great add on, but i hope that it will be for XP10 and not for XP256461