Drop ball in front of catcher = Auto base advance for CPU?

[bcruise]

Re: Drop ball in front of catcher = Auto base advance for CPU?

I haven't seen this, but what's being discussed in the thread is different from what that video is showing.

How so? It's a ball that looks like it should be getting blocked missing some collision detection and going through the catcher. The thread may have started as just being about blocked pitches but it's become a lot more about WP frequency in general (because anything a runner advances on is a WP/PB)

Regardless of exactly what his tweet means, it means they're looking into WP's and what's causing them (be it bug or something else).

[Jr.]

Re: Drop ball in front of catcher = Auto base advance for CPU?

How so? It's a ball that looks like it should be getting blocked missing some collision detection and going through the catcher. The thread may have started as just being about blocked pitches but it's become a lot more about WP frequency in general (because anything a runner advances on is a WP/PB)

Regardless of exactly what his tweet means, it means they're looking into WP's and what's causing them (be it bug or something else).

I mean, it's good that they're fixing that particular bug, but that won't change the balls that are blocked and stay right in front of the catcher but runners still advance. That's a collision detection issue, which doesn't affect the issue that started this and a few other threads.

[Steven78]

Re: Drop ball in front of catcher = Auto base advance for CPU?

How so? It's a ball that looks like it should be getting blocked missing some collision detection and going through the catcher. The thread may have started as just being about blocked pitches but it's become a lot more about WP frequency in general (because anything a runner advances on is a WP/PB)

Regardless of exactly what his tweet means, it means they're looking into WP's and what's causing them (be it bug or something else).

This is NOT the issue.........

Sent from my SM-G900R4 using Tapatalk

[nomo17k]

Re: Drop ball in front of catcher = Auto base advance for CPU?

I don't know why the level of distrust with the developers has gotten quite a bit elevated this year (which hasn't been particularly common especially with longer-time members in the forum), but the fact that the devs are looking at an issue likely related to what we want to get fixed cannot be a bad news, no?

Of course there is no guarantee that the issue the twitter thread was talking about is about WPs or Ramone was talking about that specific collision detection issue or WP issue in general, but I don't see why this should be taken as a bad news at all.

For example, I think it's entirely possible that there is something amiss in collision detection in that particular play this year, and more WPs are caused by the catchers not being able to block on that kind of play somehow this year.

[bcruise]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Sigh.

I only brought it up because it reminded me of what syf was saying about the catcher animations not being being able to field the ball cleanly (a ball going straight through a catcher in a blocking animation could be another example of that). It's entirely possible that all of the odd/bad catcher behavior is interconnected and a factor in the excessive WP's, and I thought it was good to have confirmation that the devs were looking in that area. It's better than hearing nothing about them looking into this part of the game, no?

Have fun guys. I'll keep any hopeful comments to myself from here on. Feel free to twitter-watch yourselves.

[Steven78]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Distrust the devs?

Geeeeeeee I wonder why lol.

Sent from my SM-G900R4 using Tapatalk

[Bullit]

Re: Drop ball in front of catcher = Auto base advance for CPU?

C'mon guys really? The conversations in these threads have been going really well lately. Lets just stop the nonsense. Ok?

[Jr.]

Re: Drop ball in front of catcher = Auto base advance for CPU?

I didn't mean to offend anyone. I just don't see the connection between what that video is showing (the ball going through the catcher's mitt) and the issue of runners advancing too easily on actual blocked pitches.

No one ever said it was bad news or that they distrusted the developers. People are inferring way too much out of a simple statement of clarification.

[stealyerface]

Re: Drop ball in front of catcher = Auto base advance for CPU?

I think there are three totally different issues at hand here, but I am encouraged that there might be some attention paid to all three...

Issue one, in my opinion, is a collision detection problem, whereby the catcher's glove does not recognize the ball hitting it, and allows it to pass through the glove. Bcruise gave us an example of this is the tweet about fixing the glitch. This is including, but not limited to, deflections, where the ball hits the pocket of the glove, but seems to just continue through the catcher's glove, changing directions, but triggering the animation of the catcher running towards to backstop to fetch the ball. Now, if the game included the "Cross-up" where the catcher thinks a curveball is coming, and drops his glove to where the pitch should end up- were it a curveball, this happens from time to time, and indeed causes a passed-ball. But the game does not, at least in the front part of the engine, have an input that "fools" the catcher, so the randomization of a ball that passes through a solid object in order to gain a plausible number of wild pitches into the stats... well, that needs to be rethought.

Number Two, and my main beef, is the fact that during my exhaustive testing of splitters, curveballs, and changeups in the dirt, there are two main animations for the catcher. I ignored the guy who claimed that when the catcher drops to a "block" position, he shouldn't be picking that cleanly, because that is nonsense, and if you watch (or play) baseball, you'll see many a catcher drop the glove into a defensive position, silde to his left or right, and cleanly catch a bounced-ball with a palm-up glove. It happens all the time. But not in this game.

When the catcher shifts from his crouch to a palm-up posture he NEVER makes a clean pick of the ball. Never. They will block nicely, corral the bouncer into their chest protector, deaden the ball, or have to go chase it, but on no occasion will the palm-up attitude of the catcher animation allow for a clean play on the bounced ball. Subsequent to that, if the catcher is in his crouch, he can indeed make a nice pick on a bounced ball in the dirt, but not always. This animation is done perfectly. A dice roll on the pick being clean-blocked-kicked away-totally missed is handled properly, and my feeling is that the higher rating a catcher has, the smaller the algorithmic equation that the play is a negative one.

Number three is the subject of all the consternation here on this thread, and that is when the catcher is able to block the ball effectively, he does not aggressively pursue the ball on the ground, pick it up, and make a strong throw to the bag the baserunner is attempting to advance to. There is a delay, unheeded by the baserunner, in which the baserunner obtains omnipotent knowledge of the ball being far enough away to advance, but the catcher doubles that delay with the delay animation of his own, thereby causing a double-delay that always favors the baserunner. Added to this, the catcher, if he does pick up the ball, and for those of us using analog throwing, does not make a throw based on user input. I can push my R-stick through the top of my controller until the vibration rattles the stick out of my hand, but the throw to second is the same, exact, non-urgent throw, and the runner (even with a 15 speed) is safe 90% of the time.

I have baserunner speed tweaked down in my slider set, but with the catcher animation of throwing the ball from a blocked-ball not having any speed input attached to it, this allows the slowest runner to have a better than average chance at advancing.

This thread has turned into what we try to keep from happening on OS. Someone gets a wild hair, and then the rest of the mob mentality joins in, regardless of who has seen what, and then it becomes unruly, and people start sniping and the beat goes on.

Those of us that have been here on OS for a while realize that the developers DO read these comments, and as evident by the back-and forth they afford us with regards to certain ideas, fixes, stadium updates, the color of the thread on the away-uni socks for cripes sakes, shows that they do have some interest in what the community has to say.

But my father always used to tell me that you catch more flies with honey than you do with vinegar. So maybe some constructive criticism, or ideas of how to make an issue less of an issue, is better than piling on with snippish non-constructive comments that add nothing to the conversation at hand.

~syf

[Armor and Sword]

Re: Drop ball in front of catcher = Auto base advance for CPU?

I think there are three totally different issues at hand here, but I am encouraged that there might be some attention paid to all three...

Issue one, in my opinion, is a collision detection problem, whereby the catcher's glove does not recognize the ball hitting it, and allows it to pass through the glove. Bcruise gave us an example of this is the tweet about fixing the glitch. This is including, but not limited to, deflections, where the ball hits the pocket of the glove, but seems to just continue through the catcher's glove, changing directions, but triggering the animation of the catcher running towards to backstop to fetch the ball. Now, if the game included the "Cross-up" where the catcher thinks a curveball is coming, and drops his glove to where the pitch should end up- were it a curveball, this happens from time to time, and indeed causes a passed-ball. But the game does not, at least in the front part of the engine, have an input that "fools" the catcher, so the randomization of a ball that passes through a solid object in order to gain a plausible number of wild pitches into the stats... well, that needs to be rethought.

Number Two, and my main beef, is the fact that during my exhaustive testing of splitters, curveballs, and changeups in the dirt, there are two main animations for the catcher. I ignored the guy who claimed that when the catcher drops to a "block" position, he shouldn't be picking that cleanly, because that is nonsense, and if you watch (or play) baseball, you'll see many a catcher drop the glove into a defensive position, silde to his left or right, and cleanly catch a bounced-ball with a palm-up glove. It happens all the time. But not in this game.

When the catcher shifts from his crouch to a palm-up posture he NEVER makes a clean pick of the ball. Never. They will block nicely, corral the bouncer into their chest protector, deaden the ball, or have to go chase it, but on no occasion will the palm-up attitude of the catcher animation allow for a clean play on the bounced ball. Subsequent to that, if the catcher is in his crouch, he can indeed make a nice pick on a bounced ball in the dirt, but not always. This animation is done perfectly. A dice roll on the pick being clean-blocked-kicked away-totally missed is handled properly, and my feeling is that the higher rating a catcher has, the smaller the algorithmic equation that the play is a negative one.

Number three is the subject of all the consternation here on this thread, and that is when the catcher is able to block the ball effectively, he does not aggressively pursue the ball on the ground, pick it up, and make a strong throw to the bag the baserunner is attempting to advance to. There is a delay, unheeded by the baserunner, in which the baserunner obtains omnipotent knowledge of the ball being far enough away to advance, but the catcher doubles that delay with the delay animation of his own, thereby causing a double-delay that always favors the baserunner. Added to this, the catcher, if he does pick up the ball, and for those of us using analog throwing, does not make a throw based on user input. I can push my R-stick through the top of my controller until the vibration rattles the stick out of my hand, but the throw to second is the same, exact, non-urgent throw, and the runner (even with a 15 speed) is safe 90% of the time.

I have baserunner speed tweaked down in my slider set, but with the catcher animation of throwing the ball from a blocked-ball not having any speed input attached to it, this allows the slowest runner to have a better than average chance at advancing.

This thread has turned into what we try to keep from happening on OS. Someone gets a wild hair, and then the rest of the mob mentality joins in, regardless of who has seen what, and then it becomes unruly, and people start sniping and the beat goes on.

Those of us that have been here on OS for a while realize that the developers DO read these comments, and as evident by the back-and forth they afford us with regards to certain ideas, fixes, stadium updates, the color of the thread on the away-uni socks for cripes sakes, shows that they do have some interest in what the community has to say.

But my father always used to tell me that you catch more flies with honey than you do with vinegar. So maybe some constructive criticism, or ideas of how to make an issue less of an issue, is better than piling on with snippish non-constructive comments that add nothing to the conversation at hand.

~syf

This.....this is how it's done on the OS Show Forum I fell in love with back in 2009.

We must get back to this. Please.

[Jr.]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Number Two, and my main beef, is the fact that during my exhaustive testing of splitters, curveballs, and changeups in the dirt, there are two main animations for the catcher. I ignored the guy who claimed that when the catcher drops to a "block" position, he shouldn't be picking that cleanly, because that is nonsense, and if you watch (or play) baseball, you'll see many a catcher drop the glove into a defensive position, silde to his left or right, and cleanly catch a bounced-ball with a palm-up glove. It happens all the time. But not in this game.

I misunderstood what you meant in your original post when I disagreed. Catchers do glove the ball clean when they drop to block. I've seen it in the game, but it's more rare than it should be.

[stealyerface]

Re: Drop ball in front of catcher = Auto base advance for CPU?

If you have seen a clean catch on the palm-up, I retract my statement and apologize.

I still, even with test pitch after test pitch, have yet to see a clean pick-up from the block position.

I see beautiful picks, even on balls that they, by all rights, should slide and block, so I know they can do it, I just have seen a HUGE propensity for the block-not-catch animation, and this is what I believe to be the root of this issue.

~syf

[fightingirish595]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Runners are way to aggressive on balls in the dirt. They run in situations you would never see in real life, and are often safe!

[Greencollarbaseball]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Have the catcher animations changed from past games? Or is the issue really stemming from overly aggressive base runners because of humanity-AI?


Sent from my iPhone using Tapatalk

[Jr.]

Re: Drop ball in front of catcher = Auto base advance for CPU?

Have the catcher animations changed from past games? Or is the issue really stemming from overly aggressive base runners because of humanity-AI?


Sent from my iPhone using Tapatalk

It's both. The transition animations for catchers to get up and get to the ball are slower than in the past, but the runners' reaction time and aggressiveness is a big factor, too.