Jump to content

Litjan

IXEG
  • Posts

    5,549
  • Joined

  • Last visited

  • Days Won

    395

Everything posted by Litjan

  1. Hello Rhydian, hello Meshboy, the video you saw there briefly was tagged "public" wrongly. It was actually a movie of a nasty autopilot bug that killed many virtual passengers . I am happy to say that the autopilot is steadily improving, though, and only kills me once in a while now. To do a demonstration about the electrical system would be very boring - not a whole lot of switches to move, and the effect would be limited to some caution lights and flags coming on and corresponding instruments going offline. We have a debugging tool that lists all the busses and wether they are powered or not. You´d need to lay the electrical diagram on the side while watching to understand what is going on. Geeky stuff! I will add bits about the electrical system into the other systems-video, though. For example, I can unpower a transfer bus by disconnecting it´s AC power source and moving the bus transfer switch to OFF, then try to start an engine without the corresponding igniter system powered. Now THAT is showbusiness! Can´t say too much about IXEG and XP10, except that yes, the IXEG 737 will be a XP10 product. My personal guess is that we won´t release before XP10 is declared "final", though (out of the Release Candidate state). Jan
  2. All right, all right Here is a shot of an approach to KPHX 25L. Autopilot is in command, just past the decision height. Again, a beta shot. Minor things are not right in that picture, yet. There is no Vref depicted on the speed tape. Also notice the hollow yellow bar extending from above - this shows the placard limit for the next logical flap setting. In this case it would be 158kts for flaps 40 - in the real plane this wouldn´t show, because the landing flap setting of 30 is known to the FMC. Also some minor things not working yet on the engine instruments (oil pressure too low), and some symbology on the EHSI missing (M denoting magnetic heading, track line, etc.). If you have any other questions about what you see, please fire away. Jan
  3. Thanks for your replies. We do watch the response we get on these forums very closely. There is an ongoing fruitful debate within our team about user expectations, and it is very interesting to hear what users like - although we know that there is also a "silent majority" that never posts. No one wants to model a feature that is never used. And everyone wants to model the feature that is used the most. But which is which? Where to draw the line? Fortunately (for me, and also you, Emalice) it turns out that once you do a system to a certain level, it is EASIER to make it more realistic than to work around the problems brought about by leaving out some stuff. Let me give you one example. Yesterday I talked to one of our developers about the AUTO FAIL feature of the pressurization system. This light (and the subsequent auto-switch to STBY mode) gets triggered by 5 different conditions, one of them being the TRANSFER BUS 1 being unpowered for more than 15 seconds. We faithfully reproduce that - with the unwanted outcome that every time you start the airplane cold and dark, the "AUTO FAIL" will be triggered when you turn on the battery switch (those warning lights are powered by the battery bus). Of course it is triggered, because the transfer bus wasn´t powered for 15 seconds! But this is not what happens on the real plane, otherwise I would have to reset the pressure control every time before flight when taking over a plane that was without AC power for more than 15 seconds. So where is the difference to the real plane? The real controller doesn´t monitor the 15 sec interval until it is powered (STANDBY controller is powered by TRANSFER BUS 2), so it won´t trigger during initial powerup. Now back to what I said before about modeling the whole system. If you decided to model a part of it (the 15 sec trigger) you are basically forced to also model the "don´t guard until powerup" part. Otherwise it won´t work satisfactory. This chain of features depending on subfeatures seems to lead us into modeling things all the way - which takes it´s time, but will ultimately be worth it, I think. Regarding the price - nothing is decided yet and I could not even give you a rough estimate. Jan
  4. 2x, 3x, I like the trend I am seeing here... Jan
  5. This is a copy+paste of my reply to the request for some news at the .org: Development continues at a steady pace. Programing systems is a long, tedious and sometimes very boring job. Our design paradigm calls for every button and knob in the cockpit to not only be functional, but also to have a realistic effect. If you look at this from the designer perspective in a cost/benefit relation, it is a not a very smart decision. Why? I give you an example: We are currently working on the IRSs (don´t fret, my american friends, we are not after your money! . Well, we are, but we can´t throw you in jail if you don´t pay). The IRS (intertial reference system) is basically a black box that does "it´s thing" in the background. A very expensive black box.The pilot turns it on, enters the position in the FMC and when the day is done he turns it off again. If you feel bored you can run a quick or full alignment after a couple hours when on the ground to improve accuracy. This is 95.0% of the interaction that will happen in the real plane, and probably 99.0% of the interaction that users will do in X-Plane. BUT the IRS´s can do sooo much more! You can input position manually on the CDUs. They display a lot of information on their CDUs. They have an ATTITUDE backup mode (complete with manual input of heading that will drift). Their position drifts over time. They measure latitude during alignment. They need time to align and shut down. They display certain lights, warnings, error codes and sound for certain conditions, failures and omissions. They have a test mode with effect on EADI, IVSI, etc. Other developers claim to have "custom realistic systems" but really only program for 99% of the users - they are smart! We spend the time to get another 0.9% of the users satisfied. The ones that have some background knowledge or the time to read the real operating manual. The ones that like to push some buttons and see what happens. The ones that will try the ATTITUDE backup mode and monitor IF heading drifts over time with an accurate rate according to the current latitude... the system geeks... like me . Other developers get away with their way - if someone shows up on the forums to complain about omissions like that it is easy to dismiss that as being not important (and 99% of the users will agree!). We draw the line a little further. We omit a feature only if it is definitely to our knowledge not possible to achieve with the current technology available in X-Plane. We have to deal with the background framework of that. We can work around, expand upon and really stretch the limits - and do as far as we can. This costs us dearly. Developing this last 0.9% bloats development time (my estimate) somewhere between 2 and 4 fold. If we had to feed our kids with development work for X-Plane we couldn´t do that. The user base for X-Plane is not large and not wealthy enough to pay us an adequate amount for that kind of work. Think about the numbers behind this. What is the average pay per hour for a very talented programmer in your country? And a rough estimate of time necessary to make this kind of airplane? Maybe around 10,000 man-hours. Multiply this with the pay per hour. Divide by estimated copies sold. Add another 20% or so for distribution overhead. Result is the cost per copy we´d have to charge if we wanted to do this full time as a job. Obviously this wouldn´t sell many copies... This is also the answer to why PMDG can do this full time and make money. The very different variable in their equation is "estimated copies sold". So why do we do it? Several answers to that one. First we are determined to make the best and complete airliner available for X-Plane. Many cool planes have been done for X-Plane, but we want to not only push but shatter that boundary. We want to build a name for us, so IXEG will be synonimous with ultimate accuracy and fidelity. Second we all have real life jobs that feed us. Yes, we want to make money with this plane. Yes, we want our time spent reimbursed. But we can afford to be economically unsound about it. This will not benefit most of you... just about 0.9% . Third we are X-Plane enthusiasts. We love tinkering with this kind of stuff. If you love what you do, you are willing to do it for less money than someone who hates his job. (This is, by the way, the root cause of many pilots being not paid very well around the world. But that is another story ). Forth the team was dumb enough to ask me to be their technical advisor. I get to test every system that gets into this plane. I not only test for correct functionality, but also for correct feel and look. I don´t get any money for it, but this is easily offset for me by the satisfaction of bossing them around . This light is fading too quick! This needle moves too slow! The plane isn´t floating enough during landing! I have flown this plane for 9 years now, and sometimes I get this weird feeling that something isn´t quite right, even before I can quantify and pinpoint the cause. I will put up another demonstration movie for you guys within the next few weeks. Yes, it will be as boring as the last one. We will save the ones where I do inverted low-passes at 5 feet over the runway at 338kts chasing Austin´s deer for later . Before the question of "release date" comes up again - I can´t say anything official, but we are not close to it. You might want to look for another christmas present for your wife or mother if you had the IXEG 737 in mind for her... Jan
  6. Try this site: http://www.captainpi...id=22&Itemid=53 Jan
  7. You got it right. The recirculation fan takes air from the passenger cabin, filters it and then returns it into the air streaming back into the cabin from the airconditioning packs. The "packs" are air-cycle machines that take hot air from the engines or APU, compress that air - cool the compressed air and then expand it again to make it cool. Then they mix this cool air with the original hot air as desired to get the right temperature (the air-mix-valve does that). The switches on the bottom are controlling supply into the pneumatic system by left engine, APU and right engine. There will be a tutorial and also a short description of each system, enough to let you use it in an everday situation. To understand each system fully you will have to study the FCOM. Jan
  8. Ok, as hinted at in my earlier post, there is something for you to watch on our youtube channel. Here is the link: If you have any questions about what you see, fire away. Jan
  9. We will have something for you guys to scrutinize soon... First I have to cut that *?%*§% hedge in my garden, though... Jan
  10. I think the instruments are perfectly readable and good enough for accurate manual flying. It all depends on the view, of course. If you "sit" yourself by the cockpit door to view the whole cockpit, then no, they are not readable enough for accurate flying. If you use a sensible view with all of the necessary instruments and the whole window in view, then yes, they are very clear. It does depend on your resolutions setting, of course and the distance from the monitor you sit at and so on. We will likely provide pop-ups of some things that are hard to manipulate accurately while using TrackIR, for example. One would be the CDU for the FMC. Jan
  11. Absolutely right. The best the 737-300 can do is a Cat3a approach to a limit of 200m RVR and a decision height of 50ft radar altitude. This is with both autopilots engaged. The pilots need to determine at 50ft if the lights are visible - if they are the autopilots will flare the aircraft to touchdown. Speedbrakes will autodeploy (if they are armed), the autobrake will start working (if armed). There is no "rollout" function, so the pilot needs to steer the airplane manually to stay on the centerline. This is the reason why there is a RVR of 200m required - you need to be able to see enough to stay on centerline after touchdown... Jan
  12. Yes, there will be an extensive menu for preflight options. I don´t want to give too much away, but you will be able to customize your flight to your hearts content with the ease of pushing some buttons and sliders. Jan
  13. Yes, the TO/GA buttons on the thrust levers will be simulated. Of course you can also program a joystick button with that function - easier to find that one than to swivel the view to the throttle quadrant and hunt for those little buttons when deciding to go-around just before touching down on an approach-gone-bad. Wouldn´t want to take my eyes of the runway/EADI in that second.. And I am 99.5% percent sure we will have a version for XP9 - of course it might lack some of the more advanced lighting features that XP10 will supposedly bring. But we are developing on XP9, and it would be foolish not to offer that version as well. Jan
  14. I think it is almost 100% certain that we will add a passenger cabin as well as a first rate outside 3D model, of course. Jan
  15. Here is a little teaser movie to show you the test for the fuel quantity guages: We do this every morning to test the displays. You need to hold down the test button until the "error 4" appears. Then it will run through this little cycle to test all segments of the LCD display and also check for the integrity of fuel quantity indication. http://www.xplanefre...n/IXEG/fuel.mov (lower than original quality to reduce size) Jan
  16. Yes, the goal is to make every switch in the aircraft´s cockpit usable. So if a system has a test button, pushing it will run the right test. The goal for the first iteration is not to provide detailed failure scenarios (i.e. IRS failure or PMC failure etc.). Various X-Plane failures will work, one example is an engine failure, or flameout, etc. Others might not work, as we have to use plug-ins quite heavily to make everything work. So failing a "default" x-plane component MIGHT have no effect on our aircraft. Of course we model every systems powersupply and failure conditions - so you could "emulate" a lot of failures yourself. Want to see the pressurizations "auto fail"? Well, there are 5 conditions to trigger that, and they are all modeled. Turn off bleeds for a few seconds, and the excessive cabin climb-rate will trigger that. Or unpower the respective transfer bus for more than 15 seconds. Or... We will provide checklists for "normal" use - we might provide some for non-normal conditions. But it will be perfectly viable to use the real checklists and procedures (look at post # 158) Jan
  17. Good point ;D We will add a totally random fuel consumption option so fuel flow will change with the phases of the moon, or something. On a more serious note - real aircraft seldom perform according to published numbers, and we have a "factor" for every airplane that will adjust fuel flow accordingly for planning purposes. And of course the environment and actual flight path rarely match what is planned, so actual fuel use will vary widely. It is up to you to fly a bit more imprecise than me on my trial runs Jan
  18. It will have one. It is planned to be like one of the real ones (there are many options and versions). It will integrate with the systems (autoflight, IRS, etc.) like in the real aircraft. All map modes will be featured. Work on it has started, but it is too early to show any pictures that would do the finished look justice. Interesting but unrelated tidbit: When testing fuel consumption for the simple fuel planner we are going to integrate into the GUI I did a flight of about 300NMs. We are putting in the values off the real flight manual. Those called for a fuel consumption of 1655kgs. Our model consumed 1631kgs. I did take-off from a 1500´airport (EDDM) and terminated my flight at 1000´ altitude. I think that´s where the discrepancy comes from. Jan
  19. Of course operating an airliner is not something you do by yourself (not unless EVERYONE on board had the funny smelling fish, except for you ;D ). We are still pondering if there should be certain interaction between the user and some "virtual" crew members. Nothing has been decided yet. We do cling to the intent of making this as realistic as possible, so instead of adding something that feels artificial and half-baked we would rather not add it at all. Simulating operating in a crew-coordination-concept in a realistic way is still beyond present-day AI and doing it right is a matter of long training and hard to get perfect. So nothing is set in stone - but we are still not at that point of development by a long shot. Jan
  20. Could you please rephrase the question? I am not exactly sure what you are asking and would like to give you a concise answer. Jan
  21. If you buy 60+ aircraft Boeing will mount the wings upside down, if you insist ;D Jan
  22. By all means, please keep posting and asking about any questions or observations you have. The reason we all jumped a bit was because the words (I looked up the posts to get this right) "wrong" and "incorrect" were used in. These are keywords we will be very sensitive to, because we strive for so much accuracy. Tom is right, one has to word things very carefully when discussing things over the internet, a lot of message content gets lost when not talking face to face. Then we also need to consider that english is not everyone´s native language and misunderstandings happen. Stay tuned to this channel, Jan
  23. Yes, it is not really worth arguing about I think one reason I came about this a bit tense at first was the developers dilemma we face. We are modeling one airplane a lot of people are very excited and emotional about. Call it even "in love with" (speaking for myself ). So everyone wants the IXEG 737 to be exactly like the one they know, have flown with or worked on. Yet there are a myriad of choices to make when building THE 737 Classic. And while we certainly like to discuss different features and options we do NOT want to get into a big slugfest of "oh, they are SO wrong! Look at this airliner.net photo I found!" Please continue to point out any inconsistencies you think you are seeing - and yes, there will probably be even some bugs in our V1.0 (haven´t seen any entertainment software being released without them for the last....er, I think, never ever). But DO also give us the benefit of the doubt and the chance to clarify things before calling fault on us. We are really into nerdy detail (just modeled the duct temperature in the mix manifold adjusting up or down dependent on recirculation fan use and cabin temperature), so assuming that we got ALL the switches backwards by accident was really a blow to the gut for us geeks! Jan
×
×
  • Create New...