Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nil Eyeglazed]

Hey, I'm planning on doing a bit of work on the time article.  There are quite a few confusing things in that article, and so I'm hoping to get some feedback before just excising stuff in the belief that it doesn't make sense.

"In fortress mode, a time unit is equal to 1.2 In-game minutes. There are 1200 time units in a day"-- Okay, where does this come from?  Is there actually any way to see what minute it is?  Does it read "12:04.8"?  Inclined to remove this as I don't see any kind of source or significance...

"In adventurer mode, a time unit is exactly 1 In-game second. Thus, adventurer mode is 72 times slower than fortress mode...."  Again, is there a count of seconds available somewhere in adventurer mode?  I can understand saying that time passes 1/72nd as fast in adventurer, although there probably ought to be a definition of second here-- apparently, there are 60 seconds to a minute and 1000 minutes to a day?

"...The conversion between Time units and seconds in Fortress mode, it's not precise..."

It's 72 times slower, but it's not precise?  1/72 strikes me as very precise, if there's actually any data supporting it.  Or is this referring to the conversion of game time to real time?  If so, it ought to be precise as hell-- 1 tick at 100fps takes 1/100th of a second.  Exactly.

"The average human (with 1000 agility attribute) takes 10 time units, regardless of mode, to move one square. The average dwarf (with 900 agility) takes around 11."

This is actually what started me trying to figure out how to improve this page, because that information is not accurate.  You can test it out by giving a creature an agility of 1000.  A creature with an agility of 1000 takes a step every 10-11 ticks (mostly 11); a creature with agility 1200 seems to take a step every 10, although of course there's no way I can be sure (9.999 and 10.001 are very very close to 10).

Any comments, any thing that maybe I'm not seeing?

[3]

"In fortress mode, a time unit is equal to 1.2 In-game minutes. There are 1200 time units in a day"-- Okay, where does this come from?

1.2 * 1200 = 1440 minutes
1440 / 60 = 24 hours

This is actually what started me trying to figure out how to improve this page, because that information is not accurate.  You can test it out by giving a creature an agility of 1000.  A creature with an agility of 1000 takes a step every 10-11 ticks (mostly 11); a creature with agility 1200 seems to take a step every 10, although of course there's no way I can be sure (9.999 and 10.001 are very very close to 10).

Except that insofar as previous research has gone it is accurate.

Edit: Actually, I'm wrong there. The article says "agility" but it probably means "speed"; they're entirely seperate things.

[Nil Eyeglazed]

1.2 * 1200 = 1440 minutes
1440 / 60 = 24 hours

Duh, stupid me.  Thanks.  I did my math exactly backwards.

This is actually what started me trying to figure out how to improve this page, because that information is not accurate.  You can test it out by giving a creature an agility of 1000.  A creature with an agility of 1000 takes a step every 10-11 ticks (mostly 11); a creature with agility 1200 seems to take a step every 10, although of course there's no way I can be sure (9.999 and 10.001 are very very close to 10).

Except that insofar as previous research has gone it is accurate.

Edit: Actually, I'm wrong there. The article says "agility" but it probably means "speed"; they're entirely seperate things.
[/quote]

Yeah, I suspect that the speed part of that research is correct, but while 1000 agility is typical, I don't think it's the number that everything comes out pretty at.

[dree12]

Edit: Sorry, I was mistaken. I just assumed NW_Kohaku's multiplier comment meant that 1000 meant 900 speed. This is not the case. Here's a table of speeds below:
Base 900, Agi 75: 1177.14
Base 900, Agi 800: 988.14
Base 900, Agi 900: 962.70
Base 900, Agi 1000: 936.27
Base 900, Agi 1100: 910.10
Base 900, Agi 1125: 903.01
Base 900, Agi 1137: 900.00
Base 900, Agi 1150: 897.01
Base 900, Agi 1200: 884.25
Base 900, Agi 3000: 468.18

So, therefore, your analysis was correct: A SPEED:900, agility 900 dwarf would have more 11s than tens. To get exactly speed 900, apparently 1137 (1138 too, likely) is needed. This should help develop a formula.

(adding to this: A dwarf's lowest possible agility is 75. It's highest is 3000. Remarkably, this is extremely close to the Perfectly Agile dwarf of 40d.)
Edit2: Typo
Edit3: Can anyone confirm that values over 2800 for agility don't have any effect? That's what it seems like right now.
Edit4: Okay, it looks linear. Here's my equation:
For SPEED:900 creatures:
Speed = int(-0.2601469 * Agility + 1195.91709875) where int is some sort of rounding. Is this fine to put on the wiki?

[Nil Eyeglazed]

Wow, dree!  Nice job!  Let me confirm some of that-- the weird progression (14 ticks/move @ agility 1, 11 ticks/move @ agility 1000, 7 ticks/move @ agility 5000) left me feeling like it couldn't be a linear progression, but you're right, if it's capped, it could work-- I tried a few curves that I felt would be obvious, and nothing fit.  In the end I just kind of left it up in the air in the 'time' section.

I'm curious about your speed values, though, because it's possible to read speed in more than one way, as it's a value we can only infer from delay.

There's potential for confusion even for delay: because does a delay 10 dwarf move 1, then wait 10?  That'd be 1 move per 11 ticks.  Or does a delay 10 dwarf move 1, then wait 9?  I use the latter definition of delay: it is the time between steps, so a delay 10 dwarf will cover 10 steps in 100 ticks.

So I'm curious about which way of describing it you used, as well as:

Is delay = 10000/speed, or is delay=10000/(speed+100)?  I suppose it could be confirmed by modding creatures, which I don't feel like doing; in the case of speed 1 dwarves, for instance, do they have a delay of 1/101?  Or is there a line saying something like, "if speed<100 then speed=100"?  I understand the popular wisdom is that delay=100/(speed+100), I'm just not sure that it's well-tested.

I'm curious how you reached your formula, too-- I wonder why Toady would pick such bizarre constants.  Is it based on curve matching to experimental data?  Or are your numbers found by plugging in values to the formula you reached by other means?

I'll test a couple of values and see if they match, including the possibility of capped agility effects.

EDIT: That formula doesn't make any sense to me.  Since agility is multiplied by a negative number, as agility goes up, speed goes down.  Is there a typo someplace?

[dree12]

This speed is the speed in 40d stats. That is, 988 would mean wait 9, 88% chance of wait one more, then move (so between 10 and 11 per move).

[Nil Eyeglazed]

What about the formula you gave?  Doesn't make sense as written; negative multiplier on agility leads to decreasing speed with increasing agility.

[dree12]

Exactly, and a decrease of speed = a decrease of delay.

Spoiler: Actual original post that was only edited once (click to show/hide)

Exactly, and a decrease of speed = an [del]increase[/del][ins]INCREASE[/ins] of delay.
Edit: blarg, it's past 9 here during summer break. shouldn't be posting, huh.

[Nil Eyeglazed]

Exactly, and a decrease of speed = a decrease of delay.

Spoiler: Actual original post that was only edited once (click to show/hide)

Exactly, and a decrease of speed = an [del]increase[/del][ins]INCREASE[/ins] of delay.
Edit: blarg, it's past 9 here during summer break. shouldn't be posting, huh.

Doh, my brain's not working.... 

[Nil Eyeglazed]

So I'm not seeing the same things as you with a couple of tests.  These tests are run under the assumption that delay = (modspeed+100)/100 and that modspeed=(1195.91709875-(agility*0.2601469)*speed/900), from your formula, although since everything's speed 900 that term simplifies out.  I used wolfram alpha to solve for unknowns.  That's a cool calculator they've got there.

Agility 1: Anticipated delay 12.956-- call it 13.  Found delay > 13 (14, plus or minus).

Agility 1138: Anticipated delay =< 10.  Found delay > 10.

Agility 2676: Anticipated delay =< 6.  Found delay >6.

Agility 4000: Anticipated delay ~2.5.  Found delay ~6.

(notably, if uncapped, an agility of 5000 would lead to a negative anticipated delay; intercept at 0 happens at ~4978 agility)

I don't think this is a combination of cap (explaining 4000) and "delay=delay+1" because, for instance, with agility 1138, you would expect a value extraordinarily close to an integer, yet looking at the delays, it doesn't look close to an integer.  Of course, that could be artifact because of the probabilistic nature of movement in DF.

Let me test a couple of alternate formulas.

What happens if we replace  delay = (modspeed+100)/100 with delay = modspeed/100?  Expected becomes further from found, with us expecting delay 10 at agility ~= 753.

What happens if we then replace modspeed=(1195.91709875-(agility*0.2601469)*speed/900) with modspeed=(1195.91709875-(agility*0.2601469)*speed/1000)?  Expected becomes further from found yet again.

[dree12]

These values are calculated from what the game displays in adventure mode, or the "displayed speed". That means that although the data points to the integer at 1137, since it is the middle of 1125 and 1150, rounding can make it go weird. Here's the formula for speed vs. adventure mode speed:

Adv. Mode Speed = 1000000 / (Mod Speed + 100)

and since modspeed + 100 is delay, it is the reciprocal of delay (in other words, actual speed in tiles/whatever amount of time). So these values should be preety accurate in that case. How are you testing delays?

[Nil Eyeglazed]

I take an unwounded, naked goblin, alter its agility in runesmith, and hit '.' until it moves.  I count the number of ticks until the move.  I looked at about 10 moves for each value with this most recent set of tests.  The presence of higher delay seemed like refutation, so I didn't stress over probabilities at all.  (I've got a lot of such goblins running around in my fortress because I've been experimenting with hatch-pressure plate goblin logic devices; my interest in this started with trying to design an accurate goblin-based clock generator).

The nearness of the y-intercept to 5000, which is supposedly the max agility, makes me think that the actual agility equation is likely in the form of modspeed=k-k(agility)/m where m is either 5000 or 5001.  I say that just because if Toady was using a linear equation that topped out at x=5000, that's how he'd do it-- he wouldn't have the y-intercept come before 5000.  X-intercept could be put in multiple places-- he could be making an arbitrary lower end speed, or it could be figured from delay, or adventurer speed, and reciprocals could make k a very ugly number.

The rounding is interesting because there are a couple of places in the equation that you could do the rounding.  One of these is in the adventurer display: you could have a float modspeed, and round to the nearest 25 (Is that how it always rounds?  Nearest 25?)

I think it's also likely that it's rounding at delay.  Toady has said that he's used a percentage system with older versions.  That could mean that delay 10.251 becomes delay 10 with 25% chance to act in 10, but it could also be that Toady was just speaking generally, or that it's changed, and 10.251 becomes 251/1000 chance to act in 10, else act in 11.

Of course, what could be happening is that he's figuring adventurer speed (even in dwarf mode), rounding it, and determining delay from adventurer speed, maybe rounding it again afterwards.

All that said, rounding errors and a slightly modified equation are not going to square your data with my data-- I think the only thing that would is if delay=modspeed+200, in combination with rounding errors and a modified equation.  Which I don't think anybody would like.  Guess I'll have to do some mod-based testing.

[dree12]

Please read this first, that should explain how delays work. (speed mentioned is modspeed). Adventure mode rounds to nearest unit of speed, and agility IS capped at 2800 (above that, there is no effect). I'm not sure why the numbers are that weird, but for a agility 1000 goblin:
Minimum ticks to move: (not delay) 10 (ortho) 63% Chance
Maximum ticks to move: (not delay) 11 (ortho) 37% Chance

[Nil Eyeglazed]

Okay, I've found a better way to do experiments.  Spawn a goblin in arena mode, take control, observe speed, modify stats; return to arena to observe delay.

The first thing that I confirmed is that delay=10^4/advspeed.

The next thing was sort of a shock, and explains different experimental results.  Strength affects the speed of a naked goblin.  Up to strength of 2781, I received speed bonuses for strength.  No other stats (besides agility) affected speed.  A naked goblin with a strength of 2781 and 1000 agility has advspeed 1692.  A goblin with 1000 strength and 1000 agility has a speed of 932.  A naked goblin with a strength of 1000 and a 2781 agility has advspeed 1692 as well.

Also, up to agility 2781, I received agility bonuses for speed.  So it looks like a cap of 2781, with equal effects from strength and agility.

I tried making a naked goblin with grand master armor user @ 1000 str/agility.  No effect on speed.

A goblin with str/ag of 1133-1134 has exactly 1000 advspeed.

I'll try and figure out a formula soon.  Shouldn't be too hard.  Just need to use it to verify with  some other values.

EDIT: Okay.  It's not based on agility or strength.  It's based on the sum of strength and agility, capped to 3797.  Weird, huh?

EDIT2: Lower cap too.  Sum of agility or strength <204 becomes equal to 204.

EDIT3:  Okay, here's what I got.

Step 1: If agility+strength<203 set sum=203; else if agility+strength>3797 set sum=3797;else sum=agility+strength

Step 2: Where y is sum, adventurer speed x is equal to:



Step 3: Round to the nearest integer.

This is not perfect, but it is very very close.  An alternative would be to replace the constant "1.6813" with a value like "1.68119" and rather than rounding, just drop anything after the decimal.  I doubt that either is a perfect representation, because those are not constants any sane programmer would choose, but they represent the range of values really well; if you build a tolerance of 1 into the sum, it should work for all possible values (not tested for all possible values, lol)

What do you think, dree?  Does that count as solved?

[dree12]

That was what I did, but I never thought of strength. Wow, that's just amazing - this means the average dwarf is just as fast as a human! So much for dwarf slowness. As for the constants, um, the coefficient for y is nearly equal to 0.0003, and that makes more sense than that huge fraction. Another thing is that the cap is probably 3800 rather than 3797 because there is a ±3 rounding thing. Other than that, I think it's ready for the wiki.