It has a very simple AddMovementInput added to it. It worked prior to 4.7
However, today I discovered it’s no longer working.
I believe this is a bug, otherwise it should be in the changelog. Which I scanned and found nothing.
I was able to reproduce this, so I have entered it as JIRA UE-13140 in our tracking software. Our developers will be investigating it further and we will post back here with updates.
As far as your code question, I’m unsure if that function is the direct cause of the issue at this time but it sounds like it maybe possible.
I’m on the fence here. I’m terribly sorry I’ve broken your code, but it was conceptually wrong (because the engine allowed it). The thing is you’re trying to control an AI-driven entity with fake player input - that’s what this boils down to anyway.
The change I did was required to allow floating movement component follow navigation paths.
Tell me more about your use-case. Do you really need an AI controller with that floating pawn? Not spawning the AI controller won’t help, since the code you’ve mentioned will bail out even sooner, but will give me a reference point.
I see what you mean. You’re saying the engine should never allowed this in the first place.
There’s actually no particular reason why I ‘need’ this. It’s just so happen way I did it. And that’s because I tested it with Player Controller and then I moved on to allow AI to use it.
What I did was a helicopter control AI. I merely interpolate the direction of the InputVector towards the goal to create a small sway in turning and then proceed to do a waypoint like system to get the helicopter to move from point to point.
I use floatingpawncomponent because I couldn’t find any movement component in blueprint except for Projectile MovementComponent . I used Projectile Component previously but I have to force the movement manually. Then I found out DefaultPawn has a floatingmovement component which is slightly better.
If this is the direction of the Engine then I would understand , maybe you can give me some advice on a better way to do it.
Ideally you’d derive a movement component class from UFloatingPawnMovement and hack-out the details you don’t like. But I think it would make sense to be a bit more forgiving in the mechanism I’ve implemented. The only reason I did this was to not have “input” override pathfollowing calculations. But what if I disabled the mechanism if AI is not following a path at the moment? Of course optionally!
Actually this is good. Sorry for not replying earlier. was swamped with some other work.
I’d like to add that the reason we’re using Input is because we want to standardize the movement of the vehicle when player is controlling it and when AI is controlling it. We find it easier to control in this manner.
So what you add might be useful down the road. Thank you very much.