I have decided to help with finding the Acrobatics formulae, so this thread will hold my findings. The first step is to collect enough data points and then we can see how to figure out the equations. I hope I can get out some useful information tomorrow.
Acrobatics: According to the manual and the UESP, Acrobatics influences the jump distance, the jump height, avoiding (or just reducing?) the damage when falling from great heights and how steep the slopes can be for you to climb.
Testing setup: German English retail version of Morrowind with Tribunal & Bloodmoon with latest patch, running on an early 2009 14" iMac. I'm using Wine 1.4.1 and no mods other than the unofficial patch, Better Heads and Master Index (official mod from Bethesda) will be used. Run Like the Wine and Tireless Running will only be used to get to a place, but not for testing.
Methodology: The first step is to figure out what is not relevant to each equation. I will set all skills and attributes to 50 and then crank one all the way up and then down at time and see if something changes. If nothing changes then that skill/attribute is irrelevant.
The next step is collecting data points. I will change the relevant attributes in increments of 5, giving us 20 data points.
Useful console commands:
Getpos [x, y, or z]
Set_____ [Value]
a command do manually set the position would be really useful for figuring out how far I can fall
Jump Height
Methodology: I will find a space somewhere in the wilderness, write don the player's Y-position, jump and get the player's Y-coordinate at the apex. Since I don't have a proper way of recognizing the apex I'll do it by intuition. I will make several measurements and always pick the highest value to minimize errors.
relevant attributes/skills
Acrobatics, Encumberance, Fatigue
collected data points
Jump Distance
Methodology:
relevant attributes/skills
collected data points
Fall Height
Methodology:
relevant attributes/skills
collected data points
Slope Steepness
Methodology:
relevant attributes/skills
collected data points
Acrobatics Task
Acrobatics Task
Last edited by HiPhish on 07 Jul 2012, 23:35, edited 1 time in total.
Re: Acrobatics Task
I've got a list of results I've gotten here:
https://docs.google.com/spreadsheet/ccc ... 1QXc#gid=0
Edit: Took this spreadsheet down, for any new readers. Somehow, I managed to screw things up with something I had loaded. Nothing major, but all my values were off by roughly 5-6 across the board. Enough of a pain that I figured it's probably better to start from scratch now that I know what I'm looking for anyway.
The problem is that none of it looks linear. A suggestion made by modred1 in IRC was that the jump height was incidental, and the jump formula describes initial upward velocity. I'm going to do a few more tests in there to see if this takes me anywhere.
As for the script in my testing room, it basically calculates the jumping height for me, along with a few other things. I'm currently working on a new version of the testing room which will store the maximum values achieved - since luck doesn't appear to affect acrobatics, it's only the maximums we should be worried about.
We'll need to look at the GMSTs as well, and how they affect things. This means all of them in the top part of that spreadsheet. I can coordinate with you on getting the assorted test suites created and sent/posted. We'll want a couple of sets of data points below each default, and a couple of sets of data points above each default so we can interpolate the effect the variable is having on the jumping.
I'm going to be reformatting and redoing a lot of the stuff in the spreadsheet. Since I'll be able to take the maximum (both velocity and height) of multiple jumps with my new scripts, I can make the spreadsheet far less "busy." Once I've got that done, coordinate with me and I'll give you permissions for it on Google Docs.
Once I get the new testing room done (which should be an hour or three, depending on how my mind holds up,) I'll post it up here and instruct you on how to use it - you get a fair decent bit of good information from it, and it's a hell of a lot easier than trying to console the getpos stuff -just- at the height of your jump.
Is there anything you can think of that needs to be added to the scripts for calculations? Anything you think we should do differently?
P.S. Posted this in the other thread, but catch me on IRC.
https://docs.google.com/spreadsheet/ccc ... 1QXc#gid=0
Edit: Took this spreadsheet down, for any new readers. Somehow, I managed to screw things up with something I had loaded. Nothing major, but all my values were off by roughly 5-6 across the board. Enough of a pain that I figured it's probably better to start from scratch now that I know what I'm looking for anyway.
The problem is that none of it looks linear. A suggestion made by modred1 in IRC was that the jump height was incidental, and the jump formula describes initial upward velocity. I'm going to do a few more tests in there to see if this takes me anywhere.
As for the script in my testing room, it basically calculates the jumping height for me, along with a few other things. I'm currently working on a new version of the testing room which will store the maximum values achieved - since luck doesn't appear to affect acrobatics, it's only the maximums we should be worried about.
We'll need to look at the GMSTs as well, and how they affect things. This means all of them in the top part of that spreadsheet. I can coordinate with you on getting the assorted test suites created and sent/posted. We'll want a couple of sets of data points below each default, and a couple of sets of data points above each default so we can interpolate the effect the variable is having on the jumping.
I'm going to be reformatting and redoing a lot of the stuff in the spreadsheet. Since I'll be able to take the maximum (both velocity and height) of multiple jumps with my new scripts, I can make the spreadsheet far less "busy." Once I've got that done, coordinate with me and I'll give you permissions for it on Google Docs.
Once I get the new testing room done (which should be an hour or three, depending on how my mind holds up,) I'll post it up here and instruct you on how to use it - you get a fair decent bit of good information from it, and it's a hell of a lot easier than trying to console the getpos stuff -just- at the height of your jump.
Is there anything you can think of that needs to be added to the scripts for calculations? Anything you think we should do differently?
P.S. Posted this in the other thread, but catch me on IRC.
Last edited by Epsilon on 08 Jul 2012, 05:34, edited 1 time in total.
Re: Acrobatics Task
A double post sadly, but hey, at least I've got content.
First up is the .esp file, which is attached: . It's got everything needed to test jump heights and velocities (assuming the latter matters.) The block just behind the entry point (coc "Jumping Test Cell") is called "Scripted Block of Z-Position" - this is the heart of the test area. Any time you jump in this cell, it'll tell you the peak height you reached (which wobbles a bit because of things beyond my control) and the average velocity (distance/time) of the jump. The gate is just there so I could have a doormarker - otherwise, you'd end up in the blocks when you COCed in.
If you activate the block, it'll show you the highest jump in the cell since you last cleared the data. "OK" leaves it, "Clear Data" does what it says on the box. For testing, I'd suggest at least 10 jumps, if not 20. The more jumps you do, the more likely you are to hit that "maximum," although most of the jumps will be close to each other if you're not running out of fatigue.
Speaking of fatigue, the cell endeavors to keep your fatigue at 300. This is used for testing the effect of fatigue on jumping - just set your fatigue to a level that matches the % of fatigue. Good numbers are in the spreadsheet.
Second is the spreadsheet that's got a good range of test conditions on it:
https://docs.google.com/spreadsheet/ccc ... 3BKb1c0TFE
We won't need to test every single thing - especially if you suspect something doesn't have an effect, try a couple of jumps at 20 skill and a couple of jumps at 100 skill. If they end up being the same as the baseline "all GMSTs Normal" line, black it out as not needed.
I'll get all the necessary .esp files (with proper GMSTs) uploaded eventually. After testing each one, you'll probably want to start a new game just to make sure they don't stick when changing the .esp. Fortunately, MW loads quickly with just the base stuff and chargen isn't -too- bad although I'm sure you'll get sick of the guards.
HiPhish: PM me with your gmail address (or, y'know, IRC ;p), and I'll get you added to be able to edit the spreadsheet tomorrow.
First up is the .esp file, which is attached: . It's got everything needed to test jump heights and velocities (assuming the latter matters.) The block just behind the entry point (coc "Jumping Test Cell") is called "Scripted Block of Z-Position" - this is the heart of the test area. Any time you jump in this cell, it'll tell you the peak height you reached (which wobbles a bit because of things beyond my control) and the average velocity (distance/time) of the jump. The gate is just there so I could have a doormarker - otherwise, you'd end up in the blocks when you COCed in.
If you activate the block, it'll show you the highest jump in the cell since you last cleared the data. "OK" leaves it, "Clear Data" does what it says on the box. For testing, I'd suggest at least 10 jumps, if not 20. The more jumps you do, the more likely you are to hit that "maximum," although most of the jumps will be close to each other if you're not running out of fatigue.
Speaking of fatigue, the cell endeavors to keep your fatigue at 300. This is used for testing the effect of fatigue on jumping - just set your fatigue to a level that matches the % of fatigue. Good numbers are in the spreadsheet.
Second is the spreadsheet that's got a good range of test conditions on it:
https://docs.google.com/spreadsheet/ccc ... 3BKb1c0TFE
We won't need to test every single thing - especially if you suspect something doesn't have an effect, try a couple of jumps at 20 skill and a couple of jumps at 100 skill. If they end up being the same as the baseline "all GMSTs Normal" line, black it out as not needed.
I'll get all the necessary .esp files (with proper GMSTs) uploaded eventually. After testing each one, you'll probably want to start a new game just to make sure they don't stick when changing the .esp. Fortunately, MW loads quickly with just the base stuff and chargen isn't -too- bad although I'm sure you'll get sick of the guards.
HiPhish: PM me with your gmail address (or, y'know, IRC ;p), and I'll get you added to be able to edit the spreadsheet tomorrow.
Re: Acrobatics Task Update
I've been playing with the mathematical model, and god - it's definitely not a simple linear formula. If it was, I'd probably be done already.
Adding to the problem is that Morrowind's starting velocity for a jump is ever so slightly randomized. Not by a whole lot, and I suspect it's more an error in the game engine than a specific setting, but a series of tests and calculations show that the error does exist.
On the bright side of things, my twiddling and testing have confirmed that the value for gravitational acceleration is, in fact, 627 units/second^2. I've used Morrowind's internal velocity measurements to confirm this to a pretty high degree - certainly enough to convince me.
I'm currently working on 200 data points (with averages) from skill 1-200 on the standard game GMSTs. This should be done within a couple of days, since I'm doing anywhere from 50-100 tests to make sure error averages out.
Attached is an archive that has the AcrobaticsBase GMST set to 0 and the AcrobaticsMult GMST set to 1. Each data point should have at least 100 measurements taken of it if the measured velocity is below 250 or so - this makes sure that any error is averaged out as much as possible. Above that, it's still best to take at least 50 measurements. The built-in script takes the averages for you and tells you how many jumps you've made. Make sure to zero the counter ("Clear Data" button) after changing your skill level to the next one.
Adding to the problem is that Morrowind's starting velocity for a jump is ever so slightly randomized. Not by a whole lot, and I suspect it's more an error in the game engine than a specific setting, but a series of tests and calculations show that the error does exist.
On the bright side of things, my twiddling and testing have confirmed that the value for gravitational acceleration is, in fact, 627 units/second^2. I've used Morrowind's internal velocity measurements to confirm this to a pretty high degree - certainly enough to convince me.
I'm currently working on 200 data points (with averages) from skill 1-200 on the standard game GMSTs. This should be done within a couple of days, since I'm doing anywhere from 50-100 tests to make sure error averages out.
Attached is an archive that has the AcrobaticsBase GMST set to 0 and the AcrobaticsMult GMST set to 1. Each data point should have at least 100 measurements taken of it if the measured velocity is below 250 or so - this makes sure that any error is averaged out as much as possible. Above that, it's still best to take at least 50 measurements. The built-in script takes the averages for you and tells you how many jumps you've made. Make sure to zero the counter ("Clear Data" button) after changing your skill level to the next one.
- Attachments
-
- jumpingtestSeries3.7z
- Series 3 of Jumping Tests
- (4.8 KiB) Downloaded 232 times
Re: Acrobatics Task Update
Do you have a steady, solid framerate? I wouldn't be at all surprised if Morrowind's physics were dependent on the framerate, which would amplify floating-point precision errors.Epsilon wrote:Adding to the problem is that Morrowind's starting velocity for a jump is ever so slightly randomized. Not by a whole lot, and I suspect it's more an error in the game engine than a specific setting, but a series of tests and calculations show that the error does exist.
Re: Acrobatics Task Update
It's relatively steady, and more importantly, high - it's running at 148 according to MGE/MWSE. Also, if it was a precision error, shouldn't it stack up the higher the jump goes? Because the error remains at roughly +/- 3 all the way up and down the scale.Chris wrote:Do you have a steady, solid framerate? I wouldn't be at all surprised if Morrowind's physics were dependent on the framerate, which would amplify floating-point precision errors.Epsilon wrote:Adding to the problem is that Morrowind's starting velocity for a jump is ever so slightly randomized. Not by a whole lot, and I suspect it's more an error in the game engine than a specific setting, but a series of tests and calculations show that the error does exist.
I originally thought it had something to do with the measuring method I had - it uses a timer and tracks the player's z position to get a maximum height and a starting velocity for the player. That's obviously limited to framerate as far as how often it can take measurements, but it had a bit of jitter to it as well - something like +/- 2-3 units/second.
There's also an internal velocity counter (accessible through the TDT console command,) and this is what tipped me off that there's some sort of problem deep within the game engine. All the models I made show that Morrowind's physics follow traditional kinematic equations. Evidence for this is that my calculated velocities match (again, +/- 3 units or so) the velocity shown in the TDT command for things such as terminal velocity (that were determined experimentally.)
If I assume that g and terminal velocity were determined correctly (and the latter I can 100% confirm is at least within 99% of what was determined experimentally,) I can work backwards from height and velocity at a given point in a jump (as shown by TDT, once again) to determine the initial impulse applied to the player.
... wow. I just rambled on about my processes, didn't I? Either way, the more you know. ;p If you want to see more about my measurements, "jumptest_testscript" (the script I use to automate all the measurements) in the .esp is well-commented with what I was thinking while doing it.
Re: Acrobatics Task Update
If linear was true, I would have found it a week ago.(Interestingly, they simplified it in Oblivion and made it linear.)Epsilon wrote:I've been playing with the mathematical model, and god - it's definitely not a simple linear formula. If it was, I'd probably be done already.
I will be very curious to see what exactly it is.
(because I am kinda lazy, and also because I have textures and models to do, I havnt bothered testing myself) With the data I do have, I can make 0-50 fit an equation and 50-100+ fit an equation(perfectly), but I cant make 0-100+ fit anything.
Pretty sure all I need is to know the relation between the GMSTs to figure this out, but I will let you find it.
Re: Acrobatics Task Update
That's essentially what I'm doing. I actually managed to get (roughly) 1-200 to fit a proper (and relatively simple) equation using an exponent and some division, but it -badly- falls apart at higher acrobatics levels. As it stands, I'm collecting averaged data points, twiddling GMSTs around so I have multiple points of reference, and throwing processor power at it with that Formulize program you posted in the general formulas thread. And thanks again for that!Tarius wrote:If linear was true, I would have found it a week ago.(Interestingly, they simplified it in Oblivion and made it linear.)Epsilon wrote:I've been playing with the mathematical model, and god - it's definitely not a simple linear formula. If it was, I'd probably be done already.
I will be very curious to see what exactly it is.
(because I am kinda lazy, and also because I have textures and models to do, I havnt bothered testing myself) With the data I do have, I can make 0-50 fit an equation and 50-100+ fit an equation(perfectly), but I cant make 0-100+ fit anything.
Pretty sure all I need is to know the relation between the GMSTs to figure this out, but I will let you find it.
(Note: I know that AcrobaticsMult is used as an exponent to skill somewhere, because the data curves when it's set to 8 and goes utterly flat when set to 0. I just don't know -how-.)