New General Release (3.2.15)

Status
Not open for further replies.

gadgets

Resource contributor
The two most recent development releases (j) and (k) both contained a critical error when run under FSX. Development Release 3.2.06(m), just posted to http://stuff4fs.com fixes this. Barring reports of further issues, I expect to make this a general release this weekend.

Don
 

gadgets

Resource contributor
Shortly after I released 3.2.07 earlier today, someone commented that the "category=airplane" statement in the [general] block of the aircraft.cfg files applied only to FSX and P3D aircraft. In updating for P3Dv4 compatibility, I inadvertently applied the condition also to FS9 aircraft, which may explain the sudden rash of missing aircraft reports.

As always happens, this kind of advice only seems to arrive after I've made a new general release.

I have just re-released 3.2.07 with a single fix to correct that situation as General Release 3.2.08.

Sorry for the inconvenience.

Don
 

gadgets

Resource contributor
It appears I misplaced a line of code while introducing PV4 compatibility - resulting in a corrupted Traffic & Parking analyser display. Development Release 3.2.08(e), now available from http://stuff4fs.com, should provide more satisfactory service.

Don
 

gadgets

Resource contributor
I have just posted a new General Release (3.2.09). Release 3.2.08, released last weekend, contained a couple serious issues which were quickly corrected. Since you guys have had a week to otherwise shake-down the earlier release, I feel confident that 3.2.09 will be longer-lived.

Don
 

gadgets

Resource contributor
I have just posted Development Release 3.2.09(l) to http://stuff4fs.com. This release has two significant changes:
  1. AIFP has always "assumed" that the text files it read were encoded as UTF-8, i.e., ASCII format. With Prepar3d v4, this is no longer a valid assumption. Accordingly, AIFP now checks file encoding prior to loading a file. This issue has most recently been encountered with Add-on.xml files.
  2. The Ttools manual advises that flightplan, airport and aircraft text files can contain comments, both as whole lines and appended to data lines. AIFP ignored the latter (very infrequently used) and (incorrectly) treated such comments as part of the last element of data in a line. This development release properly handles such comments.
In light of the first issue above, I am considering another general release. If no significant issues are reported with this development release by the end of this week, I'll re-release it as 3.2.10.

Don
 

gadgets

Resource contributor
Since there have been no adverse comments for some time, I have just renamed Development Release 3.2.09(m) to General Release 3.2.10 and posted it.
It should be detected automatically the next time you run AIFP.
 

gadgets

Resource contributor
I have just posted Development Release 3.2.10(a) which corrects a couple of situations reported while I was away.

One of those reports highlighted a shortcoming with collecting add-on airports in PV4. While I have fixed the specific error reported, I still need to address add-on airports referenced in addon.xml files. I will do so ASAP and re-release. In the meantime. please give this development release a good workout.

Don
 

gadgets

Resource contributor
Since there have been no adverse comments for some time, I have just renamed Development Release 3.2.10(k) to General Release 3.2.11 and posted it.
It should be detected automatically the next time you run AIFP, or you can obtain it directly from http://stuff4fs.com.

Don
 

gadgets

Resource contributor
I have just posted General Release 3.2.12. It fixes a critical fault in the previous general release and in a development release.
It should be detected automatically the next time you run AIFP, or you can obtain it directly from http://stuff4fs.com.

Don

Reply
 

gadgets

Resource contributor
Development Release 3.2.12(a) uploaded to http://stuff4fs.com. It contains a new feature - Rationalization of Aircraft.cfg Parameters - requested by a user. The archive includes an updated user manual.

This is a very powerful function, initiated from near the bottom of the Main Panel Aircraft menu. It has the capability to rationalize any parameter in aircraft.cfg files. However, in inexperienced or careless hands it has the potential to corrupt one's entire "stable" of aircraft. So, I've placed a warning on the dialog itself and require confirmation prior to making any changes. I suggest backing up your Aircraft/Simobjects folder prior to using the new release - at least until its proven.

Don
 

gadgets

Resource contributor
AIFP can now load, manipulate, compile and decompile AIG's recently introduced multi-week flight-planning packages. They are handled just like other FPs. The only noticeable difference is that departure and arrival times are prefaced with a weeks indicator. For example "2/3/2130" indicates 21:30 on Wednesday of the third week. (For consistency with day numbers, the first week of a multi-week FP is Week 0.)

I have just uploaded Development Release 3.2.12(m) to http://stuff4fs,com. It "cleans-up a few "odds and ends" related to multi-week programming. Please give it a try - whether you are programming multi-week FPs or not - just to exercise the non-multi-week stuff so as to ensure there are no other adverse consequences of the changes I have made. Please report any issues, no matter how seemingly minor.

I plan to let this development release "soak" for a week or two to clear out any final issues, after which I will make a new general release.

Don
 

gadgets

Resource contributor
I have just posted a new General Release 3.2.13, which supports AIG's multi-week flightplans. The new release should be discovered automatically the next time you run AIFP. If not, you can download from http://stuff4fs.com.

Don
 

gadgets

Resource contributor
An issue has been discovered in the latest general release affecting the creation/editing of multi-week flightplans. Please download development release 3.2.13(a).

Don
 

gadgets

Resource contributor
I have just made General Release 3.2.15 to correct a critical error.

When creating or editing a flight plan in which the departure time was such that the local time day-of-week differed from the UTC day-of-week (morning in Australia, evening in the Americas), the departure day-number recorded for the leg may have been incorrect. The problem has been in existence since Release 3.2.13 in which I implemented multi-week FPs for AIG, but was only reported yesterday.

You may wish to review any FPs you have prepared in the interim.

One step forward, two steps back.

Don
 
Status
Not open for further replies.
Top