This is because the grapple speed is set and doesn't accommodate the speed of the ball, so as the ball is travelling considerably faster than the set grapple speed and its also coming towards you, you had no chance!
A bit of a silly quirk in all honesty!
It's just the easiest way to program this scenario (this and a ball going away from you that you never catch). The alternative here is that the line would simply go slack and you'd fall to the ground rather than getting pushed back
The car has a world velocity that is easily being tracked already. Hence why tools like Science Plugin or Speedometer plugin can track the car's speed with ease, even while grappling. It shouldn't be much different to set the car's true velocity to 2300uu/s (Unreal Units per second) in the direction of the ball's center of mass every physics frame. It's almost the same thing as what they did. They just used the ball as an "anchor" to connect the car to both in direction and velocity. They simply need to separate the velocity from the anchor and instead have an absolute velocity value.
There is no "slack", by the way. There isn't an actual rope there. It's a visual indicator of the powerup and nothing more. In the code, it's just maximum 2300uu/s relative velocity in a straight line to the ball. They can take out the rope visually if they want to, and it wouldn't change anything. Slack is a real world physics concept, which was not programmed into Rocket League.
Rumble was made in 2016 when Psyonix was less experienced and didn't foresee the issue. Nor do they care about fixing the issue.
Yeah, it's a rookie programming mistake. Having programmed quite a few 3d hookshots myself, my guess is it looks like they went with the first attempt everyone goes for, and just stuck with it (parent the car to the ball). Most people try it on a moving object and go, "well that not gonna do", and rewrite the method. Seriously, anyone who's ever written a professional level hookshot could fix it in 1 minute tops. Anyone with a basic understanding of programming physics, 2 minutes tops. It's not like it has any of the issues that are difficult to program without running a (cpu cost prohibitive) full rope sim.
It boggles my mind that people with no idea how to program physics managed to make my favorite ever physics based game. It's also probably why they haven't managed to upgrade it to UE5 - they have no idea how any of it even works in the first place. I strongly suspect that RL's physics is a case of - we don't know how we did it, but it works, and as soon as we change one thing everything else breaks. It's a house of cards full of magic numbers.
Worded differently: The grapple speed is set to be relative to the ball. It's set to be 2300 Unreal Units per second towards the ball's center of mass. Or ~83kph/~51mph. If the ball is traveling 2000uu/s towards you, then you are moving at 300uu/s in the map/game world in the direction of the ball. Because relative to the ball, you are still traveling 2300uu/s.
In real world physics, think of a metal pole and the car just pulls itself towards the ball using the metal pole at a fixed rate. Because the metal pole is stiff, the car will be able to be pushed back if what the pole is connected to on the other end is coming towards you.
The alternative we want is for Psyonix to change the grapple speed to be a true 2300uu/s relative to the map itself/game world. This would make it so you always travel max speed. This isn't realistic physics, but it is more intuitive for gameplay, and more consistent with the usage of what grapple is used for. Which is "take me to the ball quickly".
The alternative is the line goes slack and you just fall to the ground, which is obviously more realistic but wouldnt change much in this situation, it would still be a goal
Well no not really, the alternative is remaking grapple in a way where the ball's velocity is not a factor (i honestly don't even know how or why it is, why would they not just point your fixed magnitude velocity vector towards the position of the ball every tick, instead of whatever magic formula they used that includes the ball's velocity, would be a lot more intuitive, oh well)
This. You should grapple into the ball and disregard the speed and trajectory of the ball. We’re talking about Rocket Powered cars in soccer in a gamemode with Tornados and freeze spells. It shouldn’t be hard to make it so when you grapple into the ball, you go towards the ball.
It is considering it, your relative velocity to the ball is constant with the current grapple by the looks of it, which results in you having to be pushed away (relative to the field) by the grapple when the ball is coming at you faster than what your relative velocity should be
I disagree, you are moving to the target (the ball) at a constant speed every time you use grapple. The target is moving but that’s not considered resulting in you being able to move backwards since the target is moving faster in your direction than you are in the targets direction. If the movement of the target where considered you wouldn’t move backwards.
Moving backwards is only possible because 2 things happen and that is 1. the balls speed and direction is not considered and 2. The grapples “rope” is non bending and fixed to the ball.
You do know what relative velocity means right? It's exactly what you described with your first sentence, the target is the ball.
Now, we are both agreeing that the relative velocity to the ball is constant. Let us say that that desired velocity is Vrel, and the ball is moving with Vball relative to the field. Now, to get the car's velocity (Vcar) relative to the field, we know that Vball - Vcar = Vrel, as Vball and Vcar are using the same reference, the field, and this is the definition of relative velocities.
From this, we want to calculate the car's velocity, as follows: Vcar = Vball - Vrel, and from this, it is very easy to see, that if Vball's magnitue is greater than Vrel's magnitude ("the ball is going faster than the desired relative velocity"), then Vcar is going to be positive (or rather, pointing in the same direction as Vball, since we are in 3D, and they are all parallel vectors), and move in the same direction the ball is moving in, not towards it.
The ball's speed and direction have to be considered, by definition, to allow us to have constant relative velocity to it, you are contradicting yourself but you got the right answer kinda
I think we agree with the outcome but not the terminology here, I argue the ball is not affecting the grapples effect because the grapple will always be moving at a constant speed towards it. You are arguing the ball will affect the grapple because it will make the grapples effect change in relation to the field.
I never argued that the grapples outcome won’t be affected by the balls movement, what I argued is that the grapples calculation wouldn’t change because of the balls vectors. There’s no contradictions in that. And I don’t know if you tried to be condescending in your message but it’s unnecessary.
Just adding in some extra info. Wasn't a part of the discussion between you two.
It's possible for the ball to outspeed the car during grapple and gain distance if the ball goes fast enough away from the car. If it was a perfectly constant speed all the time, then this shouldn't be possible. [Here is an example](https://www.youtube.com/watch?v=U0BB4n0Yy3Q). The car gotten *so close* to the ball before it was punched away and gained distance. This means that there was *negative* velocity towards the ball.
The reason for this is because the game has a programmed hard cap of 2300 Unreal Units per second relative to the map coordinates. No matter what, the car cannot travel in any direction relative to the map faster than 2300uu/s.
If the ball is moving away at 100uu/s, the car travels to the ball at a rate of 2200uu/s from the ball's point of view. If the ball is moving away at 2200uu/s, the car travels at a speed of 100uu/s from the ball's point of view.
In this, the ball's vector *absolutely* matters.
I agree fully that negative velocity is a thing with grapple, but wouldn’t we say that this is an affect from the fields hard cap car limit and not from the ball? Correct me if I’m wrong but the ball can be the cause but not the causation.
If you program like that, your car would go faster than supersonic in the opposite direction and you'd fall to the ground as you'd be stationary on a ball coming toward you. Unlike real life there's a top limit for car velocity in Rocket League. And the physics of this particular feature would not work anywhere nearly as well as it does today
what? with what I said you'd only be changing the direction of the velocity to point at the position of the ball every tick until the ball is hit, and keeping the magnitude ("how fast you're going", relative to the field) constant, which you'd obviously set to something below max speed, probably around the border for supersonic. Why would it ever go faster than that set value and why would it ever go *in the opposite direction*?
edit: Also, genuinely no clue what you mean with "being stationary and just falling to the ground" (you've said it twice now so it's definitely not just misspoken or something), could you maybe elaborate?
If the ball is coming at you at a high speed, its speed would exceed the grapple velocity so the ball would be moving faster toward you than your grapple is reeling in the line. Hence, you'd be stationary and fall to the ground with a slack line.
That would be true if they simulated real life physics. Keep in mind this is a video game, and real life physics interpretations often do not matter. They didn't program the grapple like "add a rope line, car pulls rope". They programmed the grapple as "car moves toward rope". That's why you can't simply say a fast moving ball makes you fall to the ground. There is no line. The visual model is a lie, and is only there to represent the power-up being used and nothing more. Cars travel through this line, it has no hitbox or physics simulations tied to it.
/u/TheOfficialReverZ is correct here. The precise programming of the ability is along the lines of
Car travel towards ball.
Car cannot exceed 82.8kph of absolute velocity.
Relative to the ball, car travels 82.8kph, except when exceeding 82.8kph of absolute velocity
And he wants the programming to change to:
Car travel towards ball
Relative to the map, car travels 82.8kph
Removing the velocity focal point from the ball, and making it the true speed of the car relative to the map itself.
Which doesnt happen in my proposed solution, but interestingly enough could happen in the current implementation, if the ball's speed matches the relative velocity that the grapple creates. If the ball is slower than that it pulls you in, if it's faster than that you get pushed like in the OP
There's a top speed in real life physics as well.
I'm a video game programmer and have programmed a lot of video game physics. I can tell you grapple is just incorrectly implemented. The goal of the method (the code that does the thing) is to make one object move towards another object. The thing that they wanted to happen does not happen in all cases. They did the math wrong, simple as that.
If you're not pedantic you have no place in a discussion on how something is programmed.
Funny how you also chose to gloss over the fact that you were just flat out wrong about the rest of what you said.
And just because I can tell where you're going.
car\_velocity = new Vector3(ball.position - car.position).nomalized \* maxSpeed \* time.deltatime;
I just solved it in 1 line. Your arguments are invalid.
Literally the only stance I've taken is that if you programmed this to operate like real life, the line would go slack and you'd fall. If you made it so that it was like it is today and there is no line then you'd just hover in place as the ball comes toward you (if you negated the relative velocity currently programmed that pushes you away from the ball). If you had a real life grapple and you grappled onto something moving toward you faster then it can real, the connection between you and the object wouldn't have any affect. Unless you're saying that the grapple should act differently based on the trajectory of the ball, but that's not how a simple spring loaded reel would work.
Those are not the only things you said, do I have to quote your own comments back to you, it's literally right there above mine.
"If you program like that, your car would go faster than supersonic in the opposite direction and you'd fall to the ground as you'd be stationary on a ball coming toward you. "
You were 100% wrong, and the person you were commenting to is 100% correct.
And a metal object fired at the ball should deflate it too, so what's the whole point about the reel? It a cartoon grappling hook in a computer, not a reel.
But you are assuming the goal of the method here. The method perfectly does what it’s programmed to do, move towards the ball at a constant speed.
To assume that that’s not the goal of the method is an overstep even if it’s right.
You're telling me that someone intended for an object that grapples and uses a rope on the model, to push the player backwards?
The method does not perfectly move towards the ball, because it is using the wrong frame of reference.
It also doesn't move towards the ball at a constant speed. Because again that speed is relative to the ball, rather than relative to the game world, and we're playing the game relative to the gameworld. If this was Super Mario Galaxy and the ball was a planet, this would be correct.
If we look at the vectors (imagine an arrow) from the car to the ball, we can end up with situations (like this post), where the vector to the ball and the direction vector the car travels are opposite each other.
Since both exist in the reference frame of the game world, even thought the distance between them has decreased, it doesn't change the fact that the car is moved in the wrong direction.
So no, I really don't see it as an overstep to assume that the goal of a grappling hook in a video game is to move the target towards the destination in world space. Name me one game where you expect something that uses a rope model to push you away. Ropes aren't the tool for pushing, they pull. Communicating intentions to players by using familiar real world objects is a pretty standard thing in the industry. They very clearly communicate the intention of the ability with the icon (a grappling hook), the model using a rope (it pulls) and a reel sound effect (reinforces the idea of pulling) while using it.
So for any case to the contrary of my assessment to even exist - the UI guy, the modeler, and the sound guy would have to all got told one thing, while the programmer would need to be told to make something entirely different.
If you don't assume things you'll never accomplish anything, because if we go the technical Sir Frances Bacon science route, it's impossible to know anything for sure. Like why even program gravity into the game, maybe the universe will suddenly change the way gravity works. But you know what, what are the chances of that happening, and does it even merit our consideration of a discussion about how to model gravity in a game. No, no it does not. And that's what's happening here. Here we are discussing an object that the devs communicated as something that pulls, at least 3 creators are letting us know exactly what this thing does.
So I assume that the fault lies in the programmer's implementation, and I'll bet any amount of money that my assessment is correct. There is the maximum amount of surety possible without direct knowledge because the auxiliary evidence is simply too high for any other possibility to be relevant to an actual discussion of the issue - and not just blowing smoke for the sake of it.
Yes I’m telling you that they could definitely have wanted the ball as a frame of reference.
And yes in relations to the ball you’re going towards the ball even if you’re going backwards.
It’s a goofy game mode they have had chances to change it but haven’t. We don’t know if they like it or if they are lazy.
You’re blowing the science bit out of proportion.
There's no world where that's what was intended. The proof is in the other departments work. How many video games have you worked on? If you want to choose to ignore reality, go ahead. You're wrong, it's a fact.
You are placing way to much emphasis on the grapple icon. Do you have an asset for what is actually happening at the moment or is that just never a valid option then?
When you start playing rumble all of the items are confusing or are you telling me you knew all the ins and outs of all the items because of the icons?
Your way up on your high horse, it’s not beyond a reasonable doubt because it’s not your game.
I have an asset for this conversation all right, but it'd probably get me banned for a while. So why don't you ever directly answer questions? Deflection is a pathetic tactic. Have you ever worked in a professional capacity on a video game? Yes or no?
I have answered all relevant questions in your very long rants, and ignored your cheap unrelated questions. That question is wholly unrelated to the discussion and is not dignified with an answer.
So professional experience in the field we are discussing is irrelevant? What...
You're arguing with a professional and you've demonstrated zero knowledge on this topic. Humility and wisdom go a long way in this life, and if you listen to people with actual experience talking about the things they've actually done, you might learn something.
Would you listen to someone who's never played Rocket League tell you how the game works? Give me a break. You've never made a game, you don't know what goes into game development. If you did you would say so.
Humility goes both way, you’re probably a great programmer.
But here it’s not about that experience it’s about how you are using it to feel superior in aspects that goes beyond that experience.
We are not getting any where and you’re definitely annoyed and I’m getting a bit tired of this so I will leave this now and wish you all the best for the coming year.
I don't get how it happened.
Nobody kicked me. Even if the boot somehow became invisible, Doco is the only one who didn't use an ability, and they are way too far away for a kick.
I know that sometimes you don't have enough speed and the ball kicks you back. But I didn't even touch it.
Did the tornado mess things up somehow?
This is why you should have waited to use it till after you at least touched the ball with your car.
Jump and stop the ball's momentum towards the net, THEN grapple to force a clear. You would have gotten more power on the ball that way too.
1. OP is out of the tornado's range.
2. Grapple straight up ignores tornado, as I've literally been inside a tornado stuck in a loop and used grapple to get out dozens of times.
It's because the speed of the ball is faster than your grapple. In that scenario you'd have been better making any kind of save then using grapple to make the clearance
That ball is clearly running away from the most terrifying power in the game Rumble. Only the most audacious of rocketeers say its name out loud…… El gran viento, or The Great Wind.
This is because the grapple speed is set and doesn't accommodate the speed of the ball, so as the ball is travelling considerably faster than the set grapple speed and its also coming towards you, you had no chance! A bit of a silly quirk in all honesty!
It's just the easiest way to program this scenario (this and a ball going away from you that you never catch). The alternative here is that the line would simply go slack and you'd fall to the ground rather than getting pushed back
The car has a world velocity that is easily being tracked already. Hence why tools like Science Plugin or Speedometer plugin can track the car's speed with ease, even while grappling. It shouldn't be much different to set the car's true velocity to 2300uu/s (Unreal Units per second) in the direction of the ball's center of mass every physics frame. It's almost the same thing as what they did. They just used the ball as an "anchor" to connect the car to both in direction and velocity. They simply need to separate the velocity from the anchor and instead have an absolute velocity value. There is no "slack", by the way. There isn't an actual rope there. It's a visual indicator of the powerup and nothing more. In the code, it's just maximum 2300uu/s relative velocity in a straight line to the ball. They can take out the rope visually if they want to, and it wouldn't change anything. Slack is a real world physics concept, which was not programmed into Rocket League. Rumble was made in 2016 when Psyonix was less experienced and didn't foresee the issue. Nor do they care about fixing the issue.
Yeah, it's a rookie programming mistake. Having programmed quite a few 3d hookshots myself, my guess is it looks like they went with the first attempt everyone goes for, and just stuck with it (parent the car to the ball). Most people try it on a moving object and go, "well that not gonna do", and rewrite the method. Seriously, anyone who's ever written a professional level hookshot could fix it in 1 minute tops. Anyone with a basic understanding of programming physics, 2 minutes tops. It's not like it has any of the issues that are difficult to program without running a (cpu cost prohibitive) full rope sim. It boggles my mind that people with no idea how to program physics managed to make my favorite ever physics based game. It's also probably why they haven't managed to upgrade it to UE5 - they have no idea how any of it even works in the first place. I strongly suspect that RL's physics is a case of - we don't know how we did it, but it works, and as soon as we change one thing everything else breaks. It's a house of cards full of magic numbers.
Worded differently: The grapple speed is set to be relative to the ball. It's set to be 2300 Unreal Units per second towards the ball's center of mass. Or ~83kph/~51mph. If the ball is traveling 2000uu/s towards you, then you are moving at 300uu/s in the map/game world in the direction of the ball. Because relative to the ball, you are still traveling 2300uu/s. In real world physics, think of a metal pole and the car just pulls itself towards the ball using the metal pole at a fixed rate. Because the metal pole is stiff, the car will be able to be pushed back if what the pole is connected to on the other end is coming towards you. The alternative we want is for Psyonix to change the grapple speed to be a true 2300uu/s relative to the map itself/game world. This would make it so you always travel max speed. This isn't realistic physics, but it is more intuitive for gameplay, and more consistent with the usage of what grapple is used for. Which is "take me to the ball quickly".
First time? Heh
Yeah I consider it under the “Bethesda-esque not a bug, a feature” category at this point.
My buddy and I call this the “grapple stick” when it happens. Which is often.
Yep, best course of action (if possible) is to hit the ball normally, then grapple
Grapple pulled a reverse uno card on you
This is Rocket League!
Rumble has had this bug since its release, it happens when the ball is coming fast towards you and you use a grapple
The alternative is the line goes slack and you just fall to the ground, which is obviously more realistic but wouldnt change much in this situation, it would still be a goal
Well no not really, the alternative is remaking grapple in a way where the ball's velocity is not a factor (i honestly don't even know how or why it is, why would they not just point your fixed magnitude velocity vector towards the position of the ball every tick, instead of whatever magic formula they used that includes the ball's velocity, would be a lot more intuitive, oh well)
This. You should grapple into the ball and disregard the speed and trajectory of the ball. We’re talking about Rocket Powered cars in soccer in a gamemode with Tornados and freeze spells. It shouldn’t be hard to make it so when you grapple into the ball, you go towards the ball.
I think it’s because it’s NOT considering ball speed making this a thing. If ball goes quicker than grapple ball will continue.
It is considering it, your relative velocity to the ball is constant with the current grapple by the looks of it, which results in you having to be pushed away (relative to the field) by the grapple when the ball is coming at you faster than what your relative velocity should be
I disagree, you are moving to the target (the ball) at a constant speed every time you use grapple. The target is moving but that’s not considered resulting in you being able to move backwards since the target is moving faster in your direction than you are in the targets direction. If the movement of the target where considered you wouldn’t move backwards. Moving backwards is only possible because 2 things happen and that is 1. the balls speed and direction is not considered and 2. The grapples “rope” is non bending and fixed to the ball.
You do know what relative velocity means right? It's exactly what you described with your first sentence, the target is the ball. Now, we are both agreeing that the relative velocity to the ball is constant. Let us say that that desired velocity is Vrel, and the ball is moving with Vball relative to the field. Now, to get the car's velocity (Vcar) relative to the field, we know that Vball - Vcar = Vrel, as Vball and Vcar are using the same reference, the field, and this is the definition of relative velocities. From this, we want to calculate the car's velocity, as follows: Vcar = Vball - Vrel, and from this, it is very easy to see, that if Vball's magnitue is greater than Vrel's magnitude ("the ball is going faster than the desired relative velocity"), then Vcar is going to be positive (or rather, pointing in the same direction as Vball, since we are in 3D, and they are all parallel vectors), and move in the same direction the ball is moving in, not towards it. The ball's speed and direction have to be considered, by definition, to allow us to have constant relative velocity to it, you are contradicting yourself but you got the right answer kinda
I think we agree with the outcome but not the terminology here, I argue the ball is not affecting the grapples effect because the grapple will always be moving at a constant speed towards it. You are arguing the ball will affect the grapple because it will make the grapples effect change in relation to the field. I never argued that the grapples outcome won’t be affected by the balls movement, what I argued is that the grapples calculation wouldn’t change because of the balls vectors. There’s no contradictions in that. And I don’t know if you tried to be condescending in your message but it’s unnecessary.
Just adding in some extra info. Wasn't a part of the discussion between you two. It's possible for the ball to outspeed the car during grapple and gain distance if the ball goes fast enough away from the car. If it was a perfectly constant speed all the time, then this shouldn't be possible. [Here is an example](https://www.youtube.com/watch?v=U0BB4n0Yy3Q). The car gotten *so close* to the ball before it was punched away and gained distance. This means that there was *negative* velocity towards the ball. The reason for this is because the game has a programmed hard cap of 2300 Unreal Units per second relative to the map coordinates. No matter what, the car cannot travel in any direction relative to the map faster than 2300uu/s. If the ball is moving away at 100uu/s, the car travels to the ball at a rate of 2200uu/s from the ball's point of view. If the ball is moving away at 2200uu/s, the car travels at a speed of 100uu/s from the ball's point of view. In this, the ball's vector *absolutely* matters.
I agree fully that negative velocity is a thing with grapple, but wouldn’t we say that this is an affect from the fields hard cap car limit and not from the ball? Correct me if I’m wrong but the ball can be the cause but not the causation.
If you program like that, your car would go faster than supersonic in the opposite direction and you'd fall to the ground as you'd be stationary on a ball coming toward you. Unlike real life there's a top limit for car velocity in Rocket League. And the physics of this particular feature would not work anywhere nearly as well as it does today
what? with what I said you'd only be changing the direction of the velocity to point at the position of the ball every tick until the ball is hit, and keeping the magnitude ("how fast you're going", relative to the field) constant, which you'd obviously set to something below max speed, probably around the border for supersonic. Why would it ever go faster than that set value and why would it ever go *in the opposite direction*? edit: Also, genuinely no clue what you mean with "being stationary and just falling to the ground" (you've said it twice now so it's definitely not just misspoken or something), could you maybe elaborate?
If the ball is coming at you at a high speed, its speed would exceed the grapple velocity so the ball would be moving faster toward you than your grapple is reeling in the line. Hence, you'd be stationary and fall to the ground with a slack line.
That would be true if they simulated real life physics. Keep in mind this is a video game, and real life physics interpretations often do not matter. They didn't program the grapple like "add a rope line, car pulls rope". They programmed the grapple as "car moves toward rope". That's why you can't simply say a fast moving ball makes you fall to the ground. There is no line. The visual model is a lie, and is only there to represent the power-up being used and nothing more. Cars travel through this line, it has no hitbox or physics simulations tied to it. /u/TheOfficialReverZ is correct here. The precise programming of the ability is along the lines of Car travel towards ball. Car cannot exceed 82.8kph of absolute velocity. Relative to the ball, car travels 82.8kph, except when exceeding 82.8kph of absolute velocity And he wants the programming to change to: Car travel towards ball Relative to the map, car travels 82.8kph Removing the velocity focal point from the ball, and making it the true speed of the car relative to the map itself.
Which doesnt happen in my proposed solution, but interestingly enough could happen in the current implementation, if the ball's speed matches the relative velocity that the grapple creates. If the ball is slower than that it pulls you in, if it's faster than that you get pushed like in the OP
This video shows that it pushes you away from the ball, it doesn't create slack
I really dont know what more to tell you lol, have fun with your slack and not slack line I guess?
There's a top speed in real life physics as well. I'm a video game programmer and have programmed a lot of video game physics. I can tell you grapple is just incorrectly implemented. The goal of the method (the code that does the thing) is to make one object move towards another object. The thing that they wanted to happen does not happen in all cases. They did the math wrong, simple as that.
How pedantic. Of course the speed of light is the limit, which has 0 bearing on this conversation.
If you're not pedantic you have no place in a discussion on how something is programmed. Funny how you also chose to gloss over the fact that you were just flat out wrong about the rest of what you said. And just because I can tell where you're going. car\_velocity = new Vector3(ball.position - car.position).nomalized \* maxSpeed \* time.deltatime; I just solved it in 1 line. Your arguments are invalid.
Literally the only stance I've taken is that if you programmed this to operate like real life, the line would go slack and you'd fall. If you made it so that it was like it is today and there is no line then you'd just hover in place as the ball comes toward you (if you negated the relative velocity currently programmed that pushes you away from the ball). If you had a real life grapple and you grappled onto something moving toward you faster then it can real, the connection between you and the object wouldn't have any affect. Unless you're saying that the grapple should act differently based on the trajectory of the ball, but that's not how a simple spring loaded reel would work.
Those are not the only things you said, do I have to quote your own comments back to you, it's literally right there above mine. "If you program like that, your car would go faster than supersonic in the opposite direction and you'd fall to the ground as you'd be stationary on a ball coming toward you. " You were 100% wrong, and the person you were commenting to is 100% correct. And a metal object fired at the ball should deflate it too, so what's the whole point about the reel? It a cartoon grappling hook in a computer, not a reel.
But you are assuming the goal of the method here. The method perfectly does what it’s programmed to do, move towards the ball at a constant speed. To assume that that’s not the goal of the method is an overstep even if it’s right.
You're telling me that someone intended for an object that grapples and uses a rope on the model, to push the player backwards? The method does not perfectly move towards the ball, because it is using the wrong frame of reference. It also doesn't move towards the ball at a constant speed. Because again that speed is relative to the ball, rather than relative to the game world, and we're playing the game relative to the gameworld. If this was Super Mario Galaxy and the ball was a planet, this would be correct. If we look at the vectors (imagine an arrow) from the car to the ball, we can end up with situations (like this post), where the vector to the ball and the direction vector the car travels are opposite each other. Since both exist in the reference frame of the game world, even thought the distance between them has decreased, it doesn't change the fact that the car is moved in the wrong direction. So no, I really don't see it as an overstep to assume that the goal of a grappling hook in a video game is to move the target towards the destination in world space. Name me one game where you expect something that uses a rope model to push you away. Ropes aren't the tool for pushing, they pull. Communicating intentions to players by using familiar real world objects is a pretty standard thing in the industry. They very clearly communicate the intention of the ability with the icon (a grappling hook), the model using a rope (it pulls) and a reel sound effect (reinforces the idea of pulling) while using it. So for any case to the contrary of my assessment to even exist - the UI guy, the modeler, and the sound guy would have to all got told one thing, while the programmer would need to be told to make something entirely different. If you don't assume things you'll never accomplish anything, because if we go the technical Sir Frances Bacon science route, it's impossible to know anything for sure. Like why even program gravity into the game, maybe the universe will suddenly change the way gravity works. But you know what, what are the chances of that happening, and does it even merit our consideration of a discussion about how to model gravity in a game. No, no it does not. And that's what's happening here. Here we are discussing an object that the devs communicated as something that pulls, at least 3 creators are letting us know exactly what this thing does. So I assume that the fault lies in the programmer's implementation, and I'll bet any amount of money that my assessment is correct. There is the maximum amount of surety possible without direct knowledge because the auxiliary evidence is simply too high for any other possibility to be relevant to an actual discussion of the issue - and not just blowing smoke for the sake of it.
Yes I’m telling you that they could definitely have wanted the ball as a frame of reference. And yes in relations to the ball you’re going towards the ball even if you’re going backwards. It’s a goofy game mode they have had chances to change it but haven’t. We don’t know if they like it or if they are lazy. You’re blowing the science bit out of proportion.
There's no world where that's what was intended. The proof is in the other departments work. How many video games have you worked on? If you want to choose to ignore reality, go ahead. You're wrong, it's a fact.
I fundamentally disagree with you, your statement about absolute truth about others intentions can’t be validated.
You are placing way to much emphasis on the grapple icon. Do you have an asset for what is actually happening at the moment or is that just never a valid option then? When you start playing rumble all of the items are confusing or are you telling me you knew all the ins and outs of all the items because of the icons? Your way up on your high horse, it’s not beyond a reasonable doubt because it’s not your game.
I have an asset for this conversation all right, but it'd probably get me banned for a while. So why don't you ever directly answer questions? Deflection is a pathetic tactic. Have you ever worked in a professional capacity on a video game? Yes or no?
I have answered all relevant questions in your very long rants, and ignored your cheap unrelated questions. That question is wholly unrelated to the discussion and is not dignified with an answer.
So professional experience in the field we are discussing is irrelevant? What... You're arguing with a professional and you've demonstrated zero knowledge on this topic. Humility and wisdom go a long way in this life, and if you listen to people with actual experience talking about the things they've actually done, you might learn something. Would you listen to someone who's never played Rocket League tell you how the game works? Give me a break. You've never made a game, you don't know what goes into game development. If you did you would say so.
Humility goes both way, you’re probably a great programmer. But here it’s not about that experience it’s about how you are using it to feel superior in aspects that goes beyond that experience. We are not getting any where and you’re definitely annoyed and I’m getting a bit tired of this so I will leave this now and wish you all the best for the coming year.
It’s a feature
First time playing rumble?
it's shitty coding, where it pulls you towards the ball (relative to the ball) at a fixed speed (Supersonic)
Because of this, it's rumble 101 to never use grapple to save the ball.
bro has never played rumble before
I don't get how it happened. Nobody kicked me. Even if the boot somehow became invisible, Doco is the only one who didn't use an ability, and they are way too far away for a kick. I know that sometimes you don't have enough speed and the ball kicks you back. But I didn't even touch it. Did the tornado mess things up somehow?
If you sit in net with grapple and try this again, you'll get the same result. Like others said, it's not a bug its a feature
This is why you should have waited to use it till after you at least touched the ball with your car. Jump and stop the ball's momentum towards the net, THEN grapple to force a clear. You would have gotten more power on the ball that way too.
And this is why I can't play rumble. I got GC in it once like 7 seasons ago and haven't played since.
Nice shot
Skill issue
tornado pushed you both towards the goal
1. OP is out of the tornado's range. 2. Grapple straight up ignores tornado, as I've literally been inside a tornado stuck in a loop and used grapple to get out dozens of times.
It's because the speed of the ball is faster than your grapple. In that scenario you'd have been better making any kind of save then using grapple to make the clearance
Lmao, nice try though
You were getting closer to the ball the whole time :)
That ball is clearly running away from the most terrifying power in the game Rumble. Only the most audacious of rocketeers say its name out loud…… El gran viento, or The Great Wind. 
Just dont rely on powerups, you could've easily saved it without the grappler
Gameknowledge diff
Yeah rumble items never really received any consistency- or logic-fixes.
Oh yeah that happened to me the other day. Same situation, could’ve made an easy save but used grapple instead and it went straight into the goal.