tkyler

Mick, Default x-plane, like FSX, comes with marginal complexity. The GPS system is currently not very featured BUT is going to get a pretty sizable update in the very near future. Now that being said, you will not be getting FMS style functionality out of the box.. Only the 3rd party add-ons, again like FSX, will have FMS functionality with SID/STAR and route mapping abilities. There are only 3 aircraft currently that have this, the CRJ200, 777 and 757...all using the same code base by the same author so they will all have a similar feel. There are other 3rd party aircraft in the works with that will also have FMS functionality and I'm sure more will make their way into x-plane in the future. Folks are so used to acquiring add-ons for FSX, they routinely 'think' of their addons as default after a while. When folks move over to x-plane, they forget how much money they spent on FSX add-ons to get all that goodness...but that's just the way it is. X-Plane has some catching up to do and it will get there. It has been built from the ground up with stronger and more accessible "legs" than FSX and I believe we will see x-plane carry flight simming where FSX has not. TomK

Seeing as there are two contrails coming out of it.......I'll go with a 757.

Ditto Kris. we've all been there. I walked out for 6 months during the MU2 dev period....a break is a good thing. All the best, Tom

What can I say....it was a long flight and I had to brace myself to wiggle my bum and get blood flowing again. TK

Not necessarily, there are some subtleties and caveats related to camera and acf settings though, both in planemaker and in sim that have tripped me up also. For example, if your aircraft loads with a 2D panel visible (dependent on a few factors), then it will appear as if you are drawing to the xplane window when in reality you are drawing to the panel texture....its just that the 2D panel texture is visible. Try going to a 3D view using SHIFT-9 and see if you openGL drawing appears any different. TomK

There are two phases specific to drawing to the panel texture....'xplm_Phase_Panel" and 'xplm_Phase_Gauges'. The phase in which your drawing callback is called is defined during the registration of your drawing function with 'XPLMRegisterDrawCallback'. First, ensure you registered your drawing callback to be called during the phase, "xplm_Phase_Gauges" like so: XPLMRegisterDrawCallback (myDrawingCallback, xplm_Phase_Gauges, 1, NULL);This says you want the function named "myDrawingCallback" to draw during the Gauge drawing phase (which is drawn to the panel texture)....the 1 says, "draw before x-plane draws(I think.....the docs do not clarify but if you don't draw on top of xplane graphics it won't matter). the NULL, of course, means you're using no reference pointer of any type. Without your registration function, we can't know if this is the problem for sure...so this is just a stab. The following link covers this topic http://www.xsquawkbox.net/xpsdk/mediawiki/XPLMDisplay TomK IXEG

they are not the same. I am not sure if the blender scripts for version 2.69 contain xplane .OBJ import scripts, I do not think so. The original "xplane2blender' scripts for blender 2.49 DO have an import option for xplane OBJ; however, it is a bit limited in that it does not support a lot of "modern" OBJ commands. The method to import an OBJ into blender is to: 1.) Use Blender 2.49. Menu item under import exists 2.) IF the import fails (which it probably will), remove all lines in the OBJ text file that begin with 'ATTR'. This usually requires a custom script or 'GREP" search/replace to remove those lines as there might be a lot and hand removing could be tedious but doable. 3.) Retry the import 4.) If successful, save and then open with Blender 2.69 CAVEATS: Make sure the 3D cursor is at the (0, 0, 0) position before the import. IF the import fails after cleaning out all lines with "ATTR" in them, then clean out the lines beginning with "ANIM". If that fails, clean out every line that doesn't begin with the word "TRIS". Only do this 'cleanout' on the part of the OBJ at the bottom of the file...after the sections with lines beginning with "IDX". those IDX lines and all above must stay intact. The blender 2.49 import script will choke on some "ATTR" and "ANIM" commands so that is what you want to clear out. TomK

This ones is on me. Gizmo is allowing devs to add much deeper simulation experiences but there are not many of us programming with it yet and so our time is spread thin at the moment. Jason has done his part and is waiting for me to finish up some part of the 152. I think you give him too much credit Cam.

use the "open" function in blender and point it to the fuselage.png found in the paint kit folder. TK

What folks like about PMDG is two-fold. 1.) They simulate what folks want....deep simulation. 2.) They deliver! Number 2 here cannot be overstated and as mentioned earlier, they have a reputation for delivering. When PMDG develops a simulation, you know what you're getting. In the x-plane world, that kind of repeatability of uber-detail has not yet been demonstrated IMO. With IXEG, we are trying for not only uber-detail, but the "next level" also. That is, we look at PMDG..what they offer and we say, 'we have to offer that"...but we also look at what they do not offer and we try and offer that too to push boundaries. Now until we actually deliver though....we can't be trusted and therefore do not have the credibility that PMDG has. Individually we all have credibility, but not as a team yet. XP devs MUST provide not only top quality over FSX counterparts....but repeatable quality. If developers do that for x-plane, then the migration of FSX users to products by 'native' XP devs will be seen IMO...though it will take time. X-Plane is a superior platform for customization as evidenced by what we're squeezing into our 737 vs. what FSX can not even simulate at all.....but until this is demonstrated repeatedly, FSX folks will not believe it. We have to be so convincing in our simulations that the evidence is irrefutable. PMDG should be a goal to strive for. They have a great reputation for delivering and I, for one, aspire to that. All we can do is keep producing top-quality work and let the market go where it may. TomK

It is just standard x-plane FOV settings; however, there are view settings in Planemaker that control not only the camera position of course, but also the "tilt" of the camera up or down and we have set this value specific to our cockpit based on Jan's input. A lot of authors do not tweak this value, but leave it default and as such, do not provide an optimal view for the aircraft they are modeling IMO. TomK

The nose wheel tiller cannot be operated at all by the mouse unfortunately. Most folks use a joystick or pedals to turn on the ground anyhow. This is due to a limitation with x-plane's nose-wheel algorithm which we searched for a way around but to no avail. The tiller is coupled to the nosewheel however and not the rudder angle so once the plane leaves the ground, the tiller will not move with the rudder. We discussed the option of deactivating the rudder while on the ground to simulate tiller only operation but deemed it insignificant in the grand scheme. TomK

yessir @ 18:00 GMT +/- 1 minute

its certainly that smooth if you have a decent system. I am using an older iMac i3 chip with 512 card and I can't tolerate this aircraft and busy scenery without hitting 15fps or so. Devoid of complex scenery, I do 35fps no problem.......but 99% of that FPS hit comes from my small graphics card VRAM limitation and x-plane has to do memory swaps with hardware, which is death to performance. Most video cards now exceed 1GB easily and everybody with 1GB card seems to do very well. I've seen it run on a 2GB card and just absolutely fly with everything cranked up. We have really worked hard to optimize this thing and for all that you get, I think it runs very very well. The video has been "processed" color and pixel sharpeness wise...twice. Once by the video editing software and again by YouTube....the quality we see on the screens is represented in our screenshots and not on these videos. 3 of 4 online at 18:00 GMT today. TomK

Part 2 of 4 up

Unfortunately, the Aerosoft data wasn't available when we started programming the FMS and the route building code is the nastiest code in the project so reworking it to Aerosoft will not be an overnight thing. We will; however, look into it very soon after release. It might be easier to code with he Aerosoft format, we'll see. The next video, part 2 of 4...we will release some time between 18:00 and 19:00 GMT today.....and it gets better! Tom Kyler

Part 1 of 4. We will release the others on consecutive days. TomK http://www.youtube.com/watch?v=rMRKx8hZjXw#t=0

We are going with navigraph data...so subscribers get whatever they give. We will look at moving to Aerosoft's format in the future though as we feel this is a more robust dataset better suited to the future needs of flight simmers. TomKyler IXEG

Just wait till the next teaser movie comes out in a day or two. We are having a bit too much fun immersing ourselves in the cockpit and sounds. TomK

night shot. a video should be coming along in the near term. Not just a pretty face as the upcoming video will demonstrate...most everything is operable with considerable attention given to immersive detail...aural, visual and tactile. TomK

The FMS is not complete enough for setting up a full flight ktomais. Partso of it work, but not all of it. The FMS is probably around 75% and we have to connect lots of loose ends together. Tutorials are definitnely a big part of what we want to provide. TomK

We do not control turbulence from the aircraft side of things. The turbulence model in x-plane is a bit crazy and I myself simply turn down x-plane settings along with the thermal climb rate, which introduces ridiculous turbulence. We also do not put in wing flex and engine shake as of now. We have a philosophy of operational accuracy first and secondary physical responses later. Such effects go into the "eye candy" category, which is not bad at all...we like eye candy ourselves, it simply falls at the end of our priority chain, so given the option of spending our time developing low priority eye candy effects now vs. real aircraft operational accuracy, we choose the latter as priority. In addition, wing flex is not easy to get right. Most folks use simple relationships and this results in excessive flex in hard landings, which looks bad. We would like to implement proper beam flexure and stiffness models from mechanics and possibly forcing functions to get small wing vibrations while taxiing. All that being said, the classic has relatively stubby wings and do not flex as much as longer wingspan aircraft so nobody on our team misses it, we're having too much fun just sitting in the cockpit. In summary, yes we like wing flex but we will not put it in to simply make a longer bullet list for marketing. Once we get everything else done right, we may turn to the wing flex for this model, we may not...the short wings may not be worth the effort involved for this aircraft, at least not for the initial release. We are 3+ yrs into this and need to wrap up asap. Once we have a product on the market, some revenue and more time to invest in this kind of thing, then you will probably see more eye candy features applied. Right now the cockpit and sounds are just fantastic to experience IMO. We are working towards another video as soon as possible. TomK IXEG

There is a bit more to the story, Jason is being very professional. Some technology from the 737 is desired to make its way into these Four Forces projects. The problem is between the 737 work, Laminar crunch time on some end of year work, finding time to work with Four Forces has been difficult so I bear quite a bit of the blame here. As always, we feel the quality of the work is worth waiting for, at least from our perspective... but we share in the frustration that we do not have more hours in the day as we have to maintain other jobs to pay bills while the x-plane market is still relatively small. TomK

I am reminded of the movie, "Captain Ron" where the boat captain says. "We must be close to our destination because I put in just enough gas to get to our destination and we are almost out of gas" Another example...If I get on the road and drive on the wrong side of the road and do not get in a head-on collision because no one else is on the road.....then someone else does gets on the road and we do get in a wreck...... That's like saying its their fault because until they got on the road, I was fine so the problem must be with them. Sometimes, you do not know you have a problem until someone or something else brings it into the light. In these situations, you simply investigate and improve, usually with the cooperation of both parties involved as is could be anywhere....but folks other than the plugin authors need to refrain from comment as to the nature of the problem. TomK

The library file gets overwritten during the update....which means even though your object still exists, the library entry no longer does and you must re-insert the entry into the library.txt file. I myself used to keep a small text file with my custom entries in it and after updates, I'd cut and paste in the custom entries back into the library.txt file. The library system is designed to reuse objects......so if you have a one-off NDB station, then it should be part of the custom scenery package; however, if you do plan to reuse in several scenery packages, then of course use the library but because its "yours" instead of "laminar's" then you can expect that cut/paste operation each update....MAYBE...because if memory serves, you MAY be able to create your own library.txt file with just the custom entry and put it in the same folder as your object. X-Plane grabs many library.txt files recursively along the way when loading, so you might try a "one-entry" library.txt file and see if that works. If not, then add the entry to the bottom of another library.txt file and give that a go. TomK