How to stop the pawn exactly where I want? (Tick problem in behavior tree services)

Development Programming & Scripting AI
, , ,
1

I want to stop the pawn exactly at a certain distance (on the red line).
But checks happen every tick. So always stop at the next tick.
The distance is always greater than desired (Sometimes too big).

ServicesAndDistances
ServicesAndDistances964Ă—299 1.94 KB

The error depends on the speed of the pawn and the time interval of the tick.
If the tick time interval is smaller, it compromises performance.
If the pawn speed is smaller it is not realistic.

That is why I am asking.
Is there any trick to getting the pawn to stop in exactly the right place?
Thank you so much!!

1 Like
2

Hi,have you tried playing around with these settings?
image
(they’re in floating pawn movement component).
Ai move to is not gonna 100% precise anyways.if the acceptance is too low it sometimes jittery at the end.perhaps setting it’s location directly at the end is a workaround?

1 Like
3

Hi @baobao4435
Thanks for your reply.
I have been trying to modify those parameters and I have seen no difference.
Maybe it’s because of what I’m trying to do… it’s not the default behavior it’s supposed to have.

Jump
Jump964Ă—293 1.62 KB

The pawn is trying to get from point A to point B
But in the middle there is no ground.
If he does not stop at point X he will fall into the void.
In fact I want it to jump from point X to point Y.

Then you might wonder why I don’t use a Nav Link Proxy…
It is because Nav Link Proxy is not working here because the ground is moving.

So I have a task that moves the pawn from point A to point B (I don’t want to abort the task). I just want to stop the movement immediately and launch the pawn from point X to point Y. (that’s why I’m using a service and not a task)…

I’m trying to get the check done on the previous tick. (Maybe it will work)

I’m trying something like this:
JumpDeltaDistance = PawnVelocity*DeltaSeconds + JumpDistance;

It seems to work better than before but it still fails many times.

More ideas are welcome :upside_down_face:

Thank you very much for your help @baobao4435 !! :heart:

4

It seems that increasing the FPS a little helps a lot.

I was using 30 FPS (until today it was enough for me)… I increased it to 35 FPS and it seems that the pawn is able to stop in time most times.

I thought that the service ticks were synchronous since by default they have an interval of 0.5 seconds. So, I still don’t understand why this happened.

1 Like
5

congratulations you found a solution.
I don’t know the movement implementation,why it falls…”Ai move to“ doesn’t fall in my experience,it tends to find a reachable way to go.but my experience in UE is limited ,:smiley: .
if you post the movement/service BP,other more skilled people may help.

6

It has an easy explanation.
What I did was “hack the navigation mesh”…
I put a collisionless mesh over the hole.
Only the vehicle collision is activated.
So the path finding system works.
The shortest path to get from point A to point B is above the hole.

To prevent it from falling into the void, you just have to stop the pawn immediately.
And launch it to the other side.
The condition is very simple too. From a mathematical point of view it should not fail.

       float JumpDistance = 100.0f;
       float JumpDeltaDistance = PawnVelocity*DeltaSeconds + JumpDistance;

	if (FVector2d::Distance(PawnLocation, BorderLocation) < JumpDeltaDistance)
	{
	     CharacterMovement->StopMovementImmediately();
	     Character->LaunchCharacter(VelocityInDirection, true, true);		
	}

Theoretically simple.
The only difficulty is to stop the pawn before it falls into the void.

Increasing the FPS helped a lot… also decreasing the tick interval from 0.5 to 0.25 seconds helps.

However, it continues to fail sometimes.

I’m starting to think that achieving precision/accuracy in this is not going to be possible.
Maybe it’s a good idea to work with the understanding that error is inevitable.

In that case, to prevent it from falling into the void, the distance would have to be increased knowing that between two ticks the pawn would be able to move a maximum distance.

But that could cause the pawn to have to make exaggeratedly large jumps.

In my case it is calculated that the error can be (±)1.5 meters. So in the worst case it must jump 3 meters plus the length of the hole… It seems unrealistic and exaggerated.

Something like this: :rofl: :rofl: :rofl:

1 Like
7

this is brilliant.I collected the trick. :grin:
I don’t know CPP :joy: .
But hi,how about use a collision box to trigger the jumping?


character jump function:
image
image1527Ă—779 197 KB

1 Like
8

Yes, that is the best solution when the ground does not move.
You could even have used a Smart NavLinkProxy.
But that doesn’t work if the ground moves.
The pawn must wait until the ground is in the correct position.
I’m using a ray to check the path.
But the ray only works every 0.25 seconds.
That’s the Achilles’ heel, all checks are every 0.25 seconds.
That’s why it fails sometimes.

Thank you very much for your help!! :heart:

1 Like
9

then make it check every tick.don’t set delay for it :grin:.especially your using CPP.that’s not a performance issue to me.

1 Like
10

It’s a big performance problem.
The lag is horrible.
It’s impossible to play like this…
Even more so when it is a multiplayer game.
Look at the statistics graph (it almost exploded).
I used 120FPS by default and the stuttering was brutal. I only got 10FPS.
I think every tick is not an option.

1 Like
11

that’s…unexpected.a single line trace costed so much? I hope you don’t blame on me giving bad advice…

12

I’m not sure… I think it affected the entire behavior tree…
Actually each tick depends on frame rate.
For 30FPS one tick is 0.033 seconds
For 60FPS one tick is 0.016 seconds
For 120FPS one tick is 0.008 seconds
I think the behavior tree services are not designed to work this way.

I’ve actually done some things to the actors’ OnTick function and it doesn’t affect performance as negatively as this.

Your help is greatly appreciated…if you didn’t tell me I would never have tried it. :heart:

13

I’m sorry, you’re right.
I tried with an interval of 0.008 seconds and nothing happened.
I think the screen recording program caused the the lag. :rofl: :rofl: :rofl:
In fact, it seems to work…
I will continue trying larger and larger intervals until I get an optimal interval… it really does affect performance, but it is not as brutal as it seemed…

At the end of the day your idea was good!! :heart: :heart: :heart:

1 Like
14

you were scaring me. :joy: .IMO condition checking should happen every tick when it related to movement.
those melee combat game.when they swing the sword,even line trace every frame is not enough.because when the user’s computer has less frame rate,the trace becomes unreliable.they have to trace multiple times in a single frame…

1 Like
15

I think I have got it.

It seems that if it does 15 checks per second it never fails (an interval of 0.066 seconds).
I would like to be sure that this happen on other computers too.

On the other hand seems performance depends on FPS…
A task may cause lag at 30FPS… but the same task at 120FPS does not cause lag.
So it’s hard to know if the task is really expensive or not…

Well, it seems to work.

What do you think?

1 Like
16

I think 15 times is not enough…I would set intervals to 0.but you tested it out it has no problem ,then keep it :grin: .

I guess it’s probably something else causing the lag…sometimes restart the engine may help…because the task doesn’t seem to be heavy.(a bunch for loop in tick is real considered heavy).

1 Like
17

OK, I’ll keep an eye on it. If I see problems I will reduce it. Otherwise I’ll leave it like that. I really want to compromise performance as little as possible.

Spawn projectiles cause very brief lag. Especially if they have particle systems attached. It is most notable in the middle of a great battle. You can see many thin mountains on the performance chart.

Another problem with projectiles is when I start the engine for the first time… I don’t see the first shot or I only see the gray mesh of the sphere. The second shot looks correct. This also happens in standalone. I know it happens because it is not loaded in memory. But… what can I do?
Maybe I need to shoot in background while loading screen? :rofl: :rofl:
If I have to fire all the weapons before the game starts it’s going to be a pain…
Surely there is a more effective method that I don’t know about.
If you know it, please let me know.

Thank you so much!! :heart:

1 Like
18

forgot to accept your solution…
Thank you very much for your help!!
Much appreciated!! :heart:

1 Like
19

no worries bro,I didn’t help much,you solved your problem.

I don’t know about this.but I guess it’s probably the assets haven’t been baked.I met it sometimes but didn’t pay much attention on it.
you could try to package the project so it bake everything automatically.but you’ll have to choose a good time to experiment with so.because it takes pretty much time packaging :smiley: .
and the particles.I like to disable their light effects (if they have).a lot of particles from market place have light effects. disabling the light increases pretty much performance to me. but all depends on ones needs,aesthetic, etc :grin:

1 Like
20

Thanks for the advice.
I still have not control over these matters.
I have noticed that lights, reflections, shadows and especially fog consume a lot of resources.
I have all that disabled… my graphics card is not capable of processing all that.
I made the particle systems myself. They certainly have many emissive materials.
But I can’t deactivate them… they are the life of the party… without them everything would be very boring.

I’m going to investigate baking in Unreal… I’ve used it in Blender but never in Unreal… I’ve been too busy with programming… new problems appear every day…

Right now my abilities system just broke (I didn’t touch anything).
That’s why I use C++… blueprints has too many problems.
I guess I’m just not going to use the abilities system anyway. I think it’s unnecessarily complicated.

Thanks for the tips bro!! :heart:

1 Like