So, I have decided to remove my answer to sneze2r's post and to systematize all information about my propositions to include for hills profiles. In my opinion, hillmakers should have much more freedom in preparing desirable hill profiles than currently. How it should look? First of all, let's start with inrun.
- Generating startgates spacing. Currently it is based on 'step' parameter which can be measured horizontally. My idea is to combine two parameters: es and number of startgates. The equation used for that could be es/max (max - number of startgates) and everything would be generated in inrun line.
- Generating r1 parameter. First of all, I would like to ask: what kind of curve is used to generate this parameter? The change of curve type is dependent on what answer to this question I will get. If it is cubic equation, then there is nothing to change in that case; if other, then it should be changed into cubic. Also, on a few hills certificates we can see that r1 parameter has two values - the reason is that at beginning of curve is different radius than at the end of it. Example is Vikersundbakken, where r1 has at its beginning 142 meters radius, and at the end 100 meters radius. In that case, two methods could be used alternately, so using - it is my proposal to name that parameters - r1a and r1b would work normally when just r1 is not defined.
Now there are my ideas for landing zone.
- P-point used alternately with l1. Currently l1 is not generated too accurately (mostly it is related with h and n parameters, so I am going to suggest using just P parameter to define concretely a length, where blue sheets start and where landing zone arrives to moment defined with beta-p.
- Bigger priority for rL in situation, when hillmaker don't want to define beta-L. It could be used alternately as well. Sometimes beta-L parameter is not measured correctly, so prioritize rL parameter would be a nice variety.
- Adding r2L parameter as an optional. It should work like that: if r2L is not defined, it won't cause not loading the hill by the game - then r2 will generate as an one curve (defining potential r2L=r2). Currently r2L is required in newest hills since 2008, when JUMP-08 standards became announced by FIS.
- Another option which could diversify creating more realistic lower dhill curvers: defining a length where U-point is situated. In that case, there won't be any need to use r2L, r2, r2x and r2y.
- Options to choose curve type. Currently I know that the r2 and r2x with r2y are generated as a cubic parabola, and FIS requires in hill projecting standards to use quadratic parabel. So I would like to suggest some types of curves as a parameter 'curve' connected with r2L, r2 and with U-point location: 'quadratic', 'cubic', 'clothoid', 'circular', etc. It should be connected with U-point position, if r2L, r2, r2x and r2y are used, the curve equation should be changed from cubic to quadratic, according to FIS standards.
- Beta-U also as an optional parameter. When it is not defined, it should be automatically generated as a 0 degrees. If it is defined, my proposition is to define it in values 0≤x≤10 (what is your suggestion about maximal available beta-U?). After U-point, it should go smoothly into 0 degrees depending on 'ar' parameter.
Some ideas for me look like easy to implement, some difficult, but it doesn't matter. As I write at the beginning, hillmakers in my opinion should have much more freedom with generating hill profiles, so chances with creating realistic profile could be much bigger than nowadays.