Dozer

I can only point you at the manuals. I can't read them myself, because I can't download them, because my internet connection is rubbish. But the CRJ has a Flight Management System simulation that is at least mostly complete - i'd be surprised if it's missing any important FD or autopilot modes. CRJ: http://www.jrollon.com/CRJ.html ERJ: http://forums.x-plane.org/index.php?showtopic=45360 (I'm not sure this manual is up-to-date. It is from May 2010, and a new version of the ERJ was released in Oct 2011. Possibly the 2011 updates were only cosmetic, for example the pushback truck. I'm completely guessing here.)

I bought it years ago to say thank-you to the author, Dan Klaue, for his excellent YouTube videos on how to use PlaneMaker and Blender to make aircraft. The ERJ-140 was the subject project of the video. At that time, it had no systems simulation at all, but now the .org page is saying 'Amazing model with custom systems' so it must have been updated. I'm a bit annoyed; I never received an email to tell me the aircraft I'd purchased had been updated... Modern glass-cockpit aircraft aren't really to my taste so I didn't use it much. I haven't had it installed for the last eighteen months or so; sorry I can't give more information. If you're not specifically after an ERJ-140, the Javier/Philipp CRJ-200 is on sale at the .org until the 30th, half price at $30: http://store01.prostores.com/servlet/x-planestore/Detail?no=292 I haven't used it, but this aircraft has an excellent reputation. It's been out for over a year, but most people will agree it's one of the highest-quality X-Plane additions yet made, with good systems simulation.

Zero marks for observation; this is the X-Plane forum In XP9, you can't assign multiple axis to the same control, so you'll need to assign the pitch and roll each time you change over. Or you can use X-Assign to create presets and/or load specific control-bindings per aircraft. You can bind multiple joystick buttons to the same command though. Just don't be unplugging one device and plugging in another; this DOES confuse X-Plane. (XP10 has an entirely rewritten joystick interface bit, I haven't used it, but it probably works the same way as for XP9 as far as the end-user is concerned. You can experiment for free with the XP10 demo if you like, if you haven't got XP10 already.)

I loved Silent Hunter III back in the old days. Never quite committed enough time to it to completely figure out how to plot torpedo solutions though. I like playing computer games which require plotting things on paper and using a protractor - hence interest in realistic-y aircraft navigation. I've found a likely candidate dataref: sim/graphics/view/view_pitch. I think it's the camera boresight angle above the horizon in degrees (so negative values are below the horizon). It can be easily read with DataRefEditor. Remember the DataRefEditor window can be resized by dragging the edge, and moved by dragging the centre, and if you type in view_pitch in the (not very obvious) filter box in the lower left frame, it will hide all the datarefs except this useful one. I'm wondering how a sextant tool might work in sim. It might be possible to have the main part of a classic naval sextant animated to stay vertical and aimed at the horizon, with a preset camera position at the pivot-point of the arm. (I'm inventing names for sextant bits here.) Then you'd manually aim the camera in the vicinity of the star, move the arm so it lines up with the star, and read off the arm angle from a scale on the 3d object. If the base and the arm of the sextant are both rotating around the preset camera position to keep the base aligned and the arm lined up with the star, this could probably be done without complicated camera-override-y plugin code - in fact probably without any plugin work at all. Aircraft bubble sextants and periscope sextants, used in the age of pressurised aircraft, would probably need a camera-override-y plugin and a bit more work.

No worries, I should have used the 'check inside' feature. I'll order again for the correct item!

Nooo! It arrived a few days ago, but this is the study guide - it's just contextless questions with the answers written at the back! Did you mean to recommend this one? http://www.amazon.com/Electricity-Electronics-Technology-published-Paperback/dp/B00A0705MQ I've been stalled for ages on this project, not for any great technical reason I don't think, just lost a lot of focus and vision for life generally a month or so ago. My last great revelation was that, as the batteries NEVER reach above ~25V no matter their state of charge or their current, and the generators are voltage-regulated to ~28V, the current flow will always be into the batteries when the generators are running. So figuring out how to model a charging battery, as well as a discharging one, this is the next step. I just need to turn off the browser and launch the compiler, which I will be doing, starting from... now.

Thanks Goran, that clears things up a lot. In the distant past (with my old PC, which is still stuck on the other side of the world) I did modify the Duchess and other X-A aircraft, but didn't ask for permission as I didn't know the ToS required it. (Personal changes, not distributed or published anywhere.) Probably other tinkerers didn't know about the ToS either, or they did know and didn't care! That's probably why no-one asked about modifying things. Either that or they were just very happy with the downloaded aircraft and didn't see any need to change it. I replaced the DMEs on another aircraft which didn't have any conflicting plugins - an unusual aircraft which does appear to have two standalone DME tuners alongside two plain VOR tuners. I'm very aware of the difficulty in making unilateral modifications to something like the Saab! Possibly I'm being paranoid, but I'm really hoping there's not a situation where leading developers would desire encrypted .obj files and .acf files etc in X-Plane 11, preventing user modifications. The transparent and mutable interface between interface and simulation is very very valuable; being able to tinker and make a fix (instead of politely asking a dev to make a change, and waiting indefinitely) is a massive strength. I'm hoping that developers are happy with this, as long as their work is not distributed and they're not expected to support modified things.

Thanks for explaining this Goran - as you've developed many aircraft you must have had this conversation with confused users many times. What do you think about users privately modifying the aircraft for their own use, without redistributing, without expecting support? Your/X-A's Terms of Service explicitly prohibit this. I hear suggestions it's a 'don't ask, don't tell' policy and X-A don't really care what users do in private, but if this is X-A's attitude why doesn't the ToS just say 'If you modify the files, we are not obliged to offer support' instead of 'modifying the files is prohibited, if you do it or discuss how to do it, your licences are void'? (That was a paraphrase.) I'd like to buy a licence to receive digital files which are expected to produce a certain result (for example, to simulate a particular aircraft in the X-Plane simulator), and to receive support if it doesn't work as expected/advertised. But I'd like to make local copies of those files and make modifications to them, for my own private non-redistributed use, without entitlement to support, with the blessing of the developers and the publisher. The sort of modifications I'm talking about: - change datarefs in the .obj file (for example, changing the DME readouts and frequency selectors to my own twin-standalone-DME plugin instead of the VOR DMEs) - change animations in the .obj file (for example, hiding the flap assemblies if the flaps had failed) - fixing minor bugs in advance of an official fix (for example, swapping the flood and post lighting rheostat datarefs so the function matches the labels) - changing the flight model in Planemaker (for example, altering the flap limit speeds to a different margin of error for 'gameplay'/taste reasons) - adding a pilot figure object, visible in external view

This is depressing. Sorry the order didn't work. I hope it can be resolved. Wish it could have been sorted privately by email and without forum threads and bannings and unpleasantness like that. X-Plane.org is a separate organisation to Laminar Research, who make X-Plane. They only sell X-Plane 10, they don't develop it. There are other legitimate vendors of XP10 - for example, X-Aviation.com: http://www.x-aviation.com/catalog/plane-p-80.html X-Aviation have excellent customer service; they're renowned for it. They also have a growing community on their forums, including many who were outcast from X-Plane.org for various reasons, and are the home to many aircraft developers. I don't like their Terms of Service, which prohibit modifications to the aircraft they sell, though. It's especially regretful because they sell many excellent aircraft I'd like to tinker with (for my own personal use). I hope you will be unbanned at the .org; there is a great community there, lots of expertise.

The trim-wheel noises! The signature sound of the Dreamfleet 727! That brings back memories. I loved that aircraft, but I can't go back to it, with the 1024x768 panels animating unaliased at a fixed 16fps. I remember in the Dreamfleet aircraft the aircon noise and the instrument agitators nearly masked the sound of the engines. (Sorry for bringing up end-user modifications - it's off-topic and deserves its own thread. Good to discuss it on the neutral AVSIM forums, though.)

This is on the list of things I'd very much like to make. Glad to find someone who knows about celnav! How good is the X-Plane sky - are the stars accurate? Literally all you need is a tool to point at a body and get the angle above the horizon? This should not be hard... You might be able to do this immediately if there's a dataref for camera angle above the horizon. The old navigation ways are the best. The advent of EFIS and GPS makes everything so boring. (have you seen the 'Children of the Magenta' lecture about the FMS/autopilot mindset of modern pilots?)

I'm overdramatising things here. Before making a purchase I'll email the X-A administrators asking for permission to make specific types of modification, all for my own personal use: - changing dataref names in the .obj files - changing animations in the .obj files - altering the .acf with PlaneMaker If I can get written permission (an email/PM must count as 'written'), I'll buy the aircraft, and modify away. Otherwise I probably won't. I won't deliberately ignore the wishes of the developer/vendor and ignore the ToS, even privately! (Coincidentally, happy Christmas everyone!)

It would be a good idea to check the ToS/EULA to confirm you're allowed to make modifications to the aircraft, or discuss modifications to the aircraft - this is sometimes prohibited.

Hullo AVSIM, Do the reviewers take requests at all? Not sure if it's appropriate to ask... (If it is appropriate to ask, I'd love to see a review of the FlyJSim 727 for X-Plane 10. If it is inappropriate to ask, don't read the previous sentence.)

Well, snap. I don't know how long that clause has been in the ToS but I've been making and posting modifications to X-A aircraft for years without realising it was a breach. (Maybe it wasn't a breach if the ToS were different when I purchased. No-one's complained... yet.) I'll go clean up my uploads. Very sad to see that clause there. I expect permission to modify aircraft beyond 'factory standard' condition and the presence of this clause presents a major disincentive to buy. (Disclaimer: I don't buy many aircraft anyway, not many run on my ancient PC, so I don't expect this statement to dismay any publishers.)

A must-have model. Looking forward to its release!

The livery packs were made by third parties - they've been released as payware so the artists get partial remuneration for their effort. I say 'livery packs' but AFAIK there's only one available right now, the $19.95 'Complete Set' of 51 liveries that DannyH mentioned. There's at least one other pack coming, but I don't think it's part of the 'Complete Set'.

I only bought the CIVA. I don't have XP10 so can't use the 727, but look forward to reading reviews. (If Avsim could review it formally I'd love that.) I really enjoyed the Simufly CIVA for MSFS and look forward to seeing how Philipp's CIVA compares. Unfortunately it doesn't work for me with XP9 in Windows (yet)!

I think the best method for setting a default viewpoint (and for handling 3d cockpit viewpoints generally) is to use the PilotView plugin. You can assign up to eight camera preset positions which you can move the camera to with commands (keyboard or joystick buttons) as well as being able to move the camera about normally. PilotView can be set to start automatically and load preset #1, so you can set the 'default' position without using Painmaker by using PilotView preset #1. PilotView also has roll control of the camera so it might enable the TrackIR's roll input. I don't know about that, I don't have a TrackIR. You can get PilotView from here: http://www.xpluginsdk.org/pilot_view.htm

I love this Getting all those overhead-panel lights to dim in the hardware will be a fun challenge!

Awww. That's me out of a holiday job then!

Just read the manual myself. Javier certainly writes in a very distinctive and charming way! I'm tempted to offer to revise his manuals, to correct some spellings and expressions, perhaps in exchange for a copy of the aircraft... I'm a bit short of cash at the moment. I have one crushing disappointment: this is a British aircraft, yet all the text on the instrument panels is UPPER CASE. This is the universal American practice, but some British aircraft from the 50s-70s period would use lowercase and it was very distinctive and characterful! Perhaps it was only De Havilland who did this. I have no doubt Javier's modelling is correct - the fault belongs with Handley-Page, the Jetstream's original designers! More seriously, the requirement to load a different aircraft before exiting X-Plane is very unusual. I thought it was possible to override the flight controls without losing the joystick axis bindings - I've done this myself, but not in an aircraft which uses the default autopilot. Also, it is absolutely essential to offer a no-questions-asked money-back guarantee. Potential buyers like yourself, Walt90, who are considering purchase but are concerned about issues which might or might not exist, are more likely to buy if there's a money-back guarantee. A user who's paid $30 for a product which they can't use is an unhappy user who won't buy the next product and who will moan on the forums. Telling them they can still use the product in the future when they've upgraded their computer will not make them happy! This isn't my opinion, I got it from Joel Spolsky, who writes a lot about software development. He has this guarantee on all his company's products. I laughed out loud at the 'COPILOT TO TOILET' button! Also it's good to see an aircraft where the doors and windows don't open when the fuselage is pressurised - often this is overlooked.

Hang on - the source code needs to be altered for 64-bit? I don't know that, but I haven't got XP10 or a 64-bit computer so I haven't crossed that bridge yet. I thought the source code stays the same, it just needs to be compiled with a 64-bit compiler. That's the process for building cross-platform plugins for 32-bit XP9 anyway. The same source code can be used to make Windows, Mac and Linux plugins, unless you're using OS-specific functions to, for instance, find the path to an .ini file. The burden is that the programmer needs access to all three OSes to build, test, and provide tech support for the plugin. For this reason, I've only produced Windows versions of my plugins, as I don't have a Mac or the cash (or, to be honest, inclination) to buy one, and haven't had the time (or, to be honest, inclination) to install Linux yet. In any case, I'm sure that 32-bit and 64-bit versions can be developed, tested, and supported from the same computer, and that will be easier than multi-platform plugins which must be compiled, tested and supported from more than one computer.

X-Plane developers already support at least two platforms: Windows, OSX, and many support Linux too. So I don't think any developers will be fazed by the expectation of compiling both 32-bit and 64-bit versions of their plugins for the next 12 months or so. 32-bit use will probably fade away as people upgrade. Because X-Plane has been the best choice for Mac users for many years, there's disproportionate numbers of Mac X-Plane users. I think the stats for X-Plane users are roughly 50% Mac, 50% Windows, and 2% Linux. Roughly. A developer who can only manage one version of their product is already denied a place in the X-Plane market.

Thanks Alan, that was a good article. Thanks for the detailed reply Tom! I see what you mean about using randomness and noise for systems which don't directly impact on the flying experience. But going by what's written in the pilot's manual for this particular aircraft (the de Havilland Dominie), figuring out what's happening to the electrical system is a fairly significant part of the pilot's workload, even without any failures (or consequences from misuse!). I've assumed the most straightforward way to simulate this stuff is to model things on a volts-amps-and-ohms level but I'll look again and see if a more empirical solution would work. Incidentally, re the 737 and hardware - there's a bug with Teensy where it cannot cope with dataref idents longer than 58 characters, or 55/54 for array datarefs. I've written a plugin which creates aliases of datarefs to get round this issue, but if the i737 can use short dataref idents for stuff likely to be used by hardware, life will be easier for users. I think Paul said he'll fix this issue, but it's a lot of work for him on a relatively low-priority issue, so I don't know how soon this is likely to be addressed.