guym-p

That's very sad news. Heinz was an inspiration to all X-Plane developers. Guy.

Plugin testing is a bit of a slog, but it's going well. With 451 custom datarefs, my first test was to check each one against a range of criteria: Basic functionFailure recognitionWhat happens if the Comet is loaded with engines running?What happens if I save and load a situation?PauseReplayMore detail on that here: http://dh-aircraft.co.uk/news/news.html Situations and replay are not perfect. They can not be without either waiting for a future version of X-Plane and the plug-in SDK that allows developers to register custom datarefs with the whole recording mechanism, or without writing one's own complete replay system, which would be reinventing the wheel. However, none of these tests check for the interactions between one dataref and another, therefore a large part of testing is churning through all the manufacturer's original check lists making sure every thing comes on when it should do: gauge needles spring into life, warning lights glow or extinguish, and systems become live when switches are thrown. These tests have thrown up some bugs which I am gradually chasing down and stamping on. I won't pretend that these are ways of catching everything. I'm sure there are some bugs scuttling undetected until I devise a new trap. My "master" development model is still X-Plane 9.70 on Mac OSX. As soon as that's done I shall port it to Windows, check that, then proceed with a wholesale upgrade to X-Plane 10. This mornings tests included checking interior light levels at various times of day. This is the cockpit at dawn: Guy.

Don't put pressure on yourself to come up with something in weeks, then give up when you can't. It takes a L—O—N—G time to become proficient in all the skills. I was so appalled by my early work that I scrapped the Comet and started it again, from scratch … twice. If you're one of those people who enjoy the journey as much as getting there, then it's all part of the fun. I regret I sometimes go for a week without tuning in to read the forums, but when you have questions (and you will) please don't hesitate to ask. There are always some in the community who seem to take great pleasure slamming newbies, who might say: "There have been dozens of topics on this already!" and then not give an answer, but there are others who will always help if they can. Search, read, but above all experiment. Don't be afraid to try a new technique. Even if it leads up a blind alley, you will have learned a lot. Good luck! Guy.

Another thing is how you choose to model instruments. If you map Plane Maker instruments to a 3D cockpit it becomes a FPS hog. Therefore if the aircraft you are designing has analogue instruments, model them in 3D with animated needles and flags. Obviously when you have to use Plane Maker instruments, e.g. for EFIS, then you must. Guy.

Stunning. Simply stunning. As for frame rates, the depth and quality of Tonka's work goes so far beyond expectations that the question is no longer whether the polygon count or texture detail is low enough to run on my computer, but what computer I must buy to run the Jaguar. Guy.

I think there is plenty of room for several Boeing 737s. It's been operating since 1968, and with yet another new version in development for 2017. I've travelled on so many of the things, from family holidays on 737-200 to the present day, that it's easy to ignore them as part of the furniture. In fact they have punctuated important events throughout my life, and, if I stop and think about it, there is a lot of nostalgia attached to them. I'm sure I speak for a great many (if not all) of us. 46 years. Is that the longest production run for any airliner? The longest production run for any jet aircraft was 50 years, but the 737 will beat that — especially if the 737 MAX is successful. Studying how the 737 has changed is to map the evolution of the modern jet engine, cockpit and navigation systems. It might be ubiquitous, or boring: the "Ford Mondeo" of the stratosphere; but it's an extraordinary achievement, and one that deserves to be celebrated with many different versions in X-Plane spanning its entire history. I'm all for it. Guy.

This is, quite simply, the best model I've seen. Full stop. Absolutely super work, Tonka. I can't wait for you to start posting pictures of the cockpit.

Very beautiful indeed. Lovely lighting.

I can't find one here, but have you tried searching in "Downloads" at X-Plane.Org? There is a Freeware Antonov An 225 by "Zeheron" for X-Plane 6.50 that was updated once by Gary Hunter, and more recently (Feb 2013) by Ramzzess. I've not tried it, but it might get you going. Guy.

Thanks! I've just finished the fuel system plug-in. Everything needs testing properly, of course, but the code is finished, a few changes or additions to the model have been made, and it's working well. A fuller write-up is here: http://www.dh-aircraft.co.uk/news/files/fb38443eed8229868c16b7817042f947-107.html The job list is getting smaller ... Guy.

That's a real nuisance. I have only ever used Blender in its vanilla state; I have never tried XP2Blender. Commiserations, etc ...

I'd endorse that, too. Absolutely possible, and you would learn an enormous amount in the process. Developing for X-Plane has always been very much about "learning by doing": there would be times when you're banging your head against a wall, and a lot of pleasure when the penny drops and it all works. Do you have 3D skills? If not, that will be a steep learning curve. It takes a while to get your head around navigating a 3D model and creating shapes by extrusion and manipulation. This has nothing to do with X-Plane. Like any skill, perhaps learning a language or a musical instrument, it takes time, effort and patience. It's definitely possible, though. The ACF format is modular, and you can drop a replacement cockpit straight in. As for Project Two, there could be an intermediate stage purely with animation. I am not familiar with either aircraft, but it's amazing what you can achieve purely with existing datarefs and animation. For example hiding the hot-spot for a key-click so that a switch can not work until another switch or lever is operated first — that sort of thing. Of course, if you want to extend the functionality of X-Plane itself, then you need to write a plug-in program. Guy.

Much as I admire Blender and its enormous capabilities, I have always found it unnecessarily complicated to achieve the most basic things. By contrast, AC3D looks like software from the 1990s, and appears to be light on features, but what it does it does well. I use Blender for its advanced lighting effects, but only once the model is made. I prefer AC3D for modelling, animating unwrapping and laying out a texture UV map, and exporting to OBJ8.

It's been a while since I reported anything new. Cosmetically, the Comet hasn't changed, so I have no juicy screen shots to show off, just continuing work in code. Today, however, I had written enough and compiled enough to see various branches of the project working together. Nothing comprehensive, but it demonstrates the level of detail I'm working towards: http://youtu.be/ORzg_Q2dfl4 Guy.

Yes: check lists often specify a maximum airspeed above which wipers should not be used, and it's surprisingly low. Rain repellent products were specifically developed for aircraft to reduce the speed at which raindrops bead up and roll off the screen in the airflow. It works extremely well on cars at motorway speeds, so that one can turn off the wipers and see better.

Sorry for the lack of news. I'm deep into C programming at the moment so there's not been anything complete or demonstrable to report. I'm really pleased with the statistical performance in XP10.21. Performance in XP9.70 is good, too, but it all seems to "click" in 10. Now I'm working on systems plug-ins. You may remember from earlier news articles that there are 400 individual steps necessary to get a Comet Series 4 from absolute stone-cold start to take off and climb-out. Without any plugin whatsoever, just using built-in X-Plane datarefs, I could complete 135 items on the official check list — as demonstrated in the YouTube videos I published quite a long time ago. When you read the real check list, you quickly realise that a large number of items are about communications with aircraft and ground crew administration, which are not simulated in any way in X-Plane. Also a number of visual checks where there is no failure mode in X-Plane, therefore checking them is irrelevant. So I will never achieve a ratio of 400:400. Even so, it's an interesting ratio. The motivation behind the plug-in is not to increase that number, although that will happen as a matter of course. It is to make those things that do work function better. For example, in the YouTube video, I had used a lot of generic light switch datarefs and sliders in order to be able to move levers to satisfy an item on the check list, but the levers didn't actually do anything. Now they will. I appreciate that this will be of no interest to some users, therefore there will also be a cheat button, effectively skipping to the end of the check list. Progress is steady. I've finished the flight instruments — debugging them at the moment. The DME radios are now completely separate from the NAV radios, and the distance function works over a longer range than the standard X-Plane instruments. All radios require not only the relevant electrical bus to be live, but also the inverters and radio power switches at the navigator's station; the navigator's station has its own independent ADF radios (ADF 3 and ADF 4). That only describes a limited area of the whole plug-in, but it gives an idea of what I've been up to recently. The next steps are to sort out the electrical supply, and the fuel and hydraulic systems. At this stage, I am not going to replicate historical navigation systems like LORAN or DECCA. That's a big project that's outside the scope of the Comet model. It requires the infrastructure of transmitters and their correct geographical locations as well as the simulation on board an aircraft. I don't have that information, so it would require a fair bit of research and correspondence before any work could actually begin. I have been discussing this with other members of the UK X-Plane Development Team: we're all interested in aircraft from this period, and it would be great to have this equipment available, but we haven't begun to assess the scale of the task. I am also in quite a busy period with my "real" work, and will be on assignment abroad for the whole second half of September, which will cause something of a hiatus for the Comet project — but I'm still very much on the case! Guy.

Thanks! For an airliner, I believe that these things need to be right. At the other extreme, something purely aerobatic must "feel" right, and let the fuel consumption do what it likes. Obviously, best of all is to have one's cake and eat it, but if there is a conflict in some aspect of the flight model, then an airliner (and probably a bomber) would be biassed towards fuel consumption and range, a Pitts Special towards pure handling, and a fighter somewhere in between. It's also a challenge. I had some correspondence with a commercial simulator builder who is convinced FSX is "better" because simulator training is largely procedural, and the model must perform to the numbers. Of course, FSX does that very well. I wanted to see whether that level of statistical accuracy is also possible in X-Plane — and it is. Have I therefore "wrecked" the Comet, or turned it into something dull and unresponsive? No — I don't think so. Thrust, drag and SFC were already in the approximate range. All I've done is to give them a nudge to make them closer still. Nothing has been tuned out or toned down. "Blade element theory" is still fully engaged, the way the Comet handles is still pure X-Plane, and free to respond to its wind and weather. Guy.

I've finished the performance model at last! It's taken ages because the full series of tests takes more than a day to complete, even with two computers running and climbs and descents running automatically, via plugins. It wasn't always necessary to test everything, but I logged no fewer than 116 iterations, ranging from a simple digit change to overhauling a large chunk of code. That's a lot of testing ... I've written a report. It's a dry read, but if you're into this kind of thing, you'll appreciate it: http://dh-aircraft.co.uk/news/files/e744a904ffa2f49adffbe4c7791de9f2-105.html Guy.

I got into rFactor a few years ago. It is only for Windows, so I ran it on the Mac via Boot Camp. The physics was less convincing than Geoff Crammond's Grand Prix series, but what attracted me were the add-ons, like the Le Mans 24 circuit with choices of 1972 or 1991 layout and scenery, and cars of all ages and types. However, driving a simulator can not match the sensations of driving a car. Not remotely. It doesn't mean they're not useful to someone learning circuits, as flight simulators are useful to someone learning instruments and navigation. I often have this in mind when reading luke-warm comments from real pilots about X-Plane or FSX. Ignoring the 2D screen and lack of g-forces, which is a handicap for all desktop simulators currently, my greatest criticism of most driving simulators, including rFactor, is the amount of work one has to do to keep it in a straight line. In the end, once the novelty of all the fabulous and beautiful cars and scenery had worn off, my interest waned. Even so, I would certainly recommend it for anyone who enjoys driving simulators, because it is the best of its kind. Guy.

This definitely works. As long as a custom DataRef is functioning correctly within a plugin, all a developer has to do is to is to add the path for that plugin to his copy of Datarefs.txt. Of course it would be over-written during an upgrade, so the way to make it visible to everyone is to register it with DataRefEditor.

Thanks! And, yes: I will produce a version for X-Plane 10. I have already taken an earlier alpha and modified it for X-Plane 10 to understand the differences. The basic changes to enable the electrical, hydraulic and autopilot systems to work properly are very easy. There are some small but important changes to the object files, mostly to do with how things are lit. The Rolls-Royce Avon Engine plugin will need totally different thrust curves and an independent test programme to make sure they are accurate. It will take time, but days or weeks rather than months. The biggest nuisance will be the need to maintain development paths for two parallel products, which is why I have decided to develop the primary model for X-Plane 9.70, and only split them at the last possible moment. Guy.

I would have thought a new iMac would be a much better choice. It's a direct replacement for your old computer, ie with an integral screen, and much better graphics support. However, as X-Plane and all its add-ons continues to get more and more sophisticated, I can see 1GB VRAM becoming the desirable minimum (if it hasn't done so already) so you will need to shop at the high end of the iMac range. Guy.

I've taken some time this morning to gather a few screen shots and post them here: http://www.dh-aircraft.co.uk/news/files/26afff15b5a355380e75d62b0917ca57-103.html This is the first time I've had it back together and in any way photogenic since some rather major revisions. The changes were precipitated by adding a periscopic sextant in the roof (which, actually, I see I forgot to post news about here) but, because the sextant required changes to internal and external models, UV maps, new shadow-bakes and textures, the changes were far-reaching. While I was at it, I swept in some other improvements, too. Apart from any truly unsightly aberrations, black triangles, gaps or thrashing I find during testing, that's it cosmetically. I can now clear the decks and concentrate on programming. More on that later. Guy.

I agree with you, really; just playing devil's advocate. Each to his own.

Perhaps Sigmoid relishes the challenge of getting it to work. There's fun in that, too.