x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

[4.8 preview 2] Confusing bug with floating pawn movement components velocity

This is a very strange issue I've found and I don't quite understand how it works, but basically for my character/enemy movements I've added a floating pawn movement component to them via blueprint, and set its velocity. This works completely for my player, however for the enemies it has stopped working in Preview 2 (It worked in 4.7 in PIE but didn't work in shipped, which I had hoped would be fixed in 4.8). Now they only seem to have velocity when attacking (which I have separately as a lerped value - http://i.gyazo.com/d96ee7a98fd19ccf9016a3f414833e96.png). Even just directly setting the velocity doesn't work, it only works with that specific setup when the lerp value is 1 and they have their attack vector instead of their movement vector. And again there is no issue with the player character-even in the 4.7 shipped version (both my player and my enemies are all pawns).

Product Version: Not Selected
Tags:
more ▼

asked May 13 '15 at 03:04 AM in Bug Reports

avatar image

SwiftIllusion
247 23 30 33

avatar image Adam Davis STAFF May 13 '15 at 02:49 PM

Hi SwiftIllusion,

What are the settings you are using for your pawn movement? Additionally can you show me how you are setting up your movement in your event graph? Thank you!

avatar image SwiftIllusion May 14 '15 at 12:59 AM

While going to take screenshots of the differences between the player pawns 'floating pawn movement' and the enemies 'floating pawn movement', which I had thought were the same, I was able to discover the core problem.
When trying to add the attack for the enemy-which moved it faster than its walking speed, I found that the 'max speed' value capped its speed regardless of the velocity I had set, so I changed all those values around-including the Deceleration value-which is where the issue lies.
In 4.7 Deceleration doesn't effect it at all, but it seems it does reduce what velocity is sent to the 'floating pawn movement' component in 4.8. With Deceleration set to 8000 even settings its velocity to "300,300,0" it still looks like its at a standstill. If you increase that velocity to 500 though without a direct comparison you could mistake it to have not been effected at all (my enemies attack movement speed just happened to get over the bump of the Deceleration-which is why it seemed so confusing).
I'm not sure if this an intentional change, but to reproduce this possible issue just add a floating pawn movement component to anything with 10000 deceleration (the acceleration doesn't seem to affect it) and play with the velocity you set it to-it will barely move at 400 but will start moving more above 500.

avatar image Adam Davis STAFF May 15 '15 at 03:36 PM

Hi SwiftIllusion,

I just wanted to check for some clarification. Is this error no longer occurring after utilizing the Deceleration data? If I'm reading this correctly the deceleration feature is now working which is what caused the complication. If this is the case, I will go ahead and mark this as answered for tracking purposes.

avatar image SwiftIllusion May 15 '15 at 03:53 PM

Sorry the Deceleration is not the solution, but the problem that was found.
When setting the velocity directly (not using 'add input vector') the acceleration/deceleration should be ignored, like it is in 4.7. However in 4.8 the deceleration is somehow overriding the velocity that is being set on the 'floating pawn movement' component and reducing its speed (so that even when velocity is set to 400, if you have 10000 deceleration it will almost look like it's at a standstill-where in 4.7 it would be moving correctly at a velocity of 400)..

avatar image Adam Davis STAFF May 18 '15 at 07:27 PM

Hi SwifIllusion,

Do you have a screenshot of the blueprint you are using this functionality on? Can you send me a screenshot of your eventgraph so I can try to reproduce this as closely as possible?

avatar image SwiftIllusion May 19 '15 at 07:51 AM

I was able to create a demonstration scene which will hopefully help best.
https://www.dropbox.com/s/d0zqg7rvdq52ddj/TestFloatVelocity.zip?dl=0
That's made in 4.7. The BP_VelocityPawn object has parameters exposed 'Velocity/Acceleration/Deceleration'. The pawn in the scene on the left has 15k deceleration, the pawn on the right has 0 deceleration. In 4.7 you can see they both move at the same speed by using left/right/up/down after pressing play. If you open that in a copy in 4.8, you'll see the pawn on the left with 15k deceleration barely moves while the pawn on the right moves freely.
I'm not sure if this is an intended change, however it doesn't personally make sense when setting the velocity directly for deceleration to affect the pawns speed.

(comments are locked)
10|2000 characters needed characters left

1 answer: sort voted first

Hi SwiftIllusion,

I saw what you are experiencing, however after looking into your blueprints in this project I believe the problem lies with the blueprint setup as opposed to trouble with the deceleration in the floating pawn movement. Testing it separately it seems to be working as intended, however with the setup you are currently using the deceleration is used as an additive instead of multiplicative force, so it adds the negative value to your movement every tick. As such, it is determining that every tick needs to accelerate then decelerate, which causes the movement of one pawn to decelerate over the other which has a 0.0 deceleration.

more ▼

answered May 19 '15 at 03:27 PM

avatar image SwiftIllusion May 19 '15 at 03:56 PM

Sorry but I think you must be misinterpreting the blueprint as that's definitely not what I'm doing.
http://i.gyazo.com/c42f9d14e64f8ea18e2f37491bdf943b.png
On begin play I add the floating movement pawn, then I get the acceleration/deceleration from the exposed acceleration/deceleration parameters on the controlled pawn placed in the scene, and then this opens the gate for the tick tree to set the velocity based on the exposed velocity value of the pawn and your current input.
At no point do I use the acceleration/deceleration anywhere for calculating the velocity, I only have that setup so you can easily change the values per each pawn instance in the scene for testing purposes.

EDIT: Additionally your above assessment doesn't account for why it works perfectly in 4.7 but breaks when it is converted to 4.8

avatar image Adam Davis STAFF May 19 '15 at 05:25 PM

Once floating pawn movement is added the acceleration and deceleration become an immediate factor on force applied, which will affect the velocity of your pawn. The only difference between your setup and one that does what the intended functionality is is how the movement is calculated. You are currently using a testpawn that adds your up and down for your vertical velocity and adds left+right for your horizontal. This then has the acceleration and deceleration applied to it for the total velocity (done behind the scenes in floating pawn movement, may not be directly visible). Try this to see what I mean:

  1. Create new character blueprint

  2. In your input axis, make a moveup and moveright, make up/down keys in moveup, left/right keys in moveright (set 1.0,-1.0 as you have them, you only need the two axis mappings however).

  3. In your character blueprint, create events "input axis moveup" and "input axis moveright"

  4. On each, add an "add movement input" node.

  5. Set moveright to (0,1,0) with the scale as your axis value, do the same to your move up with (1,0,0) on moveup.

  6. Add a floating movement component, set deceleration to 8,000

  7. compile, save, close blueprint, press PIE.

To see the difference in deceleration, change the value to a low number. The lower the number the less deceleration your pawn will have. This is working as intended. Because of the implementation you are using it is simply adding the values every tick instead of multiplying the axis value.

avatar image SwiftIllusion May 19 '15 at 11:31 PM

I'm really sorry but I think again you're misinterpreting what my blueprint is doing.
I don't use the movement input node. I understand that the movement input node will have acceleration/deceleration applied to it behind the scenes for when you increase/decrease the movement input sent to it. However what I am doing is setting the velocity of the movement component directly, ignoring any of that.
To see what I mean in my example change the acceleration value. It has no effect even in 4.8. The only part of the floating pawn movement components setup variables that limit you, at least in 4.7, is the max speed-which will clamp the velocity.
The reason I do it this way is so I can have more finite control over the 'makeshift' acceleration/deceleration myself which I cause by using in my full project an 'finterp to' node with adjustable interp speed. And for some of my enemies attacks that have them move forward or for when my character dashes, I lerp to a velocity scaled by a timeline curve to have further control.
I guess I can just work around the way it changed in 4.8 by going around and changing the deceleration to 0 for everything, I was just concerned it may also be affecting something else I'm unaware of yet and I didn't want to have to wait an entire version for it to be fixed if it could be fixed for 4.8.

avatar image Adam Davis STAFF May 20 '15 at 03:33 PM

I believe the change that occurred is that the floating pawn movement acceleration and deceleration now affect all velocity as opposed to just movement input, which I would expect to be the case. The reason I suggested the movement node was simply to test if the deceleration was properly decelerating movement as intended, which it does seem to be.

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question