Acrobatics Task

[Lazaroth]

Do you mean if ( Skill >= 50 ) ?

[Epsilon]

Do you mean if ( Skill >= 50 ) ?

Ahh, yes. I'll make sure to fix that. <_<

I guess I tried to get too fancy. The original was basically "if (Skill < 50)" and then "else"

[Chris]

Someone on IRC has suggested an alternate way of making it work, but I'll be damned if I could figure it out.

That would likely be me.

The idea is that there's two separate "components" to the calculation: a linear term and an exponential term, which are multiplied together to give the final result. The exponential term reaches 1.0 at skill 50 and gets clamped as the skill continues to rise, leaving the linear term as the sole contributor from that point on (giving you a linear slope for skill>50 and an exponential-looking slope at skill<50). So essentially:

Code: Select all

result = linear_term * min(exponential_term, 1.0f);

You have the linear term by looking at the results for skill>=50. So to get the exponential term, you would do:

Code: Select all

exponential_term = result / linear_term;

The only questions this would leave you with is which GMSTs are used for which term. You could try playing around with them and seeing which affect the linear slope, and which only affect the exponential skill<50 slope (note that GMSTs that affect the linear slope would have some affect on the exponential slope too, since the two are multiplied).

[Tarius]

I have improved upon those equations. After some tinkering, I get this:

Code: Select all

If skill < 50(definitely less than, not equal to)
Velocity = 212.5 + 0.616*AcrobaticsBase + (0.06*Skill)^AcrobaticsMult 

Code: Select all

if skill  50+
Velocity = 212.5 + 0.616*AcrobaticsBase + 3.095^AcrobaticsMulti + AcrobaticsMulti*(1.88*s - 97.88)

This fixes that kink completely; so no odd loss of velocity at level 50. This also makes it so that there is no error greater than +/-5 units in all cases except when the AcrobaticsBase is low and the AcrobaticsMult is high; in which case starting at ~skill=23, it doesnt increase as rapidly as it should.(this of course means that the (0.06*Skill)^AcrobaticsMult term is too low, but even an increase like .0601 is too much for the normal and other cases) In the normal case where base=128 and mult=4, the max error is about 4 and on average is only ~2.

The above numbers are also nice and simple now and the equations look neater.

[Epsilon]

I have improved upon those equations. After some tinkering, I get this:

Code: Select all

If skill < 50(definitely less than, not equal to)
Velocity = 212.5 + 0.616*AcrobaticsBase + (0.06*Skill)^AcrobaticsMult 

Code: Select all

if skill  50+
Velocity = 212.5 + 0.616*AcrobaticsBase + 3.095^AcrobaticsMulti + AcrobaticsMulti*(1.88*s - 97.88)

This fixes that kink completely; so no odd loss of velocity at level 50. This also makes it so that there is no error greater than +/-5 units in all cases except when the AcrobaticsBase is low and the AcrobaticsMult is high; in which case starting at ~skill=23, it doesnt increase as rapidly as it should.(this of course means that the (0.06*Skill)^AcrobaticsMult term is too low, but even an increase like .0601 is too much for the normal and other cases) In the normal case where base=128 and mult=4, the max error is about 4 and on average is only ~2.

The above numbers are also nice and simple now and the equations look neater.

All in all, I'd rather lose about 5 velocity on that "kink" than end up with a 100+ velocity difference with a high multiplier. Your equations look neater, but there's still a "flat" spot on the curve and the error is significantly larger on the 1-100 data set with a high multiplier. 5 velocity is going to be .02 height difference. In fact, for the record...

Code: Select all

Velocity	Height Difference from Standard
1		     0.000797
5		     0.0199
10		    0.0797
20		    0.319
35.412	   1.000
50		    1.994
100		   7.974
200		  31.897

This is the reasoning behind the seemingly arbitrary "error goal" of 20 - a player isn't likely to miss a single unit of height, and 20 is a pretty attainable "absolute error" value. Missing 8 units (at 100 difference) is a bit more noticeable, and if the error gets as high as 200, they'll definitely notice it if they're comparing to standard.

If you want to plot it in Formulize, you can use this to eyeball it in the Report tab, "Plot Model Values from a Dataset" option:
Velocity = if(less(Skill, 50), 212.5 + 0.616*AcrobaticsBase + (0.06*Skill)^AcrobaticsMult, 212.5 + 0.616*AcrobaticsBase + 3.095^AcrobaticsMult + AcrobaticsMult*(1.88*Skill - 97.88))
(that's your equation in a form that Formulize can use)

Don't get me wrong - I'm glad other people are looking at it and trying to find ways to improve it. I'd just prefer suggestions that matched the error on all the data points at least as well as the one I posted.

[Tarius]

I already put the if less than formula and such into the program, thats how I compared my equation values to the originals.

As for the errors, I think it is much better to get closer to the original values than to try and fit things where the multiplier is increased by a large amount. I cant think of anything that actually changes the values that much anyway. Anyone changing them is likely not going for close to original anyway as they want something very different.
As for up near 200 skill, I know that there are just a couple mods that remove the 100 level cap. However, I think once you start getting up that high, differences become less noticable; it becomes more like you jump really high or you jump really high.

[Tarius]

Ok, I fixed that problem with the high multiplier. There is no kink and it is still accurate when the numbers get changed.

Code: Select all

v = if(less(s, 50), 212.5 + 0.616*b + (0.015*(3.785 + m/18.6)*s)^m, 212.5 + 0.616*b + 3.095^m + m*(1.88*s - 97.88))

V=veocity
B=AcrobaticsBase
M=AcrobaticsMulti
S=Skill

So I think this is probably the best one to use.

[Epsilon]

I already put the if less than formula and such into the program, thats how I compared my equation values to the originals.

As for the errors, I think it is much better to get closer to the original values than to try and fit things where the multiplier is increased by a large amount. I cant think of anything that actually changes the values that much anyway. Anyone changing them is likely not going for close to original anyway as they want something very different.
As for up near 200 skill, I know that there are just a couple mods that remove the 100 level cap. However, I think once you start getting up that high, differences become less noticable; it becomes more like you jump really high or you jump really high.

You also have to consider things like the Jump spell, and I'm not even sure -which- GMST that changes, if any. That said, I agree with you - no sense in worrying about a couple of units of height above 100. "Jump high" or "Jump really high" indeed. xD

I'm digging around to see if I've got some of my non-smooth data points still kicking around to toss into the table. That'll let us make sure the formulas are consistent rather than Formulize just managing to match the points we have (which is a worry when you start getting into longer equations.)

Your new formula is quite a bit closer than the one I posted though, by about 5 velocity. Thanks!

[ElderTroll]

Good job guys!

[Tarius]

You also have to consider things like the Jump spell, and I'm not even sure -which- GMST that changes, if any. That said, I agree with you - no sense in worrying about a couple of units of height above 100. "Jump high" or "Jump really high" indeed. xD

I'm digging around to see if I've got some of my non-smooth data points still kicking around to toss into the table. That'll let us make sure the formulas are consistent rather than Formulize just managing to match the points we have (which is a worry when you start getting into longer equations.)

Your new formula is quite a bit closer than the one I posted though, by about 5 velocity. Thanks!

Ah yes, the Jump spell, I didnt think of that one.
Interesting thought, I dont think NPCs ever jump; or if they do, its only for companions and the only companions I have used get the same spell you do. The point being though that t would be safe to change GMSTs like this without it effecting the NPCs.

As for matching data points, I tweaked things by hand, I didnt let it run through the program. When its that close and you know about what effects what, it isnt that hard to manually change things.

Anyway, I think it will be off to more data taking. If the Jump spell does indeed change a GMST, it shouldnt be hard to figure out which one as long as it still goes by this equation.