Warrior General Games

Originally posted by jdbolick
If speed isn't affected then nothing is. The only empirical evidence we have suggests that the effect of energy is determined at the start of the play and does not degrade during the play as energy is drained.

I dunno when ya watch players play with energy completely turned off they seem to break a lot more tackles and do a lot better things than I ever see from guys when they are at full energy and the bar degrades. No evidence or anything. Just from looks of the games with and without energy used and watching dots at full energy in regular games in comparison to watching dots with no energy on.

Originally posted by Fumanchuchu
Every tic, the rolls take into account Attributes, VAs, and SAs that can all change the value of each other from a tic to tic basis. The sim also tracks direction, speed, ball position and distance to other defenders in real-time. Why wouldn't it scan for current energy level as well? The energy/morale bars react to whats occurring on the field, so they're not a facade, they are derived from the sim, why would Bort go to all that trouble to light up a bar if the sim wasn't already tracking that stuff?

My point though is I would think you have to divorce yourself from what you "see" in a replay from the actual play that happened in the game. A replay of a play in the game is visual... whereas the play that the replay is from happened inside the CPU's mind, calculated and resulted in a blink. All the math done to create the play is done at once. Then we get to "see" a replay of that result. Knowing how people post bugs about dots doing this and not doing that led me to realize this... that the replays aren't nearly as accurate a representation of the actual play as we think they are/should be. Again... I cannot guarantee you this as absolute fact... I don't code for Bort and company and therefore don't have a front row seat behind the curtain of Oz.

At one point bort clearly stated that morale and energy were updated tick by tick and the effects were instantaneously applied. I cant find it in the wiki however.

Originally posted by Fumanchuchu
Every tic, the rolls take into account Attributes, VAs, and SAs that can all change the value of each other from a tic to tic basis. The sim also tracks direction, speed, ball position and distance to other defenders in real-time. Why wouldn't it scan for current energy level as well?

Agree, it would be trivial to put energy into the code if all of the rest is in place. Iterative computer code that works with time steps is pretty methodical once the ground rules are laid down.

The speed script I'm running shows the fire catch returner clearly reduce his speed as the play progresses (taking into account the rounding produced by the spatial coordinates). Not by much, looking at the way the line wiggles I'd have a rough guess of 5-10%. Maybe I'm using an old script though.

Originally posted by mandyross
The speed script I'm running shows the fire catch returner clearly reduce his speed as the play progresses (taking into account the rounding produced by the spatial coordinates). Not by much, looking at the way the line wiggles I'd have a rough guess of 5-10%. Maybe I'm using an old script though.
See, this boggles my mind because I have no clue what you think you're seeing. http://goallineblitz.com/game/replay.pl?game_id=2091427&pbp_id=5862341 I minimized my window so that I would have a perfectly horizontal threshold to compare against so my eyes wouldn't deceive me, and the green line is exactly level. It remains the same distance from the top of the window throughout the play, minus minor variation for course adjustment early in the return.

edit:
Using minimized windows, the OP link does drop during the course of the play but just fractionally. There's hardly anything there, so if that's energy taking effect then energy loss must have almost no effect on attributes.

To unboggle your mind, I'm seeing this: http://oi50.tinypic.com/rgvtyw.jpg

Obviously our speed scripts are different, but I'm not worried about that as the one I'm using uses the tick-by-tick coordinates. If there is another one out there that has more data manipulation: averaging, a running filter, that sort of thing, I'd be interested to see it.

Only someone who doesn't understand finite element coding and time series analysis would claim that there is no speed drop there. (As a way to get started on this topic, I'd recommend Tautology's mega-post ... link?).

The drop not large, before I estimated 5-10%, I'd say around 5% is probably closest to the true value. But it does exist, something which is entirely logical from a coding point of view.

Now someone just needs to find the Bort quote to confirm ...

Originally posted by mandyross
To unboggle your mind, I'm seeing this: http://oi50.tinypic.com/rgvtyw.jpg Obviously our speed scripts are different, but I'm not worried about that as the one I'm using uses the tick-by-tick coordinates. If there is another one out there that has more data manipulation: averaging, a running filter, that sort of thing, I'd be interested to see it.
Yeah, that's an inferior script which explains your mistake. Fu listed the better one here:
Originally posted by Fumanchuchu
I'll try to find a link for the script I'm using, it shows both the red line and green line declining.

edit: here it is: http://userscripts.org/scripts/show/56383 goes with pabst's replay rewrite: http://userscripts.org/scripts/show/31640
When you get that one you'll see that the speed maintains a constant level which the red line jitters around during the period of slight horizontal movement before stabilizing during the purely vertical movement.

That looks better, but still shows that you are wrong bolick. The green line is clearly a running average (something I guessed without having even seen it, and something that I was doing in my head based on deathblade's original speed script). The graph shows the speed when crossing the 30 yrd line (purely vertical movement) is greater than the speed during the final 10 yards of the play. Not much, maybe a 2.5% difference. Here it is with a straight line drawn on it, probably a more accurate way to see things than trying to align it with the screen edge.

http://oi46.tinypic.com/smzzbk.jpg

I assume that when you say that the green line (running average speed) is flat, you are talking about the final 15 yards or so. This doesn't prove anything, as the replay doesn't have enough decimal places in the player coordinates to draw meaningful conclusions from such a small part of the graph, and the nature of taking a running mean on a time series. If Bort included 1 more decimal place of accuracy in these replays, there would be an obvious decline in the graph.

I think we've reached the limitation again of where your current understanding lies with regards to the speed script, finite element coding and time series analysis. Maybe Tautology will write another book for you with baby steps? Unfortunately, that is far beyond my level of patience.

Originally posted by mandyross
That looks better, but still shows that you are wrong bolick. The green line is clearly a running average (something I guessed without having even seen it, and something that I was doing in my head based on deathblade's original speed script). The graph shows the speed when crossing the 30 yrd line (purely vertical movement) is greater than the speed during the final 10 yards of the play. Not much, maybe a 2.5% difference. Here it is with a straight line drawn on it, probably a more accurate way to see things than trying to align it with the screen edge. http://oi46.tinypic.com/smzzbk.jpg
lol @ you being so blatantly misleading. Come on, man. You ran your black line along the top of a couple of peaks and not through the middle of that sinusoidal portion where the horizontal movement produces less accurate results. You know as well as I do that had you done so, it would look perfectly flat like I said. The little gap between your black line and the green line in the middle of that graph is exactly the same size as the little gap between them at the end of the graph. What frustrates me, though, is that other speed script results seem to show a gradual decline. So we have some results that are perfectly flat, showing no speed loss at all, and others showing a very slight decline. Again, I could very well be wrong, but more than anything I'm confused by having examples that support both sides.

Originally posted by
I think we've reached the limitation again of where your current understanding lies with regards to the speed script, finite element coding and time series analysis. Maybe Tautology will write another book for you with baby steps? Unfortunately, that is far beyond my level of patience.
Funny how I have the reputation for being "the bad guy" and yet I always have to put up with stuff like this where you're being a dick to me unprovoked and unwarranted. In fact, I think you're insulting me here precisely because you know that the green line shows you were not being accurate.

Originally posted by jdbolick
Originally posted by mandyross

That looks better, but still shows that you are wrong bolick. The green line is clearly a running average (something I guessed without having even seen it, and something that I was doing in my head based on deathblade's original speed script). The graph shows the speed when crossing the 30 yrd line (purely vertical movement) is greater than the speed during the final 10 yards of the play. Not much, maybe a 2.5% difference. Here it is with a straight line drawn on it, probably a more accurate way to see things than trying to align it with the screen edge. http://oi46.tinypic.com/smzzbk.jpg
lol @ you being so blatantly misleading. Come on, man. You ran your black line along the top of a couple of peaks and not through the middle of that sinusoidal portion where the horizontal movement produces less accurate results. You know as well as I do that had you done so, it would look perfectly flat like I said. The little gap between your black line and the green line in the middle of that graph is exactly the same size as the little gap between them at the end of the graph. What frustrates me, though, is that other speed script results seem to show a gradual decline. So we have some results that are perfectly flat, showing no speed loss at all, and others showing a very slight decline. Again, I could very well be wrong, but more than anything I'm confused by having examples that support both sides.

Originally posted by

I think we've reached the limitation again of where your current understanding lies with regards to the speed script, finite element coding and time series analysis. Maybe Tautology will write another book for you with baby steps? Unfortunately, that is far beyond my level of patience.
Funny how I have the reputation for being "the bad guy" and yet I always have to put up with stuff like this where you're being a dick to me unprovoked and unwarranted. In fact, I think you're insulting me here precisely because you know that the green line shows you were not being accurate.

lol @ you for not understanding what my horizontal line represents. I even laid it out for you on a plate: "the speed when crossing the 30 yrd line".

It is clear that the speed of the dot when it is moving vertically when it crosses the 30 yard line at the start of the return is greater than the speed when it moves vertically during the last part of the play. No matter how much you change the window size and tilt the screen. Other replays show this more evidently, due to the hidden decimal in the sim code falling into a more visually obvious range when transferred to the replay code.

The confusion behind having examples that supposedly support both sides is taken away if you focus on the resolution of the time and distance steps in the replay code. Then you will realise that you're plain wrong. You have to understand the resolution you get when using discrete time and distance steps in computer code - Tautology helped you a lot in the past, now it is time to take that next step and read up on running means and the limitation of using them on a truncated, low resolution time series.

I understand the mathematics behind the green line (even predicting what it would be based on before I had even seen the script), you do not. It's something that is used commonly in time series analysis to smooth data, and you have to take this into account before drawing erroneous conclusions based on a fraction of one play. You've reached that point again where you're mathematically and computationally out of your depth and so just start to lash out aimlessly.

I am aware that you go a little insane when you get out of your depth, and of the painstaking process required to bring you around. Someone should just ask Bort during the next Q&A if energy and confidence are updated on a tick-by-tick basis in a replay, the answer will be yes.

At the planck scale, things don't move at all. They are just suddenly somewhere else.

Need an SA to represent that, imo.

Originally posted by tautology

At the planck scale, things don't move at all. They are just suddenly somewhere else.

Need an SA to represent that, imo.

Reprogram the sim to represent dots as wavefunctions and introduce tunnelling? And any precise speed measurement made is meaningless as you can't tie down the position of the dot. I like!

Originally posted by mandyross
Reprogram the sim to represent dots as wavefunctions and introduce tunnelling? And any precise speed measurement made is meaningless as you can't tie down the position of the dot. I like!

DEs used to do this from time to time, so there is a precedent

Originally posted by mandyross
lol @ you for not understanding what my horizontal line represents. I even laid it out for you on a plate: "the speed when crossing the 30 yrd line".
The 30 yard line is an arbitrary point because it's not the point at which he begins moving horizontally, as that doesn't happen until the 31.5 or so. You picked the 30 yard line only because that was the highest speed, but you already know from the tautology post you keep referencing that isolated, extreme data points cannot be considered accurate in these script estimations of pixel data. And if you had drawn the 31.5, it would look like this: http://img193.imageshack.us/img193/3276/mandyrossisfullofshit.jpg Wow, imagine that. Unlike what you claimed, the line is perfectly level, indicating that the his speed does not decline at all over the rest of the return.

Originally posted by
I understand the mathematics behind the green line (even predicting what it would be based on before I had even seen the script), you do not.
Actually I do. Your ridiculously condescending attitude is especially comical precisely because of my mathematical background. But you're making this entirely too complicated to mask the fact that you screwed up. That smoothing average irons out into a flat line throughout the rest of the return. It does so precisely because the speed doesn't change from that point, so there is no rounding error to influence the data.

Originally posted by
You've reached that point again where you're mathematically and computationally out of your depth and so just start to lash out aimlessly.
Again, you are the one repeatedly insulting me, not the other way around. And furthermore, it seems pretty obvious that you're doing so because you realize that you made a mistake. Look man, you can pretend to be more intelligent than I am but we both know it's not true, so spare us the empty bluster.

Originally posted by jdbolick
Originally posted by mandyross

lol @ you for not understanding what my horizontal line represents. I even laid it out for you on a plate: "the speed when crossing the 30 yrd line".
The 30 yard line is an arbitrary point because it's not the point at which he begins moving horizontally, as that doesn't happen until the 31.5 or so. You picked the 30 yard line only because that was the highest speed, but you already know from the tautology post you keep referencing that isolated, extreme data points cannot be considered accurate in these script estimations of pixel data. And if you had drawn the 31.5, it would look like this: http://img193.imageshack.us/img193/3276/mandyrossisfullofshit.jpg Wow, imagine that. Unlike what you claimed, the line is perfectly level, indicating that the his speed does not decline at all over the rest of the return.


You don't understand anything. Your reasoning is some of the most cretinous I have ever heard.

The 31.5 green line data point is lower because it takes into account the points of the red line beyond 31.5, where he has horizontal movement. Your conclusions are idiotic and just plain wrong.

That is what a running mean does to a time series! It is obvious that you don't understand this. Learn to program and look at the code, do a data analysis course, anything. You just don't have the qualifications to make any sense here and you are just misleading others.