Enhancement proposal for creation of non-catalogue, freestyle figures, compliant with the Aresti-system

[Dirk07]

Hi all,

to bring everybody onto the same page, I've spent an afternoon or two to explain some things in quite some detail here, before my actual proposal is rolled out, so please do me the honor and read it carefully. Please let me know about any misconception or mistake, if I have made one and if any question remains.

User Demand and Historical Background

In recent years, I have received recurring questions on non-catalogue or freestyle-figures, like:

• How can I create a freestyle-figure in OpenAero?
• Will there be amendments to the currently available choice of non-catalogue figures in the figure-selection?
• Can you implement in OpenAero this set of funny figures, sketched on a paper, please? See also attached file for such examples, but please ignore the K-factors in there as they are not necessarily correct (haven't checked them) NonCatalogueFigures.pdf
• Where can I submit my freestyle figure for general use?
• Etc.

Some of these figures even included continous line-segments in a knife-edge attitude. Without further explanation I want to make clear that such knife-edge attitudes are explicitly not part or subject of this proposal, although worth another discussion.

The motivation for non-catalogue figures is surely as various and legit, as the aerobatic disciplines, contests and displays are various.
However, those, who have understood José Aresti´s SYSTEM down to the detail, will likely have concluded that at his time the Aresti-Catalogue was simply a means of choice and the best means for distribution - a handy outcome or dilevery of applying his system hundreds of times - each time for every base-figure - with the intension to simplify competitors' lifes, when proposing or selecting certain figures, compliant with the system, as this system ensured a systematic, reproducable and therefore fair calculation of K-factors, based on the figure's extent.

José Aresti has emphasized that his catalogue is not final, in fact will likely never be finalized and is hence subjected to continued enhancement or changes, as the system allows its application for many more combinations of loops and/or lines than what has been captured so far in the catalogue.

Current Situation

Indeed, every definition in OpenAero's figureXX.js-files works analog in a wide degree to the Aresti-System, although the base-figure-K is not automatically calculated (as foreseen by the Aresti-System) out of the figure-description, but calculated manually and assigned to it "hard-coded", which has been actively decided in order to let OpenAero be consistent with the catalogue and the sporting codes, which in return are not consistent with the Aresti-System for a few couple of base-figures. These few inconsistencies likely originate from copying or revision mistakes, typo's or similar that occured long back in the past.

A rather easy example for such a base-figure definition in these files is following code-line:

+_c^+ 8.5.6.1(10) ~~~''_c'''_'~~d~

It shows the assignment or bijective association of a certain base-figure's placeholder +_c^+ against its catalogue-number 8.5.6.1, K-factor (10) and another regular expression ~~~''_c'''_'~~d~, used by OpenAero as a 'drawing instruction'. Thus, the base-figure's placeholder, callable by the user via the sequence-string, poses a short-cut or abbreviation for the much longer drawing instruction, which it-self is not directly callable through the user's interface - SO FAR.

Syntax of the base-figure placeholder

+_c^+ is one particular out of further possible placeholders for a particular base-figure ("half-cuban eight") of a figure-family, here particularly:

• + starting in up-right attitude
• _ an even number of half-roll-elements is permissible on the first roll-element - here before the arc
• c the base-figure letter to be called by the user in the sequence-string to access this association for a half cuban eight
• ^ an odd number of half-roll-elements is permissible on the second roll-element - here after the arc
• + ending in up-right attitude

Generally, there may be further symbols used, to specify the permissible roles or spins:

• & any kind and extent of roll is allowed (i.e. quater rolls, n/8 rolls)
• $ any kind and extent of rolls or spins are allowed

Syntax of the drawing instruction

It is further crucial to understand that the drawing instruction does not have the same syntax as the base-figure's placeholder!
In particular the letters do have a different meaning. Here, the letters describe consequetively the changes in line direction throughout the figure always w.r.t. the current direction and attitude:

• d or D: 45°-arc, resp. 1/8-loop
• v or V: 90°-arc, resp. 2/8-loop
• z or Z: 135°-arc, resp. 3/8-loop
• m or M: 180°-arc, resp. 4/8-loop; can be ammended with / to create the arc with half of the normal radius (as used in humpty bumps)
• c or C: 225°-arc, resp. 5/8-loop
• p or P: 270°-arc, resp. 6/8-loop
• r or R: 315°-arc, resp. 7/8-loop
• o or O: 360°-arc, resp. full loop

Lower case letters are "pitch-up"- or positive arc changes - or pull-arcs. Upper case letters mean then the opposite direction - "pitch down" or push-arcs. This is evident from comparison with another code-line: -_c^- 8.5.6.2(14) ~~~''_C'''_'~~D~ is the same figure, but flown the "negative way" - with inverted entry and exit attitudes, it has now to use upper case letters in the drawing instruction, as the arcs have become push-arcs.

The symbols ~ and ' are used to extend lines (likewise in the sequence string, see OpenAero language). The symbol _ is here a placeholder for ANY roll-element, irrespective of even or odd permissible numbers of half-roll-elements. If that symbol is written immediately before or after a letter for a direction change, there will be no straight line segment in between that arc and the roll-symbol. The last crucial information on this code line is to understand that the number and order of roll-element symbols in the base-figure placeholder (_,^) must match the number of roll-element placeholders in the drawing instructions (_) as they are 'mapped' onto each other. If the numbers don't match or if they are not in the correct order, the base-figure is ill-defined.

For the previous example ~~~''_c'''_'~~d~ it means that from starting position (on horizontal line - by convention):

• ~~~'' the current line is extended by 3 plus 2/4 units, hence yielding a rather long horizontal line segment
• _ first roll-element placeholder (irrespective of even or odd permissible number of half-rolls)
• c the direction is changed by 225° by positive arc (pitch-up), hence a positive 5/8-loop into diagonal down line
• ''' extends the diagonal down line by 3/4 of a length unit
• _ second roll-element placeholder, again irrespective of even or odd - however, the mapping to the base-figure's placeholder ensures that just odd numbers will be permissible
• '~~ extends the line segment after the second roll-element placeholder by 2 plus 1/4 length units
• d the direction is changed 45° pitch-up (which indirectly mandates also the second roll-element to be of an odd permissible number, otherwise the now current position was on a vertical down line)
• ~ the line (before figure finish) is extended by 1 length unit

The figure ends then on horizontal line by convention.

Proposal

Since

• the possible combinations of non-catalogue base-figure compositions, using the Aresti-System, are already tremendously large if not infinite,
• accordingly a systematic catalogization, as attempted so far in the figureXX.js-files' section 0 - non-catalogue figures, is likely to be a never ending story,
• any attempt of providing a large set of such additional non-catalogue base-figures or figure-families thereof is also very time-consuming, demanding and likely not satisfactory to every user, and
• ever and ever again, new combinations are to be found and proposed by users, asking for implementation

it appears to me as a much better idea and way forward, if OpenAero withdraws from updating figureXX.js-files for the purpose of having the latest fancy freestyle figures implemented and, if instead OpenAero would enable the users to define their non-catalogue / freestyle-figures them-selves, by means of:

1. an appropriate user-interface enhancement - likely a new front end module with buttons and menu etc. to let the user input a drawing instruction in user-friendly way. Ideally, this front end receives a catchy name, as has been done with the "Free (Un)known Designer", i.e. "Base-Figure Magician", "Arestichemist" or "Fancy-Figure-Composer" - here I'm very open for further proposals ;)
2. an upgrade of the sequence-string interpretation routine that enables to process any drawing instruction embedded to the sequence-string (see below)
3. perhaps an accordingly updated sequence-checking routine
4. another dedicated amendment to the OpenAero manual

It is imperative that all required information to reproduce such a user-defined freestyle figure is embedded in or to be derived out of the sequence-string. The idea is to have a sequence string like the following to be understood as "half-roll split-s, humpty-bump, user-defined fancy figure with one half roll on first roll position and 4/4-roll on second roll position, hammerhead:

2a b 2user44{_user defined drawing instruction_} h

where 2user44 is the figure with 'user' as base-figure identifier that calls unlike other base-figure letters directly the drawing instruction in the parenthesis, provided after it. If 'user' causes problems, use another feasible descriptor instead. This definition does not contain the catalogue number, since it is irrelevant, and the K-Factor, since it could be automatically calculated.

Once, such a definition is successfully accomplished, any user and any contest director can save such figures to the queue or anywhere else, and operate them likewise to every other catalogue figure.

Thank you for your attention and best regards,
Dirk

[OpenAero]

Hi Dirk,

This is an excellent proposal. Like you, I have frequently received requests for non-Aresti figures.

First, I have made steps to implement such a system before this proposal. It's still in a very basic development phase which I will describe later.

I agree that for such a system to be widely useable, a user-friendly figure designer is essential. This is a big project that will take significant time and in which decisions will have to be made, such as:

• Can figures start/end in other attitudes than level flight?
• Will knife-edge be an option?
• Do we allow custom K factors?
• ...

Also, the current system does not calculate K factors, but I agree that automatic calculation according the Aresti rules would be best.

Now, for a description of the implementation as is currently available at https://openaero.net/devel.

• There is currently very little checking/error correction. It's easy to completely screw up a sequence drawing, possibly preventing your browser-based devel version of OpenAero from restarting correctly. "With great power comes great responsibility".
• To prevent lingering problems, it's best to test these features in an incognito browser window. In this way, when you close the window everything will be reset
• Figures can be built using the following format:

$catalogueNr(powerK:gliderK)drawing

catalogueNr (non-compulsory)
At least 3 numbers, separated by dots. Can not be an existing Aresti nr.
(powerK:gliderK) (non-compulsory)
When included, relevant K is shown and used in calculations. Can be formatted as (powerK), (:gliderK) or (powerK:gliderK).
drawing (compulsory)
Drawing code. Must start with + or - for upright or inverted entry. Further coding as in figures23.js, except for rolls. Rolls are included as (rolls), e.g. (1,2f) for a single roll position with full roll and half snap.

I'm not at all sure if this is the best way, or if I will change it radically in the future. Your feedback is very welcome!
There is no support for graphical editing (blue circles etc) or editing through the Figure Editor. Only sequence text editing. While editing, the sequence and figure will most likely go all over the place. This is the current "normal" behaviour.

Figures and sequences built this way in the devel version will not load correctly in the stable version of OpenAero. It may be some time before I consider this stable enough for full release.

So in general, the good news is that you can now make any figure in the devel version. Try the following sequence text:

"{6,3}Triangular" $0.1.1.1(:12)+~~~~z~()~v~()~z~~~~ (-25,19) "{5,3}Square" $(14)+~~~v~(1)~v~()~v~(1)~v~~~ (-20,17) "{7,3}Kobra" $+~d~(2)~v~(2)~d~

[Dirk07]

Hi Ringo,

thank you very much for your thorough response. I'm really happy to see us sharing similar thoughts, once more :) and I'm quite surprised for two reasons:

• I see that changes to the sequence-string interpretation in that scope are seemingly not a show-stopper
• Considering your example sequence-string, you have succesfully merged the drawing instruction syntax with the roll-element syntax to effectively a common syntax, designed for direct / rapid definition of freestyle figures, is this correct? - This appears quite brave to me, but also ultimately elegant. I was not sure, if that is feasible, but it looks like. I'd prefer it over my previous syntax proposal. Have run a few little checks with "{0,3} wedding rings" $+~o~o~ and it various ways of definition, like "{0,3} wedding rings" $+~o!(1)''(1)''o!(1)~ Have not discovered any problem with that syntax.

But before attempting to implement any substantial code changes that likely affect OpenAero's backbone, I think it's worth to do, what engineers should always do first: Let's agree on mandatory conventions, the scope of and the requirements to this change. Part of that will already address some of the questions. Here's my proposal. Add, correct or reject per your descretion:

Convention No 1

We generally destinguish beyond OpenAero:

1. Aresti-Catalogue-Figures (as already implemented by Families 1 through 9)
2. Aresti-System-Compliant, Non-Catalogue Figures i.e. the "Kobra" in your previous example or any other figure that:

• can be drawn, using the existent/merged drawing instructions syntax without further changes to them, as these instructions can be considered compliant with the Aresti-System (this excludes any knife-edges to my understanding; perhaps debatable), and
• allows automatic K-factor calculation i.a.w. the Aresti-System, and
• starts and ends in level flight by convention (up-right or inverted) - If particularly this criteria is not met, how would you "connect" one figure with the next (keep in mind that OpenAero already counts positive and negative entries and exits at different airspeeds for a reason, so is there more complication really required?)

3. Aresti-Non-Compliant Figures, not meeting any of the criteria under 2.

In order to refer more easily to them in subsequent discussions, we might want to use "primary", "secondary" and "tertiary" base-figures as better pronouncable equivalent terms. However, for rolling out this entire idea and its implementation, I think it is best way forward to concern solely the secondary base figures.

It is easy to imagine that the tertiary figures will cause a lot of extra-headache, should their implementation be attempted. Although I would really like to see some knife-edge-elements in OpenAero one day, I believe it is not time for them, yet. Consider just this example:

So, $+~d~(2)~z~~~v~ draws a tooth, using pull-arcs.
The drawing of a knife-edge tooth like $+~d~(4)~z~~~v~ must fail, as OpenAero only knows how to draw pull- or push-arcs, using lower and upper case letters, but not rudder-arcs, needed at z. So either, we invent them somehow with another syntax-upgrade, which is quite complex, I guess, or we indicate the rudder-arc by a hammerhead-symbol on the tip, which is perhaps more complicated, but not necessarily more elegant.
I feel, we should come back to this particular feature later. Smaller steps are faster and more rewarding than exhaustive giant leaps. And admittingly, implementing the knife-edge feature might not be as difficult as letting figures start and end in other than level attitudes.

Convention No 2

As mentioned in my initial post, here, Non-Catalogue Figures (secondary and tertiary base figures) are by convention not to be assigned to any kind of catalogue number, simply because it does not fulfill any purpose. Outcome of this change should be that any secondary base figure should be created through that new interface and operated, using the queue and the free (un)known designer, but not by the figure selection as all the other catalogue figures.

Any figure can be named and labelled already without a catalogue number, using particular letters or other arbitrary names. The only reason, why OpenAero has implemented the catalogue numbers for the primary base figures, is to allow rule-assignment/application, rule-checking and hard-coded-K-factor-checking - hence three objectives that do not apply to freestyle figures with automatically calculated K-factors. Beyond that I currently do not see any user-demand or contest scenario that asks or prescribes hard-coded K-factors on freestyle figures.

Convention No 3

I do not see any reason why still to hard-code the K-factors for freestyle-figures, which is prone to errors. Calculating it from the drawing instruction should definitely be the ultimate goal. I also cannot see any user demand for custom K-factors at the moment, do you?

---

Let me know, if you agree or where you disagree with these conventions.

I would be intrigued to see, how I can assist you in the implementation. What is your idea of the user interface so far? Do you imagine something totally new, like you did with the free (un)known-designer or do you perhaps rather think of amending or "recycling" the figure editor?

So far I just imagined that it needs:

• a dropdown menu for directional changes (pull- and push-arcs),
• a button to extend a straight line + plus a delete- or undo-button
• another dropdown menu for setting the permissible roll-element (even, odd, all rolls, all rolls and spins)
• special symbol buttons (tailslide, hammerhead etc., narrow arc, loop apex limits)
• maybe 2 cursor navigation buttons (?) - to go back and forth through the figures' line and arc segments

At a later step some further controls may ease the creation, i.e. an automatic inverse/reverse-the-figure-checkboxes.

Best regards,
Dirk