Setanta

This is the problem I was trying to point out! Because these fields are easily modifiable their value as a reference point is minimal. Yep, and unlike some payware providers I've always been very pleased with the support I've got with aircraft I've bought from X-Aviation. Very true, but sadly it's the nature of the beast when it comes to X-Plane. People will tamper and tweak and then complain when they break something. It seems to me that your exception to my original idea was that it involved the user modifying the original .acf file. The whole point is that it wouldn't. It would remain in its factory sealed condition. What would be changed is the data within the running copy of X-Plane. Would this cause problems for your plugins? What I was looking for was another way to change the acf_descrip without having to modify the original file in PlaneMaker which causes problems with the update procedure. Setanta

While it may have been meant purely for the use of the developer the actual data is easily accessible to anyone. This may change in the future but right now this is the way things are - and if something is easy to modify, you can bet your ass that someone will modify it Setanta

Actually there's nothing 'horrible' about it at all. The whole problem seems to stem from the false assumption that the acf_descrip data is fixed for a given aircraft, which it obviously is not - it can easily be (and often is) modified in PlaneMaker or under plugin control. The Falco plugins seem to make this assumption, which is poor programming practice at best. XFSE assumes that the acf_descrip is user modifiable but assumes that it won't be modified by another plugin during a session, which is somewhat more forgivable. Probably the best solution would be some modification of practices on both sides to remove this dependency - both should really use a file external to the .acf to store the information they require. Actually if the Falco did this then users could tweak until their heart's desire and it would work fine with XFSE as it stands. Setanta

Just had a thought (I know, you can smell the wood burning)... As an alternative to this process, a quick check on the datarefs shows that /sim/aircraft/view/acf_descrip seems to be (somewhat surprisingly) writable. I believe this is the setting that needs to be changed for XFSE to work. Perhaps this would be a better approach - it could be set up in the plugin to read it from the xsFalco.ini file (as used for the default VFR Code). This would avoid any need for the original author of XFSE to modify his script and give a more flexible system all around as well as neatening up the files associated with the Falco. Setanta

Made me wonder if Cameron has been reading my posts over at AvSim's X-Plane forum Seriously though, it was nice to hear someone else pretty much confirming what I've been trying to get over to some of the FSX community about development for X-Plane over there . Setanta

Hi folks... I feel the need to point out a few things about the above mentioned optimisers... 1 : Renicing X-Plane is unlikely to have very much if any effect on frame rate, especially on a dual cpu system. Even on a single cpu system gains are likely to be absolutely minimal and some timing critical functions may be compromised by uninformed use of the renice command. If you quit all other open applications before running X-Plane then you are unlikely to get more than perhaps a couple of percent extra cpu allocated to X-Plane, which will only give any detectable increase in frame rate if your setup already maxes out your processor. 2 : It is the nature of OS X and its virtual memory system to deal with memory allocation on the fly in the most effective way possible. Freeing up ram with an application such as this will not affect the actual amount of ram available for X-Plane and hence will not affect frame rate. What it may do is free up ram before X-Plane starts up rather than as required which will speed the loading process somewhat (through the process of freeing up the memory in the first place probably takes at least as long). It may also give an increase in frame rate immediately after X-Plane loads - however this advantage will rapidly disappear as memory is allocated normally. 3 : According to reports 'Quartz Extreme 3D' and 'Quartz GL' may or may not give frame rate advantages depending on your particular setup. In some cases it may make frame rate drop significantly. However, turning the options on and off globally is not recommended. The procedure recommended by Apple is for the developer to test their software and, if there is an advantage to be had either way, for their software to turn the option on or off for that particular application. I don't know if X-Plane does this or not. However, if you find a significant advantage to having either turned on I'd recommend dropping a line to Austin to ask him to examine the possibility of turning it on the correct way. Setanta