Analysing and modifying the AFX file with QBasic.

[aleatorylamp]

Hello folks,
This would be the continuation of a subject recently started on the "Conspicuous by their Absence" Thread.

Ivan had commented on some small and extremely practical utilities he had written in "C" and using batch files, with which he could make some dreary and long AF99 operations very easy and fast. For example, re-scaling the whole aircraft or moving it to an improved position.

These small programmes involve very simple mathematical actions on aircraft elements present in a given directory, and I was immediately inspired to try and produce similar programmes using QBasic.

I know QBasic is one of the most outdated programming languages, considered by most as only good for Kids, but not even that, because why show them something useless when there´s more modern stuff like "C" and "C++" around...

Well, OK, granted, but I haven´t learnt anything else, and QBasic is the only thing I can understand and use to any effect.

It does have tremendous power to manipulate strings and files though, except perhaps for extracting file names from directories, which I haven´t found the way to do yet. Maybe it isn´t possible.

As a result, I can´t write small QBasic programs that act on all part files stored in one directory, to re-scale or re-position them one after the other, in one go.

However, it could be done acting on the whole AFX. All the vertices are present - they aren´t in the AFA, AFC or AFS files - only the AFP Aircraft Part files show vertices, and so does the AFX.

So at the moment, I have got as far as identifying all the lines containing information on vertices present in all the parts corresponding to everything in the AF99 aircraft. ...all except the templates for structures, which is a different matter.

I have also been able to isolate the three x,y,z coordinates for each vector. Now I have to turn them into real numbers, apply some maths to the needed ones, turn them back into text and re-insert them into the string to re-build a new AFX.

The problem with Structures is that they have a different Syntax, so the name of the type of bulkhead template between the first two inverted commas type will serve as identifiers. Maybe I´ll use the firs three letters of the bulkhead names, as the shortest is "Vee". Then, there are only two coordinates for the templates, so I still have to study which is what.

They must also be processed. As the AFX, when unpacked, actually generates all parts, I doubt that un-processed bulkhead vertices will work properly with processed Structure part vertices!

Then there is a mysterious short line with a confusing "", syntax, which however does not correspond to a vertice. It may be the reference number of the Family that the component or Structure is grouped into, as the numbers do not depend on the position and repeat themselves in other models as well.
There are 8 possible numbers: 83, 84 (left-right?), 10 (low wing facing down?), 12 (mid wing facing up?), 26 (canopy?) and 13, 17 (both aft?) and 36 (body?). Ah dunno yet completely, but probably it won´t matter and won´t need processing.

Anyway, here´s a screenshot of my progress so far. The different colours show the vertex numbers. The only ones missing are the Template Structures that have only two coordinates.

Cheers,
Aleatorylamp

[aleatorylamp]

Hello All,
After managing to identify and isolate the structure templates, came the task of actually modifying certain parameters, and leaving others intact.

To start off, I chose to lengthen a model by a very small amount, and after several different AF99 unpacking errors, creation of garbage structures and components, and other errors caused by missing commas or superfluous inverted commas, or excessive zeroes where there should be nothing, it worked!! My test-model is now a couple of inches longer.

Here is a sample screenshot of a part of the listing that can be can generated so as to check what is going on during the process. The culprits were the short lines (labelled by me as "Short", for me to monitor) that have a certain value, one of 12 possible numbers I believe, and which is repeated in other models, and must not be processed.

My deduction is that is depends on the family group of a mainly a component or structure, and its orientation. However, there are also other short lines that can be upto 2 positions longer, and they can´t be processed either.

Now, the next part is to either rip out the wheels before processing, because they shouldn´t be stretched. Alternatively, they could be identified and be ignored (which would be more artfull) by the stretching process, to be shifted manually from within AF99 perhaps.

Following that, texture mapping can also be identified and corrected to fit the stretching...

P.S. From the second screenshot one can see that the "victim" is the original AiraCobra AFX by Eric Johnson. It was useful to use that as a reference point for my experiments, as Ivan had also done some research with effective "C" programs to facilitate quick adjustments on the entire model, that would otherwise take ages to perform manually with AF99.

Interestingly enough, no offsets of any kind needed processing - neither the CoG offset, which this model has, nor e.g. the Wheels, that are originally built at the origin (0,0,0) and shifted into position on the Assembly blueprint.

As regards the first screenshot, the coloured lines at the end of each line is the modified output of the modified lines. The original lines are the white ones on the left, and do not include the first two numbers - those are reference character codes of certain positions that are of assistance to check the parsing. Once proven correct, they could of course be deleted, as I did for the Structure Template identification to make space.

Update: Greater precision with 2 decimals.
At first I thought it wouldn´t handle 2 decimals in the vertex coordinates, as the model only has upto 1 decimal after the point, but then I remembered a comment in a recent post on the Conspicuous thread about AF99 handling upto 0.01 ft precision, and it worked fine, so here´s an update of the results screen section screenshot, substituting the old one.

Cheers,
Aleatorylamp

[aleatorylamp]

Hello all,
I just missed something: Wheels and Propdisc haven´t budged! - because...
La-dee-dah!, they were built at origin, 0,0,0. Oh, what fun! They were offset.

I was completely wrong about " no offsets of any kind needed processing etc..."
...famous last words before blundering.

Now I´ll have to make the programme identify them for moving slightly,
...or apply the maths to the offset points. Let´s see...
...or put in the parts into their proper position with AF99 let´s see if they´ll allow
themselves to be moved, because often they slip back) before running them
through the modifier.

Ideally a program like this should detect null-point-built elements and
intelligently place them, but that´s a bit difficult to program.
Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

I don't happen to know what scaling factor you are using but there is a reason why I chose some really large (2X and 3X) scaling factors for experimentation.
With small scaling factors, something can still be wrong and you will never see it.
As an example, you only saw the Wheels and Prop Disk.

This screenshot that I originally attached back at Post 1493 in the "Conspicuous by Their Absence" thread will give you an idea of what else is a bit mis-located that you are not seeing at the moment.

As we have discussed offline, it does not work to actually move the AF99 Part because often a single Part will appear in multiple pieces and MOVING the Part will move them all which may cause effects that are very hard to work with.
Our goals may have been different, but mine was to create a program which does as much of the alteration in an automated fashion as possible without any major detail work on the pieces.
I actually did not quite do that.
The StretchIt program worked on Parts.
Components are thus affected without any need for separate consideration.
Structures, however, were not addressed at all.
I found it simpler to re-build the Structures individually because on this project, I had intended to alter the Bulkheads (cross-sections) of most of them anyway.
A Triangular Cannon Barrel just does not look right when there are so many resources left over.

I am glad you figured out that the single decimal place in the original model could not be retained with the kind of editing we are doing. The ability to put together a fairly good looking model with such low precision is why I believe Eric Johnson did a really great job here. There are places he could have done much better, but many of the improvements we are doing here are possible because the tools are better.

- Ivan.

[aleatorylamp]

Hello Ivan,
I tried the same component but transparent, but the AA alpha transparency 179 option was invisible, except without hardware accelleration, and the AF99 transparent option was solid.
There must be something amiss, but for the moment the only thing that´s working is the
Structure with AA-179.

I´m glad you like the provisional adaptation of the 12-sided spinner to the 8-sided fuselage.
I noticed it required some +0.03 ft hand-work on the right (the parts aren´t mirrored),
and with the canopy too. Not that it´s noticeable on the model in the sim, though!

As far as I know, the only way to simulate armament weight in FS98 is by defining a separate fuel tank, and emptying it as required from the fuel menu. Having a user-defined location, this would affect flight behaviour.
Fuel tank locations are in record 1003, and their capacities, in Record 302, and the Weight of the extra tank (this one is the Centre one) would be deducted from the Dry Weight.
Here is a screenshot of the mouse-run fuel menu - My FS98 is a German one.

It´s annoying that AA is incapable of remembering a number of things, including everything after a global shift caused by a re-positioning of the Centre of Rotation in AF99, a global MoveIt process, or an equally global AFX Modifier Move operation.
I suppose the best idea is to leave AA operations few and far between until you have achieved the correct null point position.

AA forgetfulness is I think it´s a matter of age: When it came out, Siri or Cortana hadn´t been born yet. I´m sure they would have shown AA the cool things, like a mother cat shows its kittens. Maybe Icould be shown something by these two, to retard neuron deterioration.

That would make millions nowadays: Get an AI upgrade for the brain! They have sensors on limb-stumps to naturally control artificial extremities, so a brain upgrade is next on the list, I suppose. Or control FS by telepathy...

That´s good news on your "new" hardware. The K6-II is a sturdy and reasonably fast machine, and seems to do nicely. Fine!

Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

Interesting approach to weights and balances with extra Fuel in FS98.
I had thought that Fuel was "Kraftstoff". That is how I am used to seeing it in the manuals.

You need better numbers for your Mitte Tank.
I am not really prepared to do the calculation at the moment.
I was about to do a similar calculation for refining my own DP files but just had not gotten there with all the computer hardware events.

I believe you are being very unfair to Aircraft Animator.
It recognizes pieces of the aeroplane by their vertex locations. If you alter any of the vertices, you have a different piece.
That is pretty fair.

How is it to figure out that we have altered EVERY vertex in the MDL but that they are the SAME?
Are they really the same?
The axis of rotation is very dependent on the vertices of the animated piece of the aeroplane.
For the CoG change, I shifted the entire aeroplane about 4-5 inches vertically.
That means the Landing Gear is also shifted 4-5 inches from its axis of rotation and would look pretty stupid rotating about the old axis.

By the way, I suspect that 0.03 feet offset is a side effect of the Truncation of numbers I was describing earlier.
I will check my own copy of the P-39D to see if mine shows the same issues.

- Ivan.

[aleatorylamp]

Hello folks,
In order to produce a more or less usable .air file for the moment,
for the P-39D-D2 Airacobra and its 1325 Hp Allison V1710-63 engine,
there is some interesting information in the 2 performance documents
I have found, i.e. the Allison Operations and Maintenance Manual .pdf
and the site with test results and links I posted before. The following
would appear to be appear quite useful:

5-minute powers, 3000 RPM:
--------------------------
Take-off: 1325 Hp, 51.0 "Hg MP, done at 104 mph.
WEP S.L.: 1550 Hp, 60.0 "Hg MP, giving 306 mph.
Standard Emergency: 1450 Hp, 55.0 "Hg MP.

15-minute powers, 3000 RPM:
---------------------------
Military Power at S.L.: 1050 hp, 44.2 "Hg MP.)
Military Power 12000 ft: 1150 Hp, 44.2 "Hg MP, giving 362 mph.
(Another source states 42.0 2Hg MP.

Normal rated Power:
-------------------
at S.L. : 910 Hp, 2600 RPM, 37.8 "Hg MP.
(Another source states 880 Hp, but no MP).

10800 ft: 1000 Hp, 2600 RPM, 37.2 "Hg MP.

Critical altitude is 11200, or 12000 ft (also named military
rated altitute), depending on the source.

Landing speeds 89 mph, with flaps and gear down.

There are several cruise powers mentioned, but I´ll see to that
later on, once the basis for the .air file is established.

My thoughts as to the distribution of powers, i.e. normal
throttle lever travel and WEP (type 2 methanol-water), would
be to include the 15 minute powers in normal power, and have
the 5 minute powers as F10-WEP.

The problem here would be that 1550 Hp WEP is rather more than the
1325 Full take-off power. Were this to be included in WEP, then we´d
all take off with 1550 Hp, which doesn´t sound reasonable. But, how
to prevent prolongued use of 1325 take-off Hp would be the question.

A different matter is how accurately I´ll be able to put allo this into
the .air file, but it will be fun to try.

Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

I am somewhat curious as to where you got the designation P-39D-D2.
Other than your posts, I have never seen this designation.
I believe that with the V-1710-63 engine that you specified, you are really referring to the P-39D-2-BE.

If this is true, then I believe you need to recalculate the Center of Gravity.
My calculations were based on an aeroplane (P-39Q-1) equipped with a 37 mm cannon.
The 20 mm Hispano that was standard on the P-39D-2 would have been quite a bit lighter and changed the balance of the aeroplane.
That 20 mm Hispano cannon was also the reason I did not choose to build the D-2 version even though it met the requirements in other respects. The 20 mm cannon was not well thought of by US forces operating the P-39.
The P-39K is basically the same as the P-39D-2 but with a 37 mm gun which is why I thought it would be a good follow-on build after the P-39D/F was done.

If you graph the data you have collected about engine power and settings, you will probably find that it will be contradictory in certain areas.
To actually build something, you will need to sort through the data to have some consistent values. I had to do the same with the V-1710-35 but there were some choices about who and what to believe.

You also need to be careful about anecdotal data. Your "20 MPH Faster" quote from the post you deleted is a good example of such a comment that I find to be not very plausible.

The table of data that you have linked is pretty good. It is actually the same place where I am finding data on other models of the P-39.
The problem as usual is that some of this data contradicts other data that I have, one has to choose what to believe.
There is also no data on the exact model that I am attempting to build.

I have actually been messing around with the EJ P-39D. Last night I finished reworking the Flaps so that they are no longer "Slotted Flaps".
I have been doing my best not to alter the shapes even though I know that they are incorrect. Proper shapes would have made things easier. My objective is to do a general cleanup and corrections without altering the general shapes and appearance of the original model.
This model uses "Retracted Flaps". I generally use "Deployed Flaps".
Both have their advantages and limitations, but I believe my standard method of Deployed Flaps is better overall if Aircraft Animator is used.
Aircraft Animator also does not remember Deployed Flaps from one execution to the next.
The problem is that the tool is so simple to use that it omits some very useful features.

I also reworked the Main Landing Gear Wells so that they would no longer disappear from certain angles.

I was also tempted to build a Transparent Canopy as well in order to test the required Assembly sequence for when I build the actual Project.
It looks to be pretty easy because of all the resources that are still remaining.

- Ivan.

[Ivan]

Hello Aleatorylamp,

You are totally correct in saying that the information isn´t terribly hard to find.
Actually, I had already seen all you posted on your Airacobra thread. That was
the reason behind my comment there:
"You have certainly put together a good summary of the different models."

Perhaps it should be "Mostly Correct".
There were two pieces of data that I had to estimate based on fragmentary evidence:
The .30 Caliber ammunition load of the P-39C and
The .50 Caliber ammunition load of he P-39Q.
I wasn't building either version yet, so it wasn't crucial that I get the numbers entirely correct but if you were actually able to find a good reference for these, I would be interested to know where. I am thinking the P-39Q information should be fairly easy to find if I look hard enough but the data for P-39C would probably be a bit harder.

I just finished the first pass at Engine Power and Level Speed tuning for the P-39D/F model.
Speed at Sea Level (500 feet)
309 MPH - Actual but this number was probably corrected to Sea Level
310 MPH - Model

12,000 feet
368 MPH - Actual
368 MPH - Model

Some sources put the altitude a bit higher for maximum speed.
Now it is time to tune some of the other bugs out of the AIR file.

- Ivan.

[aleatorylamp]

Hello Ivan,
Thank you for your post, and the reasoning explained therein. Obviously your project is of a different nature, and requires a completely different approach, which I understand, involving considerably more detailed research to start off with.

I am just trying to achieve a reasonably usable .air file without so much complication. There is a lot of information available to be sifted through, as you say, and a lot of it is contradictory, especially in important areas like CA and MP. Hence my experimentation with different values here, and my comments on the thread. As it is, I´ve progressed a little further, and it´s looking better.

I hadn´t expected that commenting on these factors would be so complicated, and that it would be difficult or impossible to deal with in a simpler fashion, and I don´t want to interfere with your project, which is going along rather different lines.

I have almost all the answers to list of questions you posted, but I´m sure it will involve a lot of time and effort on your part to go through, and it will definitely interfere with your project, so I prefer not to do this.

It would mean hijaking too much of your time for something that is not so important.
I don´t even know yet if the result of the model upgrade will be good enough to upload.

Thank you very much anyway!
Cheers,
Aleatorylamp

[aleatorylamp]

Hello Ivan,
OK, thanks!
With the small fuselage-length correction, I suppose the numbers of other discrepancies are too small. I was using the same 1.0191 multiplier as you had done that excluded the nose-cannon from the specified length of the plane. The screenshots have the grid on to show the difference, although it is not calibrated.

Incidentally, I didn´t process any of the offsets. I haven´t posted a screenshot of the model yet because the textures aren mapped correctly yet.

Parts created at the null point won´t react to ANY scaling and stay put, and one can only really act on them through the offsets, or on the AF99 model itself.

Here, the problem is that the parts not only have to be placed correctly, but have to be shifted back, and it sometimes doesn´t really work as expected, now I realize that it´s for the reasons that you have just explained, so it´s better to delete the old ones from the list of the original model and put in new ones. Then, the AFX modifier will work fine - I hope! I´m just doing that now, and I´l take advantage of the situation and put in some 12-sided wheels.

The screenshot looks like the plane has taken some severe hits - flak maybe... Things are disjointed and missing - the wheels have been shot off and are already distant!

Anyway, I agree with your comments on the original E.J. AFX - it´s quite nice to work on!

Cheers,
Aleatorylamp

[aleatorylamp]

Hello Ivan,
I was just being facetious, like a brainless ignoramus, bragging... Actually, I had a hard enough time making AFX Modifier produce something recognizable by AF99, let alone remember something previous, that I quite envy the makers of Aircraft Animator, especially as regards the graphic interface.

Imagine SCASM: You block out a certain routine between the label and the double dummy jump below, click on "G", and get a selection of Top, Side, Front and 3D view-pictures with coordinates as per the mouse pointer.

No other possibility for FS98. Fuel = Bombs, bullets and shells, without the fireworks. I remember a guy with the alias FSAviator helping out with FS2002 versions of the Riesenflugzeug and the Grossflugzeug, and he suggested this principle. If you had a 500 Kg bomb or a 1000 kg one, you´d gain quite a lot of altitude as soon as you let go of one of those!

"Kraftstoff" would be Power Stuff, whereas "Treibstoff" would be Drive Stuff or Impulse Stuff, and are the same. For the sake of illustration, I took the first aircraft I had in the FS98 aircraft list, added a Mitte-Tank with 50 Gallons, just to illustrate it, and did nothing else but a screenshot of the fuel menu.

50 USG - 300 pounds worth of cannon, bullets and belly bombs is just about exactly wrong... but I just put in a different number to make it stand out from the normal Tanks. I expect that a convenient l/r fuel tank selector gauge that doesn´t include a Mitte-Tank, or Mitteltank, would ensure that your ammo and bombload won´t get used for fuel and increase your range...

Why a 0.03 ft truncation only on the right? The mind boggles anyway...

Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

My German is pretty poor at this point and I never did study any technical German.
I just try to read aircraft manuals to find the things I need to get something done and that is typically what I have been seeing.

I just did a quick check on my version of the EJ P-39D and found a similar but lesser problem: only 0.01 feet off from Left to Right at the Nose where the Spinner joins.
That sounds pretty fair. You have a Truncation problem in your program. I had a Rounding problem.

Let's step back for a moment and remember where we started.
The EJ P-39D is an old FS 5 Aeroplane.
When we started, EVERY dimension was to a precision of 0.10 feet.
We INCREASED the size of the Parts of this aeroplane.
If there were any variations between Left and Right, the MINIMUM difference would be 0.10 feet which would be very noticeable.
If there were variations that large, a magnification would have only increased the differences and we are not seeing that.
Thus we can state with great confidence that the variations did not exist before we messed around with the model.

I know now that there was a rounding problem with my StretchIt program.
I corrected this when I encountered the same thing with test executions of the StretchTexture program.
By that time, I had already used StretchIt on all the Parts and did not think to go back and check.
Luckily, the Parts and AFA are not that dependent on each other. (!)

Seems like losing the Animations is not the biggest problem with this little non-project.

- Ivan.

[aleatorylamp]

Hello Ivan,
First things first! Here are 2 links to the Allison "E"-type Engine Operations and Maintenance handbook, all 26.9 Mb of it! It takes quite a while to download, but it is something I´m sure you will enjoy. The second seems faster:

http://tradecoastcentralheritagepark...dbook_1944.pdf

http://www.avialogs.com/index.php/en...allations.html

I misinterpreted the -D2 nomenclature from somewhere, where they said the -D version had -D1, -D2, -D3 and -D4 subtypes, and mistakenly added the "D" as well, instead of only the number.

I corrected the fin/rudder and the canopy last night.
The fin was placed 0.33 ft too high and the lower part had to be extended another 0.22 ft.
The canopy, although the top and base-line seem OK, had the front and back 0.2 ft too low. These corrections will make the nose and aft fuselage slant correctly.
Then, the spinner is too small, and be about 0.28 ft fatter.
The worst is the "slim" belly - it has to go down another 0.8 ft. I still have to check the width.

These will be the reference points for the fuselage correction.
First I´ll do with the 8 sides it has, and then skillfully insert an extra 4...

I still have to do the flaps on my version. Personally I prefer putting in retracted flaps tagged with Speed below 195, because of AA missing things with deployed ones, as you said too.
Updated comment: With flaps built as retracted, I only need to delete the 4 deployed-flap parts, untag the old retracted flap parts, leaving them as normal wing parts, and repeat the undersurface of the retracted flap, tagging it with Speed Below 195.

Well, it´s coming along. Here´s a blueprint screenshot, showing the cabin and fin shape changes (which don´t fit the old fuselage properly!), as well as the centre of rotation.
The CoG is set a little aft of what I had before, but perhaps not enough. Would think it is still too far forwards? Perhaps the best place to correct the still-needing-attention CoG would be with the 2 places that offer offsets in the .air file.

Regarding the .air file, I´m not sure what to do:
I wonder if it would be better to eliminate the 1550 Hp max. 60 "Hg WEP, keeping it as the 1450 Hp standard 55 "Hg WEP. This would, however, include Take-Off power, which should really only be 1325 Hp with 51 "Hg.
I wonder if you would like to suggest something...

Well, it´s slowly progressing... It´s actually a lot of fun too!

Updated comment:
I´ve just changed the new screenshot - again! It now shows the bright-orange (thickened to be more visibile) outline of the planned, improved, more pot-bellied fuselage, but not as much as I had it a while ago! The air intake also has been moved upwards by 0.1 ft, and the spinner is fatter now too. Of course, as always, I value your views and/or opinions should you like to comment.
I´ve also checked the main landing gear. It seems to have the correct position, which is a relief.

Cheers,
Aleatorylamp

[aleatorylamp]

Hello Ivan,
I understand that previous tests in your case would slowly be superseded by new data you are uncovering, and I now also remember the initial test results you posted.

The different Boost Gain values I am testing, give me different critical altitudes and maximum speed points (for military power) on the graph, that I am comparing to the shapes of the P-39 performance graphs shown at the bottom of the Air Coprs War Department performance test page.

For the moment, I´ve done 3 tests, and from what you are posting, I gather that you
may be interested generally in the results I am getting. If not, just ignore these figures!

Boost Gain at 2.3 and MP at 0.42 Hg for military power.
309 mph at S.L. and 361 at 12500 ft. (peak just above 11000 ft).

Boost Gain at 2.36 and MP at 0.44.2 Hg for military power.
315 mph at S.L. and 367 at 12500 ft. (peak at around 12500 ft

Boost Gain at 2.47 and MP at 0.44.2 Hg for military power.
315 mph at S.L. and 372 at 12500 ft. (peak at 13000 ft).

What is turning out to be very practical and satisfactory, is that Boost Gain increases give consistent and proportioinal power increases as altitude increases, and do not require other adjustments.

I have conveniently set Emergency Power Press Change Rate to Zero, and this prevents any manifold pressure value distortions when altering max. and WEP manifold pressure parameters.

What I´m also seeing, is that my performance at greater altitudes is on the low side, and in the middle area of the graph above and below CA, it tends to be a little greater.

If I remember correctly, this is normal for CFS1. In the case of the P-39, it will not be worrying, because this aircraft was not really designed for altitude performance anyway, so simmers will probably use it for mid- and lowaltitude dog-fighting and ground attack.

At the moment I´m using the .air file of the P51d, using the correct specifications as far as power, weights, dimensions and fuel for the P-39-D2 and the engine specs of the Allison V-1710-63 (including its gear-ratio to the propeller) are concerned, as well as the Dp files with the different rounds for the 20 mm motor cannon in the nose, the two 0.50 ca. nose guns, and the four 0.30 cal. wing-guns: 60 rounds for the cannon, 400 for each nose-gun, and 1000 for each wing gun.

The propeller is for the moment that of the P51d, but I also want to see how the propeller from your BV-141 compares. I´m not using the one from the P47d because it seems too big, but possibly the Spitfire one would also be good to test.

So this is as far as I´ve got, and it is more or less going as I had been expecting.
Cheers,
Aleatorylamp

[aleatorylamp]

Hello Ivan, Hello all!
It´s done! It´s doing what was aiming for, namely adjusting the model´s dimensions to apply
overall corrections after having started building. This will save a lot of work and time.

As I never build with offsets, I don´t have to include corrections for shifted parts, and I do texture mapping from within AF99, so that won´t need to go into the program either.

Here´s a partial screenshot showing the old vertex coordinates in white, and the modified ones in yellow, and red for a structure template.

Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

I am glad you accomplished what you had set out to do.
I don't believe this kind of tool would have ever been useful for any of my own projects.
When I screw things up, I screw them up MUCH worse than a uniform 2% scaling factor which is why I had not done a program like this until I began to examine this P-39D AFX.

- Ivan.

[aleatorylamp]

Hello Ivan,
So it´s my fault again - I should have guessed. I can imagine my physicist daughter criticising me for not having had a scientific, empiric approach to check the original AFX for this discrepancy, not just checking my AFX Modifier modified one!

Then I would have got curious as to why the AFX Modifier only increased the left, and not the right... and I might have caught on. But you are/were getting a 0.01 difference too.

So the quest (non-quest) continues... It´s still interesting though, this non-interesting stuff...
Who said hobbies weren´t fun?

Update: Confirmed: The Original AFX has no r/l differences at all.
So why does the bug only appear with mirrored parts - do negative numbers bug ? I´ll do a page-by-page run with my Modifier and watch the input/output results.

Update 2: Result: Right! Negative numbers process with +0.01 ft.
Maybe it´s some logically illogical mathematical rule that rounding always goes in the positive direction - but truncating too? Or maybe it´s just computer illogical logic.
Now I have to find out how to stop this.

BTW: I wouldn´t worry about the German... Too many nouns for the same thing.
Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

As I mentioned in my prior post, I already corrected this problem in StretchIt when I found it in the StretchTexture program.
I just had not gone back to check, but fixing the model isn't that hard. Tedious, but not difficult.

I have a great advantage over you in this area because this kind of thing is typically covered in a general Computer Science education, but perhaps not in a general programming class.
....I suppose I should CONFIRM that my fix actually worked before making the arrogant assumption that it did.

- Ivan.

[aleatorylamp]

Hello Folks,
A lengthy part of the job, but not difficult: The fuselage, still 8-sided, to make dimensioning of all the parts in the three components easier, is now more pot-bellied.
I still have to adapt the wing roots to the new fuselage belly, which may be a bit more difficult,
and position the forward landing-gear parts accordingly. You can see in the blueprint that they are still not done yet.
Here´s 2 screenshots. The look is a bit more realistic.
I still have to get the texture mapping a bit better overall.
Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

I had to do a couple more revisions to the flight model I was working on.
I had originally planned to do the P-39K with the V-1710-63 engine and had left a couple parameters unchanged when I switched to the P-39F.
About three hours of editing and testing and now the numbers for mine are:
314 MPH @ 500 feet and
368 MPH @ 12,500 feet.

I am a bit surprised you had such a simple time with doing the Flaps.
Mine was much more involved and took the better part of a day to finally get working the way I wanted.
First I tried the method you described, but could not get rid of the bleeds of the Wing Roots from outboard.

Thanks for the link to the V-1710 E series manual. I am not sure if I already have a copy of the one for the E series but I know I have the equivalent for the F series engines. The folks naming the PDFs don't make it obvious from the name of the file, so I can't tell without going through a bunch of files. Be very careful when using this for reference material though.
This manual is from 1944 and everything is fine if you are building a P-39Q but the earlier models may not have had the same engine power ratings and limitations. Production quality improved as time went on AND fuel quality improved so that often the same nominal model of engine would be making more power in 1944 than 1942.
My subject is the Airacobra from 1942 when it was an important fighter aircraft of the US Army.

Whose drawings are you using for your corrections? It isn't clear where you are getting the reference numbers for your changes.

Be careful about references you find. It seems there is a LOT of incorrect information even from people who should know better.
I have seen one "source" with access to an actual P-39 that didn't know that the 4 guns IN the wings were actually .30 caliber instead of .50 caliber. I have an actual printed book on my shelf that has lots of cool pictures but the assertions and conclusions in the written text are simply incorrect. I have a report that was written about the Allison engines that has aircraft performance curves that I know are incorrect because there are actual flight tests that contradict them.....

Gotta Run.
- Ivan.

[aleatorylamp]

Hello Ivan,
Mini-tools like yours would have been obviously been easier to use, but I can´t make them for reasons I´ve explained. The only thing I can accomplish is to act on the AFX file with QBasic, which incidentally, I thought was pretty interesting, albeit rather peculiar.

What I will also do with it (and describe it on this thread), once it comes to the point, is generate a separate AFX for the fin, scale that with my program, unpack it and put the pieces on the P39D - test-baby conveyor belt. It is the way I can use my AFX Modifier to act only on selected areas of the plane, so it will be useful for that too! ...at least for me...

Now, because I don´t like leaving pets stranded, abandoned on a country road, I won´t abandon my results on my modified E.J. AFX. They will continue serving me, and I will make good use of the test model, just for some practise as I explained when you so kindly sent me the AFX, thanks to which my Apprentice Department is having a great time!

I observe that the wheel and exhaust textures share half of the same texture-bitmap each, and re-scaling has (naturally) made rather a mess of the mapping. AF99 will do a good job of re-mapping textures except for the wheels and exhaust ones, that will have to be entered manually.

I can see the numbers on the original texture-spread, so maybe that will serve as a guide for me to understand how that has to go, once I elongate the nose-gear by 0.50 ft, thanks to info as per your investigations on the other thread! Also, I´ll clean up the bits and pieces on all gear struts.

Then, I shall proceed with a 179 alpha transparency canopy structure (speed below 179 for AA), to see if anything worth commenting upon happens, put in an inhabitant and do a nice glue-sequence for the cockpit.

And, to finish, there is a planned conversion of the octogonal cross-sectioned fuselage components to be dodecagonical, (taking advantage of the situation to make the belly a bit more pot-bellied), and give the tail-plane an airfoil section. Then, if nothing else crops up, at the end, my apprentices will be able to fly about in their own updated Airacobra, and practise their engineering skills on the engine too!

It will probably continue being fun!
Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

Mini-tools like yours would have been obviously been easier to use, but I can´t make them for reasons I´ve explained. The only thing I can accomplish is to act on the AFX file with QBasic, which incidentally, I thought was pretty interesting, albeit rather peculiar.

I never really did understand the logic of not being able to work with a simple process but preferring to deal with a much more complicated process. It just does not make any sense.

What I will also do with it (and describe it on this thread), once it comes to the point, is generate a separate AFX for the fin, scale that with my program, unpack it and put the pieces on the P39D - test-baby conveyor belt. It is the way I can use my AFX Modifier to act only on selected areas of the plane, so it will be useful for that too! ...at least for me...

Your description of packing just the Fin into a new AFX file in order to do some fairly simple processing seems like a rather convoluted way of accomplishing a very simple task.

This proposal actually brings up a LOT of other questions:
1. Where did you get the idea that the Fin is out of scale in relation to the rest of the 3D Model?
2. Which way are you planning on stretching / scaling the Fin Parts?
3. WHY are you bothering to do anything at all with the existing Fin Parts when they also have the Diamond cross section instead of a proper Airfoil shape?
If you are going to do some heavy editing to those pieces, why not just build them from scratch. It would be quicker and simpler.

Then, I shall proceed with a 179 alpha transparency canopy structure (speed below 179 for AA), to see if anything worth commenting upon happens, put in an inhabitant and do a nice glue-sequence for the cockpit.

And, to finish, there is a planned conversion of the octogonal cross-sectioned fuselage components to be dodecagonical, (taking advantage of the situation to make the belly a bit more pot-bellied), and give the tail-plane an airfoil section. Then, if nothing else crops up, at the end, my apprentices will be able to fly about in their own updated Airacobra, and practise their engineering skills on the engine too!

it seems to me that you are going about this in the wrong order.
When you start looking at how to put in a Transparent Canopy, Cockpit and other cool things you will see how the current divisions of the Fuselage won't work well with that idea.
It makes a lot more sense if you are going to spend the time to build a 12 sided Fuselage to do that first and plan for the Cockpit and Transparent Canopy ahead of time.
You will avoid a lot of problems that way.
You will also find out what is really wrong with that Aeroplane's Tail; It really isn't a scaling issue.

I chose not to go there because I saw that when allowing for the precision possible with Aircraft Factory 99, just about EVERYTHING in this model had a shape problem so it didn't make sense to do more than just correct the most obvious problems that were the most benefit at the least cost in time.
I had to go further than I wanted because as I pulled on one string, others would unravel and I could not leave the patient bleeding from other areas even if I had not been working there.

- Ivan.

[aleatorylamp]

Hello Ivan,
I suppose one could hardly expect a beginner´s COBOL class in 1978 to include positive and negative rounding off in a Personnel Database exercise during the first half of the first year.

A Payroll Spreadsheet program that would include percentages, overtime, penalty hours´ reductions, and bank transfers, included it, but was for 2nd year students. Our computer teacher was the Oil refinery´s Univac 9030 programmer, who made a bit on the side at the school. I bet he rounded off upwards to the nearest 10 whole numbers!

I´ll put in another "IF" clause to cover negative numbers then,
or I might have my own idea for an efficient Smart Fix!
More later!
Cheers,
Aleatorylamp

[Ivan]

Hello Aleatorylamp,

With COBOL, I believe there is a good chance you would really be working with Binary Coded Decimal and not floating point numbers. There is much less ambiguity there.

My suggestion (pretty obvious one) is to do an exhaustive test of the multiplication section WITH THE DATA THAT IS CAUSING PROBLEMS.
You already know for sure that the Left - Right offsets at the base of the Spinner cause problems.

I will re-run my StretchIt program on the Parts when I get a computer operational again.

- Ivan.