1 Attachment(s)
Analysing and modifying the AFX file with QBasic.
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
2 Attachment(s)
Further progress... itīs working!
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
Future plans for the test bed.
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
Mysteries return... but get solved too
Hello Ivan,
OK on the flaps, and I noticed the spinner thing, thanks!
I didnīt change the shape either, other than splitting it for the prop component and the glue. The fuselage would need re-shaping first, and I probably wonīt do that after all, because of the worms that come out in this work. The "workms"!
So, I finished re-vamping the nose with only a new 12-sided spinner, props with better shapes and uniform lengths and positions, and the lengthened nose-gear.
This, as a preliminary face-lift, with a nice prop-blur included! Classified as a nose-job!!
I wasnīt too worried about the small bleeds - yet - because I was more interested in the CoG shift to the newer position (thanks very much for your suggested new CoG position!): A bit further back and a bit further down - fine to do with AF99, but I wanted to get the whole model to sit on that new place with its null point!
Sounds coherent, what you say: The centre of rotation being where the CoG is, and the centre of lift, infront a bit (offset in the .air file), would then cause the inherent instability that this aircraft had in certain circumstances.
So, I deleted the AF99 CoG offset 3.5,-1.1,0 to make it 0,0,0, with the intention of correcting the re-vamped P-39D with my AFX Modifier Move Option.
But... Oh, Woe! NOTHING except the spinner templates (the vertical one didnīt even exist because I used "Longitudinal Symmetry") were visible in the new, unpacked Model!! And this with no error messages of any kind!
Backtracking, it turned out it was not the CoG shift itaself that was creating the problem, but something in the "nose-job", combined with it, because both the original AFX, and the stretched AFX, do allow Moving the aircraft to center its null point on the new CoG position.
Update: I discovered is was a new short line that should only be like "",-2.41 right at the beginning of the AFX listing that mistakenly had extra commas and parameters, so it has to be parsed the same as other short lines like "",83 , which are identified but must go into the newly generated AFX unchanged. Allowing three more characters in the cropping of these short lines cured the new problem.
So, the re-positioning works, and so does the "nose job", which is a relief!
However, all this wonīt eliminate further worms. After a face lift that probably will not involve a new fuselage any longer, or anything else thatīs difficult, I think my Iīll finish my re-working exercise - itīs only for practise anyway, and the resulting aircraft will have served its purpose - and also look a bit better!
Extra Update:
OK! So here are two screenshots with the 0,0,0, at the centre of rotation.
Itīs now 18 in. below the centreline (prop axel), and I was trying for about 30% from the leading edge, but I think I fell short and itīs only 27 or something, and will probably have to to go a bit further back. The question is whether this concept is correct, to have the null point on the Centre of Rotation.
Then, I still have to re-map all the textures, as it has all changes, of course, but that should be no problem: Easy skiving with AF99-automatization!
I gave up on sharing one bitmap with different areas for wheel-doors, exhaust and wheels, because I was going crazy, and my psychiatrist is on an extended holiday because he is deranged completely himself, so now thereīs an own bitmap for each of those.
Cheers,
Aleatorylamp