Analysing and modifying the AFX file with QBasic.

Hello Aleatorylamp,

How well did the 12 sided Spinner blend in with the 8 sided Nose?
Even the original didn't blend in all that well and they were both 8 sided.

There are just small bleeds at the Nose.
There are some major bleeds at the Wing Roots when seen from outboard and
There are plenty of bleeds on the underside especially on the Landing Gear Wells.

Regarding Stability and Center of Lift:
I actually have noticed the instability but haven't really gone very far yet in tuning the AIR file other than trying to get the weights more or less located properly. Even those are still subject to revision, so *I* don't have any useful conclusions yet.

Regarding Center of Gravity:
I don't think I told you what you think I stated.
I told that the CoG of the 3D Model was pretty close Longitudinally and should be at around 9 inches below the Thrust Line. vertically as opposed to a bit over 13 inches as it is now. That would be a slight shifting of the CoG FORWARD which I believe can be ignored FOR NOW, and CoG shift UPWARD.

Regarding Parsing and Interpreting Data:
My principle has always been to retain the formatting of the original when possible unless it is OBVIOUSLY incorrect.
In the case of AF99, I can tell you that often the AFP files leave out numbers when they can be assumed to be Zero.
The problem is that this isn't the natural way that the programming languages display numbers.
That is why I have a special (!) routine called "Normalise" which takes a number and puts it into what I understand the AF99 format to be.
The Serious Test is to use your program to process the data on one execution and then reverse the parameters to "un process" the data on a separate execution.
The resulting file should be identical to the file you started with.
If it isn't, you have a problem.
This actually works better with the Move programs than the Stretch programs because with multiplication, there are rounding errors.
Think about it: If we use a multiplier of 1.0191 as I did for my stretch of the EJ P-39D, there are going to be LOTS of places where that does not work out to an exact 0.01 feet increment.
There won't be any actual Tolerance Stacking because all the offsets are absolutes from the Origin, but any particular point may stretch to one particular increment and the un-do may not take it back to the exact same place it was before.

Another check is to make sure that any piece that starts off as symmetrical ends up just as symmetrical.
I wasn't getting that on my first couple versions of the program which is what I was describing as "stability issues".
The difference wasn't easily visible and didn't happen frequently, but I knew it was there.

- Ivan.
 
Hello Aleatorylamp,

I don't believe you understood my original post which I will quote here:

Ivan Ivanovich said:
These are with current data and subject to change as I refine calculations.
The Stretched Model actually ended up VERY near correct for Longitudinal Center of Gravity as compared to my estimates.
If I were you, I would leave that number alone for now.
The VERTICAL Center of Gravity is quite a bit off though.
It should be around 8-9 inches (I think I used 9 inches) below the Thrust Line.
I believe the current MDL has it at about 13 inches which won't totally ruin things either, but it help to get things closer to get the Landing Gear positions correct.

The Main Gear should be +- 68 inches Left - Right according to Paul Matt's drawing and according to the manuals.
The contact point should be 18 inches aft of the CoG.
Click to expand...


You can of course do whatever you want, but if you are trying to follow my suggestion, I believe you actually did the opposite.

- Ivan.
 
Hello Ivan,
Oh Dear! I got all the numbers mixed up, especially when the Move Option started failing...
The numbers that are in now, were not intended.
What was intended is what you have now re-confirmed, ...Sorry, and thanks!
Nevertheless, the mess will actually be very easy to fix because the AFX Modifier is working
very well, so it will only take a couple of seconds - unless of course it doesn´t...

Thanks also for your longer post and your helpful indications, warnings and failsafe measures!

There is a kind of Normalization option in QBasic that puts zeroes in, so that the format is always ##.## ,##.##, ##.## after the initial "",
of a vertice line. This also has rounding off effect. I was trying it before, so maybe that will help.
I had discarded it when I saw that the AF99 AFX didn´t have all the zeroes, and thought that putting them in would interfere with the parsing, but if the zeroes disappear anyway, it will probably not matter. I´ll see.

Also, at the moment, there is no rounding off without the ##.##, so with 0.009, a 0.01 should be added, and it isn´t - I noticed the slight variations! Without rounding off it is worse than with.

Done: OK, the CoG is 9 inches below the centreline, and I´ve left the fore/aft as it was just now as it is more or less where it was before. The actual position numbers in AF99 are different now because the null point is now at the centre of rotation, so there´s no CoR offset anymore, but the fore/aft CoR measurement is the same - or should be!

Cheers,
Aleatorylamp
 
Last edited:
Hello Aleatorylamp,

The "Normalization" I was describing for AF99 is a bit different. They actually use some really strange number formats if I remember correctly. What you are describing is pretty standard.

The "Rounding Error" problem I was describing would be fairly small and very much like running a printed picture through a scanner and then printing it again repeatedly. Gradually the errors accumulate, especially if the multiplication factor has a few decimal places.

The actual problem you are running into is a Truncation Error via using the formatted PRINT in BASIC.
It is a much worse error.
It is worth your time to fix this, especially if you intend to run the Stretch program multiple times on a project.
It is actually pretty easy to do.

You should not run into this problem with the Move program.
That is probably the best place to test if your program damages the AFX file.
Do your test by moving the AFX around by several offset triples so that the last one takes it back to the original location and then compare the AFX to the original.
There should be no differences at all.

What does the revised aeroplane look like?
Do post a screenshot.

- Ivan.
 
Hello Ivan,
Thanks very much for your interest and support. I´m finding it very useful indeed!

One of the steps to fit the numbers to the second decimal place, which really only truncates them, is muliplying their value by 100, and dividing its integer value by 100. Eventually it ends up getting worse if you do it to the same file several times - that´s why I only do it once, keeping the original file if I have to re-apply anything. It´s not really too inaccurate if you only do it once.

As the different trials to get the position right moved all the textures, and I hadn´t re-mapped them yet, I was only posting blueprint screenshots. Aircraft screenshots looked terrible!

The up/down setting for the null point is now at 8.89 inches, and the Forward position is actually very accurate too - between 31 and 32% from the leading edge. The Wheels are at 68 inches sideways in the .air file, and in the model, the inboard wheel-edge is at just under 66 inches, and the outboard edge at 72, so it´s quite OK, I suppose.

I was also fitting the 12-sided spinner to the noce with some triangles, and it came out quite well. As soon as everything is presentable I´ll post a screen shot. I´m almost done in that aspect, and the "nose job" is almost finished except for the nose-gear yoke, which has to be changed a bit to prevent the deforming bleeds.

More later... have to feed the cats (they´re like a clock...)

Update: OK, here are six pictures, taken from the best no-bleed angles.
A short second phase of the "Nose Job" would involve the nose-gear door and propeller bleeds, which aren´t apparent on the pictures though.

What´s done for the moment, looks quite good. It may also not be too annoying to make the fuselage a little rounder and pot-bellied too, while I´m at it...

Bell´s design of the Airacobra is admittedly motivating enough in itself, as are your comments and indications!

I´m also following your progress with your "new" hardware on the other thread, so as soon as that is functional enough, I can post something more tangible if you were to be interested.

Cheers,
Aleatorylamp
 
Last edited:
A quick canopy transparency test

Hello again,
The Airacobra AFX have a separate canopy component in Canopy High Wing, but it doesn´t react well to any AF99 or AA transparency.

Simply by tracing the side and top of the canopy component, the templates were made for an identically shaped top-only structure, to be tagged for AA Alpha Teansparency 179. Then, the 7 "floorboards" were added in Body Main, declared as Insignia Top, and the result came out very clean, and very quickly, with no glue as yet, but it needs a little at the front and back as there are some bleeds. Here´s a screenshot for now!

Now for the canopy spars or frame - which will take a little more precision work.
As yet, the fuselage hasn´t been modified.

Cheers,
Aleatorylamp
 
Hello Aleatorylamp,

I had also noticed the separate Component for the EJ P-39D Canopy, but didn't think it could be done well enough without bleeds. Not only that, but the Canopy in that AFX isn't really shaped correctly either.
I don't see how you can get a proper shape with so little control over the cross sections that are forced upon you by the available options for Sructure bulkheads.

Why not do it as a Component? There are certainly plenty of resources left.

I may have to use your idea for the 12 sided Spinner. It certainly does improve the look.
The other changes look pretty good too.

Today I got enough of my replacement Development Computer running so that I could actually run a production through Aircraft Factory 99 and through Aircraft Animator. I thought I would do a quick edit with a manually set Center of Rotation but the result was that all my Aircraft Animator moving parts were lost.
I backed out the changes after seeing this.

I was wondering:
The armament load in the real Airacobra affected flying characteristics.
Most of this can be simulated in Combat Flight Simulator.
How would you simulate this in Flight Simulator 98 where there isn't the varying armament load?

- Ivan.
 
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
 
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.
 
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
 
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.
 
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? :biggrin-new:

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.
rolleyes.png


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.
ipepsi2.gif


BTW: I wouldn´t worry about the German... Too many nouns for the same thing.
Cheers,
Aleatorylamp
 
Last edited:
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.
 
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
 
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.
 
Hello Ivan,
I have finally discovered that the problem has to do with negative numbers in general, at least in the case of QBasic, and is not the origin of the Bankers´ Conspiracy to justify Money Lending.

I was using the INT function to get 2 decimal places from a double precision number. This was causing a problem, because it doesn´t only truncate.
Life is full of treacherous traps.

"INT returns the largest integer less than or equal to a numeric expression."
as told by QBasic Help. So, as they say, he who announces his intention, is not a traitor.

Increasing the digit in a negative number makes it less than what it was before. The mind starts bending here, but of course, -2 plus -2 is -4. It´s smaller...

INT(12.54) 'Output is: 12
INT(-12.54) 'Output is: -13

INT(-(5.001) * 100) / 100: ' output: 5.01 <<<< OH ?? Yes!
INT(-(5.3111) * 100) / 100: ' output: 5.32 <<<< OH ?? Yes!

INT(5.001): ' output: 5
INT(-5.001): ' output: -6 <<<< WHOA!!!! ARGHHHH! You´re dead!

But now I´ve just discovered a more useful one, even if not perfect:

FIX truncates a floating-point expression to its integer portion.

FIX(12.49) 'Output is: 12
FIX(12.54) 'Output is: 12
FIX(-(5.001) * 100) / 100: ' output is: 5 <<<< Fine.
FIX(-(5.8891) * 100) / 100: ' output is: 5.88 <<<< Well, OK...

Even if FIX won´t round off anything and just truncates, at least it
won´t warp the model on the right, so that´s what I´ll use.

Cheers,
Aleatorylamp​


"Why make it simple if you can als
​
 
Let d6 = int (rnd (0) * 6) + 1

Hello Aleatorylamp,

Your code snippets actually bring back some memories from long, long ago, but not far, far away.

The subject line above was the typical way we would program a 6-sided die.

I was actually hoping you would see how close you actually were to taking care of the entire mess with truncation but it seems like you are satisfied with it. *I* would not be. It isn't at all hard to fix.

Try This:

LET Result2D = INT (FloatVar * 100 + 0.5) / 100

My BASIC syntax may be a little rusty, but I think you can get the general idea.
(Yes, I know "LET" isn't really necessary, but makes it very recognizable as BASIC.)

I was doing something pretty similar in C with type conversions taking the place of the FIX function that you have available.
That direction is a bit more cumbersome because there needs to be a conditional to check if the Floating Point value is Negative or not.
Perhaps there is a quicker and simpler way to do this in C, but this was the first thing I tried and it worked, so I didn't bother looking any more.

- Ivan.
 
Hello Ivan,
I actually liked the "LET" thing in Basic, because it gives a tremendous sense of power. You can let anything be whatever you want!

MY$ = "1000000" is by no means as satisfying as: LET MY$ = "1000000" !!

Wow, I was looking for something that would automatically do it, and not have to subtract 0.01 with an IF for all negatives, but I wouldn´t have thought of your fascinating code snippet.
It appears that for negative values, the +0.5 takes care of preventing it from getting too small.
I´ll try it out and think about why it works!
Thanks a lot!
Cheers,
Aleatorylamp
 
Hello Aleatorylamp,

If I were you, I would go for a bit more than $1,000,000.
After all, when you can control the outcome that well, why not make things comfortable for your self?
I personally would go for about $100,000,000.
That would give me a bit more freedom that just 1 million would not.

LET me know if that code fragment works for you.
I just finished up a little test this afternoon. After I got the pieces installed in my computer (minus the cover), I tested it by deleting all the Parts and then extracting the original AFX to replace the Parts.
Then, I edited the spreadsheet with all the File Names that I had used last time to add the StretchIt command and also add the Parameters.
When I ran the script, it ran fine on everything except for the last 4 Parts on the list.
All 4 Parts caused StretchIt to fail with an illegal access attempt.
It turned out that these 4 Parts did not exist.
Apparently they were the result of my edits to create Wing Guns many years ago.

When I figured this out, I copied all the hand modified Parts that were done after the first Stretch execution a couple weeks ago and also restored all the AFC and AFS files as well.
It compiled with no problem and now the Bulkhead at the Spinner is a perfect octagon to match the Spinner.
My edited StretchIt program is using q pretty similar formula to what is in the code snippet, so let me know how it works for you.

I did a small edit of the Center of Rotation in AF99 while I was doing everything else. I have not checked to see how things line up.

Now I get to re-do the animation but first I need to set up the computer in a new location after I clear some desk space.
More on details in the other thread.

- Ivan.
 
Hello Ivan,
Ha ha!
I´m afraid I haven´t had a chance to try anything since my last post, because
a) I killed Windows 10 for being a predator on my dual-O.S. set-up and put in Windows 7 again, and
b) A friend brought some expectedly dead hardware innards, which miraculously revived to a stable state after a memory and CPU-Fan exchange. It´s one of the last single-core AMD computers - not bad. The interesting thing is that there are Win98, WinXP and Win7 drivers for it on the Internet.

Now I have to give my daughter a German conversation class, and then do some chores in the house. I expect to get some time off tonight for some experimenting with the Stretching and Moving options on the AFX modifier, and will report accordingly!
Cheers,
Aleatorylamp
 
You must log in or register to reply here.
Back
Top