Enhancement proposal for creation of non-catalogue, freestyle figures, compliant with the Aresti-system about main HOT 2 OPEN

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~

from main.

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

from main.