Jump to content

Weird 'hold' command behaviour


Recommended Posts

Ran into some trouble in my mission to get units to stop and move using triggers. So i setup some test missions to see whats going on.

 

Setup: set a group of 4 bradleys with a hold command on the spawn point, and prepared a triggered action 'move to waypoint 1', and a second triggered action  to move them to waypoint 2.

After that,  i setup a trigger after 10 seconds, to trigger the action to waypoint 1, to set them on their way, and a second trigger after 2.5 minutes to send them to waypoint 2.

 

Result: they start moving to the steerpoint 1 after 10 seconds, and at the steerpoint they stop again. (no hold command is present at that waypoint)

after 2.5 minutes, the second action is triggered, and they start moving to steerpoint 2, but they never get there. they stop somewhere halfway there, move like confused ants, and then stop. Somehow, the hold command screws up any subsequent move commands if it is not cancelled.

 

My expectation would be that a 'move to waypoint' command, would auto cancel any hold command given. As you can see, they do actually ignore the hold command and move to the waypoint and then stop again. Now this would be fine except for the second waypoint, wich gave a different result, and makes the group end up at a seemingly random position.

 

The only way i am able to achieve the result i want, is to introduce stop conditions to the hold command using flags, and give hold commands at each steerpoints with different stop flags. Not exactly elegant is it?

 

I dont know if this new 'buggy' behaviour, or by design, but imho any movement command should auto cancel the hold command until a new hold is encountered by the group.

 

now here's the kicker:

 

If i plan all this with the default speed of the bradley (11kts), the group actually makes is to the steerpoint i send them to (either 1 or 2) . However if i set a max speed for the waypoints (36 kts), i get the weird behaviour of them stopping halfway. 

 

What is going on here?

 

Hold command 11kts.miz Hold command 36kts.miz

Link to comment
Share on other sites

Their first task (that youve given them) is hold, Then youve given them two triggered actions that say 'they should only ignore their 'hold task' if a trigger action is commanded'. So your orders for the Bradley- Is hold. Youve not told them to do anything else.
Its like going to a shop and being ordered to buy sliced bread- They wont buy unsliced bread, unless you give them a trigger action.

Youve given them only two triggered actions, which they follow twice- Then they hold, as youve tasked them to do..
They are following your orders.

So every time they reach a waypoint, they are Holding, because youve not told them to do anything else.

You need a 'Hold' Task to have a stop condition 'On Flag/Timer', So that when you trigger a flag, they ignore your 'hold' command and move onto the next task you give them (Switch Waypoint) and work upon their own initiative after a certain amount of time..

Note the new task after hold has a stop condition of 15 minutes..
I then tell them to 'carry onto the next waypoint'..
 


image.pngimage.png

 

 

 

 

Hold command 11kts.miz


Edited by StevanJ
Upload new mission with a new task after 'HOLD' had a 15 minute 'Stop Condition'
Link to comment
Share on other sites

7 minutes ago, nighteyes2017 said:

If you read my post carefully, i already concluded that the hold task should have a stop condition. I get it. But that still does NOT explain why they stop halfway to a waypoint.


They didnt do that on mine.. They made it to the second waypoint.
Try a reinstall x

Link to comment
Share on other sites

24 minutes ago, nighteyes2017 said:

did you try both missions? because i get different results on both missions. the 11 kts works, the 36 kts does not. the bradleys stop halfway to the second waypoint.


So, tried both- Both missions do the same thing, both hold just short of waypoint 1, UNLESS you HAVE another task after the hold command and offer them a 'hold' stop condition.
Youre current task list, makes your tanks prioritise time. They'll hold short until they get the 'nod' to carry on from the clock. They arent getting the nod to carry on and are holding as a priority before they hit any of their waypoints.

If you change the triggers to 'waypoint' tasks, they'll prioritise hitting waypoints first.

If you ever need proof that they are hitting their waypoint. Put a 'switch waypoint 4' task, on waypoint 1- That way youll know if they do or dont hit (what they assume is) their waypoint.

When I deleted the group and all your triggers, started again, and tried to change your ME parameters to actual Waypoint Tasks and not a 'task Push', I had 0 issues.
ie 'Hold' stop condition at 0 (10 Seconds), then 'Hold' at 1 stop condition (150 seconds), they hit their waypoint bang on every time..
 



I dont think its an ME bug- and If you feel that you arent happy with their pathfinding, report the bug with a track here..
However, as you can see, if i give them a straight forward set of orders with proper stop conditions, they hit waypoint parameters (a waypoint task trigger verifies this).


If you would rather do things your way- an extra task, sets them on their way.

Alternatively as you can see in the video above, giving them orders in a correct priority list, theyll do exactly what you want them to do, and hit every waypoint to within mm's..
I hope that helps you?

Hold command 11kts.miz EasyTriggers.trk

Link to comment
Share on other sites

Well thanks for the extensive testing. I appreciate the help. I know there are different ways to get them to do what you want to. I understand how to use the triggers, so no need to explain that.  The way i had set them up is NOT how i would normally do this, and my point is not about that.  Its just a quick and dirty setup to show the problem here. It is NOT, about how to set them up. 

 

As i said, i am getting different results with the 36 kts mission from the first post. You say both missions hold short at waypoint 1. that is not, how i set it up. I have setup up a second timed trigger that activates after 2.5 minutes. (again, not how i normally do this, its just a way to demonstrate the problem). So both missions should end up at waypoint 2, and not waypoint 1. the 11 kts does this just fine. The 36 kts does not (at least, not in my case). 

i recorded what happens here. this is a video of what happens in the 36kts mission from the first post. I time accelerated it. watch the timer in the upper right corner.

 

1) after 10 seconds. the command is given to waypoint 1. They go there and wait (as the should because the hold is still active. yes i know)

2) after 2.5 minutes, the second command is given to waypoint 2. You can see them heading for it, but halfway there, they just stop. and this is the problem.

 

again, its not about how to get them there. I can think of 3 way to do the same setup. But they should not stop halfway, even with this setup.

the ONLY difference with the 11 kts version is the speed i set for the group, and in the 11 kts version they get to waypoint 2 just fine. 

 

So why does a difference in speed cause them to stop halfway?
 

 

 

Link to comment
Share on other sites

50 minutes ago, nighteyes2017 said:

Well thanks for the extensive testing. I appreciate the help. I know there are different ways to get them to do what you want to. I understand how to use the triggers, so no need to explain that.  The way i had set them up is NOT how i would normally do this, and my point is not about that.  Its just a quick and dirty setup to show the problem here. It is NOT, about how to set them up. 

 

As i said, i am getting different results with the 36 kts mission from the first post. You say both missions hold short at waypoint 1. that is not, how i set it up. I have setup up a second timed trigger that activates after 2.5 minutes. (again, not how i normally do this, its just a way to demonstrate the problem). So both missions should end up at waypoint 2, and not waypoint 1. the 11 kts does this just fine. The 36 kts does not (at least, not in my case). 

i recorded what happens here. this is a video of what happens in the 36kts mission from the first post. I time accelerated it. watch the timer in the upper right corner.

 

1) after 10 seconds. the command is given to waypoint 1. They go there and wait (as the should because the hold is still active. yes i know)

2) after 2.5 minutes, the second command is given to waypoint 2. You can see them heading for it, but halfway there, they just stop. and this is the problem.

 

again, its not about how to get them there. I can think of 3 way to do the same setup. But they should not stop halfway, even with this setup.

the ONLY difference with the 11 kts version is the speed i set for the group, and in the 11 kts version they get to waypoint 2 just fine. 

 

So why does a difference in speed cause them to stop halfway?
 

 

 


I understand, There is a 'Priority System' for tasks.

Their instructions by your orders:
1 Hold until trigger 1 (time more than 10) then move to waypoint 1.

2 Hold until trigger 2 (time more than 150) then move to waypoint 2.
They do this-

The minute you give the AI 'triggered Actions' Thats you saying to them- Do this and await my list of triggers..
They will do the minimum, to achieve the tasks you want them to do.
Youve told them to 'Move on trigger', they move each time triggered, and only stop when they feel like they have met the parameters of the waypoint.

Im guessing that they believe they have reached the Waypoint (despite them falling short), This can be verified by a 'switch waypoint task' on the waypoint.

The 'speed lag' is a by-product of the waypoint system. If youd given the same order to a Ship, it would probably stop in the same spot, the only difference is the bradley has a better braking system. Its travelling faster, Therefore it feels it needs a bigger breaking distance. Silly i know, but more likely. The AI havent been programmed to not be erratic..
SEE HERE

Its the same with the warbirds when moving from waypoint to waypoint, you ask them to turn left gently, and they aggressively pull 9'gs.

Link to comment
Share on other sites

Braking distance. now there's an idea. That could be it. Dont have time to test that today however.

 

So if that is the case, then different units, would stop short of the actual steerpoint based on their speed and needed stopping distance. As a workaround, i could place 2 steerpoints at the same spot and see what that does.

 

will test it tonight.

 

that would still classify as a bug to me though 😉

Link to comment
Share on other sites

2 hours ago, nighteyes2017 said:

Braking distance. now there's an idea. That could be it. Dont have time to test that today however.

 

So if that is the case, then different units, would stop short of the actual steerpoint based on their speed and needed stopping distance. As a workaround, i could place 2 steerpoints at the same spot and see what that does.

 

will test it tonight.

 

that would still classify as a bug to me though 😉


Yeah, I hear you.

Its REALLY silly, because if you move your triggered actions to waypoint 3, they drive through waypoint 1 perfectly and hold short of the next waypoint if at speed.
Unless you follow the manual to the mark, the AI wont do what you want them to im afraid.

Link to comment
Share on other sites

Ok, so i've done some further testing. I put waypoint 2 further away in the 36 kts version. They stop the same distance away. So not halfway, but the same distance as the first time. So yeah, definitely something to do with stopping too early because they think they need the distance to stop. 

 

However they did not actually think they got to the waypoint itself. I added a command to waypoint 2, to see if it gets executed when they stop. It didnt. No matter wich command i added to steerpoint 2 (switch, fire at point) gets executed. So apart from them stopping too early, they dont actually seem to think they got to the waypoint. So the moment they start braking, is not the moment at wich they look at the commandlist for that waypoint.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...