breakout_et_b2 navigation

[TomTom]

Could it be that I am just too fast? We should try it after 1 minute+. If it proves that a short delay lets the bots get to defensive positions then creating a one-time removable barrier could slow the humans down. TBD.

[enigma1]

Hi Tom, one other thing if you recall I used a teleport on this map to get around the bots getting stuck in the tunnel entrance. When I placed waypoints for the darji2 I noticed the node radius alters the bot's movement. If you have a node radius of 5 say the bot will crouch. Is there some info about it? I mean if we set it to 1, will a bot prone? Or using a combination of nodes?

In any case I will leave the teleport there for the time being but if I figure some other way to change it I will.

Thanks
CK-Chaos

[TomTom]

AFAIK the radius is not a behavior flag. The bots will crouch on their own but the placement of the first node inside a duct or low tunnel will influence the success rate. A large radius could be detrimental in that the bot satisfies the navigation step too early before crouching. Another thing to try is tweaking the node lower to the floor and using the walk flag so the bot does not jump going in. Also align the preceding node so the bot goes straight in not clipping the sides.

In general Avoid node radii smaller than 10. It could adversely affect navigation success rates, make the bots look like bots and could trap/delay the bots affecting game play or balance.

Getting the bots to go prone might be possible with a roam with the prone flag but of course that only works if the bot had the roam as its chosen action. Now you can put two disconnected nodes on top of each other for the path away from the roam but in this case it would not work.

[enigma1]

yes I tried already the nodes beneath the ground but at least the combinations I made did not reliably worked. The bots will sometimes pass through sometimes not. I got it in one case - the best case - where the bots will get through but with a delay and several attempts. And if 2 bots were in things again would be unreliable.

Ideally, the prone flag should reference the node not the action.

[TomTom]

These difficult navigations I find fun, but often do them in isolated tests first before proceeding to the full project (northpole had at least 4 special cases to do before committing to finish the waypoint). The use of the prone flag via actions is not ideal but in Northpole I was able to use it via an Alt-roam inside the cannon. That worked because the cannon was a longer path so the bots really only accessed the cannon by the route system. In your case the sewer is the natural shorter path so bots will chose it in ways you can not control by routing to an alt-roam. I guess the teleport is the best way, though if you get the bots to crouch you might shift its trigger point to inside the sewer.

I agree that nodes should also have independently a crouch and prone flag to handle a few special cases like keeping under cover. I added in the wiki's FritzBuglist_ET a requested:new functionality sub-section for ideas like this. If you have a well thought out case feel free to add something on new behavior flags for navigation nodes. Bobots as I recall used different types of connection wires for some of its bots behavior.

[enigma1]

I just investigated a bit more about the dynamite/defuse problems.

The defuse problem is actually a bug it happens to me on warbell. When the defending team defuses a dynamite and the game doesn't say dynamite defused. The defending teams engineers will just run straight to the dynamite action and stand there and the attacking teams engineers just use camp and roam actions.

If you want to quickly see what happens was described briefly earlier but here are the steps to reproduce the issue.

1. Load map bettery add a single ally eng bot to make things easier.
2. Join the ally team as an engineer and start the map
3. Follow the bot will construct the ramp and then head towards the gun controls
4. Let him plant do not fully defuse till the last 5 secs. You should fully defuse when the bot walks away (does it the last 5 secs to avoid damage).

5. There are 3 actions linked for the plants so repeat step-4, he will plant just 3 times alltogether and you need to defuse the last 5 secs as explained.

Ok now there is a fix at least as much I tested it works every time.
1. Edit the map's waypoints change actions 74,75,9 to be active forever (1).
2. Remove the linked actions from actions 74,75, 9 so the all links are -1 ie the actions aren't linked together.

And that should be it. The engineer will plant again no matter when you defuse or how many times you defuse the dynamite.

Also if during regular gameplay the dynamite actions aren't processed for some reason check the goal tracker. As Tom mentioned earlier all actions are best to be active forever to get around the goal tracker issues.

[TomTom]

Ok in a wholly new map I have confirmed your last 5 seconds defuse bug (using keyword-fix beta but I think the bug goes way back).

However your apparent fix can be explained differently. When the entity changes state to destroyed (killed) FritzBot searches for a single action with the same toi entity number then updates that action and triggers its aiscript test block. For dynamite actions it then checks if any other actions are linked and updates/triggers them. By not linking the actions and setting them active 1 the other dynamite actions are not updated and therefore remain Active till the map ends or until the aiscript deactivates them. This is similar to using regular dynamites where major_construct_plants should be used. (The type mismatch means the aiscript has to provide the activate/deactivate control explicitly.) Now if the de-linked actions were not active forever then the extra dynamites might lose focus if the goaltracker increments twice, but in aiscript method that still could be the rest of the map (depending on map and waypoints).

I think your idea is an interesting workaround, but until I evaluate the defuse behavior I would suggest linking all or all but one. If the defuse behavior suffers then the unlinked dynamite action might need to be located in the same space as a linked one. And of course the aiscript must deactivate the unlinked actions when the entity is blown. And to avoid having to test which action gets updated you can use the event_explode set to the func_explosive targeted by the entitiy's toi.

[enigma1]

Hi Tom, thanks for taking the time to investigate this. I also tried placing different dynamite actions around the same toi (unlinked). hobbit's editor complains about it and also when I tested it the allied engineer could place the dynamite using one action spot while the axis engineer would go to a different action spot because they were unlinked but point to the same toi I think. We could use different tois one for each action but I am not sure it worths the resource expense.

CK-Chaos

[TomTom]

BTW I still have not confirmed that the engineers act the same way re:the 5 second bug if the opposite team defuses. This may just be because the planting engineers switch to fight mode and don't invoke their self-preservation behavior.

The defuse action to the locked up situation (defuse your own team's dyno in the last 5 seconds, get your team spamming no valid goals or equivalent then add engrs to the defusing team (respawn at 1sec)) looks like they also believe dynamite is planted and will go to the actions and wait. Now if I plant another dyno at one of the locked up actions the defusing engineer will defuse and that resets the lockup and the planting team goes back to plant.

Now I have not tested defuse at de-linked actions, but the going to the wrong defuse point I have observed in linked cases. This was a problem I found in 2hide and caha_tavern. The defusing engrs go to one of the actions and if they don't see the dynamite they just stay there. Now in each map I was linking in defuse only actions to cover human plants out of sequence or placement, and I found that is a problem in other ways, so I should go back and check if the poor defuse search behavior is also related. (And no, defuse only actions don't work. alas).

[enigma1]

Hi Tom, regarding the opposite team defuse I have seen it happening. Seems to me the team is not a factor for the defuse action but of course only Mal could tell for sure.

It's just harder to replicate it with bots as they need to defuse the last 5 seconds and with 3 linked actions is quite hard to emulate. Using straight gameplay at least.

With the test map I did where I also have the cvops alt roam issue, I ended up setting a single action for the dynamite plant and it works reliably. I changed the other previously linked actions to do something else.

CK-Chaos